Protocol Features

Overcast is an options protocol. Two parties agree on the terms of an option, lock the assets on-chain, and receive transferable rights that let them exercise or reclaim the option later. This page walks through everything the protocol can do, roughly in the order a position moves through it.

Each feature notes the event it emits, so you can follow the same lifecycle from an indexer's point of view.

Deposit and withdraw

Before doing anything else, funds are moved into the protocol. Every account has a per-asset escrow account it fully controls.

• Deposit moves tokens into an escrow account. At the protocol level anyone can fund an escrow account: the payer and the credited owner are separate, so a third party can deposit on someone else's behalf. (The Solana SDK's deposit path is currently self-funding only — funder = depositor.) Offers draw their collateral and premium from these accounts, so the account is funded first. Emits Deposited.
• Withdraw moves idle tokens back out to the owner's wallet. Only the account owner can withdraw, and only funds that aren't locked in an open offer or option (and only when withdrawals aren't paused and the escrow account exists). Emits Withdrawn.

An option's terms

An option is described by a single, immutable set of terms agreed by both parties. There are exactly 2 + 1 assets, collateral and settlement, plus a premium. There are no other assets or other combinations.

Field	Meaning
domain	Chain domain the terms commit to.
startTimestamp / endTimestamp	The window in which the option can be exercised (unix seconds).
collateralAsset / collateralAmount	What the writer (maker) locks up.
settlementAsset / settlementAmount	What the holder (taker) pays to exercise.
premiumAsset / premiumAmount	The upfront price the taker pays the maker for the option.
settlementLayer	Which settlement layer gates exercising (see below).
borrowAllowed	Whether the collateral can be borrowed while the option lives.

The terms are fixed once the option exists. Both sides signed off on them, so nothing about them can change afterwards.

Writing an option

An option is created by matching two halves. Each half is a standing offer that locks the offering party's assets up front:

• Collateral offer, posted by the maker (the writer), locks the collateral_amount of collateral_asset. Emits OfferCreated with side: MAKER.
• Settlement offer, posted by the taker (the buyer), locks the premium. Emits OfferCreated with side: TAKER.

Both halves are the same kind of standing offer, distinguished only by their side. Either one can be closed by its creator while it is still unmatched, returning the escrowed assets. Emits OfferCancelled.

Note that the settlement asset is not locked at creation. Only the collateral and the premium are escrowed up front. The taker pays the settlement later, at exercise time.

Matching

Accepting matches a compatible collateral and settlement offer into a live market option. This:

• consumes both offers and creates the option,
• pays the premium from the taker to the maker's deposit,
• mints the two rights (below),
• runs the option-creation hook, which may levy a fee (FeePaid).

Emits MarketOptionCreated.

Rights: exercise and redeem claims

Creating an option mints two transferable rights (Token-2022 mints on Solana; ERC-20 claim tokens on EVM). They are what actually authorize the later actions, and because they are tokens they can be transferred to anyone. On EVM the holder of the right is who can act; on Solana the exercise/redeem handlers resolve claim accounts from the taker/maker identity, so a transferee holding the tokens cannot exercise/redeem through those handlers.

• Exercise right, minted to the taker, is burned to exercise the option.
• Collateral-return right, minted to the maker, is burned to redeem collateral after expiry.

Exercising

Between start_timestamp and end_timestamp, the holder of the exercise right can exercise, in full (or partially if the settlement configuration allows it):

• deposits the proportional settlement_amount into the option,
• receives the proportional collateral_amount out,
• burns that many exercise claims.

The configured settlement layer is consulted first and can allow, reject or modify the exercise (for example, an oracle-gated layer only lets an in-the-money option exercise). Emits OptionExercised.

Redeeming

After endTimestamp — or earlier once all exercise claims are burned (a fully-exercised option) — the holder of the collateral-return right can redeem to reclaim their share of whatever is left in the option: unexercised collateral plus any settlement that exercising takers deposited. Burns the return claims. The settlement layer is consulted and can prevent the redemption. Emits OptionRedeemed.

Redeeming is blocked while any collateral is still borrowed. That outstanding amount has to be repaid first (see below).

Borrowing and repaying

If the option was created with borrow_allowed, its locked collateral can be put to work while the option is live:

• Borrow: As long as the exercise window has not started, the taker can borrow collateral from the option's escrow (subject to the settlement layer's approval). Emits OptionBorrowed.
• Repay: borrowed collateral can be paid back by any party, not just the original borrower. Emits OptionRepaid.

Outstanding borrows must be repaid to zero before the taker can exercise or the maker can redeem.

Settlement Methods

A settlement method is a pluggable, decision-only module chosen per option. It never holds funds. The core protocol owns every escrow, and the method only answers questions at key moments:

• can_match: is this option allowed to be created?
• can_exercise: is this exercise allowed right now, and how does it settle?
• can_redeem: is this redemption allowed, and what amounts are paid out?
• can_borrow: is borrowing allowed?

Two layers ship today:

• Physical (Raw): the taker pays the full proportional settlement asset and receives the full proportional collateral. No oracle — ITM/OTM is game-theoretic (the taker exercises or not in the window). When spot is below strike for a call, there is normally no incentive to exercise unless the taker can exit under better conditions.
• Oracle-gated: exercise is only allowed when the oracle price makes the option in-the-money. Each chain reads the price feed native to it — Pyth on Solana, Chainlink Data Feeds on EVM. It runs in one of two modes:
  • Gated: the taker pays the full proportional settlement asset and receives the full proportional collateral, exactly like the physical layer but only when the oracle says the option is in-the-money.
  • Intrinsic: the taker forgoes paying the settlement asset and instead receives the option's profit (the price surplus) directly out of the collateral, denominated in the collateral asset. The remaining collateral stays escrowed for the maker to redeem. This delivers a cash-settled-style payout without the taker needing the settlement asset on hand.

For product-facing methods (five total = layer + Access; Physical · Raw and Physical · Gated share capital on the chart), start with Settlement Methods · Layers that ship today.

Delegated signing

Actions don't have to be sent by the principal themselves. An account (the owner) can authorize other keys to sign actions on its behalf, so an off-chain operator can submit and pay for transactions while the owner stays the party the action acts for.

Authorizing keys

The owner signs directly to manage its set of delegates:

• Add a signing key: registers a delegate key (ed25519 on Solana; an EOA address on EVM) as authorized. On Solana each authorized key gets its own on-chain record keyed by (owner, key), so an owner can authorize as many keys as it likes and revoke them individually; on EVM this is a party → delegate → permissions map (revoke = set permissions to 0, no record/rent). The authorization also carries the key's permissions, so an owner can scope a delegate to only the actions it should perform (for example, a key that may exercise and redeem but never write options). Emits AuthorizedKeySet.
• Remove a signing key: revokes a previously authorized key. Emits AuthorizedKeyRemoved.

Signed operations

To act on the owner's behalf, a delegate produces an operation: a signature (ed25519 on Solana, 65-byte secp256k1 on EVM) over a canonical, domain-separated digest that commits to the version, domain, curve, action, its payload, an expiry, and a one-time nonce. On Solana the transaction carries this operation alongside a sibling ed25519 verify instruction; on EVM the digest is recomputed and recovered via ECDSA.recover (signing key/digest are not sent). The protocol checks that the signing key is authorized for the owner before running the action.

Replay protection is per operation: consuming one creates a UsedOperation record keyed by (signer, nonce) on Solana, so the same signed operation can't be used twice, and it is rejected once past its expiry. Solana-only: anyone (not just the owner) can close that record after expiry to reclaim rent to the original payer — there is no EVM counterpart and no Cleared event there. Emits OperationConsumed on use and OperationReplayProtectionKeyCleared on cleanup (Solana only).

The following actions can be delegated this way:

• make an offer (either side),
• close an offer,
• exercise an option,
• redeem an option,
• withdraw.

Borrowing and repaying are not delegatable operations.

Protocol administration

The protocol has a small amount of global configuration and safety control:

• Config: the authority can set the whole ProtocolConfig — protocol authority, pause authority, option-creation hook, plus pausedActions / pauseAuthorityMask. Emits ProtocolConfigUpdated (ProtocolInitialized at genesis).
• Pause: a dedicated pause authority (a hot wallet, separate from governance) can halt individual instructions (deposit, withdraw, create offer, close offer, accept offer, exercise, redeem, borrow, repay, burn exercise claims) in an emergency, scoped to whichever of those governance has allowed it to touch. set_paused is pause-only — governance resumes via set_config. Emits ProtocolPaused.