Calls and forced sales
What happens when equity falls below the maintenance requirement: the grace tiers, how to cure, and the deterministic partial close that runs if you do not. All of it works at any hour of any day.
When a call raises
The moment equity falls below the maintenance requirement, the account enters a maintenance call. The call is raised on chain with the exact shortfall announced in the event, so every front end shows the same number:
An account carries at most one call at a time. While it is open, buys and collateral withdrawals are blocked; selling and depositing stay available, because those are how you cure. The keeper sweeps every account on a short interval, but raising, clearing and executing calls are all permissionless, so the machinery does not depend on any single operator.
The grace window
Grace depends on one thing only: how far equity has fallen against the maintenance requirement at the moment the call raises. The hour and the day do not enter the calculation, so a call raised at 3am on a Sunday runs exactly the same clock as one raised at noon on a Tuesday.
| Equity at raise | Grace |
|---|---|
| At or above 85% of the maintenance requirement | 4 hours |
| Below 85%, at or above 75% of the maintenance requirement | 1 hour |
| Below 75% of the maintenance requirement | none |
Two tiers and a floor, and nothing else. Because the venue is open continuously, every position in the basket can be priced and sold at any hour, so no account is ever held in a call waiting for a session to start and no class of collateral is temporarily unsellable.
Below 75% of the maintenance requirement there is no grace at all, and an existing call becomes immediately actionable: the floor pierces a running grace window whenever it is crossed, at any hour.
Curing
During grace you can deposit collateral, sell positions yourself (sale proceeds pay the debit first), or do nothing. The cure check runs inside the deposit and sell transactions themselves, so the instant equity is back at or above the maintenance requirement, the call clears in the same transaction. There is no waiting on a sweep. Note that interest keeps accruing through grace, so the shortfall at the deadline is slightly larger than the shortfall announced at raise.
The forced sale
If grace expires uncured, the desk runs a partial close. Whitelisted keepers act first; after a 10 minutes priority window, anyone may execute. The target is always initial margin, not maintenance, so a freshly closed account carries a full cushion and does not bounce straight back into a call on the next tick.
A forced sale can execute at any hour of any day, and that is a safety improvement rather than a hazard. A desk that can only sell inside a session has to sit on a breach until the session opens, by which time the gap has usually widened and the account may be past the point where selling covers the debit. Here the sale runs when the breach happens, at the smallest size that restores the cushion, so less collateral is sold and less bad debt reaches the vault.
Selection is deterministic and not operator-steerable. The engine ranks asset classes by their total maintenance contribution, highest first, then ranks positions inside the class by size, and sells from the top until equity reaches initial margin. Paused and halted legs are skipped, and USDG is never force-sold: cash is netted against the debit at the daily charge instead. Each leg's notional x is sized by the closed-form solve of the post-sale margin identity, where im is the asset's initial weight and p its penalty rate:
Selling x of an asset reduces the initial requirement by im × x while the penalty costs equity p × x, so this is the minimum sale that restores equity to initial margin. As built, a tenth-of-a-cent rounding guard is added to the numerator so the identity holds in integer arithmetic, the size is capped at the position, and an asset whose penalty meets or exceeds its initial weight is skipped, since selling it cannot help. The account is frozen for the duration of the sale loop and unfrozen after.
Every fill routes through the Router against the oracle mark, inside a 1.50% forced-sale budget. Large sales are chunked by a per-leg clip sized at deploy time to what the venue's depth absorbs within the budget; a leg that cannot fill inside the budget fails safely, is skipped, and the engine moves to the next asset. See trading and the venue for how fills are bounded.
Penalties
| Asset class | Penalty |
|---|---|
| Stock and ETF tokens | 3.00% |
| Crypto and majors | 5.00% |
| WEEK | 0.50% |
| USDG | 0.00% (netted, never sold) |
The penalty is taken from each leg's sale proceeds before the debit is reduced and is paid to the cash vault in full. It is vault income: it accrues to depositors through NAV, not to the protocol, and no share goes to whoever executed the sale. Executors gain only earlier execution, never different execution. Every value here is governed; the parameters page renders the live set.
When collateral runs out
If the sales exhaust the collateral and a debit remains, the residual is written off through a fixed waterfall: the vault's insurance line pays first, and only what exceeds it falls on vault NAV. The split is attributed on chain in the write-off events, one from the call engine with the principal and interest lost, one from the vault with the insurance and NAV shares, so depositors can verify exactly where every write-off landed. One contract runs all of this, the desk's forced sale engine; the contract addresses page lists it under that role, and the product speaks only of calls and forced sales.