# Current release status

This file supersedes the older rehearsal progress summaries. The website is public; mainnet financial activity remains disabled.

## Deployed and pending

- Active Devnet factory: `Ez288n8SpxVGkgGbkqHhzBmb1YoXZaAU83rPdsxmyZhU`, recorded in `DEVNET_ADDRESSES.json` and `DEVNET_REPLACEMENT.json`.
- Its current executable is the 21-day release-window adapter. The 2.1-day window, scoped milestone agents and governed coin metadata are local candidate changes, not deployed functionality.
- `BUILD_PROVENANCE.json` records clean rebuilds of source commit `427366932d233d57c6fc2a9e2f0e92ec5e269d2c`; all four artifacts match. “factory-production” is a historical build label for the non-fixture default build, not proof that mainnet activation is implemented.
- `FACTORY_NEXT_UPGRADE.json` and `FACTORY_NEXT_UPGRADE_INSPECTION.md`, when present, identify the actual next factory upgrade. The disposable `DAO_FIRST_UPGRADE.json` is historical rehearsal evidence and must not be used to upgrade the factory.
- After execution, verify deployed bytes, update the baseline, and set `EVANGEL_RELEASE_WINDOW_SECONDS=181440` for the web deployment. Until then the UI defaults to the deployed 21-day allowance.

## Governance ownership

The founder confirmed that all three current reviewer wallets are theirs. See `GOVERNANCE_OPERATORS.json`. Two configured signatures remain necessary, but this is founder-controlled governance, not independent review. No signer keys have been supplied to the assistant. Mainnet disclosures must reflect this structure.

## Remaining gates in execution order

1. Sign and execute the inspected Devnet factory upgrade; verify finalized executable bytes before baseline promotion.
2. Complete live acceptance of new instructions, fee-day settlement, development/community/expense payouts, refunds, challenges, owner verification/revocation and wallet/RPC recovery. See `DEVNET_ACCEPTANCE_STATUS.md`; UTC collection-day boundaries cannot be bypassed.
3. Finish a deliberate mainnet factory/network initialization path. Current initialization rejects real e/acc and the application rejects mainnet selection. Do not bypass these checks using development signers or flags.
4. Complete wallet-driven launch/trade acceptance, slippage/price-impact/rent review and receipt recovery. Mainnet quote/venue code must be freshly verified.
5. Deploy persistent agent/keeper services with protected signing, durable queue/budgets, funded bounded fee payers, alerts and recovery. The milestone conversation interface and human review workflow still need production acceptance.
6. Refresh the first-party security report for the final exact build, verify production governance configuration and close remaining web/API/identity checks.
7. Verify chart asset deployment, market-data capacity and real indexed pool data; publish metadata limitations and founder-control disclosures; begin only with an explicitly bounded mainnet release.

## Operations verified this pass

The keeper now distinguishes custody authority from the immutable upgrade guard and verifies guard code and policy pins. A read-only live cycle passed monitoring, collection planning and settlement planning. This does not mean a continuous keeper is running or payouts have executed.

Mainnet readiness is still false. Public launches remain disabled. Completed scripts and local tests are not substituted for live receipts or user signatures.

## Factory upgrade commands

- Prepare/inspect: `node --env-file-if-exists=.env.local scripts/solana/prepare-factory-upgrade.mjs`.
- Stage the exact candidate: same command with `--broadcast`; this does not propose, approve or execute the upgrade.
- After canceled/expired/completed proposals, use `--successor` to require inspection of the previous plan and archive it. Active proposals cannot be silently replaced.
- After participant execution: `node --env-file-if-exists=.env.local scripts/solana/finalize-factory-upgrade.mjs`, then `--write` to promote only verified executed bytes.