Bankroll Recovery
Players have successfully bankrupted the house
If losses for the CLP bankroll are large enough that NAV falls to zero or below, the pool is insolvent. Traders and gamers have successfully bankrupted the house. All trading and betting activity stops, because the engine cannot responsibly accept new risk against a bankroll with more liabilities than assets. Normal CLP deposits and redemptions are also suspended, since a non-positive NAV has no meaningful per-token price.
Bankroll recovery is the process of restoring positive CLP NAV so activity can resume.
Permissionless Recapitalization
Any party may recapitalise the pool. The depositor must restore NAV above a minimum solvency buffer, and in exchange receives 99% of the resulting CLP supply. Existing holders retain 1%.
To give a recapitaliser 99% of the pool while existing holders keep the tokens they already own, the protocol issues 99 times the existing supply. Total CLP supply therefore increases by a factor of 100 with each recapitalization.
The required deposit is the deficit plus the solvency buffer. A deposit that restores NAV to any amount below that is rejected in full and no funds move.
An insolvent CLP has no positive residual equity for its existing token holders. The 99% allocation reflects that the recapitalizer is funding a new solvent bankroll, covering the existing deficit and supplying the capital required for the pool to resume operation, while existing holders retain a 1% interest in the recovered pool.
Solvency Requirements
A recapitalizing deposit must satisfy two conditions. Both are evaluated before any funds move.
The first is that NAV after the deposit is at least 1 WBTC. Restoring NAV to a satoshi above zero would leave the pool nominally solvent but with too little bankroll to accept bets, and a single further loss would return it to insolvency immediately.
The second is that the resulting per-token price remains representable:
nav_after * 1e9 >= supply_after
where
nav_after = pool NAV in sats after the deposit
supply_after = CLP supply after the 100x increase
Recapitalization Limits
SPL token supply is capped at 2^64 - 1. Since each recapitalization multiplies supply by 100, a recapitalization is rejected once the existing supply exceeds approximately 1.8e17.
For a pool bootstrapped at 10 WBTC, the initial CLP supply is 1e8 base units. Four recapitalizations are available at the 1 WBTC minimum. A fifth remains possible, but the price condition raises its minimum post-recapitalization NAV of approximately 10 WBTC. A sixth is rejected outright; the deposit fails and no funds move.
Migration
Migration returns the CLP supply to a workable scale, after which every recovery route is available again. It is renewable rather than a one-time escape, and it is initiated before the final permissionless recapitalization is consumed.
Migration is initiated after the fourth bankruptcy or earlier if CLP supply exceeds 1e15 base units. In either case at least one further recapitalization remains available, so the permissionless route stays live as a backstop while migration is carried out.
Migration requires an in-place program upgrade and will follow the following process:
All users are notified of the planned migration.
The upgrade is queued against its 48 hour timelock. The pending change is public for the whole of that period.
Once the timelock has elapsed, the engine stops accepting off-chain trades and bets if the bankroll is still solvent.
global_pausedis set.The upgrade executes and the migration instruction is called to add a second CLP mint, a fixed conversion ratio, and rescale the per-token price.
global_pausedis lifted and all activity resumes.Each holder submits the conversion instruction. The CLP they hold is burned and the replacement token is minted at the fixed ratio.
Because the price is rescaled by the inverse of the conversion ratio, each holder's economic value is unchanged across the migration. A holder who converts later rather than sooner is neither advantaged nor penalized.
Last updated