The protocol,
end to end.

Three properties that fall out of the design

• -Nothing can default. A writer must escrow the collateral before an offer appears on the shelf: OfferBook.list calls escrow.commit before it writes the offer struct. Every option in circulation is backed by collateral already sitting in WriterEscrow. There is no margin, no leverage on the writer’s side, and no liquidation engine, because there is nothing to liquidate.
• -There is no oracle. Anvil settles physically: the holder pays the strike and receives the underlying. Nobody rational does that unless the option is in the money, so the holder’s own decision carries exactly the information a price feed would have supplied.
• -The protocol never prices anything. Writers name their own premiums. A writer who prices badly is the one who finds out. Anvil has no volatility surface to maintain and no model risk, and it cannot be arbitraged through mispricing because it never quotes.

A worked example

Gold at $4,500 an ounce. A writer escrows 100 oz, lists calls at a $4,700 strike expiring in thirty days, and asks $35 per contract of one ounce.

Gold at $4,400  not exercised   buyer  -$3,500 premium
                                writer keeps 100 oz + $3,500

Gold at $4,650  not exercised   buyer  -$3,500 premium
                                writer keeps 100 oz + $3,500

Gold at $5,200  exercised       buyer  pays $470,000 for gold worth $520,000
                                       net +$46,500 after premium
                                writer gets $470,000 + $3,500,
                                       gave up gold worth $520,000

The writer’s downside is never losing money. It is underperforming holding. They keep the first 4.4% of any rally, from spot up to the strike, plus the premium, and give up everything above $4,700. That is the trade, and it should be stated plainly to anyone writing.

One thing the prose gets wrong

Every document in this repository describes a single instrument: the writer escrows the underlying, the holder pays quote to take it. The contracts are more general than that. AnvilTypes.sol declares OptionKind { CALL, PUT }, createSeries takes a kind, and AnvilMath.collateralLeg and strikeLeg swap the two tokens for a put:

         collateral leg          strike leg
CALL     underlying, size        quote, strike
PUT      quote, strike           underlying, size

A put is the same machine with the tokens swapped, and it has an integration test of its own. Where this page says “underlying” and “quote”, the contracts say “collateral leg” and “strike leg”, and for a put those are the other way round.

The series is the atomic unit

A series is one tradeable line, fully described by its terms. Every offer, option token and escrow balance is scoped to one. The id is a hash of the terms, so the same terms always name the same series and two people opening “$4,700 gold calls expiring Friday” independently land on the same line rather than on two thin ones.

struct Series {
    address     underlying;    // the asset being priced
    address     quote;         // the token the strike is denominated in
    uint128     contractSize;  // underlying per contract, in its own units
    uint128     strike;        // quote per contract, in its own units
    uint64      expiry;        // unix seconds; exercise is impossible after
    OptionKind  kind;          // CALL or PUT - decides which token is collateral
    SeriesStatus status;       // NONE | ACTIVE | EXPIRED
}

There are no fixed-point prices anywhere in Anvil. A strike is quote-per-contract in the quote token’s own units and a contract size is underlying units, so every number in the system is a raw token amount. That removes an entire class of decimal-scaling bugs, at the cost of a frontend having to know both tokens’ decimals.

Listing an asset is admin-gated; opening a strike is not. SeriesFactory.listAsset fixes the quote token, contract size and tick for an underlying, and after that createSeries is permissionless: an empty series holds no collateral and obliges nobody, so gating it would only slow the market down. Expiry must be in the future and within maxHorizon, which initialises to 180 days.

The tick grid

Strikes must be an exact multiple of the asset’s tick. createSeries reverts with StrikeOffGrid otherwise. Without it you get a long tail of near-identical strikes ($150.00, $150.01, $150.02), each holding thin inventory that nobody can compare and nobody can fill.

Snapping concentrates writers onto rungs a buyer can actually compare. It is the only place in the protocol where a design decision exists purely to make a market legible rather than to make it safe.

Availability is an identity, not a cap

A strike is not an infinitely deep order book. It holds exactly as many contracts as writers have collateralized:

available = listed − sold

listed rises when a writer escrows and offers, and falls when they pull an unsold offer. sold only ever rises. So “132 available” means 132 contracts are genuinely backed by underlying sitting in escrow right now: not a limit somebody chose, and not a quote that evaporates when you click it. recordSold reverts with InsufficientAvailability rather than overselling.

The ladder, and sold-out routing

InventoryManager keeps the strikes for an underlying and expiry in a sorted list, inserted in position at series creation. When a strike sells out it exposes the nearest live rung above and below, so a buyer can be routed on-chain rather than trusting the frontend to know what is left.

ladder(underlying, expiry)            -> Rung[]  every strike, ascending
nextRungUp(underlying, expiry, K)    -> Rung    nearest at or above K
nextRungDown(underlying, expiry, K)  -> Rung    nearest at or below K

struct Rung { bytes32 seriesId; uint128 strike; uint128 available; }

Both searches skip rungs with nothing behind them. A registered but unwritten strike is not somewhere a buyer can go, so it is not offered as an alternative. If no rung qualifies, the call reverts with NoLadderRung rather than returning an empty struct that a caller might mistake for a real one.

What cannot happen

A writer cannot cancel an option someone is holding. cancel returns only the unsold remainder; contracts already bought stay collateralized until expiry. A buyer cannot buy their own offer; fill reverts with BuyingOwnOffer. A holder cannot exercise at or after expiry; exercise reverts with Expired. A writer cannot settle before expiry, or twice.

The one thing that can go wrong is a holder forgetting. An in-the-money option left alone until expiry pays nothing, the same as on any physically settled venue, and the reason a frontend should nag.

Why it is deferred

Gas. Exercise costs O(1) regardless of how many writers back a strike. The obvious alternative (walking a writer list on every exercise and marking each one assigned) gets more expensive the more writers a series attracts, which is exactly backwards: the most popular series would be the most expensive to trade.

The cost of deferring is that a writer does not know their assignment until expiry. They know the ratio can only move against them as more exercises land, and they know their maximum: they can be assigned on every contract they sold, and never on one they did not.

Why the ratio has to stay fixed

settleWriter zeroes the writer’s own position but deliberately does not decrement the series totals. If it did, the denominator would shrink as writers settled and a later settler would compute a different assignment than an earlier one for the same series. The pool totals are frozen at expiry so every writer gets the same answer whenever they show up.

// Zero the writer's position before paying out. `_pools` totals are
// deliberately NOT decremented: the assignment ratio must stay fixed
// across every writer's settlement, or later settlers get a different
// answer than earlier ones.
_committed[seriesId][writer] = 0;
_sold[seriesId][writer] = 0;

Rounding favours the pool

Assignment rounds down. The sum of every writer’s assignment can therefore fall a few units short of the quote the pool actually took in: at most one unit per writer. That dust stays in escrow and is recoverable by admin through skim, which can only ever move the difference between the held balance and the tracked obligations for that token.

The direction of the rounding is the point. It always errs toward the pool holding too much rather than too little, so it can never leave a writer unpaid. skim cannot reach collateral, because collateral is inside obligations.

The same accounting is what makes solvency checkable from outside: obligations(token) is what the escrow owes in that token, and the escrow’s balance should always cover it.

Why commodities and equities lead

The instinct to open with the safest asset is right about risk and wrong about revenue, if “safest” means a tokenized T-bill. An at-the-money option is worth roughly

premium ≈ 0.4 × S × σ × √T

which means premium scales with volatility. Over thirty days, as a fraction of notional:

A T-bill is safe to write because there is nothing to insure. At 0.06% the writer earns about $60 per $100,000 committed for a month, and locks the capital up to do it. That is not a conservative first product; it is no product. Tokenized T-bills are absent from the listed set for exactly this reason.

Gold and equities are the sweet spot: real premium, and a tail that behaves nothing like crypto. They lead the ladder. Real-world assets still belong on the collateral side (idle base asset parked in a yield-bearing T-bill token), just not on the underlying side. One caveat from WriterEscrow: rebasing tokens break its fixed-amount accounting, so use a non-rebasing wrapper.

How the sample chains are generated

None of the numbers on the trade desk are market data. What is real is the shape: each chain is generated from one two-term model rather than typed by hand, so the relationships an options chain cannot violate hold everywhere by construction.

call(K) = max(S − K, 0) + TV(K)
put(K)  = max(K − S, 0) + TV(K)

// Both sides take the SAME time value at a given strike, so
// put-call parity holds exactly:
call(K) − put(K) === S − K

Strikes are centred on spot, snapped to the market’s tick, five rungs either side. One rung per side is sold out on purpose, so routing to the nearest live rung stays demonstrable on the desk. That is a display decision, not a protocol one.

Where the per-series numbers come from

They are set so the worst realistic single-series loss lands at roughly the same fraction of capital in every tier, about 1.5%. A more volatile asset is not banned; it is sized down until it hurts the same amount when it goes wrong.

That equalisation is the principle worth keeping if the numbers are ever retuned. The specific percentages are governance’s opinion; the property that a tier-3 blowup and a tier-1 blowup cost the vault the same is the design.

Why utilization is attached to the tier

Utilization is a global measure (total capital committed across everything), but the cap checked is the one belonging to the tier being written. The effect is that the riskiest asset carries the tightest gate on the whole book: a tier-3 write only clears if total commitment is under 45%, while tier 1 can run the book to 85%.

Why tenor tightens as volatility rises

Variance grows with the square root of time, so a 90-day position on a 100%-vol token carries far more of it than a 90-day position on gold. Tenor is also lockup: deposits and redemptions are shut until every position settles, so a long-dated write on a volatile name holds every depositor hostage to it.

The limit that is not enforced

Moneyness. “The strike must be within 20% of spot” is the single most useful limit an options book can have, and it cannot be checked without a price. Enforcing it would put an oracle back in the critical path, the dependency the whole protocol was designed to avoid.

The tradeoff is not symmetric, and it is worth being precise about. An oracle used only for pre-trade limits is far weaker than one used for settlement: if it breaks, the vault stops writing, it does not pay the wrong person. That makes it a defensible thing to add later. It is left out for now so the assumption stays visible.

A manager choosing sane strikes is an off-chain assumption, not an on-chain guarantee. A manager who writes deep in-the-money options passes every check in this contract and loses the vault its money on the first expiry. Volatility is unverified too: tiers encode governance’s view of how volatile an asset is, and an asset can change regime faster than governance moves.

console2.log("Reminder: moneyness is NOT enforced on-chain.");
console2.log("A manager can write deep-ITM strikes and pass every check here.");

Why it exists

Anvil’s order book cannot fill an order nobody wrote. Early on there are no writers, so a buyer clicks buy and nothing happens. The vault is the counterparty of last resort: capital that is always willing to write, so the shelf is never bare. That convenience is paid for by the people whose capital it is.

It is a client, not a core module

The vault writes through AnvilCore exactly as a person would, and the protocol cannot tell it apart from one. Nothing in the venue changed to accommodate it. That separation is the point: the venue keeps its property of being unable to lose money, and the risk lives behind an explicit deposit instead of in the protocol everyone else uses. Someone who only wants to trade never touches it.

Share pricing without an oracle

An ordinary vault marks its open positions to compute a share price, and marking an option needs a price feed, the exact dependency Anvil removed. Two decisions avoid reintroducing it.

• -Rounds. Deposits and redemptions are only open while the vault is flat, with no unsettled positions. roundActive() is the gate, and both deposit and redeem revert with RoundIsActive while it is true. There is never a moment where someone can enter or exit at a stale mark, because when the gate is open there is nothing to mark.
• -In-kind redemption. Leaving hands you a pro-rata slice of every token the vault holds, not a valuation of it. If assignment left the vault holding the underlying, redeemers receive underlying. Nobody has to agree on what anything is worth.

The cost is a lockup: capital cannot leave mid-round. That is disclosed rather than engineered around, because the alternative is an oracle.

One asymmetry worth understanding

Redemption works on a mixed vault; it pays out in kind across everything held. Deposits do not. If a previous round ended in assignment, the vault is sitting on underlying, and someone depositing only the base asset would buy a share of that underlying for nothing, diluting everyone already there. Pricing that deposit fairly would need to value the underlying, which needs a feed.

if (roundActive())     revert Errors.RoundIsActive(round);
if (!_holdsOnlyBase()) revert Errors.VaultNotInBaseAsset();

// First depositor sets the peg 1:1. Afterwards shares price off the
// base-asset balance, which is exact because it is all the vault has.
shares = totalShares == 0 ? assets : (assets * totalShares) / held;

LPs can always leave; they cannot always enter. That asymmetry is the price of not having a price feed, and it falls on the person trying to get in rather than the person trying to get out, which is the right way round.

Trust assumptions

Worth being explicit, because this module has more of them than the rest of Anvil put together.

• -The manager sets every premium. Underpricing bleeds depositors slowly and invisibly. This is the single largest risk and it is not enforceable on-chain.
• -The manager chooses what to write, and can therefore concentrate the vault into one strike or expiry, up to whatever RiskLimits allows, and RiskLimits is optional: writeOffer skips the check entirely when the address is zero.
• -Admin can replace the manager, but cannot touch deposits or force a redemption.
• -Settlement is permissionless. Depositors never need the manager’s cooperation to get the vault back to a redeemable state; anyone may call settlePosition.

This module has no tests. Not incomplete tests: no test file at all. It is also absent from script/Deploy.s.sol on purpose; script/DeployVault.s.sol exists for it, and has never been broadcast to any chain.

Where the READMEs and the Solidity disagree

Found while transcribing the signatures above. In every case this page follows the Solidity, because the Solidity is what would run.

The instrument ladder

Every rung keeps the founding rule, collateral before the contract exists, and each one asks a little more of the treasury than the last. The first rung asks nothing, which is why it is the one trading today.

The flywheel

The venue’s take is two small tolls on activity: the fee on premium (FeeController, capped by an immutable constant) and the 30 bps spread on the payment leg every desk purchase crosses. Neither requires the treasury to trade, predict, or hold risk; both scale with nothing but usage. That is the whole engine.

1. 01

   The venue trades

   Writers escrow collateral and list; buyers pay premium. Every fill routes the fee on premium to the treasury, and every purchase crosses the ANVIL book on the payment rail, where the 30 bps spread on that leg accrues to the treasury too.

2. 02

   The treasury grows

   Two streams, both proportional to volume, neither dependent on the treasury taking risk. Part of the take accrues in ANVIL itself, so venue usage is structural demand for the token rather than a story about one.

3. 03

   The balance sheet unlocks capacity

   Position limits in the risk tiers are sized so the worst plausible loss on a single series costs the same share of the treasury whichever asset it is. A larger treasury therefore means larger limits, more listed markets, and eventually the next rung of the instrument ladder.

4. 04

   Capacity attracts flow

   Deeper books, bigger size and richer instruments bring more writers and buyers, whose trades are step one. The loop closes; each turn is funded by the last one.

The order of operations matters. A venue that sold undercollateralized options first would be borrowing against a treasury it had not earned; this one sells the instruments that need no backstop, lets the tolls compound, and buys each new capability with retained earnings. Usage funds capacity, capacity earns usage, and the treasury is the flywheel’s bearing: everything turns around how much stands behind the venue.

The strategy: covered calls at mass-market scale

Covered calls are the oldest conservative options strategy there is, and packaged “buy-write” products are enormous in traditional finance: JPMorgan’s JEPI grew into one of the largest actively managed ETFs doing essentially what an Anvil writer does, and Global X’s QYLD built roughly eight billion dollars doing it mechanically. “Own the asset, sell the upside, collect income” is demonstrated mass-market demand, not a thesis.

The collateral model: the DOV wave

The 2021 DeFi Option Vault generation: Ribbon Finance (peaked above $300M TVL), Thetanuts, Friktion, Katana, sold fully collateralized covered calls and marketed exactly the property this protocol is named for: full collateralization eliminates liquidations entirely. The writer side of this design is proven at scale. The epilogue is instructive too: vault yields compressed as everyone sold the same expiries, the 2022 bear punished depositors, and Ribbon pivoted into Aevo, a leveraged derivatives exchange; the model this protocol deliberately rejects.

The settlement mechanic: Opyn v1, and oracle-free precedent

Opyn’s first protocol (2020) issued fully collateralized, physically settled options: the holder paid the strike and took the asset, no oracle involved. Structurally it is the closest ancestor of this design, and it worked mechanically; it never found liquidity, and Opyn v2 chased capital efficiency into margin and cash settlement. Panoptic later showed “oracle-free options” can carry a protocol, via a very different mechanism over concentrated-liquidity positions.

A live neighbor

Meraki offers fully collateralized calls and puts on tokenized equities, deployed on the same chain this protocol targets, with one decisive difference: it settles in cash against live oracles. It validates the market while leaving this design its differentiation: physical settlement, no oracle to manipulate, and writer-set premiums instead of oracle marks.