Security model

STONK is designed around conservative backing, least-privilege administration, delayed governance, direct Chainlink reads, and roleless automation. This document states the intended security properties and operational assumptions. It is not an audit report and does not imply that the system is free of defects.

Security objectives

1. STONK minting cannot exceed explicit policy allowance or bypass active-module controls.
2. Scheduled staking rewards cannot exceed risk-adjusted excess backing.
3. Treasury withdrawals cannot reduce risk-adjusted backing below STONK supply.
4. Bond payouts cannot exceed received deposit value, per-deposit limits, or market capacity, or settle below the user's minimum payout.
5. Invalid, stale, paused, mismatched, or implausibly moving oracle data cannot increase backing or authorize a bond deposit. Sequencer-unsafe data is also rejected when strict PRICE is installed; the initial accepted mainnet mode does not provide that guarantee.
6. No single steady-state EOA can administer the protocol.
7. Administrative changes are visible before execution through Governor and Timelock delay.
8. The guardian can stop dangerous flows and veto queued operations but cannot take control.
9. Keeper or frontend compromise does not grant protocol authority.
10. Users retain an unstaking exit even during an unusually large rebase backlog.

Core invariants

Minting

• STONK accepts mint calls only from MINTR.
• MINTR accepts mutation only from active, selector-permissioned Kernel policies.
• mintStonk consumes a per-policy allowance.
• Deactivating MINTR blocks mint and burn module actions.
• BondDepository returns unused allowance when a market closes.
• Distributor grants itself only the exact reward immediately before minting it.

Backing

• Reserve value derives from actual TRSRY token balances.
• Valuation rounds down.
• USDG upside is capped at $1.
• Volatile assets are discounted by a governance-configured haircut.
• Reserve-token decimals are pinned at registration; live metadata drift invalidates the price instead of changing value scaling.
• Invalid aggregate prices contribute zero.
• Strict deposit valuation reverts on invalid quote prices.
• TreasuryCustodian checks post-withdrawal reserves against total STONK supply.
• Distributor pays at most the smaller of configured reward and excess backing.

Bonds

• Deposits measure the treasury balance delta rather than trusting the requested amount.
• Third-party deposits require recipient approval, preventing note-limit griefing.
• A reentrancy guard covers deposit and redemption.
• Users set a maximum price and minimum payout for slippage protection.
• Payout must be nonzero, below maxPayout, within remaining capacity, and no greater than conservative received value.
• Notes track payout, claimed amount, creation, maturity and market; cumulative claims cannot exceed payout.
• Each user has at most 128 note slots, and fully claimed slots are reusable.
• Redemption pays only the note owner.

Governance and authority

• Kernel executor becomes StonkTimelock.
• RolesAdmin administration and steady-state protocol roles become StonkTimelock-controlled.
• Timelock renounces external default administration.
• Governor and the temporary genesis Safe can propose; genesis cannot execute or cancel.
• Guardian can cancel and shut down; guardian cannot propose, execute, withdraw, configure, or restart.
• Timelock execution is open for liveness but applies only to ready scheduled operations.

Oracle defenses

PRICE binds each asset to a specific feed identity and configuration. Validation covers:

The module deliberately has no offchain writer, signer, or keeper role. There are two explicit implementations:

Mainnet deployment cannot silently choose the first mode: config and an environment acknowledgement must both name the exception. A Chainlink or Robinhood oracle issue can reduce liveness and backing value, but cannot be bypassed by a protocol operator publishing an alternative number.

Accepted sequencer risk

STK-001 documents the accepted failure mode, scenario exposure, compensating controls, expiry, and governance upgrade. In unprotected mode a round may remain within the six-hour heartbeat across an L2 outage and be consumed before the first fresh post-recovery round. This can overmint STONK and create an inclusion-access advantage. The state is High risk, not “healthy.”

The initial deployment creates no markets and uses a zero Distributor rate. Governance must not create funded markets until it approves an aggregate active unsold-capacity ceiling and the remaining launch findings. When a canonical feed exists, governance replaces the module with strict StonkPrice; its constructor validates and copies the installed registry before the Kernel reconfigures dependent policies.

Fail-closed versus liveness-safe reads

getPrice is strict and reverts when a price is invalid. Bond deposits use this path because accepting an unpriced asset could create unbacked STONK.

tryGetPrice converts invalid pricing into zero. Aggregate reserve views, withdrawal checks, and reward calculations use conservative values so one broken asset does not freeze all accounting or accidentally preserve its previous value.

Trust assumptions

The protocol assumes:

• Robinhood Chain continues to provide correct consensus and transaction ordering; in accepted unprotected mode the protocol cannot detect sequencer downtime or enforce recovery grace;
• configured Chainlink proxy contracts and their feed networks behave within their published security model;
• Robinhood tokenized-equity contracts correctly expose oraclePaused();
• governance participants review proposals and retain enough independent voting power;
• genesis and guardian Safe owners are independent, secure, and meet operational threshold;
• Safe proxy, singleton, and any nonzero fallback-handler code hashes pinned at deployment correspond to the intended Safe 1.4.1 contracts;
• the compiler, Foundry, OpenZeppelin dependencies, build environment, deployer machine and RPC responses used during launch are independently verified; and
• monitoring detects degraded RPCs, stale feeds, emergency state, low keeper gas, rebase backlog, and governance events.

Tokenized equities and their oracle availability inherit real-world market hours, corporate actions, issuer/custodian arrangements, and regulatory constraints. A treasury asset can become illiquid or unavailable even when its onchain contract is functioning.

Privileged failure analysis

Governance capture

A quorum of delegated voting power can schedule arbitrary Timelock calls within the contracts' capabilities, including module upgrades and asset changes. The voting delay and Timelock create review time but do not prevent malicious governance after capture. Delegation diversity, public decoding, guardian veto, and narrow proposal scope are essential.

Guardian compromise

A compromised guardian can halt minting/withdrawals and cancel queued operations, causing denial of service. It cannot restart, transfer treasury assets, mint, or execute arbitrary calls. Governance can replace its authority through delayed actions.

Genesis Safe compromise

While bootstrap proposer access remains, a compromised genesis Safe can schedule Timelock operations but cannot execute them early or cancel governance. Monitoring and the guardian can inspect and veto malicious queued actions. Revoke genesis proposer access promptly after governance activation.

Keeper compromise

The keeper can call only public rebase(). Its funded key can lose its small gas balance or spam public calls, but it has no protocol role. Multiple independent keepers reduce liveness dependence.

Frontend compromise

A malicious frontend can misrepresent data or ask a wallet to sign dangerous transactions. It cannot bypass contract authorization. Users should inspect wallet calldata, chain ID, contract addresses and explorer links. The candidate rejects mismatched manifest chain IDs and does not report reverted receipts as confirmed. Production deployments should still use protected origins, pinned builds, CSP, and independently published manifests.

Emergency states

Emergency can independently deactivate minting and withdrawals. Expected effects include:

Operators and the app should treat inactive modules as a high-priority state and prevent users from initiating flows expected to revert. Restart must be a documented governance proposal through the Timelock.

In unprotected PRICE mode, a sequencer outage, recovery without a fresh round, unexplained inclusion discrepancy, or missing monitoring interval is also an incident trigger. Stop new minting, preserve feed rounds and L1/L2 timestamps, calculate active unsold capacity and completed payouts, and do not restart deposits until the risk acceptance is reviewed.

User-facing risk disclosures

• STONK is not a bank deposit, stablecoin guarantee, or claim enforceable against a traditional brokerage account.
• Backing per STONK is a conservative accounting metric, not an automatic redemption right.
• Bond price can move before transaction inclusion; use explicit slippage limits.
• Bond payouts vest and are not liquid until redeemed.
• sSTONK rebases can be zero when excess backing is unavailable.
• gSTONK requires delegation for voting power and is subject to governance outcomes.
• Oracle staleness, market closure, Robinhood pause state, congestion, RPC failures, or emergency shutdown can temporarily prevent actions.
• Smart-contract, governance, bridge, chain, oracle, token issuer, custody and regulatory risks remain.

Verification and testing

The repository includes unit, fuzz, invariant and integration tests. Important suites cover:

• Kernel policy/module registries and selector permissions;
• cumulative MINTR allowance and supply accounting;
• TRSRY withdrawal approvals;
• oracle cap, freshness, round completion, deviation and non-reverting conservative reads;
• full-precision valuation and haircut rounding;
• bond price, fee-on-transfer, slippage, backing, capacity, reentrancy and vesting behavior;
• staking catch-up, exit behavior and conservation;
• gSTONK wrap/unwrap conservation, rebase accrual and vote checkpoints;
• governance proposal success and defeat paths; and
• a complete protocol lifecycle integration test.

Passing tests are necessary but not sufficient for production. Launch also requires an independent audit, a current mainnet-fork rehearsal, exact deployment simulation, source verification, control-plane checks, production wallet smoke testing, alert fire testing and an operator sign-off.

Incident response

1. Confirm the symptom independently across RPC providers and preserve transaction, block and log evidence.
2. Classify whether risk is minting, treasury outflow, oracle integrity, governance, frontend, keeper, or availability.
3. If funds or uncontrolled minting are at risk, the guardian uses the narrowest shutdown function that contains the issue.
4. Cancel any related queued Timelock operation if necessary.
5. Publish the affected contracts, blocks, user impact and current restrictions without speculating beyond evidence.
6. Reproduce the issue on a fork and prepare a minimal reviewed remediation proposal.
7. Re-run the full validation and deployment-invariant suite.
8. Restart only through governance after the fix, independent review and recovery checklist are complete.
9. Publish a post-incident analysis and add regression coverage.

Never restart merely because monitoring returned to green; the root cause and onchain state must be understood.

Reporting

Do not test against production in a way that risks funds or availability. A security report should include affected commit or deployed address, chain ID, impact, reproduction steps or test, and a suggested containment when known. Avoid publishing an exploitable issue before maintainers have a reasonable opportunity to respond.