Our book
The allocation key picks where. It cannot pick who.
Most of this design exists to make one sentence true: if the key that drives allocation were stolen tomorrow, the attacker could move our capital between venues we already approved, waste some gas, and nothing else.
It is our money, so nobody else absorbs a mistake here. That is the argument for building it this tightly rather than an argument against.
The mechanism
Two paths, and only one of them carries money
Position limits
Adding exposure waits. Removing it does not.
Every venue carries two caps — a hard amount and a share of the book — and the vault checks them on every move. The allocation engine is never trusted to check its own arithmetic.
Slow · queued · reversible before it lands
Approving a venue, or raising a cap
Queued, then executable only after a timelock. Re-queuing restarts the clock, so a pending change cannot be quietly escalated at the last minute. With no depositors to warn, this survives as self-discipline: the delay is there to stop us from doing something quickly that we would regret slowly.
Immediate · no delay · one transaction
Cutting a cap, or shutting a venue off
A guardian can lower any cap, stop all further allocation to a venue, cancel a queued increase, and unwind a position — with nothing to wait for. A guardian who has to wait is not a guardian, and a pause that traps our own capital in a failing venue is the exact thing one exists to prevent.
The bound the vault cannot see
A rebalance is many moves, and losses add up
The vault limits what a single move may cost. But a reallocation is many moves, and ten legs each spending the permitted five basis points spend fifty between them. Nothing inside one move is in a position to notice.
So the allocator measures the aggregate across the whole transaction, and holds a turnover ceiling per window beside it — churn comes straight off the return, and no single move can see the total either.
That bound is only real because of how the keys are wired. The allocation key holds a role on the allocator, never on the vault, so it cannot reach the vault directly and cannot route around anything the allocator enforces.
Tested by trying it, not asserted
Accounting
Read back, never assumed
Every figure the book reports comes from state read back after the fact. A venue accepting a transaction is not the same as a position existing.
What moved, not what was asked
Venues round, cap and partially fill. An adapter returns what actually arrived, and the vault trusts the smaller of that and its own balance change.
Position value, not deposit value
A position is valued at what redeeming it would really pay, net of any exit fee the venue charges — not at the optimistic conversion.
Liquidity the venue admits to
Exit capacity is the venue's own answer, which already accounts for its utilisation. When its markets are full, our withdrawable amount falls on its own.
What this does not fix
The risks that remain, stated by us rather than found by you
A bug in our own contracts
The most serious technical risk, and it lands entirely on us. Properties are written as tests before the code they constrain, adapters are exercised against the real deployed venues rather than mocks, and an external audit comes before capital. None of that is a guarantee.
Concentration
One balance sheet, no fee income to offset a bad quarter, and returns that scale with capital rather than with users. Caps and a floor on venue count bound the damage; they do not diversify the funding.
A venue we approved gets exploited
Our share of that loss is the whole loss. Caps, risk-score gating and the ability to cut exposure instantly bound it. They do not prevent it.