The short answers

Nothing, as an idea. The problem is what it charges. Take f of whatever the share price has made above the mark, then move the mark to the price that survives the fee, and the charges telescope: the total is exactly f × (highest price ever observed − the price you came in at). There is no term in that for where the price ended, so a vault that rises and comes straight back down has still charged you — on 19 of the 40 real markets measured here, the holder made nothing and was charged anyway.

Because the maximum in that formula is a maximum over the moments the vault looked. Look more often and you find a higher peak. On the same 40 markets, a 20% fee crystallising every block charges a median of 2.67 bps and the same fee every 27.8 hours charges 0.00 bps. Nothing else about the vault changed.

Record statistics say how much: sampling a maximum at n points falls short of the continuous one by a universal constant over √n. The site checks that constant rather than quoting it.

Every holder carries a weighted-average entry price. At exit you pay 20% of max(0, exit − entry) × your shares, out of your own proceeds. It is path-independent: two holders in and out at the same two prices pay the same fee whatever happened in between, and a holder who is flat pays nothing.

Because it needs one number for the whole vault and a per-holder fee needs a number per holder — and that has a real cost, which this site publishes rather than hides. Two accounts holding the same number of shares can redeem for different amounts, and previewRedeem(uint256) has nowhere to ask whose. It returns the worst case here, which the standard permits and which under-values a real holder. previewRedeemFor(owner, shares) is the answer, and withdraw uses it because the standard hands it the owner.

Yes, to the letter. transfer moves exactly what it is asked to move, balanceOf is a plain number, totalSupply is a plain number. The basis travels with the shares rather than resetting at the current mark, so nobody sheds a liability by sending shares to a fresh address and nobody inherits a mark they did not pay for. What is not fungible is the value: two equal balances are not equal claims, and the site says so on the front page rather than in a footnote.

Move the mark. The vault prices its position at one Uniswap V3 pool, and that is the only price it has, so a manager who can push that pool can sell the position into the vault at an inflated mark and let the price come back. Property 31 executes exactly that and measures it: on a $200,000 vault, pushing the mark to twice its value and selling 500 tokens in takes $50,000 from holders, and the manager nets exactly what they lose.

This is a property of every vault that marks a position against a venue it does not control, and closing it needs a second price source rather than a bound the manager supplies. It is published rather than argued away, and it is the reason the guarantee on the front page is about sweep specifically and not about the manager in general.

Arete.sol has no canonical deployment. Every property on /contract is run on Robinhood Chain’s own EVM through eth_call, which executes real code against real state and leaves nothing behind. /app deploys a vault from your own wallet.

Deploy, deposit, crystallise and redeem are ordinary signed transactions on Robinhood Chain. Every write is simulated from your address first. No key is handled here or held anywhere in this project.

Every price is a Uniswap V3 Swap event decoded from its own sqrtPriceX96. There is no vendor, no oracle and no candle API in this repository. The scan reads 45,536 Swap events across 40 pools directly from Robinhood Chain and computes each price from the sqrtPriceX96 carried in the event itself.

No. The properties on /contract are a self-review with sabotages, which is a different thing from an audit and does not substitute for one. The 17 sabotages exist because a suite nobody has found the floor of is a suite that proves nothing, and 1 of them is expected to survive every property and says why.