Mainnet launch gates

No funded market or public mainnet launch is authorized until every blocking item has linked evidence and two named approvers.

A. Architecture and review

• The token design is STONK plus non-rebasing ERC-4626/ERC20Votes stSTONK.
• Scheduled emissions and external accounting automation are absent.
• Unit, fuzz, invariant, integration, local E2E, and production-fork coverage exists for the candidate.
• Independent auditors review this exact release and retest all fixes.
• Every Critical is closed and every open High is fixed or has a signed, bounded, expiring exception.
• Static analysis, current advisory databases, license scan, secret scan, and reproducible artifact checks pass.

B. Economic and external assets

• The proposed launch mechanics and liquidity memo has exact approved parameters, named signers, reproducible calculations, and no unresolved required-human-approval field.
• Stress backing, liquidity discounts, drawdown policy, and minimum reserve ratios are approved.
• Per-asset, issuer, sector, volatile-bucket, and aggregate live unsold-capacity limits fit the approved loss budget.
• Equity closure, gap, corporate action, freeze, blocklist, upgrade, zero-liquidity, and USDG depeg scenarios are rehearsed.
• Revenue copy and accounting make clear that stSTONK has no promised yield; any value growth comes from actual STONK deposited into the vault.
• Public copy states backing is not redemption or a peg.
• External-token administrator, implementation, pause, blocklist, and liquidity monitoring is live.

C. Oracle and sequencer

• Every asset and feed matches current official registries, live code, metadata, round behavior, cap, heartbeat, and pause behavior.
• STK-001 has two named approvers, a maximum aggregate exposure, expiry, and rollback trigger while strict sequencer protection is unavailable.
• Frontend, manifest, verifier, and public documentation consistently disclose the active sequencer mode.
• Alerts fire on stale, future, incomplete, deviating, paused, upgraded, or identity-changed price sources.

D. Control plane

• Genesis and guardian Safes are canonical, threshold at least two, independently controlled, module-free, guard-free, and use only permitted fallback configuration.
• Hardware-backed signers, recovery, out-of-band calldata decoding, and escalation tree are tested.
• Guardian cannot propose, execute, withdraw, configure, mint, or restart; genesis cannot cancel or execute.
• Governor and Timelock parameters match the approved memo.
• Genesis proposer revocation has an owner, proposal, and deadline.
• One-use deployer retirement and zero remaining privilege are independently verified.

E. Deployment

• Exact broadcast is simulated on a current fork with final Safes, config, toolchain, and RPC behavior.
• Two reviewers approve every transaction, constructor argument, role change, CREATE address, and runtime hash.
• Broadcast uses a private RPC; receipts, source verification, release commit, and manifest are archived.
• Independent verification from a separate operator and RPC passes.
• Production starts with zero bond markets and no emission mechanism.
• Any market-opening proposal is separately decoded, simulated, and bounded by approved capacity.

F. Frontend and operations

• Production bundle uses the verified mainnet manifest, exact ABIs, restricted RPC, allowed Privy origins, and intended release commit.
• DNS, TLS, CSP, framing, MIME, referrer, publishing protection, monitoring, and rollback are tested.
• Wallet smoke covers bond limits, note redemption, vault deposit/redeem, delegation, voting, wrong chain, unavailable deployment, invalid oracle, and emergency states.
• Independent monitoring covers RPC, prices, assets, backing, vault, supply, markets, roles, governance, Timelock, Safes, and frontend integrity.
• Alerts and public status delivery are fire-tested.

G. Incident readiness and approval

• Guardian containment, Timelock cancellation, evidence capture, frontend action disablement, public notice, and governance recovery are rehearsed.
• Primary and backup responders plus Robinhood, Chainlink, Safe, RPC, frontend, Privy, auditor, and legal contacts are current.
• Public security contact, safe harbor, severity model, response targets, and bounty are live.
• Launch exposure remains within the approved per-tranche cap, and consecutive tranches do not overlap.
• Engineering/security approver: ____________________ Date/block: ____________________
• Operations/risk approver: ________________________ Date/block: ____________________