Event Reference

Design stage. Exact event signatures, parameter names, and log topics publish with the contracts. The public repository contains only a README and a LICENSE as of 2026-08-29, so nothing on this page is a Solidity declaration you can copy. UNVERIFIED — PENDING GATE-0 What follows is the event surface implied by the accounting in the litepaper: for each event, why it exists, the fields the accounting requires, and what a verifier reconstructs from it. Treat every field name below as a description of a required value, not a promised identifier.

Why the event surface is derivable before the code

Vessel's accounting is a small set of per-epoch identities. The litepaper commits to an invariant that holds for every epoch and is enforced in code and fuzzed:

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

where G is the gross funding collected in the epoch. If that identity is to be checked by anyone other than the contract itself, each term must be observable from logs. That requirement fixes the minimum event surface regardless of how the contracts end up naming things. This page is written from that requirement.

What "epoch" means here

The litepaper describes daily accrual with a continuous NAV. The settlement period used by the on-chain event is not specified beyond that UNVERIFIED — PENDING GATE-0; the word "epoch" on this page means one settlement, whatever its length turns out to be.

Settlement (the waterfall event)

CONSERVATION

Purpose

One event per settlement carrying every term of the waterfall, so the conservation invariant can be replayed off-chain from logs alone, without reading contract state.

Fields the accounting requires

The litepaper's waterfall runs in a fixed order. Each step produces a value the event must carry.

Field (descriptive)	Source in the waterfall	Notes
epoch identifier	settlement index or timestamp range	needed to order settlements and detect gaps
G, gross funding	funding harvested across the venue leg this epoch	signed; may be negative
protocol fee	10% × max(G, 0)	zero when G ≤ 0
reserve portion of fee	half of the fee while Reserve is below its 2%-of-TVL target	the split point is the Reserve target
treasury portion of fee	the remainder of the fee
Hull accrual A_H	r_H × H × Δt	r_H is a contract parameter, not a market rate
Ballast residual	what remains after fee and Hull accrual	positive in a normal epoch
Ballast drawdown	loss absorbed by Ballast NAV	first in the shortfall ordering
Reserve delta	change in Reserve balance	positive from the fee split, negative when it absorbs shortfall after Ballast
Hull impairment	principal impaired after Ballast and Reserve are exhausted	a credit event; expected to be zero

Whether Ballast residual and Ballast drawdown are one signed field or two, and whether Hull impairment is a separate event, is a contract decision not yet published UNVERIFIED — PENDING GATE-0.

What a verifier reconstructs

• The invariant itself: sum Hull accrual (less any impairment), the Ballast residual or drawdown, the Reserve delta, and the fee; the total must equal G.
• The fee rule: fee must equal 10% × max(G, 0), and the reserve portion must equal half of it only while Reserve was below target at the start of the epoch.
• The Hull rate: A_H / (H × Δt) recovers r_H, which must match the parameter published for the series and must sit within [0, r_cap] with r_cap = 15% APR.
• The shortfall ordering: in any epoch with negative G, Ballast drawdown must be nonzero before Reserve delta is negative, and Reserve must reach zero before Hull impairment is nonzero.
• A running Reserve balance, checked against the 2%-of-TVL target.

The

diagram shows the two regimes this event describes.

Deposit and withdraw (per deck)

Purpose

Track the principal side of the balance sheet per tranche so H and B can be reconstructed and the subordination floor checked.

Fields the accounting requires

• deck identifier (Hull or Ballast) and, for Hull, the series identifier, since Hull is issued in fixed-maturity series (4-week at launch)
• account
• assets moved (USDC) and tranche units minted or burned
• for Ballast withdrawals: a request event and a completion event, because withdrawals are subject to a 48-hour cooldown; the request timestamp is what proves the cooldown was honoured
• for Hull: a maturity redemption event distinct from issuance, since early exit is by secondary sale only and the contract has no early-redeem path to log

What a verifier reconstructs

• H and B over time, and therefore B / (H + B). The floor θ_min = 20% must hold after every Hull issuance and every Ballast withdrawal; an event sequence that violates it is a bug report.
• Per-series Hull supply against its maturity, for principal-plus-fixed-yield redemption.
• Any Ballast completion earlier than 48 hours after its request.

Rebalance (spot and venue legs)

Purpose

Prove the book stayed delta-neutral. The litepaper's rule is that net delta stays within 1% of gross notional, with a rebalance on band breach or on a 4-hour timer.

Fields the accounting requires

Two legs, ideally two events or two structured entries in one:

• spot leg: direction, quantity, price, and the route or venue used (SIMVENUE — SIMULATED today the venue leg is SimVenue, a simulated venue behind the IVenue interface; the spot route in the deployed testnet contracts is not publicly verifiable UNVERIFIED — PENDING GATE-0)
• venue leg: direction, notional, fill price, and margin moved
• trigger reason: band breach or timer
• resulting net delta and gross notional after the rebalance

What a verifier reconstructs

• Net delta after each rebalance, checked against |net delta| ≤ 1% × gross notional.
• Timer discipline: no gap longer than 4 hours between rebalances unless the band was never breached, which the trigger reason lets you distinguish.
• The capital split at launch leverage λ ≤ 2: spot fraction λ / (1 + λ), short margin 1 / (1 + λ), hedged notional λ / (1 + λ), plus the 10% idle USDC buffer. Cumulative spot and margin legs should track that split.
• Liquidation distance: the short-leg liquidation price is required to sit at least 40% above mark; the venue leg's margin and notional let you recompute it.

Venue funding accrual

Purpose

Record the raw funding the venue pays or charges before the waterfall touches it. This is the source of G.

Fields the accounting requires

• venue identifier (SimVenue today; Perpl next)
• funding rate applied and the interval it covered
• notional it was applied to
• signed funding amount

On SimVenue the rate is owner-settable. That is the point of the simulation, and it is also why this event matters on testnet: it is the only place the rate that produced G is written down.

What a verifier reconstructs

• G for the settlement event, as the sum of venue funding accruals in the epoch. A mismatch between the two is a break in the pipeline.
• The input to the Hull rate formula. r_H = clamp(EWMA_30d(net funding APR) × (1 − h), 0, r_cap) with h = 40%; a verifier with the accrual history can recompute the EWMA and confirm the published r_H for the next series. On testnet with an owner-set rate, this check is a test of the formula, not of the market.

Crank execution

Purpose

Keepers execute margin top-ups, rebalancing, and funding harvest permissionlessly. Each execution needs a log so that liveness can be measured and the actor identified.

Fields the accounting requires

• action type: margin top-up, rebalance, harvest, settlement
• caller
• amount moved, where applicable (top-ups draw on the idle buffer)
• outcome, including the de-risking case: a buffer breach triggers automatic de-risking and never added leverage, and that path should be distinguishable from an ordinary rebalance

What a verifier reconstructs

• Keeper liveness: time between eligible and executed for each action.
• That de-risking, when it fired, reduced exposure. A crank that increased notional after a buffer breach would contradict the litepaper.
• Whether keeper rewards, if any, are paid. No keeper incentive is described in the litepaper. UNVERIFIED — PENDING GATE-0

Feeding the indexer

The Envio HyperIndex pipeline described on the indexing page consumes exactly these logs. Two things follow from the tooling constraints:

• The contract must be deployed and verified on a Monad explorer before contract-import can pull its ABI. Until the Vessel contracts are published and verified, no indexer can be generated; the schema on this page is the target, not a working config.
• The settlement event is the one to index first. Every derived table (Reserve balance, per-series Hull accrual, Ballast NAV) is a fold over it.

A minimal schema, expressed as the entities the accounting needs rather than as a promise about field names:

# Illustrative shape, not a published schema
type Settlement {
  id: ID!            # epoch identifier
  grossFunding: BigInt!
  fee: BigInt!
  feeToReserve: BigInt!
  feeToTreasury: BigInt!
  hullAccrual: BigInt!
  ballastDelta: BigInt!  # residual (positive) or drawdown (negative)
  reserveDelta: BigInt!
  hullImpairment: BigInt!
  txHash: String!
}

Opt in to hash under field_selection.transaction_fields so each row links to its transaction.

Verify the hedge

The events above are chosen so that this procedure needs nothing but logs and one price feed.

1. Fold deposit and withdraw events per deck into H(t) and B(t). Check B / (H + B) ≥ 20% at every event boundary.
2. Fold rebalance events into spot position and venue short position. Check |spot − short| ≤ 1% × gross notional after every rebalance, and check that gaps between rebalances never exceed 4 hours unless no breach occurred.
3. Sum venue funding accruals per epoch and compare to the G carried by the settlement event.
4. For each settlement, check hullAccrual + ballastDelta + reserveDelta + fee − hullImpairment = grossFunding. Any nonzero residual is a break in the invariant the contracts claim to enforce.
5. Recover r_H from hullAccrual, H, and the epoch length, and confirm it equals the series parameter and does not exceed 15% APR.
6. In any negative epoch, confirm the loss ordering: Ballast first, Reserve second, Hull last.

While the venue is SimVenue, steps 3 and 5 verify Vessel's arithmetic against a rate someone chose. They say nothing about what funding on a real venue would have paid, and this page makes no claim about that.

Unaudited

Vessel is experimental software on testnet. The invariant is enforced in code and fuzzed per the litepaper, but that code has not been audited and has not been published for review. Treat this page as a specification for what you should be able to check, not as evidence that it holds.