Executive Summary
ProofGuard is JIL Sovereign's protected-launch control plane for tokens issued through JIL's DEX AMM — a policy-and-evidence layer that sits alongside the AMM's own execution engine under the operating principle "proof before liquidity." This claim covers ProofGuard's launch control loop: the mechanism that decides, milestone by milestone, whether a launching project ever gets its raised capital and liquidity back.
The loop inverts the standard sequence used by liquidity bootstrap pools and bonding-curve launchpads. Rather than handing proceeds and trading liquidity to the project the moment the sale event ends, ProofGuard routes 100% of raised proceeds, project-side liquidity, and launch liquidity-provider positions into on-platform quarantine accounts at close. From there, capital is released only in scheduled milestones, and each milestone requires two independent conditions to hold at the same moment: an elapsed-time gate, and a continuously recomputed market-integrity risk score at or below a milestone-specific ceiling.
Problem Statement
Liquidity bootstrap pools (the Balancer/Uniswap-style LBP pattern) and bonding-curve launchpads release 100% of raised capital and/or trading liquidity to the project team the instant the sale event ends, with no further checkpoint. Any red flag that surfaces afterward — a wash-trading spike, a coordinated sybil-cluster dump, a sanctions hit against a founding wallet — arrives only after the capital is already gone. Where a lock exists at all, it is typically a single static calendar unlock (an LP-token timer from a locker service), blind to everything that happened between the timer starting and it expiring.
Why Existing Approaches Are Insufficient
- Uniswap/Balancer-style LBPs: Auction mechanics govern price discovery during the sale only; once it closes, proceeds and liquidity are the project's to move immediately.
- Bonding-curve launchpads (pump.fun-style): Liquidity is instantly tradable at graduation with no post-close quarantine or milestone structure at all.
- LP lockers (Unicrypt, Team Finance, PinkSale-style): A single static time-lock on the LP token — a calendar event, not a behavior-conditioned gate, and it says nothing about the project's raised proceeds.
- Third-party risk scanners (GoPlus, Token Sniffer): Produce an advisory score that is not wired into any capital-release enforcement path — a bad score doesn't stop a withdrawal.
Technical Architecture
Close-to-Quarantine Handoff
When a launch's liquidity bootstrap auction closes, the lifecycle engine atomically anchors the close event, then quarantines the total raised proceeds, any project-side liquidity, and the launch LP positions into separate quarantine accounts in a single transaction. The pool transitions LBP_CLOSED → QUARANTINE_ACTIVE only once that quarantine write is confirmed.
Risk-Tier-Selected Release Profiles
The release schedule for the proceeds quarantine is built from one of three predefined profiles, selected by the risk tier assigned during Phase 0 certification (see the certification claim in this filing's Trading & DEX category). Each profile fixes the milestone count, elapsed-day gates, release percentages, and per-milestone risk ceilings in advance — none of it is discretionary at release time.
| Profile | Milestone Days | Release % | Max Risk Score | Manual Approval |
|---|---|---|---|---|
| Normal | 7 / 14 / 30 / 60 | 20 / 20 / 30 / 30 | 40 / 35 / 30 / 25 | No |
| Conservative | 14 / 30 / 60 / 90 | 10 / 15 / 25 / 50 | 35 / 30 / 25 / 20 | Final milestone only |
| High-Risk | 30 / 60 / 90 / 180 | 20 / 30 / 25 / 25 | 20 / 20 / 20 / 20 | All milestones |
Joint Time-and-Score Evaluation at Release Time
A release request is evaluated, in order, against: pool freeze/pause/termination state; milestone status (already released, rejected, or paused blocks the request outright); whether the milestone's elapsed-day gate has been reached, computed from the quarantine start timestamp; whether the pool's current risk score exceeds the milestone's risk ceiling; a set of externally assertable denial flags (sanctions match, cluster abuse, material wash trading, founder-wallet anomaly, treasury misuse, LP manipulation, unresolved contract vulnerability, legal hold, regional-operator objection); and, for milestones flagged as requiring manual approval, whether that approval has already been recorded. Only when every check clears does the engine compute the release amount, update the quarantine account's released/remaining balances, and mark the milestone released.
Evidentiary Anchoring
Every release approval and every release denial — with its specific reason code — is written into a tamper-evident, hash-chained ledger before the database transaction commits, so the release decision and its evidentiary record land atomically together. No release or denial happens without a durable, independently reproducible record of why.
Prior Art Differentiation
| Approach | Release Basis | Post-Close Re-Evaluation? | Reasoned, Anchored Denials? |
|---|---|---|---|
| Uniswap/Balancer LBP | Immediate at auction close | No | No |
| Bonding-curve launchpad | Immediate at graduation | No | No |
| LP locker (Unicrypt-style) | Static calendar timer | No | No |
| Third-party risk scanner | Advisory only, not release-linked | Periodic, not enforcement-bound | No |
| JIL ProofGuard | Milestone schedule | Yes, at every release request | Yes, hash-chained |