Optionals: Physical Options Without a Price Oracle

Optionals treats an option as a right to exchange two assets, not a bet settled against a reference price. A writer chooses the underlying asset, strike asset, amounts, premium, and expiry, then deposits everything required to honor the offer. Once it is filled, the buyer receives a transferable receipt. Until expiry, whoever holds that receipt may deliver the strike asset and claim the locked asset. The contract needs custody, ownership, and time to enforce the agreement. It does not need an external market price.

Every offer records a position type, the two assets being exchanged, the amount represented by one unit, its strike, premium, and expiry. A covered call reserves the underlying asset for every unit offered. A secured put reserves the complete strike-side amount instead. The premium is paid when the offer is filled and does not change afterward. Token amounts are stored exactly as supplied, including each token’s own decimals, so the contract enforces the written terms rather than estimating their market value.

An option begins when its writer locks collateral and lists the terms. A buyer fills some or all available units, pays the premium, and receives an ERC-1155 position receipt. That receipt can move between wallets. Its current owner, who may not be the original buyer, controls the right to exercise. Exercising before expiry burns the receipt and performs the promised token exchange. If no holder exercises in time, the remaining receipts become inactive and the writer can recover the collateral attached to those expired units.

Discovery can be fast without making an indexer authoritative. Contract events are organized into a searchable catalogue so an interface or agent can compare live offers efficiently. Once a user selects one, the application reads the offer again from the contract, checks current availability and expiry, then simulates the exact action the wallet will sign. The indexer may help a user find an opportunity, but only contract state can authorize a fill, exercise, cancellation, or recovery. A stale interface therefore cannot change the settlement rules.

Security begins with a simple invariant: for every asset, the amount reserved across open positions can never exceed the contract’s actual balance. Collateral arrives before an offer becomes sellable, and transfers are checked using exact balance changes rather than assumed token behavior. Fees are snapshotted with each offer, external transfer paths are non-reentrant, and administrative controls cannot pause a holder’s exercise or a writer’s recovery. The design deliberately excludes leverage, rescue functions, arbitrary callbacks, upgradeable settlement logic, and oracle-valued cash payouts that would widen the trusted surface.

Optionals is built as one continuous path from offer creation to physical settlement. The contract holds collateral and enforces the exchange. The event indexer turns onchain activity into a catalogue that people and agents can search quickly. The read API and TypeScript SDK expose the same offer model to interfaces, while transaction simulation checks the exact fill, exercise, cancellation, or recovery before a wallet signs. Invariant tests connect those layers around the same rule: every open promise remains backed by the assets required to complete it.

This registry will hold the canonical Robinhood Chain addresses for the market and its supported settlement assets. Once deployment and source verification are complete, every entry will open its matching Robinhood Scan contract page so integrators can inspect code, read state, and verify transactions from one consistent reference. The names and roles are shown now; explorer links will become active when the verified addresses are available.