Admin Powers
This page lists every administrative power in Vessel, in three categories: powers the design rules out, powers that exist today on testnet, and commitments that cannot be checked until the code is published. Each row carries its verification status. A power this page does not list is a documentation bug; report it and it will be listed.
Powers that do not exist
The litepaper states the supply rule directly: "No privileged mint path exists in any Vessel contract." vUSD (Phase 3, post-audit) changes supply only through collateralized mint and redeem — minted 1:1 against the delta-neutral book, overcollateralized by Ballast and the Reserve. The landing page makes the same commitment in fewer words: non-custodial, no admin mint.
| Power | Exists | Verification |
|---|---|---|
| Privileged mint: supply created without collateral | No | Litepaper, verbatim: "No privileged mint path exists in any Vessel contract" |
| Supply change outside collateralized mint/redeem (vUSD phase) | No | Litepaper: vUSD is minted 1:1 against the delta-neutral book |
These are litepaper statements. The public repository contains only a README and a LICENSE as of 2026-08-29, so neither row can yet be checked against source. Litepaper-backed is the exact strength of the claim today; when the contracts publish, these rows gain code references.
Powers that exist today
The deployed testnet contracts hedge against SimVenue SIMVENUE — SIMULATED, a simulated venue with an owner-settable funding rate behind the IVenue interface. Perpl integration is next.
| Power | Holder | Verification |
|---|---|---|
| Set SimVenue's funding rate | Venue owner (the team) | Verified: stated by the team as a trust assumption of the simulation period |
| Deploy and upgrade contracts | not publicly documented UNVERIFIED — PENDING GATE-0 | Publishes at Gate-0 |
Because SimVenue's funding rate is owner-settable, every rate the testnet engine harvests is a number the team chose. Testnet exists to demonstrate the accounting — the waterfall, the subordination floor, the conservation invariant — not the market. Read testnet figures accordingly.
On the second row: whether the deployed contracts are upgradeable, which addresses hold owner roles, and how those keys are held is not publicly documented. That is a gap, and this page states it rather than working around it. The key inventory publishes at Gate-0; this page then gains per-address rows you can check on-chain.
Design commitments, not yet verifiable
The litepaper makes two commitments about powers Vessel will not have. A Hull series is issued with a fixed maturity and a fixed rate; the rate is a contract parameter set at issuance, never a performance figure, and per the design it does not change over the life of the series. The crank — margin top-ups, rebalancing, funding harvest — is specified as permissionless keeper work: anyone can run it.
Neither commitment can be checked today, because there is no published code to check it against.
| Commitment | Stated in | Check today |
|---|---|---|
| Permissionless crank: anyone can execute margin top-ups, rebalancing, and funding harvest | Litepaper | Not possible; contracts unpublished |
| Series parameters fixed at issuance: a Hull series carries its rate and maturity from issuance to maturity | Litepaper | Not possible; contracts unpublished |
When the code publishes at Gate-0, each row either moves into the tables above with a code reference, or the design has changed and this page will say so.
The honest summary
On testnet, you are trusting the team.
The venue's rate is a setting the team controls. The deployment and upgrade keys are not published. The commitments above are prose, not code you can read. None of this is unusual for an unaudited testnet; leaving it unsaid would be. The point of Gate-0 is to shrink that sentence — in public, on this page.