Executive Summary
Shared or federated liquidity support meant to backstop launch pools is itself an attractive drain target: a single manipulated or fast-collapsing pool can, absent hard limits, pull down support intended to protect many pools at once. ProofGuard's liquidity firewall treats vault support as a privilege a launch pool has to earn, and then bounds it with caps enforced entirely in code rather than by discretionary policy.
Support is disabled by default for every pool. Enabling it requires an explicit policy record and, ordinarily, that the pool has already reached a graduated lifecycle state. Once enabled, every individual draw is evaluated against a fixed precedence of checks — price band, rolling 24-hour drawdown, rolling 7-day drawdown, total exposure cap, and a hard stop — with the hard stop triggering an automatic, immediate disablement of further support for that pool.
Problem Statement
Insurance and support funds attached to DeFi protocols typically publish a single total-balance figure with no rolling-rate limit on how quickly that balance can be drawn down. A fast, concentrated attack can exhaust a nominally large fund within a single trading session even though the fund's total size looked adequate on paper. Where a discretionary limit does exist, it usually lives in a risk desk's internal policy rather than in code — meaning it can be paused, raised, or waived verbally under exactly the pressure of an active incident, when discipline matters most.
Technical Architecture
Vault Support Policy
Each pool's vault-support policy is a discrete record specifying a total exposure cap, a rolling 24-hour drawdown limit, a rolling 7-day drawdown limit, a hard-stop threshold, an optional price band, and whether support requires the pool to have reached a graduated lifecycle state. Support is created in a disabled state and must be explicitly enabled, which itself is denied outright if no policy exists or if graduation is required but not yet reached.
| Check | Basis | Outcome on Violation |
|---|---|---|
| Support enabled | Policy state | Deny (support disabled) |
| Price within band | Current pool price vs. configured min/max | Deny (firewall active) |
| 24-hour drawdown | Rolling sum of draws in trailing 24h | Deny (drawdown limit exceeded) |
| 7-day drawdown | Rolling sum of draws in trailing 7d | Deny (drawdown limit exceeded) |
| Total exposure | Cumulative drawn amount vs. total cap | Deny (exposure cap exceeded) |
| Hard stop | Cumulative drawn amount vs. hard-stop threshold | Deny + auto-disable support |
Ordered Evaluation, Atomic Effect
A draw request locks the pool and policy rows, evaluates the checks above in fixed order, and denies on the first violation encountered. A draw that would cross the hard-stop threshold is denied and the policy's enablement flag is flipped to disabled in the same database transaction, so no window exists in which a subsequent draw could slip through between the hard-stop breach and the disablement taking effect. An approved draw is recorded and the policy's cumulative-drawn figure is incremented before the transaction commits.
Evidentiary Anchoring
Every enablement, denial, draw, and hard stop is cryptographically anchored into a tamper-evident hash-chained ledger, giving operators and affected pools a verifiable record of exactly which cap stopped which draw and when.
Prior Art Differentiation
| Approach | Total Cap? | Rolling-Rate Cap? | Enforced By | Auto Hard-Stop? |
|---|---|---|---|---|
| Protocol insurance fund (typical) | Yes | No | Balance check only | No |
| Discretionary risk-desk pause | Policy, not code | Policy, not code | Manual decision | No |
| JIL ProofGuard | Yes | Yes, 24h and 7d | Code, ordered checks | Yes, atomic |