How NAV works

Net asset value per unit is simply the value of what a unit owns:

navPerShare = Σ ( vault.balanceOf(assetᵢ) × priceᵢ ) / totalSupply

Prices come from the NavOracle, which prices every asset, ETH included, from its own Uniswap pools on Robinhood Chain, never from an external feed: the assets trade around the clock, and so do their pools. Each asset’s price feed reads its deepest pool and cross-checks a second venue; if the two disagree beyond a set tolerance, or a pool is empty, the read reverts, so a basket can never mint against a bad price.

Resting orders trigger on a reference NAV instead: each constituent’s price averaged over the last 10 minutes of its pool, which no single transaction can move. One kind of pool keeps no history to average (Uniswap v4), so a token whose deep pool is a v4 pool is read at that pool’s live price; today that is NVDAx3L, held only by TURBO.

Dividends accrue automatically. Robinhood’s Stock Tokens carry ERC-8056 total-return accrual, so dividends flow straight into the token value, the price it trades at in its pools, and therefore into NAV. There is nothing to claim and nothing to restake.

Why deposits can’t move the price

Minting and redeeming are strictly proportional and in kind: you deposit each constituent in the ratio the vault already holds, and you redeem the same way. Adding assets and shares in the same proportion leaves NAV per share unchanged, so no deposit or withdrawal, of any size and in any direction, can move the price for anyone else.

Rounding always favours the vault: previewMint rounds deposits up and previewRedeem rounds redemptions down, so a round trip can never extract value from the remaining holders. The first mint also burns a MIN_LIQUIDITY dead-share floor, which closes the classic first-depositor inflation attack.

Three things can move NAV per share, and only three: the constituents’ own prices; the streaming management fee, which mints a small share to the treasury over time; and rebalance execution costs. The genuine trust assumption is the oracle, not the deposit flow.

How rebalances run

Between rebalances the quantities in a basket are fixed, so weights drift with price, and that live drift is shown on every basket page. On the basket’s schedule (monthly or quarterly), a rebalancer swaps constituent for constituent to reset toward target weights. Every rebalance is constrained on-chain:

• only an allowlisted router may be called;
• both sides of every swap must be constituents of that basket, so value cannot be routed out of it;
• the oracle must be live for all constituents (requireValid), so a rebalance can never price against a bad read; and
• NAV after must be within maxRebalanceLossBps of NAV before, or the whole transaction reverts.

A rebalance can therefore rearrange what a basket holds; it cannot spend it. And because in-kind redemption is always available and never pausable, anyone can exchange a share for the underlying at any time, the ultimate check that the quoted NAV is real.