Proof of Hedge
TRANSPARENCY
The claim, stated narrowly
Vessel says it is delta-neutral: long spot, short equivalent notional on a perp CLOB, net delta kept within 1% of gross notional, rebalanced on band breach or a 4-hour timer. That is a claim about a position, and a position is a thing that can be observed.
The transparency claim is about observability, not invincibility. Publishing the hedge does not make the hedge safe. It makes the hedge checkable, so that a reader does not have to take Vessel's word for whether the short exists, whether it is sized correctly, and whether funding is actually accruing. Everything on this page is graded the same way the integrations matrix is graded: by what a stranger can reproduce today, not by what the design intends.
Today the hedge venue is SimVenue SIMVENUE — SIMULATED, a simulated venue with an owner-settable funding rate behind the IVenue interface. Perpl integration is next. Any proof of hedge published now is therefore proof of a hedge against a simulated counterparty. That does not make the proof chain less useful to build; it does bound what the chain can currently prove.
The proof chain
The designed chain has four links. Each one is meant to be checkable on its own, so that a reader who distrusts the dashboard can fall back to the indexer, a reader who distrusts the indexer can fall back to raw events, and a reader who distrusts everything off-chain can fall back to contract state.
| Link | What it is | Who produces it | Independently checkable | Status as of 2026-08-29 |
|---|---|---|---|---|
| 1. Positions on-chain | Spot balance, short-leg margin and notional, idle buffer, Reserve, tranche NAVs, held in contract storage | The contracts | Yes, once addresses are published: anyone with an RPC can read state | Contract addresses unpublished. UNVERIFIED — PENDING GATE-0 |
| 2. Events | Emitted on deposit, rebalance, funding harvest, accrual, shortfall | The contracts | Yes, once addresses and ABIs are published: anyone can filter logs | Design stage. UNVERIFIED — PENDING GATE-0 |
| 3. Indexer | Envio HyperIndex over the events, exposed as a GraphQL API | Vessel operates it; anyone could run their own from the same config | Yes, once the config and schema are published: a second indexer over the same events must agree | Not public |
| 4. Dashboard | The metrics on vessel.wtf | Vessel | Only by comparing against links 1 to 3 | Live, but not reproducible until links 1 to 3 publish |
The order matters. Link 4 is the most convenient and the least trustworthy on its own; link 1 is the least convenient and the only one that cannot be edited by the protocol after the fact. A proof chain is only as strong as the lowest link a reader can actually reach.
Link 1: positions on-chain
The design keeps every quantity that defines the hedge in contract storage: the spot leg, the short-leg margin and notional at the venue, the 10% idle USDC buffer, the Reserve, and the NAV of each tranche. At leverage λ ≤ 2 the design targets λ/(1+λ) in spot, 1/(1+λ) as short margin and λ/(1+λ) as hedged notional, which at launch is 66.7% spot, 33.3% margin and 66.7% hedged notional per dollar of TVL. A reader with the addresses can check those ratios against live state.
Current state: no addresses. The public repository at github.com/Lemma-Development-Labs/vessel contains only a README and a LICENSE as of 2026-08-29. No contracts, no ABIs, no deployment record. The names and signatures of the Engine, tranche, and venue contracts are design-stage and render as unpublished UNVERIFIED — PENDING GATE-0 throughout these docs.
| Contract (testnet) | Address | Actions |
|---|---|---|
| Engine | UNVERIFIED — PENDING GATE-0 | |
| Hull series | UNVERIFIED — PENDING GATE-0 | |
| Ballast | UNVERIFIED — PENDING GATE-0 | |
| Reserve | UNVERIFIED — PENDING GATE-0 | |
| SimVenue (IVenue) | UNVERIFIED — PENDING GATE-0 |
When addresses publish, the first check is trivial and worth doing before any other: confirm code exists at the address.
cast code <address> --rpc-url https://testnet-rpc.monad.xyz
An empty result means there is nothing to prove yet. Testnet chain ID is 10143; the testnet was reset from genesis on 2025-12-16, so any address dated before that is from a prior network.
Link 2: events
Events are how link 1 becomes a history rather than a snapshot. The designed set covers deposits and redemptions, each rebalance (the delta before and after), each funding harvest (gross funding G for the epoch), each daily accrual (protocol fee, Hull accrual A_H, Ballast residual), and any shortfall step through the ordering Ballast, then Reserve, then Hull.
The useful property is that the conservation invariant, ΔNAV_Hull + ΔNAV_Ballast + ΔReserve + fees = G, can be recomputed from the event stream alone. If the events for an epoch do not sum, either the indexer dropped something or the contracts did something the design does not allow. Both are findings.
Current state: design stage. Event names, fields and indexed parameters are unpublished and unverified. The developer page on events describes the intended shape; nothing on that page is confirmed against deployed bytecode.
Link 3: indexer
The indexing plan follows the standard Monad pipeline: an Envio HyperIndex indexer, deployed on Envio Cloud from GitHub, producing a config.yaml, a schema.graphql, TypeScript handlers, and a GraphQL API URL. Envio's contract-import pulls the ABI from a Monad explorer, which imposes a hard ordering on the proof chain: the contracts must be deployed and verified on an explorer before the indexer can even be initialised. Link 3 cannot exist in public before link 1 does.
The indexer is what makes the dashboard's aggregates (funding accrued over a period, average net delta, time inside the band) reproducible. The test is simple: publish the config and schema, and let anyone run a second indexer against the same events. Two indexers that disagree are a bug report. Two that agree are the proof.
Current state: not public. No config, schema, or GraphQL endpoint is published. Whether an internal indexer exists is not something these docs can confirm.
Link 4: the dashboard
vessel.wtf shows live metrics for the testnet deployment, including funding accrued and a net delta near zero.
Those numbers are produced by Vessel and displayed by Vessel. Until contract addresses, event ABIs, and the indexer configuration are public, there is no path by which a reader can reproduce them. They are not verified performance, they are not audited, and because the venue is SimVenue with an owner-settable funding rate, the funding figure reflects a parameter the protocol operator controls, not a market. These docs do not restate the landing figures as facts for that reason.
This is the ordinary condition of a testnet dashboard, not a special deficiency of this one. It is stated here because the transparency page is the wrong place to leave it implied.
What "checkable" means here
A hedge that can be checked is one where the checking does not depend on trusting the party being checked. The word Vessel avoids is the adjective; the verb is the point. The method that gives the chain that property is on Verify the hedge: read the spot balance, read the short notional at the venue, compute net delta as a fraction of gross notional, and compare to the 1% band. The method is written now so that it can be run the day the addresses publish, and so that the addresses, when they arrive, are held to a check that predates them.
Until then, the honest grade for Proof of Hedge is: designed, not delivered. Links 1 through 3 are unpublished; link 4 is live and unreproducible.
What would move each grade
- Link 1 moves to checkable when contract addresses are published and verified on a Monad explorer (Sourcify via MonadVision, or Monadscan). Source verification matters because the indexer depends on it.
- Link 2 moves to checkable when the ABI is public and the event set is documented against the deployed bytecode, not against the design.
- Link 3 moves to checkable when the Envio config and schema are published, so a second party can run an independent indexer.
- Link 4 becomes evidence rather than display only after the three below it are checkable and its numbers are shown to match them.
The audit is a separate axis. Vessel is unaudited; a fully checkable proof chain would show what the hedge is doing, not whether the contracts are correct. Observability, not invincibility.