Executive Summary
Most economic backstops attached to crypto launches, where they exist at all, are informal — a doxxed team, a verbal commitment — with no enumerated trigger conditions and no defined path getting any recovered funds back to the people actually harmed. ProofGuard replaces that informality with a structured, forfeitable bond: an amount fixed in advance by the project's assessed risk tier, required as a precondition to becoming eligible for liquidity support, and slashable only against a fixed set of objective, enumerated conditions.
When a slash is triggered, the amount is bounded by what remains available on the bond, and the slashed proceeds are directed according to an explicit allocation structure naming the reimbursement recipients and their respective shares — not simply absorbed into an undifferentiated fund. Both posting and slashing are cryptographically anchored into the same tamper-evident, hash-chained evidentiary ledger used across ProofGuard's other controls, giving a slash decision the same durable evidentiary posture as any other verdict record in JIL's attestation infrastructure.
Problem Statement
Reputation-only launch models — a team that has doxxed its identity, or simply "looks legitimate" — carry no economic backstop at all. Where a flat insurance-style fund does exist, it typically has no taxonomy of what actually triggers a payout and no defined mechanism for getting funds to specific harmed parties; recovery, when it happens, is an ad hoc off-chain negotiation with no guaranteed outcome.
Technical Architecture
Enumerated Slash Conditions
A bond may be slashed only against one of ten fixed conditions: fraud, rug pull, misrepresentation, wash trading, collusion, treasury misuse, negligent contract exploit, launch-terms violation, undisclosed related-party trading, and regulatory violation. The condition triggering a given slash is recorded as the event's reason code, not left as free text.
Bond Lifecycle
| Stage | Action | Result |
|---|---|---|
| Requirement | Bond amount fixed by certification risk tier | Bond record created, status REQUIRED |
| Posting | Project posts collateral (cash, stablecoin, native reserve, project reserve, insurance, or founder guarantee) | Status advances to POSTED once posted amount meets requirement |
| Slash evaluation | Slash request against an enumerated condition | Amount capped at posted-minus-already-slashed |
| Allocation | Slashed amount distributed per caller-supplied recipient list | Status: PARTIAL_SLASH or SLASHED |
Structured, Allocation-Directed Reimbursement
Each slash request carries an allocation array identifying one or more recipients and a per-recipient amount. This is what makes the reimbursement structured rather than incidental: the mechanism does not merely remove funds from the offending project, it specifies where those funds go — for example, to identified affected liquidity providers or into a market-integrity reserve — as part of the same atomic operation that records the slash.
Court-Anchored Evidentiary Weight
Both the bond-posting and bond-slash determinations are cryptographically anchored into a tamper-evident, hash-chained ledger before the transaction commits, and this ledger is architected to be forwarded into JIL's dual-independent-anchor hybrid post-quantum attestation infrastructure — the same evidentiary substrate used for the platform's civil-admissible verdict records elsewhere in this filing — so a slash decision carries comparable evidentiary weight to any other JIL attestation.
Prior Art Differentiation
| Approach | Bond Scaled to Risk? | Enumerated Triggers? | Directed Reimbursement? | Anchored Evidence? |
|---|---|---|---|---|
| Doxxed-team-only model | No | No | No | No |
| Flat insurance-style fund | No | No | No | No |
| JIL ProofGuard | Yes | Yes, 10 conditions | Yes | Yes |