Resolution and settlement

Exercise is how most value should move through Plume in practice. This page covers what happens to whatever's still open when a series reaches expiry — and makes that outcome exactly as trustworthy as exercise is.

The problem with "settle at the current price"

The naive design is simple: after expiry, let anyone call a function that reads whatever price the oracle currently shows, and use that. It's simple, and it's wrong. If "current price when you call settle" is the rule, settlement isn't deterministic — it depends on exactly when someone chooses to call it. And because anyone can call it, whoever benefits from the price at a given moment has an incentive to be the one who calls it right then. The settlement price becomes a small race, and whoever runs an automated settlement bot suddenly holds real influence over outcomes just by choosing when to click — exactly the person-dependent trust this protocol is built to avoid.

The fix: bind settlement to a specific historical round

The oracle publishes a sequence of numbered price updates over time, each with a timestamp. Settling means finding the first one whose timestamp is at or after expiry, and using that exact price. Whoever calls settlement supplies which update they believe is right; the contract independently verifies it — checking that this update's timestamp qualifies, and that the update immediately before it does not — before accepting. If it fails either check, the transaction reverts. Nobody can substitute a different, more favorable price; they can only correctly identify the one true answer or fail.

This makes the settlement bot untrusted. Its job is entirely mechanical, and it has zero ability to influence the outcome, because the outcome was already fixed the moment the right oracle update was published. If the bot ever stopped running, any holder could compute the correct update themselves and settle their own position.

Rejecting bad prices outright

Separate from timing, there's a floor on what counts as a valid price: any settlement or exercise that would read a zero or negative price is rejected outright, unconditionally. This matters — a put's payoff pays out the full locked strike value when the price is zero, which is correct for a genuine price of zero but catastrophic for a malfunctioning oracle momentarily reporting zero by error. The check exists specifically so a feed glitch can never be mistaken for an actual market crash.

The fallback, and why it's small on purpose

In the rare case where the oracle never publishes a qualifying update within a set grace period after expiry — a genuine outage, not a busy bot — a series can resolve through a fallback path: it settles as worthless. Buyers receive nothing further; writers reclaim their full collateral.

This is deliberately the least favorable outcome for buyers, and used only as a last resort, because it's the one path that doesn't rely on an independently verifiable price. The round-binding rule above exists in large part to shrink how often this fallback could ever be reached — most legitimate expiries find a qualifying price within minutes, and the grace window is set well beyond that.

Corporate actions

Tokenized stocks occasionally undergo corporate actions — stock splits being the clearest example — which change what "one token" represents. Plume's contracts read a stock token's own on-chain record of any scheduled upcoming action and refuse to open a new series whose expiry would fall on the far side of it. This closes the most common case cleanly.

What this guard cannot do is protect a series that's already open when a corporate action is announced after the fact. That's a genuine, disclosed limitation of the current design, not an oversight. If you're holding a position and a corporate action gets announced mid-series, treat it as a real event worth paying attention to.