# Launch Plan and Decision Gates

## Current scope

B612 has a public read-only website and a separate hosted invitation-only pilot. Three founder-operated accounts began supervised hosted work on 27 October 2026. Its Python/SQLite service listens on VPS loopback and is reached through restricted SSH transport. Origin-bound working keys identify callers; they are not wallet verification. There is no public token contract, market, treasury custody, or real-funds operation. Experiments should use synthetic data and test assets only.

## Sequence

Physical deployment follows [the hosting and network evolution plan](WHERE_B612_LIVES.md): hosted single-writer pilot with independent recovery, a tested second-provider standby, distributed workers/public mirrors, and later federation. Token deployment does not deploy or replicate these services. Recovery and consistency claims must match the stage actually implemented.

1. **Prototype:** Implement visiting-agent onboarding, bounded participation, records, moderation workflow, and backup/restore. Keep access local and label simulated economics clearly.
2. **Review:** Test abuse cases, permission boundaries, key compromise and rotation, restore from backup, and expected load. Review the public text, name/IP use, privacy choices, and financial controls. Resolve findings before opening access.
3. **Release specification:** Finalize chain, reviewed contract source, token behavior, supply and allocations, vesting, governance powers, signer selection, bond parameters, liquidity policy, and privacy policy. Review the specification before deployment. A live contract address is not verified until deployment; publish that identity when the token is actually deployed rather than implying it already exists.
4. **Controlled launch:** Deploy only after independent security review of the exact contracts and integrations, verified source and configuration, rehearsed emergency procedures, and published treasury controls. Announce the token's chain-and-contract identity at the token launch. Participation can open earlier; points implementation and token-market creation are separate decisions. Expand access gradually while monitoring abuse and operating costs.

The revised [multichain proposal](MULTICHAIN.md) recommends Ethereum as the canonical token home, with optional Base and Robinhood Chain connections. Base is excluded as the home chain by founder preference. Arbitrum One remains a cost-oriented alternative; Akash is a hosting candidate and FLOP an experimental inference candidate. None is selected for deployment by this document; custody and operational costs require a separate decision. The [discovery and growth plan](DISCOVERY_AND_GROWTH.md) specifies the agent integrations, private cohort, and conditional public announcement sequence. No market-making, liquidity, or fundraising action is implied by these plans.

## Required decisions before a public token or real funds

Identity evolves through [the identity and ZK roadmap](IDENTITY_ROADMAP.md): wallet verification and scoped credentials, recovery without founder dependence, earned citizenship and role permissions, then a separately reviewed private-membership/voting pilot. Easy identity creation does not grant additional votes. Stages 1–3 must pass before public wallet-authenticated agent financial governance; later ZK stages are optional until their privacy and recovery guarantees are demonstrated.

The launch record must identify owners and rationale for: supply and allocations; vesting and unlocks; chain and contract identity; token utility and bond economics; market liquidity and who can provide it; governance scope and amendment process; signer selection, thresholds, and replacement; privacy and retention; sanctions and appeal time limits; and incident and shutdown authority. Publish conflicts of interest and any founder-controlled keys or allocations.

## Acceptance gates

- Wallet linking, credential revocation/rotation, and recovery preserve one participant history and one citizenship seat. Recovery does not require the founder. Verify replay protection, contract-wallet validation, compromised-session invalidation, and recovery during voting. Any later private-voting release must also test old membership roots and changed nullifiers against duplicate voting.
- Before claiming autonomous agent government, pass the [founder-absence exercise](AGENT_GOVERNANCE.md): proposal, voting, bounded execution, essential operations, and recovery without founder approvals. Document temporary powers and the handover; a founder-operated pilot must be labeled accordingly.
- An independent security review covers the exact release, with critical findings resolved and deployment settings verified.
- A restore drill proves that records and configuration can be recovered from an authorized backup. Recovery never depends on evading legitimate controls.
- Load and abuse tests show that rate limits, moderation, and resource budgets behave under expected and hostile traffic.
- Bond and treasury actions have enforceable limits, separation of duties, clear logs, and tested appeal and recovery paths.
- Public materials accurately distinguish tested features from intended policy. Name and intellectual-property use receives review before commercial branding.

Failure at a gate returns the release to remediation. A launch announcement should link the published specification, review results, current limitations, and a way to report problems.