NAV and Accrual Epochs

Vessel accrues once per day and reports NAV continuously. This page states what NAV is derived from, what happens at each accrual epoch, and the single equation every epoch must satisfy. The exact accounting artifacts (storage layout, event schema, epoch-close function) are design-stage. They publish with the contracts.

Design-stage page

The Vessel repository contains only a README and LICENSE as of 2026-08-29. No contract source, ABI, or deployed address is published. Everything below that describes contract behaviour is the litepaper design, not verified bytecode. Contract-level specifics render as unverified.

Two clocks

The litepaper separates two things that are often conflated.

Clock	Cadence	What it does
NAV	Continuous	Marks the book at current chain state. Readable at any block.
Accrual	Daily	Runs the waterfall: fee, then Hull accrual, then Ballast residual. Moves value between tranches.

NAV is a read. Accrual is a write. Between two accrual epochs the tranche balances do not move; what moves is the mark on the underlying positions, which is why a Ballast NAV quoted mid-epoch is a mark and not a settled figure.

The daily cadence is the litepaper's stated design. The exact epoch boundary (block-aligned, timestamp-aligned, or keeper-triggered) is not yet specified UNVERIFIED — PENDING GATE-0.

Where NAV comes from

The principle: derive NAV from positions the chain can observe, and treat everything else as an input.

Per $1 of TVL at launch leverage λ ≤ 2, the book is 66.7% spot, 33.3% short margin, 66.7% hedged short notional, plus a 10% idle USDC buffer held unhedged. Each of those legs is a position that lives in chain state.

Leg	Source of truth	Readable from chain
Spot balance	Token balance of the engine	Yes
Idle USDC buffer	Token balance of the engine	Yes
Short margin	Venue collateral account	Yes, where the venue is on-chain
Short notional and unrealised PnL	Venue position	Yes, where the venue is on-chain
Accrued funding	Venue position	Yes, where the venue is on-chain
Reserve	Reserve balance	Yes

Gross yield G for an epoch is the change in the mark of those legs plus funding harvested, net of execution cost. It is computed from positions, not from a reported rate.

Today the hedge venue is SimVenue SIMVENUE — SIMULATED, a simulated venue with an owner-settable funding rate behind the IVenue interface. On SimVenue "venue position" means whatever SimVenue's storage says it is, and the funding rate is a parameter the owner sets. This is a testnet artifact. The Perpl integration is next; Perpl's exchange contract is on-chain, so the short leg becomes chain-readable at that point.

Price feeds are inputs, not authorities

Marking a spot balance to USDC requires a price. Vessel sources that price from external feeds. A feed is an input to the NAV number; it is never the authority over whether Vessel is solvent.

The distinction matters in the failure case. If a feed is stale or wrong, the NAV mark is wrong. The positions are not. Spot is still in the engine, margin is still at the venue, and the hedge still nets to within the delta band. A bad feed can misprice a mark; it cannot move collateral. Which feeds Vessel reads, and how a stale feed is handled at epoch close, is covered on the oracles page: Oracles at the Monad tooling directory, and the Vessel-side treatment at /integrations/oracles.

The oracle selection itself is not yet published UNVERIFIED — PENDING GATE-0.

What an accrual epoch does

At epoch close the waterfall runs on G, the gross yield of the epoch.

1. Protocol fee: 10% of max(G, 0). Half goes to the Reserve until the Reserve reaches its 2% of TVL target; the remainder goes to treasury.
2. Hull accrual: A_H = r_H × H × Δt, where r_H is the Hull rate. r_H is a contract parameter, not a market yield: r_H = clamp(EWMA_30d(net funding APR) × (1 − h), 0, r_cap) with h = 40% and r_cap = 15% APR.
3. Residual: whatever remains goes to Ballast.

If G is negative, step 1 takes nothing (the fee is on max(G, 0)), step 2 still owes Hull its accrual, and step 3 charges the shortfall. Shortfall ordering is Ballast NAV first, then the Reserve, and only then Hull principal. Hull principal impairment is a credit event.

The conservation invariant

Every epoch must satisfy:

ΔNAV_Hull + ΔNAV_Ballast + ΔReserve + fees = G

Value that enters the system in an epoch is fully accounted for across the four sinks. Nothing accrues to a tranche that did not come from G, and nothing from G goes anywhere other than a tranche, the Reserve, or the fee. The litepaper states this is enforced in code and fuzzed.

The invariant is the check a reader should hold the contracts to once they publish. It is also why NAV is derived from positions: if G were taken from a reported rate rather than from the observed change in the book, the equation could balance on paper while the book did not.

Three consequences follow from the invariant.

• Hull's accrual is a fixed claim. When G is smaller than A_H, the difference is a negative ΔNAV_Ballast, then a negative ΔReserve. The equation still balances; it balances against Ballast.
• The Reserve is not free money. Its positive ΔReserve is a fee that Ballast did not receive. Its negative ΔReserve is a Ballast loss it absorbed.
• Fees are a first charge on positive G only. In a negative epoch fees = 0.

Worked example

Illustrative, not a forecast. Figures are chosen to show the arithmetic.

Assume TVL of 1,000,000 USDC, Hull of 700,000, Ballast of 300,000 (so B / (H + B) = 30%, above the 20% floor), Reserve below target, r_H at 10% APR as the contract parameter for this series, and a one-day epoch.

Positive epoch, G = 400:

Step	Amount	Sink
Fee, 10% of 400	40	20 Reserve, 20 treasury
Hull accrual, 700,000 × 10% / 365	191.78	Hull
Residual	168.22	Ballast

Check: 191.78 + 168.22 + 20 + 20 = 400. The treasury portion is part of fees.

Negative epoch, G = −300:

Step	Amount	Sink
Fee, 10% of max(−300, 0)	0	none
Hull accrual	191.78	Hull
Shortfall	−491.78	Ballast

Check: 191.78 + (−491.78) + 0 + 0 = −300. Ballast absorbed the loss and Hull's accrual. The Reserve was not touched because Ballast NAV covered it.

The day-count convention (365 versus actual days, and how Δt is measured on a chain with 300ms blocks) is not yet specified UNVERIFIED — PENDING GATE-0.

What is not yet published

• The epoch-close function, its trigger, and who may call it. The litepaper says keepers execute funding harvest permissionlessly; whether epoch close is the same call is not stated UNVERIFIED — PENDING GATE-0.
• The NAV read function and its return shape.
• The event emitted at epoch close carrying G, the four deltas, and the invariant check.
• The handling of an epoch whose oracle input is stale at close time.
• Whether NAV between epochs is exposed on-chain, off-chain, or both.

When the contracts publish, this page gains an interface section with the exact signatures and an event schema an indexer can consume. Until then, treat every accounting detail above as the litepaper design and nothing more.

Read next

• Oracles
• The litepaper