Risk acceptance: STK-001 L2 sequencer liveness

Decision

The project owner accepts that STONK cannot presently distinguish a healthy sequencer from an outage or the early recovery period. This is not a claim that the risk is fixed or low. The deployment and verifier identify the exception as ACCEPTED_UNPROTECTED, and the user interface discloses it on Robinhood mainnet.

Named engineering and operations/risk approvers must still sign the launch gates and approve a maximum funded-market exposure. Deployment of contracts with zero bond markets is distinct from authorizing deposits.

Failure being accepted

The primary danger is not that an outage directly changes a Chainlink price. It is transaction ordering during and immediately after an outage:

1. an equity price round is published before the outage;
2. normal sequencer inclusion stops while delayed-inbox transactions may remain possible;
3. the sequencer recovers before a fresh equity round is published; and
4. a bond deposit consumes the old round while it is still inside STONK's six-hour heartbeat.

An actor with earlier or alternative inclusion access can receive STONK against an equity asset whose realizable value has fallen. Ordinary users may not have the same ability to transact. PRICE still checks answer validity, round completion, heartbeat, description, decimals, deviation, cap, and Robinhood oraclePaused(), but none of those checks proves L2 liveness.

For an equity feed, a rough upper bound on the post-outage stale-price window is:

max(0, 6 hours - feed age at outage start - outage duration)

Actual ordering and price-publication timing can make the exploitable window shorter, but the protocol must not assume that they will.

Exposure model

Bond capacity is denominated in STONK payout. It is the maximum STONK that a market may mint across all deposits, not the quantity of quote tokens sold by the protocol. Capacity decreases by each payout; closing a market returns unused mint allowance. maxPayout separately caps one deposit.

The mainnet configuration contains nine proposed equity market templates with 500,000 STONK capacity and 50,000 STONK maximum payout each. If governance created all of them unchanged, aggregate unsold capacity would be 4,500,000 STONK. These templates are a potential ceiling, not approved launch exposure: Deploy.s.sol creates no markets.

At the $1.20 market floor and 10% equity haircut, the approximate backing after a price drop d is:

actual assets per STONK        = 1.20 × (1 - d)
risk-adjusted assets per STONK = 0.90 × 1.20 × (1 - d)
risk-adjusted shortfall        = max(0, 1 - risk-adjusted assets) × payout

The risk-adjusted figures measure violation of the protocol's conservative $1-per-STONK backing floor. At 20%, 30%, and 50% drops, nominal asset shortfall across all proposed capacity would be approximately $180,000, $720,000, and $1,800,000 respectively. This is a scenario model, not a probability estimate; it excludes existing supply, price impact, liquidity discounts, correlated exposures, issuer controls, and adversarial market timing.

Compensating controls

• Production deploys StonkPriceUnprotected, not a strict module with a fake or guessed feed.
• Mainnet deployment fails unless the config says ACCEPTED_UNPROTECTED and the operator provides the explicit acknowledgement.
• The deployment manifest, live verifier, keeper metrics, and mainnet interface expose that sequencer protection is disabled.
• All ordinary feed-integrity and Robinhood pause checks remain enforced.
• Deploy.s.sol creates no bond markets. Governance must separately create and fund each market after approving its risk budget.
• Mainnet Distributor rate is zero, so scheduled reward emissions do not consume the backing buffer at launch.
• Market capacity, maximum payout, asset count, market count, deviation, and emission rate have onchain bounds.
• The guardian can stop MINTR and TRSRY flows. Recovery requires governance.

These controls bound or disclose exposure; they do not detect the outage and do not eliminate preferential ordering.

Required conditions before funded markets

• independent review of the exact release commit and this exception;
• named engineering and operations/risk approval;
• an approved aggregate active unsold-capacity limit and per-asset limits derived from a dollar loss budget;
• external-token control monitoring and response procedures for STK-004;
• two independent RPC/keeper deployments and tested alerts;
• a current-fork rehearsal of guardian shutdown and governance recovery; and
• public disclosure that sequencer protection is unavailable.

Until those conditions are met, deploying contracts is allowed by this decision but creating or funding mainnet equity markets is not.

Upgrade and retirement plan

When a canonical Chainlink-compatible Robinhood Chain sequencer feed becomes available:

1. independently verify its address, interface, decimals, status semantics, start timestamp, and operating history;
2. deploy strict StonkPrice with the current installed PRICE module as migrationSource so the bounded asset registry is copied and validated in the constructor;
3. verify every copied asset and current strict price on a current fork;
4. execute Kernel.UpgradeModule through governance; dependent policies reconfigure to the new module in the same transaction;
5. independently verify live module wiring, feed status, and recovery grace; and
6. retire this acceptance only after the strict verifier passes and public artifacts are updated.

Any sequencer incident, unexplained price/inclusion discrepancy, missing monitoring interval, or proposed exposure increase reopens the acceptance and freezes new bond deposits pending review.

References

• Chainlink L2 sequencer uptime feeds
• Robinhood Chain oracle guidance
• Chainlink Robinhood feed directory
• Robinhood Chain terms