Where it stands

Last updated 2026-08-27. This page is the one place to look if you want to know what exists, what state it is in, and what happens next. If it disagrees with anything else in this repo, this page is probably the stale one: check the release table, which is generated against live app ids.

The short version

The keeper network is live on TestNet, holds real escrow, and has been through five rounds of adversarial review, four of them by independent language models rather than by people. None of that is an audit, and SECURITY.md says so in the words that matter: no third party has reviewed this contract. It is upgradeable, which means bugs found now are fixable in place rather than requiring everyone to cancel and re-register. Nothing but our own money has ever been escrowed in it.

The honest summary is that correctness is in good shape and usability is untested. Every interaction the system has ever had was with someone who already knew how it worked.

What is live

poetry run python -m scripts.verify_build --network testnet --app-id 769891898 proves the deployed programs are this source, byte for byte. Anyone can run it.

Three earlier deployments are superseded and must not be used: 769823086, 769802474, and 769772891.

The dogfood

Live since 2026-08-26. A rain draw serviced by Arcron. The contract became a hub on 2026-08-29 and was redeployed; there are three deployments, and the current one is the hub:

Upkeep 79 calls draw()uint64 every 2,571 rounds (about two hours), SKIP_AHEAD.

It replaced upkeep 77, which was registered against a selector rain does not have and so could never have executed: every attempt died on err in the target's own ABI router, and a selector is fixed in the box at registration. Cancelling refunded the escrow and box MBR in full and cost 0.005 ALGO. The console now refuses to register a call its own Test button has just said would fail, which is the hole that let it happen. scripts/rain_bot.py no longer drives the loop: the hub has no single open draw and holders pull claim for themselves, so the bot was reduced to a scan on 2026-08-29 and is kept only so the existing cron unit does not start failing. Full detail, including the first draw's real output and what a live beacon call needed that the LocalNet stub could not show, is in the rain release entry.

Where to look when it breaks:

• poetry run python -m scripts.verify_build --network testnet --contract rain --app-id 770130162 proves the deployed hub programs are this source. Running it against 770029154 now fails by design: that app runs the pre-hub programs.
• poetry run python -m scripts.keeper_bot --check --network testnet --app-id 769891898 says whether upkeep 79 is stalled or starved, among everything else in the registry.
• poetry run python -m scripts.rain_bot --once --network testnet --app-id 770130162 is a scan that changes nothing. It no longer reports draw state: the hub keeps that per rain box, and scripts/rain_testnet_live_proof.py is what exercises a rain end to end.
• .github/workflows/keeper-bot.yml still runs execution on a cron, a stopgap that names a long-running host as the real fix in its own header. .github/workflows/rain-bot.yml still runs on the same cadence but no longer resolves, claims or deposits: the hub gave those back to holders, and the job should be retired or repointed rather than left logging.

This is the mechanism docs/design/1.0.md describes: a recurring draw whose absence would actually be noticed, replacing the one-shot settlement that proved nothing about sustained operation. Its uptime clock starts now, at the deployment date above, not before.

The contracts

Four independent reviews plus three re-scores covered seven contracts in August 2026. They were carried out by language models given the repository and an adversarial brief, which is a useful thing and is not an audit; nobody has paid a firm to look at this. and most of their findings landed in four of them: treasury had two validation gaps, deadman had a total-loss trap on its default deploy path, embargo let a stranger hijack a fresh instance, and watchdog documented an error its own assert ordering made unreachable. None of that was the product. Those four were cut from the repository on 2026-08-26 so review attention concentrates on the contract that actually holds other people's money; see the commit for the reasoning. "Ships" below means whether it is ready to hold value belonging to someone other than us.

The reviews also refuted one reported blocker. An extra program page is charged to the creator account, not the app account; measured against both live deployments the app account base is exactly 100,000 microalgo with a second page in use.

What we know, and what we do not

Proven, and not worth re-proving:

• A 20-stage end-to-end test passes on TestNet and finishes with the app account at exactly its minimum balance, so every escrowed microalgo was either paid to a keeper or refunded to its creator.

• A simulation ran 1,008 executions across 96 upkeeps with three keepers and came out exactly solvent. Read that as a busy registry rather than as competition: the three take turns, and until 2026-08-26 all three were signing as the same account, because scripts/scenario.py funded three and then let the bot take its signer from the environment.

• A losing keeper pays nothing. Algorand rejects failing transactions at validation rather than including them, so there is no fee to pay. Established twice over: by construction in scripts/keeper_e2e.py stage 14, and, since 2026-08-27, between two keepers that genuinely collided on TestNet.

  The first real race, staged by scripts/keeper_race.py: two keeper bots aligned to the same barrier both scanned round 66703234 and both found upkeeps 71 and 75 due. They split the registry, each winning one and losing the other, which is the first time anything but a queue has happened here. On upkeep 75 the winner's SFOP56PA… is in block 66703238; the loser's KXTAGVSR… is in no block and no indexer, and the loser's balance moved by zero. A second run at round 66703289 reproduced it the other way round, with RWZRK7WB… winning and OMTXGJQT… thrown away.

Genuinely unknown, and only answerable by other people:

1. Can someone get an upkeep running from the docs alone? Tested 2026-08-26, and the answer was no. An agent given only README.md, docs/arcron.md and docs/integrating.md, with no access to this repository, did get an upkeep registered, executed by a stranger account and cancelled on LocalNet. It needed twelve guesses and had to disassemble the deployed approval program to recover the ARC-4 selectors, because no document contained them. next_upkeep_id was undocumented, which makes register a deadlock from raw algosdk. The box tail description was wrong in a way that returns a plausible incorrect value rather than raising. Those are fixed. What the exercise did not settle is whether the docs now work, since they were repaired by reading that agent's report: rerun it against a fresh agent before treating this as answered.
2. Does it survive unattended time? Still open. The earlier dogfood attempt was found dark on 2026-08-26 after roughly a day: the cron keeper was skipping for a missing secret and the local bot was pointed at a superseded app. The rain draw described in The dogfood above went live the same day and is what the clock now runs against; nothing here claims it has survived 30 days yet, only that the mechanism answering the question exists and is running.
3. Does keeping actually pay? Nobody has run a keeper for a week and looked at whether it was worth the gas.

Those are what the alpha tasks below exist to answer.

What happens next

The stages and what each one freezes are in releases.md. In order:

1. Close every finding that a MainNet create would make permanent, and reach a consensus of about 90 to 95 percent confidence across independent reviewers. Not every open finding: an earlier version of this page said that, and it contradicted the line below, because one of the open findings is "the console has no MainNet entry" and closing that publishes the path to the app.
2. Run the dogfood upkeep unattended, with the notifier watching. This is the only evidence that accrues while nobody is looking.
3. Answer the three unknowns above through the alpha tasks.
4. MainNet, deployed from corvid.algo and frozen promptly, with the app id unpublished until it is frozen.

Why 90 to 95 and not 100

Because the deployment is upgradeable, and that is a deliberate trade rather than a stage we have not finished yet.

A frozen contract has to be right the first time. Its only remedy for a bug is telling every creator to cancel and re-register by hand, so the bar before freezing is as close to certainty as a review process can get, which in practice means a paid audit and months of unchanged bytecode.

An unfrozen one can be fixed in place. That does not make bugs acceptable; it makes the cost of the last few percent of confidence wildly disproportionate to what it buys, because the failure mode it protects against is one we have a remedy for.

The honest counterpart, said plainly so nobody has to work it out: that allowance is ours and does not transfer. The reason we can accept 90 rather than 100 is that the creator can still reach every escrow, and while that is true, anyone escrowing here is trusting a keyholder rather than bytecode. Which is exactly why the app id stays unpublished until freeze, and why an unexpected upkeep before then is a person to freeze for rather than a schedule to finish.

The one rule held throughout: do not freeze, and do not invite outside escrow until it has run unattended for a while. Not for a calendar, but because "we can fix it" stops being a complete answer the moment someone else's money is involved.

With one correction, which an outside review made and which matters: there is no such thing as not inviting people, on chain. register is permissionless, so anyone who learns the app id can escrow into it during that window, and an explorer listing, a bot log, a README or a status post is the invitation. The protection during the unattended period is not the calendar and not our intent: it is that the MainNet app id is not published anywhere. If an upkeep we did not create appears before freeze, that is a real person who has trusted us, and the answer is to freeze then rather than to wait out the remaining time.

How to help

Three tasks, each about half an hour to an hour, each answering one of the unknowns above:

• #92: register an upkeep using only the docs
• #93: run a keeper for an hour and say whether it was worth it
• #94: point Arcron at a contract you wrote

None of them ask you to break it. That has been done five times. What has never happened is somebody simply using it.

Start at https://corvidlabs.xyz/arcron/console/. That address is also the answer to "is this the real thing": the contract is permissionless, so anyone can build a front end for Arcron, and where a console is served from is the only thing that separates ours from a copy asking you to sign something. Nothing else about a page proves anything, so check the address rather than the page.

Everything is TestNet, so there is no real money anywhere in any of this. Get test ALGO from https://bank.testnet.algorand.network/.