Launch readiness

The conditions under which $KAY9 may be launched, and the evidence required for each.

This document exists to make one decision hard to take casually. The product goes live first and the token goes live later, and "later" has to mean something checkable rather than "when we feel like it". Everything below is a gate: a stated condition, the evidence that settles it, and who signs off.

Nothing here authorises anything. The mainnet launch is signed and broadcast by the project owner, from wallets the owner controls, after the owner has read this document filled in. No automated process, no CI job and no assistant may do it. Deploy.s.sol refuses to run against mainnet without an explicit MAINNET_CONFIRM=I_AM_THE_OWNER, and that is a speed bump, not the authorisation.

---

0. Status

Update this block when a gate closes. A gate is closed by evidence, not by intention.

---

Part A — the watchdog must be live and useful first

The premise of the whole plan is that KAY9 earns attention before it asks for money. These gates are what "earned" means.

Gate 1 — the watchdog runs on mainnet, unattended, for 30 days

Condition. KAY9ScanRegistry deployed on chain 4663, a scanner authorised, and batches committed continuously for 30 days with no manual intervention.

Evidence. batchCount() on the deployed registry; the block of the first and most recent commit; a list of any gaps longer than six hours with an explanation for each.

Not evidence. A testnet run. A run somebody restarted by hand every morning.

Gate 2 — the record covers what people actually buy

Condition. Every graduation on the chain for 30 days has a basic scan committed within one hour of the graduation event.

Evidence. Count of PoolGraduated events in the window against count of matching AssetScanned entries, and the distribution of the delay between them. Misses listed individually.

Why it is a gate. A watchdog that misses the tokens people can buy is not a watchdog. Coverage of the launch firehose is explicitly not required — see docs/TOKEN_DISCOVERY.md §1.

Gate 3 — the record is rebuildable by somebody else

Condition. A third party, given only the chain and the batch documents, reconstructs the same feed KAY9 shows.

Evidence. A written procedure someone outside the project followed, and the diff between their reconstruction and kay9.io — which must be empty.

Why it is a gate. If the site is the only place the data exists, every claim on it is unverifiable and the token is being sold on trust.

Gate 4 — the calibration is re-run and published

Condition. docs/SCORE_CALIBRATION.md re-run against at least 50 tokens spanning graduated, fresh, stablecoin, RWA and at least 10 tokens known to have rugged.

Evidence. The updated document, including every false positive found and what was done about it, and an explicit false-negative discussion for the rugged set.

Why it is a gate. The current calibration is four tokens. It found three systematic defects, which is a good sign about the method and a bad sign about how much has been checked.

Gate 5 — no invented statistics anywhere

Condition. Every number on kay9.io traces to a chain read or a stated measurement.

Evidence. A sweep of the rendered site listing each figure and its source. Any figure that cannot be traced is removed before launch, not explained.

---

Part B — the contracts

Gate 6 — external review of the launch path

Condition. KAY9Genesis, KAY9Token, KAY9TeamVesting and KAY9LiquidityLock reviewed by someone who did not write them.

Evidence. The report, every finding, and for each either a fix with its commit or a written reason for accepting it.

Gate 7 — the full suite passes, including the parts that are inconvenient

Condition. Contracts, chain package, watchdog and web suites green; Slither clean or every finding triaged in writing; the fork test run against mainnet state from the launch week.

Evidence. CI run id, Slither output with triage notes, fork test output.

Gate 8 — the testnet rehearsal is complete end to end

Condition. On chain 46630: bid → graduate → migrate → lock → bind oracle → lock access → request → attest → dispute → expire → renew → unlock, every step executed and observed.

Evidence. Transaction hashes for each step and the resulting on-chain state.

Why it is a gate. The single most expensive error in this project so far — a block-number convention wrong by a factor of 120, which would have made the documented four-hour auction impossible to submit — was invisible to unit tests and to a mainnet fork. Only a real deployment on the real chain showed it.

Gate 9 — the launch parameters are computed, checked and signed off

Condition. Floor FDV, graduation FDV, auction duration in blocks, claim block and migration block all computed and confirmed by the owner.

Evidence. Launch.s.sol --json output, and the owner's written confirmation of each figure.

Watch the clock. Auction windows are counted in the block.number a contract reads, which on this chain is Ethereum's and advances about every 12 s — not the chain's own height, which advances every 0.1 s. Four hours is 1,200 blocks, not 144,000. docs/RESEARCH.md has the measurement.

---

Part C — custody and keys

Gate 10 — every production address is the owner's

Condition. Owner Safe, team beneficiary, creator fee recipient, treasury and deployer are all controlled by the project owner. None is a developer address, and none is an address that has ever appeared in a transcript, a log or a commit.

Evidence. Each address, who holds it, and the signer set of each multisig.

This is the non-negotiable one. No developer, contractor or assistant may be configured as token owner, treasury, team beneficiary, creator fee recipient, LP beneficiary, production deployer or production cloud owner. If any address is uncertain, the launch does not proceed.

Gate 11 — the auditor keys exist and are held separately

Condition. Three auditor keys, held by three parties, none of which is the deployer. The quorum threshold matches what Deploy.s.sol will be given.

Evidence. The three addresses, who holds each, and a signed message from each proving control.

Gate 12 — the timelock actually holds what it should

Condition. After deployment, the 48-hour TimelockController owns every administrative role, and acceptOwnership() has executed everywhere Ownable2Step needs it.

Evidence. owner() on each contract, read from chain, equal to the timelock address.

A trap worth naming. Ownable2Step makes the handover a proposal. Until the timelock executes acceptOwnership(), the deploying key still owns the contract. Both deploy scripts print this in capitals and it has to be checked, not assumed.

---

Part D — the token itself

Gate 13 — the token launch attaches to the live watchdog

Condition. Deploy.s.sol is run with EXISTING_TIMELOCK and EXISTING_AUDITOR_REGISTRY set to the addresses DeployWatchdog.s.sol produced.

Evidence. The values used, and the script's own validation passing — it checks the registry's quorum, its members and its owner against what the launch expects, and refuses a mismatch.

Why it is a gate. Deploying a second auditor registry would leave every scan committed before the launch answering to a set of auditors that no longer governs anything. The failure is silent at the time and permanent afterwards.

Gate 14 — the owner has read this document and signs the launch

Condition. The owner confirms in writing that gates 1 to 13 are closed, and personally signs and broadcasts the mainnet transactions.

Evidence. The owner's confirmation and the resulting transaction hashes.

---

What is deliberately not a gate

• A price, a market cap or a listing. None of them says the product works.
• A marketing date. If a gate is open on the date, the date moves.
• Audience size. A watchdog with ten users and a correct record is ready; one with ten thousand users and an unverifiable record is not.
• Feature completeness. Watchlists, alerts, the wallet graph and the SDK are all wanted and none of them gates the token. What gates it is that the record is real, covers what matters, and can be checked by somebody else.

---

What may ship before any of this

The watchdog itself, the free basic scan, the live feed, token pages, the badge, the integration standard and the documentation — all of it is public good with no token attached, and none of it waits. That is the point of the ordering: everything that helps somebody can ship immediately, and the only thing gated is the part that asks them for money.