How it works

1.1 The two positions, and why they are always covered

The strategy is only ever in one of two states.

The word doing the work in both names is the first one.

A covered call is covered because the ETH that would have to be delivered is already sitting in the account. We are not promising to find ETH later; it is there, untouched, for the whole life of the option.

A cash-secured put is secured because the full cash needed to honour the purchase is already sitting in the account. Selling a put with a $2,800 strike on one contract means $2,800 of USDC is committed and cannot be spent on anything else.

This is the single most important structural property of the product, so it is worth stating plainly: the position size is derived from the collateral, not the other way round. The engine sizes every trade against the balance actually present:

ETH-side, covered call:
    qty = floor(ETH balance / step) × step

USDC-side, cash-secured put:
    qty = floor(USDC balance / strike / step) × step     subject to strike × qty ≤ USDC balance

The obligation cannot exceed the capital, by construction rather than by policy. Rounding down to the exchange’s contract step leaves a small unused remainder, which acts as an incidental buffer.

There is no leverage anywhere in the product. Margin utilisation on the intended configuration is expected to run 10–25%, and margin has never been the binding constraint on position size. That range is a design expectation, not a measurement — what actually happens to PM2 utilisation under our construction is open question O7 (§4.4), and the one live margin reading we have suggests the haircut assumption behind the range is far too conservative.

1.2 The wheel

Each option runs to expiry. At expiry it either finished out of the money (the price never reached the strike — the option expires worthless) or in the money (it reached the strike).

Read down the ITM rows and the shape of the strategy appears: it sells high and buys low, and the prices are the strikes you chose. A call assigned at $3,200 means the ETH left at $3,200, plus the premium already collected. A put assigned at $2,800 means ETH was acquired at $2,800, minus nothing. The wheel is a systematic way of getting paid to place limit orders you were willing to place anyway.

The upside is that you are paid whether or not the order ever fills. The cost is that on the ETH side, any appreciation above the strike is not yours — this is a real and permanent trade-off, and it is covered in Risks.

1.3 What “assignment” physically means here

This is the part most descriptions of the wheel get wrong for this venue, and it drives a large amount of the engineering.

Options on Derive are European and cash-settled in USDC. There is no physical delivery. When a call finishes in the money, the exchange does not take your ETH — it debits USDC from the account for the difference (S − K) × qty, where S is the settlement price. On an ETH-side account there is no USDC to debit, so the account goes into deficit.

So the “assignment” of a classical wheel is not something the exchange performs for us. It is something we perform, and the arithmetic only closes if we convert the entire balance:

The result is exactly the classical wheel outcome. The deficit is not the point of the mechanism — it is simply the asymmetry that cash settlement introduces on the call side, and it must be handled rather than wished away.

1.4 The life of one cycle, end to end

  deposit                     selection                  execution
  ─────────                   ─────────                  ─────────
  user's own wallet      →    read the live board   →    ask BOTH venues
  bridges to a                filter by threshold        (order book + RFQ)
  per-user address                  ↓                          ↓
        ↓                     user picks a strike        maker order, 20 min
  arrives on Derive Chain     (or the engine does)             ↓
        ↓                                               fill, else take the
  moved to the platform                                 best available price
  wallet, same chain                                          ↓
        ↓                                               premium credited
  deposited into the
  user's subaccount


  08:00 UTC                   settlement                 next
  ─────────                   ──────────                 ────
  expiry. Settlement     →    OTM: nothing to do    →    roll into the next cycle
  price = 30-minute TWAP      ITM: run conversion         or pause, or withdraw
  of the index, 07:30–08:00        ([the conversion](/how-it-works#16-the-conversion-when-an-option-lands-in-the-money))

Deposits. Each user gets a unique deterministic address on Derive Chain. The user’s own wallet makes the bridge transaction — the backend never builds or signs it, it only says where to send and then watches the chain. The bridge mints the wrapped token directly to that address on Derive Chain, so there is no cross-chain hop on our side at all: the internal transfer to the platform wallet happens entirely within Derive Chain. From there the funds are deposited into the user’s subaccount (an NFT on Derive that is the unit of margin).

Attribution is by destination address, not by sender, so a deposit arriving from an exchange still lands with the right user. One consequence worth stating: the bridge has no native-ETH vault, so native ETH must be wrapped to WETH before it can cross, and the user is told before they press the button that they will get WETH back on the way out.

Withdrawals are the mirror image: the backend signs everything, and the recipient is always the address the user logged in with. There is no destination field in the withdrawal request — not “ignored”, but not declared at all. A request carrying one has the extra key silently dropped by validation, and the recipient is then filled in from the authenticated user — so a user cannot direct funds anywhere except back to themselves.

Expiries on Derive fall daily at 08:00 UTC, but the product only ever sells the weekly Friday ones, at least three days out — dailies have books two to three times thinner. The settlement price is a 30-minute TWAP of the index over 07:30–08:00, which makes it expensive to manipulate and independent of any single print.

1.5 Choosing what to sell, and how it gets executed

Not every option is worth selling. The board carries hundreds of instruments and most of them are economically dead — the fixed exchange fee eats the entire premium. Selection therefore runs a composite threshold. Three economic conditions must hold:

Alongside these sit structural filters that narrow the board before the economics are even considered: |delta| between 0.15 and 0.60, Friday expiries only, 3 to 30 days out, the three nearest of those — and, in automated mode, a strike the signal has marked.

Filters 1 and 2 are orthogonal and both are needed. A measured example: at 7 DTE and delta 0.098 a bid stood at 89% of mark — passing the relative test — while the fee consumed 33% of the premium. Conversely at 1 DTE and delta 0.068, a bid at 76% of mark annualised to 1.4%.

Execution asks both venues, every time. Order-book liquidity on this venue is intermittent rather than thin — on the 2026-08-12 snapshot there were no bids at all beyond 4 days to expiry, while the next day 7- and 14-day expiries had bids standing at 93–97% of mark. Hardcoding either “always the book” or “always RFQ” would be reliably wrong, so the engine takes the better of the live book bid and a request-for-quote from market makers, which costs nothing to ask. A valid RFQ quote has never been observed (open question O3), so today this is a second venue the engine asks rather than a second venue it has been shown to trade on.

Maker first. At a 0.5 ETH notional the exchange fee is $0.09 as a maker versus $0.78 as a taker. On a $3 premium that is 3% versus 26%. So the engine posts a passive order between the best available price and mark, waits 20 minutes, and only then crosses the spread unconditionally. The only thing risked by trying is time. If nothing works, the cycle retries until a 20:00 UTC deadline and then stops for good — the chain does not resume by itself the next day (§4.4). How often that happens, and why, is one of the primary numbers the first live run exists to produce.

1.6 The conversion, when an option lands in the money

This is the most operationally demanding part of the system, because it moves real money across three chains under time pressure with no path back.

subaccount → Derive Chain → bridge → Base → swap → bridge → Derive Chain → subaccount

Four properties of the design are worth an investor’s attention:

It starts itself. The moment settlement is booked, the position step hands the conversion off and closes; the conversion is a separate machine with its own lifetime and does not wait for the cycle. During the expiry window it runs on a five-second tick rather than a one-minute one — a minute would otherwise be burned doing nothing between “settlement price published” and “swap sent”.

It predicts, then confirms. Around ten minutes before expiry a projector estimates from the spot feed whether the option will land ITM, and if so begins moving the withdrawable fraction out early. That fraction is read live from the exchange’s own margin simulator, not assumed — the measurement put it at 64–76%, against the 50% the original design had guessed. But the swap never happens before settlement is final. A mis-prediction that had already swapped would mean a user’s ETH sold when it should not have been, and a swap does not reverse. A mis-prediction that has only bridged costs about a cent in gas, and the funds simply bridge back.

The projector is accurate because it does not guess: it averages the settlement window that has already elapsed. Checked against a real expiry, it came within 0.3 basis points of the price the exchange actually used.

The rollback path is the normal path minus one stage. If the prediction was wrong, the row skips the swap stage and continues through the same bridging and depositing code. There is no separate unwind routine — a rarely-exercised money path is exactly where a defect survives unnoticed until the day it is expensive.

Slippage tolerance is discovered, not assumed. The system simulates the trade at 3, 6, 12, 25, 50 and 100 basis points and stops at the first tolerance that succeeds, rather than defaulting to a wide one. On top of that, a price sanity guard compares the execution price against Derive’s own index and aborts beyond 100 bps. It is checked twice, but only the first check can abort: before signing it stops the swap, while after the receipt the money is already exchanged, so the second check records the trade anyway and its job is to summon a human.

After the swap, failure is never terminal. Once the ETH is sold, the money is on another chain in another asset. From that point the code has no “give up” branch at all: bridging back and depositing can only retry and alert. Marking them failed would mean abandoning a user’s funds on Base.

1.7 Where the boundary sits: Derive versus us

We are a layer on top of a venue, not a venue. We do not run a matching engine, hold an order book, or price options ourselves.