The fold
The width of the staircase is set by the first deposit, and never resets
dust() is totalAssets / (totalSupply + 10^offset) — the value of one share. totalSupply is fixed by whoever deposited first, and income raises totalAssets without minting anything. So a vault seeded small and earning well drifts into a coarse grid on its own, with nobody attacking it.
What sets it
The ratio of assets to shares, and nothing else. Decimals matter only because they decide how small a first deposit can be: a thousandth of a 6-decimal token is 1,000 wei, and a vault seeded with that and grown to 1000 tokens quantises every later deposit at 0.999.
What fixes it
The virtual offset, which adds 10offset phantom shares the first depositor cannot undercut. At offset 6 the same vault's dead zone disappears and the size needed for a sub-basis-point deposit falls from 619.38062 to 0.000001.
Why that is strange
Because that is not what the offset is sold for. It is sold as protection against the inflation attack, and the attack is already closed by tracking assets in storage. The parameter's real job is the one nobody names.
The table
18 rows, 8 of them re-executed on chain
Every row is a vault holding 1000 whole tokens. The only things that vary are which token, how much the first depositor put in, and the offset. The dead zone is the largest deposit that mints nothing; the last column is the smallest deposit whose rounding costs under one basis point.
| Token | Dec | First deposit | Offset | Dead zone (tokens) | 1 token costs | Size for ≤1 bp |
|---|---|---|---|---|---|---|
| USDG | 6 | one whole token | 0 | 0.000999 | 0 bps | 3.059997 |
| USDG | 6 | one whole token | 3 | none | 0 bps | 0.000001 |
| USDG | 6 | one whole token | 6 | none | 0 bps | 0.000001 |
| USDG | 6 | a thousandth of one | 0 | 0.999 | 9 bps | 619.38062 |
| USDG | 6 | a thousandth of one | 3 | 0.000999 | 9 bps | 0.624376 |
| USDG | 6 | a thousandth of one | 6 | none | 0 bps | 0.000001 |
| USDG | 6 | a thousand wei | 0 | 0.999 | 9 bps | 619.38062 |
| USDG | 6 | a thousand wei | 3 | 0.000999 | 9 bps | 0.624376 |
| USDG | 6 | a thousand wei | 6 | none | 0 bps | 0.000001 |
| WETH | 18 | one whole token | 0 | none | 0 bps | 0.000000000003 |
| WETH | 18 | one whole token | 3 | none | 0 bps | 0 |
| WETH | 18 | one whole token | 6 | none | 0 bps | 0 |
| WETH | 18 | a thousandth of one | 0 | none | 0 bps | 0.000000000625 |
| WETH | 18 | a thousandth of one | 3 | none | 0 bps | 0.000000000003 |
| WETH | 18 | a thousandth of one | 6 | none | 0 bps | 0 |
| WETH | 18 | a thousand wei | 0 | 0.999000999 | 9 bps | 619.380619380619 |
| WETH | 18 | a thousand wei | 3 | 0.000999000999 | 9 bps | 0.624375624375 |
| WETH | 18 | a thousand wei | 6 | 0.000000999 | 0 bps | 0.000624375624 |
The three tokens are the busiest contract at each distinct decimals value in use on this chain — USDG at 6, WETH at 18 — discovered by counting transfers rather than from a list. The identical 619.38062 appearing on several rows is not a copy-paste: those vaults have the same ratio of assets to shares, and the fold is a property of that ratio, not of the token.
Move it yourself
The same arithmetic the contract runs, in your browser
This is js/chain.js, the module tools/fold.mjs builds the table with. Its answers were checked against contracts/FoldProbe.sol on Robinhood Chain at 8 sampled points and matched to the wei.
The vault holds 1000 whole tokens in every case, reached by a first deposit of the size above and income for the rest. Nothing is fetched; this is the same BigInt the scanner uses.
Read a live vault
Point it at any Cusp vault on Robinhood Chain
Paste the address of a vault you deployed from the app. This reads totalAssets, totalSupply, OFFSET and dust() straight from the chain — no key, no proxy, no server.