# Robinhood Options Primitive v1 Status: **settled design**, accepted by Allan on 2026-09-12 and amended on 2026-10-01 to include transfer of the issuer position. Implementation and validation evidence belong to `opportunity/options-contract-evm`; this specification does not claim deployment or audit. The linked public testnet source snapshot implements the earlier fixed-issuer design, so its issuer behavior has not yet caught up with this amendment. Robinhood Chain is the first implementation target: mainnet 4663 and testnet 46630 are distinct environments. Ethereum, Base, and Solana remain broader intended product targets. ## Terms and lifecycle The issuer deposits a positive, fixed number of raw units of an ERC-20 collateral token. Creation also fixes a different ERC-20 payment token, a positive payment amount, and a future Unix expiry timestamp. Prices, decimals displays, and stock-token multipliers do not modify those amounts. Creation funds a separate escrow and issues one ERC-721 NFT to the original issuer in one atomic transaction. The NFT holder owns the transferable exercise right. The current issuer owns the issuer-side position: the obligation to deliver the funded collateral and the right to receive the exercise payment or a permitted collateral return. An open option may transfer that position to a successor writer before expiry. The successor must explicitly accept the position before the transfer becomes effective; the original issuer remains responsible until then. The original depositor remains recorded as historical provenance. The escrow address, deposited tokens, fixed amounts, and expiry do not change, and the issuer position is distinct from NFT ownership. Before expiry (`block.timestamp < expiry`), a holder other than the current issuer can exercise once: the holder pays the exact payment amount to the current issuer and receives the exact collateral amount. Both transfers, option closure, and NFT burn are atomic. Partial exercise and self-exercise are unsupported; an issuer holding the NFT uses cancellation instead. An issuer may cancel only while also holding the NFT and before expiry. Cancellation burns the NFT and returns the available collateral, capped at the original deposit. At expiry (`block.timestamp >= expiry`), transfer and exercise cease immediately. No grace period or automatic transaction is implied. Only the current issuer may reclaim the unexercised collateral, regardless of NFT ownership. Reclaim burns the NFT and returns the available balance capped at the original deposit. A shortfall cannot reduce the amount delivered on exercise; it instead makes exercise fail. Cancellation/reclaim can return a reduced balance, including zero, when the token allows it. Failed transfers revert the entire operation and remain retryable. ERC-721 approvals permit standard transfers, but do not authorize an operator to call exercise. An approved operator can still transfer the NFT to itself and then exercise as owner. Ownership and lifecycle changes cannot reenter during token or receiver callbacks. Closed options cannot settle again. Terms, original and current issuer, escrow, and final status remain queryable after NFT burn. ## Illustrative call and put patterns (explanatory) The original issuer is the first collateral depositor, often called the option writer. The current issuer may be a successor who accepted the writer position. The current ERC-721 holder owns the transferable exercise right. The original issuer initially receives that NFT, but the current issuer cannot self-exercise; cancellation is the issuer's pre-expiry path while it also holds the NFT. The NFT identifies the holder, while a separate contract escrow holds the ERC-20 collateral and releases it only through the collection's lifecycle rules. NFT ownership does not grant direct withdrawal from escrow. V1 does not store a call or put type. In a **covered call pattern**, the issuer escrows a fixed amount of an underlying ERC-20. A non-issuer holder can deliver the fixed amount of a different payment ERC-20 to the current issuer and receive the underlying collateral. In a **cash secured put pattern**, the issuer instead escrows the fixed payment-token amount. A non-issuer holder can deliver the fixed underlying ERC-20 amount to the current issuer and receive the escrowed payment token. Here, "cash secured" means funded ERC-20 collateral; it does not establish fiat custody or any stablecoin redemption right. These are applications of the same fixed-token exchange, not new contract types or additional v1 rules. The holder's delivery on exercise is the **exercise payment**, not an option premium. A premium would be a separate price for acquiring the exercise right; sales and premium handling are outside this primitive. The agreed token amounts do not depend on a market price. There is no price oracle, price-triggered exercise, or automatic settlement: an eligible holder may choose to exercise at any time strictly before the expiry timestamp, even when the exchange is unfavorable. This is an American-style exercise window, with the exact timestamp boundary specified above, rather than European-style exercise only at expiry. At or after expiry, an unexercised right cannot be used, and the issuer must call reclaim to retrieve available collateral regardless of market price. ## Custody and token behavior Admission is permissionless; both addresses must have contract code, be nonzero, and be distinct. Native ETH is not a settlement asset. Funding and contractual transfers require exact observed sender debits and recipient credits. Conventional ERC-20s and successful transfers with no return value are supported. Safe transfer wrappers and balance checks do not prove that an arbitrary token is honest. Taxed, rebasing, frozen, confiscatable, or dishonest tokens may make fulfillment impossible. There is no protocol insurance or administrator ability to repair their balances. Each option has an ERC-1167 escrow clone bound to its immutable collection. Initialization occurs once. Lifecycle calls are restricted to that collection. An option's obligation is its stored amount, not the escrow's entire balance. Separate custody limits cross-option accounting exposure; shared-code vulnerabilities can still affect every instance. Ordinary ERC-20 transfers do not ask the recipient for permission, so unsolicited deposits cannot universally be rejected. They create no option rights and do not change terms. After exercise, cancellation, or reclaim, only the issuer can recover residual ERC-20 balances, paid to the issuer. Recovery is a separate safe-transfer operation; a failing unrelated token cannot block settlement. No administrator recovery path can access escrow assets. Forced native ETH is outside the ERC-20 recovery interface and has no effect on accounting. ## Versions and management A registry administrator registers immutable collection versions and selects the current version. Administrator handover requires acceptance by the new administrator; the administrator may be a multisig. Activation is immediate. Only the selected version may create options. A previously registered version can be selected again. Retired versions continue transfers, exercise, cancellation, reclaim, and recovery for their existing options without consulting the registry. Each version permanently fixes its NFT ownership rules, escrow implementation, and settlement logic. The registry has no arbitrary call, NFT rewrite, escrow withdrawal, or live-code upgrade authority. Management can select unsafe code for future issuance; clients must review the exact selected version and approvals. There is no claim that registration is a security audit. ## Interfaces and observations - `createOption(collateralToken, collateralAmount, paymentToken, paymentAmount, expiry)` returns option ID and escrow address; the caller is both original/current issuer and initial NFT holder. - `exercise(optionId)`, `cancel(optionId)`, `reclaim(optionId)`, and `recoverERC20(optionId, token)` implement the rules above. - The issuer-side position may be transferred on an open option only after successor acceptance. The exact interface and any separate sale consideration remain implementation decisions; the transfer must update the payment, cancellation, reclaim, and residual-recovery recipient and authority together without moving collateral from escrow. - `getOption(optionId)` returns immutable terms, original/current issuer, escrow and effective status. Expired is a time-derived status until an issuer reclaim records terminal closure. - Standard ERC-721 transfers, approvals, interface detection, and minimal onchain JSON metadata expose the exercise right. NFT metadata includes raw terms and never depends on token symbols or a hosted metadata service. - Creation, issuer-position transfer, exercise, cancellation, reclaim, residual recovery, registration, and activation emit events. NFT mint, transfer, approval, and burn use standard ERC-721 events. ## Milestone boundaries and verification The milestone includes local contracts, tests, threat analysis, gas measurement, independent review, and deployment preparation. It excludes sales, premiums, marketplaces, pools, pricing, oracles, fees, cross-chain transfers, public publication, and transaction broadcasts. No audit, liquidity, demand, eligibility, or production-readiness claim follows from local validation. Required evidence covers atomic funding/settlement, permissions, exact expiry boundaries, shortfalls, unusual tokens, unsolicited deposits, callback reentrancy, cross-option isolation, single settlement, version changes, and administrator handover. Gas comparisons must use matching behavior and distinguish measured gas, one-time deployment costs, fee assumptions, and L1 data fees. Sources: [ERC-20](https://eips.ethereum.org/EIPS/eip-20), [ERC-721](https://eips.ethereum.org/EIPS/eip-721), [ERC-1167](https://eips.ethereum.org/EIPS/eip-1167), [exercise-style definitions](https://www.optionseducation.org/referencelibrary/faq/options-exercise), [Robinhood networks](https://docs.robinhood.com/chain/connecting/), [Robinhood stock-token units](https://docs.robinhood.com/chain/building-with-stock-tokens/). Public implementation snapshot: [v1 Solidity source and tests](https://github.com/CipherPlayLabs/opportunity-options-contracts/tree/18ecc3263c69eb1fefc23e8d3ad39dfbf0c75980).