Series and position tokens

What a series is

A series is the unique combination of asset, strike, expiry, and call-or-put — "NVDA, $160 strike, calls, expiring 2026-07-17." Every offer written against that exact combination shares one series. A different strike, a different expiry, or a call instead of a put is a different series entirely, with its own token, its own collateral, its own life.

Options as tokens, not database rows

The first version of this idea tracked ownership in a plain internal ledger. That works, but it's a dead end: a position trapped in a private ledger can't be sold, transferred, or used anywhere else, because nothing outside the contract can see or move it.

Plume instead mints a standard ERC-20 token for every series, deployed the moment the series' first option is bought. The token is a minimal clone — cheap to deploy, identical in behavior to any other token — named for what it represents, something like NVDA-C160-0717. From that point on, an option position isn't a claim recorded somewhere inside Plume. It's a token sitting in your wallet: sellable on any exchange willing to list it, sendable to another address, inspectable on a block explorer, all without Plume's app in the loop.

Minting and burning

Tokens mint in exactly one place: when a buyer purchases from a writer's offer, they receive series tokens equal to the amount bought. Tokens burn in three places: redeeming a settled position, exercising before expiry, or a writer buying-to-close their own written options. Nothing else moves supply. No admin mint function exists — the contract that governs a series is the only address ever authorized to create or destroy its tokens.

The conservation law

This is the invariant the test suite defends most aggressively, because a violation here is a violation of the collateral invariant itself — a supply bug is a collateral-release bug wearing a different hat.

totalSupply(series) == sold − redeemed − exercised − boughtToClose

At every point, for every series, this must hold exactly. It's checked under randomized fuzz testing — hundreds of runs generating arbitrary sequences of buys, exercises, closes, and settlements, checking after every single step that supply still reconciles and that the contract's balance is never less than what it could owe. If this check ever fails on any change to the code, that change is treated as broken regardless of anything else about it.

Why per-writer accounting, not a shared pool

When multiple writers sell into the same series, it would be simpler to lump all their locked collateral into one shared pool. Plume deliberately doesn't. Each writer's contribution is tracked individually, because a shared pool means one writer's assignment or early close can be paid out of collateral another writer locked — which quietly reintroduces the exact cross-user dependency the whole design avoids. Keeping accounting per-writer is what makes pro-rata assignment mathematically precise instead of approximate, and it's what makes one writer's actions incapable of affecting another writer's solvency.