Two doors into the same vault
Postern ships both on purpose. A page that only shipped the safe one would be describing a problem it had quietly hidden, and the difference between them is the entire argument.
deposit() — the front door
The ordinary ERC-4626 path, identical to every vault you have used. You approve, usually without limit because that is what the button offers, and you deposit.
- Approve once, deposit as often as you like
- Works with routers, aggregators and batchers
- Leaves standing exactly what you approved, for ever
Property 10 measures this rather than asserting it: approve without limit, deposit, and the allowance is still unlimited afterwards. If that ever stopped being true, the comparison this site makes would be false, and the build would fail.
openPostern() — the small gate
Three conditions, and the third is what turns a convention into a guarantee.
- An unlimited allowance is refused outright
- Anything other than the exact deposit is refused
- After the pull, the allowance is read back, and the whole call reverts unless it is zero
That last step is the one that matters. Without it the contract would be trusting the token to have decremented; with it, a token that does not is simply a token this function will not transact with. Property 13 deploys exactly such a token and checks that the vault walks away holding nothing.
What the small gate costs, stated plainly. One approval per deposit instead of one per lifetime. No batching through a router that expects a standing allowance. A deposit that reverts if you approved too much. Two transactions where there was one, and a worse integration story than every competitor. That is the price of the door being shut, and it is a real price — this page is not going to pretend the trade-off does not exist.
The vault publishes its own attack surface
Three view functions no other vault exposes. They are ordinary reads: any wallet, any explorer, any script can call them.
| Function | Returns | Why it is there |
|---|---|---|
| standing(address) | the allowance that address has open to this vault | what the vault could take from you right now, if it wanted to |
| residual(address, assets) | what would still be open after depositing assets | the number you should be shown before you sign, and never are |
| exposure(address) | min(allowance, your balance) | the amount actually at risk, which is neither of the two numbers anybody prints |
Executed, not asserted
These four sentences appear on the security section of nearly every vault in this category. Here each one is a property that runs on Robinhood Chain every build, and each has a deliberate defect that must be caught.
No inflation attack
A first depositor cannot round the next one down to zero shares. P2 runs the attack with a 900× donation and checks the victim recovers within a basis point.
Donations do not reprice
Assets are a storage counter, never balanceOf. P3 sends 50× the vault's holdings straight to it and checks the share price does not move.
The fee is capped in code
MAX_CUT_BPS is a constant, not a setting. P4 tries to set the cut one basis point above it and requires the call to fail.
The owner cannot take principal
sweep moves only what is above what shareholders are owed. P5 leaves a surplus, sweeps, and checks the holder still redeems in full.