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.

Status (2026-09-25): running; the 30 days started. KAY9ScanRegistry 0x79778723c021386F3C7727289A30716edaa635A1 on chain 4663, scanner 0xeaA9…Bda6 authorised in the constructor, and the Azure job kay9-scanner-run committing every two hours. First batch: batch 0, block 71,926,233, 10 scans, document on IPFS, all 10 proofs verified against the root on chain. The gate can close 30 days after that commit if no gap exceeds six hours unexplained.

2026-09-27: three batch documents lost. Batches 27, 28 and 29 (blocks 73,722,772, 73,792,926 and 73,863,382) were committed on schedule while the free pinning plan was full: the worker fell back to its own disk, and their documents are lost. Their roots and events are on chain; their contents cannot be checked. Batch documents and reports now go to the public record, <https://record.kay9.io>, and the worker does not commit a batch it could not publish there (docs/WATCHDOG.md §11.5).

2026-10-03: passes stopped by the job's timeout, and one gap of 6 h 02 min. From 2 October the same 17 scans took 15 to 25 minutes a pass instead of 5 to 8, with the engine unchanged (1.13.0 throughout); a single scan costs from about 20 seconds to nearly three minutes depending on the token's transfer history. The job's 25-minute replica timeout stopped seven passes, five of them before their commit (2 Oct 04:17, 08:17 and 10:17, 3 Oct 12:17 and 16:17 UTC); the 2 Oct 14:17 and 3 Oct 14:17 passes committed batches 87 and 98 seconds before they were stopped. Earlier, the 30 Sep 04:17 pass failed differently: the public RPC answered its commit with a Cloudflare challenge page, on both attempts. Two stopped passes in a row on 2 Oct left the one gap over six hours, from batch 85 at 06:29 to batch 86 at 12:30 UTC. Every other gap is under 4 h 10 min. The timeout was raised to one hour at about 17:00 UTC on 3 October, still well short of the two-hour interval, so two passes still cannot overlap (services/discovery-worker/deploy/azure/deploy-scanner.sh). Nothing was restarted by hand.

2026-10-04: engine 1.15.0 and the pass changes for gate 2 deployed at about 01:50 UTC (commit 2bc69ed, image ghcr.io/kay9t/kay9-scanner@sha256:04b9131e…); like the engine upgrades of 26 September, a deployment, not a restart. The first pass on it took 8 minutes for 17 scans and committed batch 103.

2026-10-09: no commit for more than six hours. The last commit is batch 191, block 83,555,104, at 19:20:07 UTC on 8 October. From about 20:00 UTC the public RPC answered any burst of requests with a Cloudflare 403 challenge page, and every hourly pass from 20:17 on met it: some published their batch document to the record and then had the commit refused, others had every scan refused (the 22:17 and 04:17 passes report as succeeded with 11 and 15 scans failed and nothing committed). Measured on 9 October from a laptop and from Azure: 20 or 30 requests a minute ran for minutes without one refusal; 45 a minute, or about 20 in four seconds, drew the challenge, which lasted 60 to 90 seconds and grew while requests kept arriving, and viem's own fast retries fed it. The fix (2105e42) spaces every request a process sends to the public endpoint 2.5 s apart, waits 90 s on a challenge and sends the refused request again, and batches concurrent reads into one HTTP request. It went to the job as image ghcr.io/kay9t/kay9-scanner@sha256:8753e977… at 06:16 UTC on 9 October, a deployment like the earlier ones, not a restart, and the 06:17 pass committed batch 192 at 06:45:51 UTC and batch 193 after it, ten scans, none refused. The gap, batch 191 to batch 192, is 11 h 25 min. Whether it is accepted as explained or the 30 days start again is the owner's decision.

2026-10-14: both gaps accepted as explained (owner). The two gaps over six hours, 6 h 02 min on 2 October (passes stopped by the job's timeout) and 11 h 25 min on 8–9 October (the public RPC's challenge), are explained above, and each was ended by a deployment, not a restart. The owner accepted both as explained, so the 30 days keep counting from batch 0 and the gate can close on 25 October if no further gap over six hours goes unexplained.

Gate 2 — the record covers what people actually buy

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

Changed by the owner on 2026-09-25 from one hour. One hour would need a pass every hour and about twice the gas. Measured the same day, the chain produced 8 graduations in three hours of chain time (against 552 new pools and 1,133 launches), and graduations head the scan queue, so every pass takes all of them first. The job runs every two hours with 17 scans a pass, about the same daily volume as every three hours with 25, so the worst case is about two hours and a quarter: two hours to the next pass, a 2,000-block reorg lag of about three and a half minutes, and the pass itself.

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.

Status (2026-09-26): running, no miss since the start-up backlog cleared. The evidence script is services/watchdog/scripts/gate2-coverage.ts, and the first reading is docs/reviews/2026-09-26-gate2-coverage.md. From batch 0, 84 of 102 due graduations were scanned within three hours and 18 later. None was missed. All 18 fell in the job's first hours, while batches 0 to 5 worked through graduations from before batch 0. From block 72,173,850, after that backlog, all 84 due graduations were scanned within three hours: median 1 h 03 min, longest 2 h 30 min. The 30 days are counted from there, which ends on 26 October.

Status (2026-10-03): the condition has been broken twice inside the 30 days, and the owner has to decide what that means. Second reading, docs/reviews/2026-10-03-gate2-coverage.md: from block 72,173,850 to 79,249,531, 579 graduations were due, every one was scanned, 494 within three hours and 85 later (median 1 h 19 min, longest 12 h 48 min). The 85 fall in two episodes:

• 76, graduated between 29 Sep 22:19 and 30 Sep 09:56 UTC. About fifty graduations arrived in eighty minutes, four times what passes of 17 scans every two hours take in that time, and the 04:17 pass on 30 September failed when the public RPC answered its commit with a Cloudflare challenge page. The queue took until batch 66 to drain.
• 9, graduated between 2 Oct 00:53 and 09:10 UTC. Passes stopped by the timeout before their commit (gate 1's note of 2026-10-03).

Batches 27 to 29, whose documents are lost, are read from their AssetScanned events instead; the first count of this reading charged their 16 graduations as late until that was added to the script.

So the gate cannot close on 26 October as written. The timeout is fixed; the burst is not, because the cap of 17 scans a pass is what keeps a pass inside its slot, and one scan took from 23 seconds to 2 min 45 s on three tokens of batch 98, measured locally on 3 October. The choices are the owner's: keep the condition and restart the 30 days once a pass can absorb a burst (from the first week of October that ends in the first week of November, before gate 14), or restate the condition. Nothing here changes the condition.

Status (2026-10-04): the owner kept the condition, and the 30 days restarted. The fix (2bc69ed): graduations, which head the queue, may take a pass past its 17 scans up to 60; a pass stops starting scans 40 minutes in and commits what it has, instead of being killed at the hour with nothing committed; a long pass commits every 17 scans; and engine 1.15.0 bounds the holder fold that made one scan take minutes. The new window counts from batch 103, block 79,579,724, 2026-10-04 02:24:53 UTC, and ends on 3 November. The first pass on the new image took 8 minutes for 17 scans, so a burst like 29 September's fits one pass. A burst larger than a pass can scan in 40 minutes would still leave its tail to the next pass two hours later; an hourly cadence would close that, at about 0.002 ETH a month more gas, and is the owner's call.

2026-10-05: two graduations late by four minutes, and the window restarts again. Third reading, from block 79,579,724 to 81,136,554 (5 Oct 22:24 UTC): 47 graduations due, every one scanned, 45 within three hours, longest 3 h 04 min. The two late ones graduated at 03:24 and 03:25 UTC on 5 October; the 04:17 pass failed in its first request, when the public RPC answered with a Cloudflare 403 challenge page, and the platform's one retry 44 seconds later met the same page, so they waited for the 06:17 pass (batch 116, 06:28:33 UTC). The capacity change held: passes took 11 to 32 minutes. The worker now waits two minutes on a challenge page and runs the pass again, up to three times, while the run is under ten minutes old (commit f587810, image ghcr.io/kay9t/kay9-scanner@sha256:f9db8433…, deployed 5 Oct 22:30 UTC). Under the condition the owner kept, the 30 days now count from batch 116, 2026-10-05 06:28:33 UTC, and end on 4 November.

2026-10-06: hourly passes (owner). The job runs at 17 minutes past every hour with 9 scans a pass, about the same daily volume as 17 every two hours; graduations still go past the cap up to 60, a pass stops starting scans 30 minutes in, commits every 9 scans, and the replica timeout is 50 minutes, under the hour between runs. A pass the public RPC refuses now costs one hour, not two, so a graduation is still committed inside three hours when one pass in a row fails. The extra gas is about 0.002 ETH a month at the batch price measured on 3 October.

2026-10-09: broken again by the RPC outage. Nothing was committed after batch 191 (19:20:07 UTC on 8 October) until the paced image described under gate 1 (2105e42), so the graduations of that night were not committed within three hours. The condition is the owner's: if the 30 days restart from batch 192 (06:45:51 UTC on 9 October), they end on 8 November, the day before the owner's confirmation on the calendar, which leaves no slack for another break. Pacing cost capacity at first: a basic scan was 45 to 57 HTTP requests, about two minutes at one start per 2.5 s, so the 06:17 to 08:17 passes took about 24 minutes for 9 or 10 scans, and a pass could fit only about ten of the 60 graduations it may take. Engine 1.15.1 (1aa368f, image ghcr.io/kay9t/kay9-scanner@sha256:416b34b7…, deployed 08:57 UTC) reads the same things in 6 to 43 requests, every report compared at a pinned block byte-identical; the 09:17 pass took 7 minutes for 9 scans, so the 30-minute budget fits about 35 to 40. A dedicated RPC endpoint would remove the challenge altogether; it is a cost decision for the owner.

2026-10-12: the paced scanner held for three days. Read with services/watchdog/scripts/gate2-coverage.ts --from 83956057 (batch 192) to block 86,237,769 (12 Oct 00:01 UTC): 67 batches, every document fetched and matched to its root; 51 graduations, 49 due, all 49 scanned within three hours, median 41 min, longest 1 h 11 min; none missed. The 63 hourly passes over the same period committed all 567 of their scans, with no failure and no challenge page. Engine 1.16.0 (d27dca3, image ghcr.io/kay9t/kay9-scanner@sha256:f4651ec4…) went to the job at 00:36 UTC; it knows Uniswap v3 and does not score a pool beside a launchpad curve that still sells the token (docs/WATCHDOG.md), a deployment, not a restart. Whether gate 2's 30 days count from batch 192 is still the owner's decision.

2026-10-14: the 30 days restart from batch 192 (owner). The owner kept the condition and did not count the night of 8–9 October as an exception. The window counts from batch 192, 2026-10-09 06:45:51 UTC, and ends on 8 November at 06:45:51 UTC, the day before the owner's confirmation under gate 14, so there is no slack: a further break moves the launch. Reading of the same day (docs/reviews/2026-10-14-gate2-coverage.md), from block 83,956,057 to 87,997,211 (14 Oct 02:06 UTC): 117 batches, every document matched to its root, none lost; 105 graduations, 103 due, all 103 scanned within three hours, median 44 min, longest 1 h 11 min; none missed. The owner chose not to buy a dedicated RPC endpoint for now; the paced public endpoint stays, and the question comes back if the challenge returns.

2026-10-19: ten days in, none missed. Reading of the same window (docs/reviews/2026-10-19-gate2-coverage.md), from block 83,956,057 to 92,156,393 (18 Oct 23:23 UTC): 234 batches, every document matched to its root, none lost; 172 graduations, 171 due, all 171 scanned within three hours, median 43 min, longest 1 h 12 min; none missed. batchCount() read 426.

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.

Status (2026-09-26): open, the procedure is published and needs its third party. The procedure is docs/REBUILD_THE_RECORD.md, also on kay9.io/docs; the tool it uses is tools/rebuild-record.mjs in the public repository, about 200 lines with viem as its only dependency; and kay9.io/feed has a Download as CSV link that gives the rows the page read, before any filter, in the columns the tool writes. KAY9 followed the procedure word for word in an empty folder on 2026-09-26: the tool rebuilt batches 0 to 22 (305 shown scans) with every root, count, engine version and event matching, and the diff against the feed's file, batches 20 to 22, was empty (42 rows). On 2026-09-27 the procedure gained a pinned range, batches 0 to 25, so that every checker rebuilds the same record: 351 rows, SHA-256 b01d57d7…f299196. That run proves the procedure works; it is not the evidence, which must come from somebody outside the project.

Status (2026-10-06): waived by the owner; it no longer holds the launch. The owner decided that the launch does not wait for somebody outside the project to run the procedure: it is public, the tool and the record are public, and the owner has invited anyone to run it. This is not a pass. Nobody outside KAY9 has rebuilt the record yet, and nothing on the site or in the announcements may say otherwise. When somebody does and sends their files, the result is published here, and a non-empty diff is a finding before the launch as much as after it.

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 first calibration was four tokens. It found three systematic defects, which is a good sign about the method and a bad sign about how much had been checked.

Status (2026-09-26): met. docs/SCORE_CALIBRATION.md was re-run with engine 1.12.0 on 84 tokens read from the chain: 60 graduated, 11 standalone pools, 8 fresh launches, USDG and four tokenised equities. A second pass labelled 219 graduations. The rugged set is 32: 14 insider dumps, 15 early-buyer dumps and 3 liquidity pulls. Hand-checking found eight engine defects and two in the method; each is fixed, tested and written up. The nine rugs with no launch-time finding are discussed token by token; replayed at graduation, six of them were already flagged as holder concentration. Most dumps came within minutes of graduation, before the watchdog's committed scan (median 1 h 03 min), so the warning in time is the visitor's own browser scan. The browser scan runs 1.13, and so does the watchdog's scanner job from batch 23 (2026-09-26 22:25 UTC, block 73,438,977). Batches 19 to 22 carry engine 1.12 and batches 0 to 18 carry 1.10.

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.

Status (2026-09-25): met for the text of that date; run again in the launch week. The sweep is docs/reviews/2026-09-25-gate5-sweep.md: every figure traced to a contract constant, a code constant, a chain read or a dated measurement. It found five wrong statements and all were fixed in all thirteen languages: two "4 h" left over from the four-hour auction, an early launch-rate estimate ten times the measured graduation rate, a claim that the watchdog scans with archive and explorer access (it uses the public RPC), and "access buys analysis" in the Persian and German text.

---

Part B — the contracts

Gate 6 — model review of the launch path

Changed on 2026-09-16, by the owner. This gate used to require review by a human who did not write the code. Several firms and communities were approached; all of them quoted a fee the project cannot pay, and the owner decided not to spend on one. The gate is therefore now what the project will actually do, rather than a standard it was never going to meet. Pretending otherwise, or leaving a gate open forever as decoration, would be worse than saying this plainly.

Condition. KAY9Genesis, KAY9Token, KAY9TeamVesting and KAY9LiquidityLock reviewed by at least two large language models from different families, at the commit that will be deployed. Different families is the load-bearing part: two runs of the same model share the same blind spots, and part of this code was written by one of them, so a review by that same model is not a second opinion on it.

Changed on 2026-09-23, by the owner: which families count. The code was written with many model families, not one, so no family is independent of it by authorship, and excluding the family that happened to write the most would not buy the independence the rule was after. What the gate keeps is the load-bearing part: the two reviews come from different families from each other, each starts with no context on the project, and each reads only the tagged commit. The reviews are GPT-5.6 Sol (OpenAI) and Claude Fable 5.1 (Anthropic).

Evidence. Each review published in full — the model and its version, the date, the commit, what was in scope, and every finding. For each finding either a fix with its commit or a written reason for accepting it. What a review did not cover is published with it.

What this gate is not, and what must never be claimed. This is not a professional audit. No firm is accountable for it, nobody carries liability for a miss, no fuzzing campaign ran for weeks, and no human outside the project has read the launch path. The word "audited" is not used about KAY9 anywhere on the site or in these documents, for the same reason the protocol refuses to say "verified safe" about anybody else's token: a reader would hear a guarantee that does not exist. What may be said is exactly what happened — reviewed by named models, on a date, with the output published.

This gate closing does not make the contracts safe. It makes what was done visible.

Extended on 2026-09-18: the watchdog stack is reviewed before it is deployed, not before the token is. DeployWatchdog.s.sol puts KAY9AuditorRegistry, KAY9ScanRegistry, KAY9Registry and KAY9AuditHub on mainnet about a month before the token, because gate 1 needs its 30 days, and they are exactly as immutable as the launch path. The same condition and the same evidence apply to them, and have to be met before that deployment. A finding in one of them afterwards is not a patch: it is a redeploy, every scan committed to the old registry answers to a contract nothing points at, and gate 1's clock starts again. docs/ROADMAP.md §8.1 dates this ahead of the watchdog's deployment.

Status (2026-09-25): closed by the owner for the launch path. GPT-5.6 Sol (OpenAI) and Claude Fable 5.1 (Anthropic) each reviewed the launch path in a fresh session; the fixes were verified by GPT-5.6 Sol and Claude Opus 5.5, and both confirmed the final commit launch-review-5 (41e30ecd). Every review, verification and confirmation is published verbatim with a disposition for each finding in docs/reviews/, and the OpenAI thread is public on ChatGPT. The owner reviewed what is accepted there and closed the gate for the launch path on 2026-09-25.

Watchdog stack (2026-09-25): closed by the owner. GPT-5.6 Sol (OpenAI) and Claude Opus 5.5 (Anthropic) reviewed KAY9AuditorRegistry, KAY9AuditHub, KAY9Registry, KAY9ScanRegistry and DeployWatchdog.s.sol at watchdog-review-1; three fix rounds followed, and both confirmed the result for deployment. The commit to deploy is watchdog-review-4 (a71cb5c6). Slither found nothing new there. Every review and confirmation is published verbatim in docs/reviews/. The owner closed this part of the gate on 2026-09-25, so gate 6 is closed in full.

Reopened (2026-10-21) for KAY9AuditHub and KAY9Registry. An external report by email said that a job's analyzedAt was not bound to its requestedAt on-chain and that a late job record became latest over a newer watchdog report. Both were confirmed and fixed (attest reverts AnalysisNotPinned; latest is the newest analysis), and both contracts are redeployed at the token launch. Both families have read the fix in fresh contexts: Claude Opus 5.5 (Anthropic) the uncommitted change, and OpenAI GPT-6 the contracts at kay9-protocol tag analysis-pin-review-1 (fb6c21d6), over four rounds that converged on 22 Oct, finding nothing in them and nine off-chain issues, all fixed. Both are published verbatim with dispositions (docs/reviews/2026-10-21-external-report.md). The commit to deploy for the two contracts is analysis-pin-review-1.

Closed again by the owner (2026-10-22). The owner read what was accepted in writing (docs/reviews/2026-10-21-external-report.md: the reporter's suggested fix not taken, the items the Anthropic review raised that were not taken, the unknown-outcome X reply left to the owner) and the two properties the OpenAI review could not conclude from source (the exact launch deployment, recorded at launch under gate 13, and the earlier review's properties end to end), and closed this part. Gate 6 is closed in full again.

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 → lock access → request → attest → dispute → expire → renew → unlock, every step executed and observed. There is no oracle to bind: the access requirement is a fixed KAY9 amount stored in the vault.

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

A rehearsal is evidence about the contracts it ran on. When a contract in the rehearsed path changes afterwards, the steps it touches are run again on a redeployed stack; hashes from the old one are kept as history and close nothing.

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.

Status (2026-10-08): met. Every step above ran on chain 46630 on the stack deployed from launch-review-5, the commit the reviews confirmed: the full path on 2026-09-24, unlock on 2026-09-30 and renew on 2026-10-08 (0xe6566497bce82d72971c57ddda2dc6bf3876efb5b6f4a0ec203509aabbb49667), hashes in docs/STATUS.md §18.

Reopened (2026-10-21) for request → attest → dispute → expire. The 21 Oct analysis-pin fix changed KAY9AuditHub.attest and KAY9Registry, both on that path. Those steps run again on a testnet stack deployed from the fix, run from this machine with the throwaway testnet keys like every rehearsal (only the mainnet launch is signed by the owner); the other steps' evidence stands.

Status (2026-10-22): met again. On chain 46630, against a fresh vault, registry and hub from the fix next to the §18.2 token, auditors and timelock: an unpinned result refused with AnalysisNotPinned; a job attested by A and B and fulfilled, its record committed after a newer watchdog report and latest staying on the watchdog report; three pinned dissents disputing a job and returning its unit; an expired job (0xe7647e7c…25d5) returning its unit. Hashes in docs/STATUS.md §19.

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 on the clock the auction reads, which on this Arbitrum Orbit chain is ArbSys.arbBlockNumber() — the chain's own height, about every 0.1 s — and not the block.number a contract sees, which is the parent chain's and advances about every 12 s. The planned 24 hours is 864,000 blocks. KAY9Genesis.chainBlockNumber() returns the clock it validates against; Launch.s.sol derives from it. docs/RESEARCH.md has both measurements and the testnet launch that was over before its first bid because the other clock was used.

Status (2026-10-06): figures chosen, not yet computed or signed off. Floor FDV USD 1,000 and graduation FDV USD 5,000 (the reference was 10,000; lowered so a small community can carry the launch, at the cost of a thinner pool and, with few bidders, a concentrated allocation). Launch at 01:00 UTC on 10 November, a 24-hour auction. The vesting TGE_TIMESTAMP proposed for 11 November 02:00 UTC still needs the owner's confirmation before the 3 November deployment. The gate closes when Launch.s.sol --json has been run in the launch week and the owner confirms its output.

2026-10-14: the vesting dates confirmed (owner). TGE_TIMESTAMP is 11 November 2026 02:00 UTC (1794362400), after the auction's expected end at about 01:17 UTC; the later tranches follow at six and twelve calendar months, 11 May 2027 and 11 November 2027 at 02:00 UTC (1810000800 and 1825898400), to be produced with ComputeVesting at deployment and checked against these. Nothing releases before KAY9Genesis.settled() in any case. The rest of the gate is unchanged.

---

Part C — custody and keys

Gate 10 — every production address is the owner's

Condition. The owner address, 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 and who holds it.

There is no multisig. The owner decided on 2026-09-16 that the owner address stays a single externally owned account. What that costs is worth stating rather than discovering: that one key is the timelock's only proposer and executor, the owner of KAY9Genesis, the team vesting beneficiary and the creator-fee recipient. Lose it and governance, the 90 M team allocation and the fee stream are gone at once, with no recovery path in any contract. A Safe would have survived losing one key and could have added signers later; an account cannot. Nothing on the website may describe the owner as a Safe or a 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.

Status (2026-09-25): owner key proven. The owner address 0xD75F06091CCc53Aa4cC499C6D3AdBa66fF6f95d3 is also the team beneficiary and the creator-fee recipient. Its holder signed "KAY9 gate 10: I hold the owner key … myself. 2026-09-25" (Etherscan 339091), checked independently with cast wallet verify. The deployer 0x2A83A3d8B3150f13E88213A60c5764aDEcEc1984 was supplied by the owner and proves itself when it broadcasts the deployment.

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.

Status (2026-09-25): met. Each holder signed "KAY9 gate 11: I hold the auditor key … myself. 2026-09-25" from their own wallet on their own machine, at the same time over a video call. Each signature was checked independently with cast wallet verify. The threshold is 2, which is what Deploy.s.sol will be given.

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 a handover a proposal. Until the timelock executes acceptOwnership(), the deploying key still owns the contract. The watchdog contracts avoid it by taking the timelock as owner in their constructors; the token deployment still hands some contracts over and prints the step in capitals. 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, and without EXISTING_REPORT_REGISTRY and EXISTING_AUDIT_HUB: the 25 Sep registry-and-hub pair predates the 21 Oct fix (a job's analysis pinned on-chain to its request time; latest by analysis time) and is replaced by a fresh one. See docs/DEPLOYMENT.md, "Except at the November 2026 launch".

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. Read just before the launch: the old registry's reportCount() and the old hub's jobCount() are both still zero. After it: every step of the post-deploy list in docs/DEPLOYMENT.md done, the three auditors seen reading the new hub.

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 (gate 3 by the owner's waiver of 2026-10-06), 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.