Why Monad

Vessel holds spot long and an equal notional short on a perp venue. The book earns funding. Its job between harvests is to stay flat. The rules for staying flat are narrow: net delta is kept within 1% of gross notional, and the position is rebalanced whenever that band is breached or a 4-hour timer expires, whichever comes first.

That is a maintenance problem, not a trading problem. The hedge does not need large moves. It needs many small ones, made cheaply, confirmed quickly, and observable in between. The chain has to make that pattern affordable. This page states what Monad provides and why each property matters for this specific workload.

The workload

A 1% band on a leveraged book is tight. At launch leverage λ ≤ 2, roughly 66.7% of each dollar of TVL is spot and the same fraction is hedged notional on the short side. Spot and perp marks drift apart; a partial fill, a funding payment, or a margin top-up all shift net delta. Every drift toward the band edge is a rebalance transaction. Every 4 hours there is one regardless.

Keepers perform these adjustments permissionlessly: margin top-ups, rebalancing, and funding harvest. A keeper's economics decide whether the band is actually held or merely specified. If confirmation is slow, the keeper acts on stale delta. If gas is unpredictable, the keeper widens its own tolerance to protect its margin. Both outcomes loosen the hedge below what the litepaper promises.

Block time and finality

Monad produces a block every 300ms. A transaction reaches speculative finality at 300ms and full finality at 600ms.

For the rebalance loop this has two consequences. First, an adjustment lands and is visible within the same second it is sent, so the next observation of net delta already includes it. The keeper does not queue corrections against a position it cannot yet see. Second, a user interacting with Vessel sees a deposit or a Ballast withdrawal request confirmed at the cadence of a web request rather than a settlement. Same-block confirmation is what makes a continuous rebalancing loop a loop rather than a batch.

Monad exposes its block states as latest (speculative), safe (validator-backed), and finalized (irreversible). Vessel's own tooling reads latest for monitoring and treats finalized as the bar for anything irreversible.

On the 400ms figure

The Vessel litepaper cites 400ms blocks. That figure predates the current network. As of 2026-08-29 the official Monad documentation states 300ms block time and 600ms full finality, and those are the numbers this site uses. The verification ledger records the correction; the litepaper text has not been rewritten.

Asynchronous execution and accurate reads

Monad decouples consensus from execution. Consensus validates against a state view that lags by three blocks (D = 3). The practical rule for anyone monitoring a position is that eth_call and eth_estimateGas simulate against speculative state and return accurate results.

This matters because the whole hedge is observed off-chain before it is acted on. Net delta, margin ratio, the distance between the short leg's liquidation price and mark (the design target is ≥ 40% above mark), the idle buffer level: all of these are speculative reads made every block by keepers and by anyone who wants to check the protocol's state. A read that reflects the block that just landed, not one several blocks behind, is the difference between a monitor and a lagging indicator.

One consequence to plan around: an account that has just been funded cannot send a transaction until the funding is three blocks old, about 1.2s. A newly funded keeper waits that long before its first action.

Gas headroom

Monad's block gas limit is 200M, with a per-transaction limit of 30M. A rebalance is a spot swap plus a perp order plus a margin adjustment, done often. The throughput constraint on Vessel is not block space. It is the keeper's own decision logic and the hedge venue's fill.

The minimum base fee is 100 MON-gwei. Monad's base fee controller rises more slowly and falls more quickly than Ethereum's, with a target of 160M gas per block. Fee spikes are therefore shorter-lived, which is the behaviour a frequent small-transaction workload prefers.

Gas on the limit, treated as a feature

Monad charges gas on the gas limit, not on gas used:

gas_paid = gas_limit × price_per_gas

This follows from asynchronous execution: the leader includes transactions before executing them, so actual consumption is unknown at inclusion time, and charging the limit removes the incentive to under-price compute.

For a keeper this is a predictable cost ceiling. A rebalance call with a tight, correct gas limit costs exactly gas_limit × price_per_gas every time, regardless of which branch the contract takes. The keeper can price its work before sending it. There is no case where an unexpected path consumes more than budgeted, because the budget is what is paid.

The discipline this demands is real and it belongs to Vessel's keeper code, not to the chain:

• Set limits from measured execution, not from a wallet's fallback. If eth_estimateGas reverts, some wallets fall back to a very large limit; on Monad the sender pays that entire limit.
• Keep the estimation buffer small, on the order of ≤ 10%.
• Cold state access is repriced upward relative to Ethereum: cold account access is 10,100 gas and cold storage access is 8,100 gas, while warm access stays at 100. Rebalance paths that touch many cold slots should be measured on Monad, not carried over from Ethereum figures.
• A native MON transfer always costs exactly 21,000 gas.

Vessel has not published its keepers' per-function gas limits. Per-call gas limits and the measured cost of a rebalance on testnet UNVERIFIED — PENDING GATE-0 are unverified as of 2026-08-29; the protocol cannot claim a specific cost per adjustment until the contracts are published and measured.

Two further account-level rules shape keeper operation: each EOA keeps a reserve balance floor of 10 MON, and accounts near that floor are limited to about one transaction per 1.2s. A keeper wallet should be funded well above the floor.

EVM compatibility

Monad executes the EVM with parallel, optimistic concurrency, and the results are identical to serial Ethereum semantics. Contracts need no changes for parallelism. The consequences for Vessel are ordinary ones: Solidity, Foundry, standard ABIs, cast code against the RPC to check that a contract exists, EIP-1559 type-2 transactions with price_per_gas = min(base + priority, max). The Uniswap V2 router interface the spot leg implements and the IVenue interface the hedge leg calls are plain EVM interfaces.

There are limits to carry over: maximum contract size is 128kb, and several precompiles are repriced upward (ecRecover 6,000, ecMul 30,000, ecPairing 225,000, among others). Neither has been a constraint for Vessel's design to date, but neither has been tested against published contracts, since none are published.

What this page does not claim

Vessel is experimental software in testnet and unaudited. Monad's properties make the rebalancing loop affordable; they do not make the hedge correct. Delta drift, funding inversion, venue liquidity, and keeper liveness are Vessel's problems and are documented as such elsewhere on this site. The hedge venue today is SIMVENUE — SIMULATED SimVenue, a simulated venue with an owner-settable funding rate behind the IVenue interface; the Perpl integration is next. Figures on this page describe the chain, not the protocol's performance.

Sources: docs.monad.xyz for network parameters, vessel.wtf/litepaper for the band and timer, and skills.devnads.com for the developer-facing gas and execution notes.