The Crank

PERMISSIONLESS SETTLEMENT

What the crank is

Vessel's book has to be maintained. The short leg needs margin topped up, the delta band needs enforcing, and accrued funding needs harvesting into the accrual waterfall. The litepaper assigns all three of these to keepers, and it assigns them permissionlessly: anyone can turn the crank.

That is the whole design statement. There is no privileged operator whose absence stalls the protocol. If a keeper stops, another keeper, or the reader, submits the same transaction.

The three keeper actions

The litepaper names three actions that keepers execute permissionlessly.

Action	What it does	Trigger stated in the litepaper
Margin top-up	Moves collateral to the short leg so the liquidation price stays at least 40% above mark	Margin maintenance uses the idle USDC buffer; a buffer breach triggers automatic de-risking, never added leverage
Rebalance	Brings net delta back inside the band	Net delta outside 1% of gross notional, or a 4-hour timer
Funding harvest	Realizes funding into the waterfall	Daily accrual; NAV is continuous

The delta band, the 4-hour timer, the 40% liquidation distance, and the daily accrual are litepaper parameters. How each maps to a specific function, and whether the three are one entry point or three, is not published. See Interface.

Rebalancing and top-ups can only reduce risk. The litepaper is explicit that a buffer breach de-risks; it never adds leverage. A keeper therefore cannot turn the crank into a lever: the action space is bounded by the same invariants the engine enforces on itself, including the conservation invariant ΔNAV_Hull + ΔNAV_Ballast + ΔReserve + fees = G per epoch.

Liveness

Liveness is the property that the book keeps getting maintained. Vessel gets it from permissionlessness rather than from an operator's uptime.

• No operator key is required to top up margin, rebalance, or harvest.
• The cost of a stalled crank is borne first by Ballast, per the shortfall ordering (Ballast NAV, then Reserve, then Hull principal). Ballast holders and anyone running a keeper are therefore the parties with the incentive to keep the crank turning.
• Whether the engine pays keepers a fee or rebate for cranking is not stated in the litepaper. Keeper compensation UNVERIFIED — PENDING GATE-0 publishes with the contracts.

Keeper economics on Monad

Monad charges gas on the gas limit, not on gas used. The primary source states it verbatim: "In Monad, the gas charged for a transaction is the gas limit set in the transaction, rather than the gas used in the course of execution." The formula is gas_paid = gas_limit × price_per_gas, with price_per_gas = min(base + priority, max) for type-2 transactions.

This changes keeper accounting in two ways.

1. Fund against limits, not usage. A keeper's spend per crank is the limit it sets, every time, including when the call does little work or reverts. Budget on the limit.
2. Tight limits are a predictable ceiling. Because the charge is the limit, a correctly sized limit makes the cost of each crank a known number before submission. Keep the estimation buffer small, at most about 10%. Do not let a wallet fall back to a huge default limit when eth_estimateGas reverts; on Monad that entire limit is paid.

Two further details matter for crank transactions specifically. Cold state access is repriced upward on Monad (cold account access 10,100 gas, cold storage access 8,100 gas, warm access 100), which affects any keeper call that touches many positions. And accounts need a 10 MON reserve balance; a keeper wallet drained below that floor is limited to roughly one transaction per 1.2 seconds. Every figure in this section is on the network page, which carries the full gas callout.

Gas on limit applies to reverts

A crank call that reverts because another keeper already cranked still pays its full gas limit. Read state before submitting, or accept that concurrent keepers pay for lost races.

Venue-side operator design

The crank acts on the hedge venue. Today the deployed contracts hedge against SimVenue SIMVENUE — SIMULATED, a simulated venue with an owner-settable funding rate behind the IVenue interface. Perpl is the next venue.

On Perpl, the relevant pattern is the delegated account. Per the PerplFoundation delegated-account repository, a DelegatedAccount is "a smart contract that holds an account on the Perpl Exchange with separated owner/operator roles." The operator is restricted by a function-selector allowlist covering order execution (execOrder, execOrders, and similar), and withdrawCollateral is owner-only and permanently blocked for the operator.

For Vessel this is the shape that makes a permissionless crank safe on a real venue: whoever holds operator rights can place and manage hedge orders but cannot move collateral out. How Vessel's engine will hold the owner role, and whether the crank calls route through a DelegatedAccount or directly through the engine, is design-stage. The verified Perpl details, addresses, and failure mode are on the Perpl integration page.

Interface

The Vessel repository contains a README and a LICENSE as of 2026-08-29. No contracts, ABIs, or addresses are published. The exact crank interface therefore does not exist in any verifiable form yet.

// Design-stage. The signatures below are placeholders, not a published ABI.
// The crank interface publishes with the contracts.

Function names and signatures for margin top-up, rebalance, and funding harvest UNVERIFIED — PENDING GATE-0 Engine contract address on Monad testnet UNVERIFIED — PENDING GATE-0

When the contracts publish, this section will carry the interface in a code block and the address in an AddressTable, and the verification page will record the source.

What to expect as a keeper

• Anyone can call the crank; there is no allowlist for keepers.
• Each call is bounded to risk-reducing actions by the engine's invariants.
• Fund the keeper wallet against gas limits, keep the 10 MON reserve, and use finalized before treating a crank as settled.
• Watch this page and the Perpl integration page for the published interface.