Last updated 12 September 2026

The options grid

Every option the protocol can issue is a point on a fixed grid. The grid is baked into the contract at deployment — you draw from it, you don't define your own parameters.

Why a grid at all

Liquidity fragments if every trader can invent their own instrument. A protocol allowing arbitrary strikes and dates ends up with thousands of unique options, each with one holder and no market. Constraining everyone to a shared, coarse grid means the same instrument gets reused, and pools accumulate depth instead of scattering.

The cost is precision: you take the nearest listed strike rather than the exact one you wanted. For an instrument whose value is dominated by volatility over days, that is a small price.

Strikes

248 values, spanning eleven orders of magnitude from 0.000001 to 10,000,000.

The ladder is approximately geometric, with a median step of about 11% between neighbouring strikes. Coverage is therefore proportional rather than absolute: a strike near 100 has neighbours roughly 11 apart, a strike near 100,000 has neighbours roughly 11,000 apart. That is the right behaviour for assets whose prices differ by orders of magnitude, and it means one grid serves BTC at five figures and a token priced in millionths equally well.

Strikes are stored as 24-bit codes in exponential form — four significant digits, a sign bit for the exponent's direction, and the exponent itself — which is what keeps the whole ladder inside a compact identifier. The decoding rule is in TokenID format.

Maturities

104 consecutive weekly expiries, every one a Friday, currently running out to 2028-07-07.

Weekly-only is a liquidity decision for the same reason the strike grid is coarse. Most volume in options markets, on-chain and off, concentrates in the nearest weeklies; offering daily or monthly expiries alongside them would split that volume without adding much.

Maturities are packed as a 24-bit date — year offset from 2000, month, day.

Underlyings

Any registered Chainlink price feed. Registration is a protocol action, not a user one: before options can be written against a feed, the feed must be added, and the contract verifies it against Chainlink's own Flags registry at that point.

The same feed supplies both the live price used by the AMM's pricing model and the settlement price at expiry.

To list what is currently available:

ISFOptions(0xf0022aC3…).getAllPriceFeeds()
// → (address[] feeds, string[] descriptions)

The descriptions are Chainlink's own labels, such as ETH / USD. Because the grid is defined independently of the underlying, adding a new feed instantly makes all 248 strikes × 104 maturities available on it, with no further deployment.

Type, kind and direction

Three more dimensions complete an option:

How many options is that

248 strikes × 104 maturities × 2 types × 2 directions = 103,168 distinct tokens per feed, all addressable under a single ERC-1155 contract, all requiring no deployment of their own. This is the practical argument for ERC-1155 here: one contract, a six-figure instrument universe, and a token id that encodes its own meaning.

Reading an option's name

Token metadata is generated on-chain, with no external server involved — the contract unpacks the id and builds the name from it. A token's name reads:

Stochastic.Finance Option  ETH / USD    1853   European  Call   Long   2026-07-17
                           └ feed ─┘  └strike┘ └ kind ┘ └type┘ └side┘ └ maturity ┘

Dates are rendered YYYY-MM-DD, which sorts correctly and can't be misread as month-first. Strikes are rendered as plain decimals with trailing zeros trimmed, so a strike of one millionth appears as 0.000001 rather than in scientific notation.

The metadata is returned as a base64 data: URI containing JSON with the same fields as attributes, so wallets and explorers show a readable position without any integration work.

Next

• TokenID format — how the six fields pack into one identifier
• Payoff & pricing — what a point on the grid is worth
• Minting options — issuing one