The set of deposit sizes that mint the same number of shares. Converting assets into shares is one integer division and it has a floor, so the map from what you send to what you are issued is a staircase rather than a line. The width of a step is the value of one share. step() returns the interval you land on, and dust() returns the width of the very first step, where the shares issued are zero.

Yes, and you can check it without trusting the page. contracts/Cusp.sol compiles with solc 0.8.26, and every build puts its 24 properties through Robinhood Chain's own EVM with an eth_call state override — the last run was at block 55,462,976. Separately, 14 checks execute the app's own calldata against real USDG and WETH. It is not deployed at a fixed address and it has not been audited.

No. There is no token, no contract address to copy, no presale and no airdrop. Anyone offering you one is not us. The only tokens involved are the share tokens your own vault mints to you.

Because the offset adds phantom shares, and more shares means each one is worth less, and the quantum you cannot buy a fraction of is one share. It is the opposite of the intuition the parameter is usually explained with, and it is property 21: at identical state, offset 0, 3 and 9 give strictly decreasing dead zones.

Because of what it is sold as. The offset is introduced everywhere as protection against the ERC-4626 inflation attack. We ran that attack four times — the table is here — and tracking assets in storage closes it on its own, with the offset switched off: 100.0000% of the victim's deposit recoverable. Against a vault that reads balanceOf, the same attack leaves 0.0000%. So the offset's security value is redundant in a vault that already tracks its assets, and its real, non-redundant job is the rounding.

Usually not, and that is worth saying plainly. A vault launched near one-to-one has steps a wei wide. It matters when the ratio of assets to shares gets large, which happens when a vault is seeded with a very small first deposit and then earns. In the table, a 6-decimal vault seeded with a thousandth of one and holding 1000 tokens has a dead zone of 0.999 tokens with no offset. Nobody has to attack it for that to happen.

From the chain, with no vendor and no key. tools/scan.mjs counts Transfer events over 26 sampled windows and reads back the most-used contracts as ERC-20s: 293,800 transfers, 4,167 contracts, 196 decoded. Decimals are read from each token rather than assumed, because decimals is the axis the whole table turns on.

This node answers eth_getLogs over about 200 blocks and returns HTTP 429 for 2,000 — a response-size limit reported as a rate limit, so widening the range looks like throttling and is not. Sampling windows across a day of chain is also the better measurement: one contiguous range is one market's worth of activity.

Everything that can go wrong with an unaudited contract you deployed yourself. You are the owner of your own vault, so you hold the only keys that matter, and there is no upgrade path and no admin on our side — but there is also nobody to call. The properties are real and they are executed, and they are not an audit.

Yes — the vault takes any ERC-20. What we cannot do is verify against one: fabricating a balance for the verifier needs the token's balances mapping, and the equities on this chain do not use a standard layout at any slot below 128. That limit is stated on the markets page rather than hidden by quietly testing something else.