Production runbook

Deployment, market authorization, and public launch are separate decisions.

Required external inputs

• Two distinct canonical Safe 1.4.1 proxies for genesis and guardian, threshold at least two, independently controlled, with no modules or guard and only the permitted fallback configuration.
• A funded one-use deployer and private deployment RPC.
• An independent RPC and operator for post-deployment verification.
• Signed STK-001 acceptance and exposure ceiling while strict sequencer protection is unavailable.
• Independent audit of the exact release candidate.
• Approved reserve, concentration, liquidity, counterparty, and aggregate bond-capacity limits.
• Production Privy configuration, browser-restricted RPC, Cloudflare credentials, and tested incident contacts.

Preflight

1. Pin the release commit, compiler, dependencies, lockfiles, and deployment config.
2. Run all repository validation and archive outputs.
3. Rehearse the exact broadcast on a current Robinhood mainnet fork.
4. Complete the production-like Robinhood testnet rehearsal with distinct canonical 2-of-3 Safes, real Safe signatures, Timelock scheduling/cancellation, emergency shutdown/restart, market bootstrap, and independent verification.
5. Verify every token and feed against current official registries and live bytecode.
6. Review the Safe owner separation, transaction list, CREATE addresses, constructor arguments, roles, and expected runtime hashes.
7. Complete independent audit and resolve every Critical and unaccepted High.
8. Build the frontend from the candidate manifest and exercise wallet login plus deposit, redeem, delegate, bond, and vote flows on the production origin.
9. Fire-test alerts for RPC, oracle, external-token, backing, role, governance, Timelock, Safe, and frontend changes.

Deployment

GENESIS_MULTISIG=0x... \
GUARDIAN_MULTISIG=0x... \
ACCEPT_UNPROTECTED_SEQUENCER_RISK=true \
RPC_MAINNET=https://private.example \
DEPLOYER_PRIVATE_KEY=... \
make deploy-mainnet

Stop on any unexplained mismatch. Do not continue across a chain ID, address, bytecode, Safe, role, feed, config, simulation, or receipt discrepancy.

Independent verification

DEPLOYER_ADDRESS=0x... \
INDEPENDENT_RPC_MAINNET=https://independent.example \
make verify-deployment

The verifier checks manifest runtime hashes, Kernel and Authority control, modules and policies, roles, Timelock, Governor token/settings, Safe hardening, asset/feed identity, price validity, zero production markets, stSTONK asset and decimals, and sequencer-mode disclosure.

Required post-state:

• Timelock controls Kernel, Authority steady-state roles, and RolesAdmin.
• Guardian Safe has only containment and cancellation authority.
• Genesis Safe is proposer-only and scheduled for revocation.
• Deployer has no protocol or Timelock role.
• Every runtime hash matches the reviewed manifest.
• PRICE assets and current answers match approved sources.
• Production has zero bond markets.
• stSTONK points to STONK, uses 9 decimals, and starts with no forced emission mechanism.

Frontend release

Commit the verified manifest, then from the same release checkout:

cd app
NEXT_PUBLIC_CHAIN=mainnet \
NEXT_PUBLIC_RPC_URL=https://browser-restricted.example \
NEXT_PUBLIC_PRIVY_APP_ID=... \
NEXT_PUBLIC_READ_ONLY=true \
CLOUDFLARE_ACCOUNT_ID=... \
CLOUDFLARE_API_TOKEN=... \
pnpm deploy:cloudflare

Verify the custom domain serves the intended commit, correct chain and addresses, Privy-enabled bundle, security headers, and all routes. Writes remain disabled if manifest, chain, or RPC state is unavailable.

The zero-market release sets NEXT_PUBLIC_READ_ONLY=true, which disables wallet login and every transaction control while retaining Privy configuration for the separately approved market-launch build.

Market launch

Contract deployment does not open deposits. After audit and approvals:

The proposed economic sequence, parameters, canonical liquidity venue, POL loss budget, and halt rules are documented in the launch mechanics and liquidity memo. That memo is a proposal until its required human approvals are complete; it does not authorize a market by itself.

1. Publish decoded proposal calldata and current-fork simulation.
2. Create only capacity within the approved aggregate unsold limit.
3. Verify backing, feed state, external-token controls, and live market bounds after execution.
4. Start below the maximum exposure and observe before increasing capacity.
5. Distribute and delegate enough stSTONK for credible quorum.
6. Complete a non-critical proposal end to end, then revoke the genesis proposer role.

Monitoring

Monitor independently from the static frontend:

• chain/RPC health and divergence;
• every feed round, freshness, proxy, and configuration;
• external-token pause, blocklist, implementation, and admin events;
• gross, risk-adjusted, and stress backing plus concentration;
• STONK supply and stSTONK assets, shares, and exchange rate;
• market count, live-market overlap, and aggregate unsold capacity;
• Kernel, modules, policies, roles, Authority, Timelock, Governor, and Safes;
• frontend availability, release marker, and security headers.

The release monitor binds to the approved manifest and frontend commit, verifies Safe proxy/singleton identity, Timelock roles and delay, protocol roles, Kernel modules and active policies, and reports recent governance, Timelock, and external-token control events. DNS/TLS certificate expiry and wallet-origin synthetic testing remain infrastructure checks outside this process.

The vault has no periodic maintenance call or automation dependency.

Incident response

1. Preserve block, transaction, log, RPC, UI, and alert evidence.
2. If ongoing mint or treasury activity can worsen loss, have the guardian contain MINTR and/or TRSRY.
3. Cancel a dangerous queued Timelock operation where applicable.
4. Disable affected frontend transaction prompts and publish precise status.
5. Quantify affected assets, markets, notes, supply, vault assets, roles, and maximum exposure from independent RPCs.
6. Simulate the smallest recovery proposal and execute only after review and delay.

Containment cannot reverse transactions, repair an external token, withdraw reserves, or restart the protocol.

Strict PRICE upgrade

When an approved canonical sequencer feed exists, verify it through official sources and live behavior, deploy strict StonkPrice with registry migration, rehearse outage and recovery grace, execute a decoded module-upgrade proposal, independently verify every policy and price, update the manifest/frontend, and retire STK-001 only after live protection is proven.