> For the complete documentation index, see [llms.txt](https://docs.buoy.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.buoy.finance/protocol-deep-dive/nav-and-share-price.md). # NAV & Share Price Every settlement on Buoy — every share minted, every withdrawal locked — happens at the vault's **Net Asset Value**. This page defines exactly what NAV includes and how the protocol keeps valuations honest. ## What counts into NAV A vault's gross NAV is the sum of everything its accounts hold, valued in USDC: | Component | Where | How it's valued | | -------------------- | ------------------------- | ------------------------------------------------ | | Idle USDC | HyperEVM (vault contract) | Face value | | Spot USDC | HyperCore spot | Face value | | Other spot holdings | HyperCore spot | Live mid-market price | | Options positions | HyperCore spot | Live mid-market price of the underlying contract | | Perp account value | Default perp DEX | Full account value: margin + unrealized PnL | | HIP-3 account values | Each HIP-3 market | Same, per market | {% hint style="info" %} **Under unified accounts, the perp legs are already inside the spot balance.** A vault's spot USDC balance is marked to market: margin backing open positions sits in it as a hold, and unrealized PnL moves it tick for tick. So for a vault in unified-account mode the valuation counts the spot balance and skips the perp accounts entirely — counting both would double the same money. The valuation reads the account's live abstraction mode and branches accordingly. Two things are deliberately **not** in NAV, because a vault can't hold them: native Hyperliquid vault equity (HLP and leader vaults — depositing into them is disabled at the contract level, since their multi-day lockups would strand capital needed to settle redemptions) and staked HYPE (no staking action is exposed on the vault). {% endhint %} Two adjustments produce the value used for share pricing: * **Pending deposits are excluded** — USDC that has arrived but hasn't minted shares yet belongs to the incoming depositor, not to existing holders. * **Outstanding withdrawal obligations are subtracted** — USDC already promised to exiting depositors (locked withdrawals) no longer backs the remaining shares. Then: ``` share price = (gross NAV − withdrawal obligations) ÷ total shares ``` ## Who computes it, and from what NAV is computed by the protocol's settlement service from **Hyperliquid's own account data and market prices** — the same numbers the exchange itself uses to value accounts. There is no third-party price oracle in the loop; the valuation mirrors what you'd see looking at the vault's accounts directly, making it deterministic and independently reproducible by anyone. ## Keeping valuations honest The obvious failure mode of an off-chain valuation is settling against a **stale or inconsistent snapshot**. Two mechanisms prevent it: ### The interaction nonce Every vault keeps an on-chain counter that increments on **every state-changing operation** (deposit fulfilled, withdrawal locked, capital moved, and so on). When the settlement service submits a NAV, it must also submit the counter value it observed while computing that NAV. If **anything** changed in the vault between the valuation and the settlement transaction landing on-chain, the counters no longer match and the transaction reverts. Stale valuations are structurally unable to settle. ### Stability checks Before submitting, the service values the vault **twice**, bracketing an on-chain state read. If the two readings disagree beyond a small tolerance (markets moving fast) or the vault's state changed mid-read, the valuation is thrown away and recomputed. Only a consistent snapshot is ever submitted. ## Additional pricing safeguards * **Depositor floors.** Every request carries a user-set floor (minimum shares / minimum USDC out). Even a correct-but-unfavorable NAV can't settle you below your floor. * **First-deposit basis.** The first deposit into a vault sets the share price at exactly 1 USDC, and share supply starts at zero — the classic "inflation attack" against early depositors in vault protocols doesn't apply. * **Underwater guard.** If a vault's net NAV is zero or negative, settlements refuse to execute rather than mint or burn at a nonsensical price. * **Dust guard.** Deposits below the vault's minimum (1 USDC by default) are rejected, and a locked withdrawal can never be reduced to a zero payout — its shares are already burned, so a zero-value release would leave the user with nothing and no way to cancel. * **Cache bookkeeping.** When a withdrawal is paid out, or its obligation is written down after a realized loss, the vault decrements its cached NAV by the same amount. Without that, the on-chain `pricePerShare` / `convertToAssets` views would read inflated for remaining holders until the next valuation landed. ## The honest caveat The nonce and stability checks guarantee valuations are *consistent* — they do not, by themselves, prove a valuation is *correct*. The settlement service is trusted for correctness, and it is operated by the protocol team. The mitigations: the method is deterministic and publicly checkable against Hyperliquid data, every settlement is public on-chain, and the cancellation mechanism bounds the damage of a non-cooperative service to delay, never loss of custody. The full trust analysis is in [Security & Trust](/protocol-deep-dive/security-and-trust.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.buoy.finance/protocol-deep-dive/nav-and-share-price.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.