Nothing runs itself on a blockchain
Leif ·
There is no cron on a blockchain. No timer fires, no daemon wakes up, nothing runs on its own. A smart contract is a thing that reacts: it sits there until an account sends it a transaction, and if nobody sends one, nothing happens. Forever.
That is fine until you want something to happen on a schedule. A vault that rebalances daily, a price that refreshes hourly, a lease that expires. The usual answer is to run a server that sends the transaction, which works and quietly undoes the point: your unstoppable contract now depends on your laptop.
So I built arcron. You escrow a fee against a schedule, and any account can earn that fee by making the call on time. No token, no allowlist, no stake, no signup. If your keeper goes down, someone else's picks it up, because the money is sitting there for whoever shows up first.
The whole idea is that it does not run itself either
Arcron has no timer. It could not have one; Algorand does not offer one. What it has is an execute entry point that anyone may call once an upkeep is due, and a box holding the escrow that pays them for it.
That is the entire trick, and it is worth being blunt about what it means: Arcron does not guarantee your job runs. It guarantees that if it runs, whoever ran it gets paid, and that nobody can stop them from being the one who runs it. Liveness comes from the incentive, not from the contract.
Right now the only keeper is mine, and at four days into TestNet that is the plan rather than a shortfall. The release table is explicit about it: at alpha, what is frozen is nothing and what is at stake is nothing, because we run every part. A keeper network with one keeper is just a cron job with extra steps, and it will stay that way until there is a reason for anyone else to show up. The difference is what happens when that bot dies: the upkeep does not become impossible, only unpaid-for, and whoever wants the fee can take over without asking me.
A keeper who loses the race pays nothing at all. Algorand rejects a failing transaction at validation rather than including it, so the loser's execute never reaches a block: no fee, no receipt, nothing in any explorer. Only the winner's transaction exists. That matters more than it sounds, because it means running a keeper speculatively is free, which is the only reason a second one would ever bother to exist. We have seen it twice now: once by construction in the test suite, and once when two keepers genuinely collided on TestNet in August.
Rounds are not a clock
Here is the part I got wrong first, and the reason the docs now have a table in them.
A cadence in Arcron is a round count, because rounds are the only thing a contract can measure. Rounds are not seconds. TestNet measured 2.66 s/round over a 45-second sample against a nominal 2.8, and that gap compounds:
| Cadence | Rounds | At 2.8 s | At the measured 2.66 s | Drift |
|---|---|---|---|---|
| hourly | 1,286 | 1.0 h | 1.0 h | ~3 min |
| daily | 30,857 | 24.0 h | 22.8 h | ~1.2 h |
| weekly | 216,000 | 168.0 h | 159.7 h | ~8.3 h |
A "daily" upkeep slides about 36 hours against the calendar over thirty cycles. Which direction it slides depends on how busy the network was.
So Arcron promises "not before this round." It does not promise "at 00:00 UTC," and nothing built on it should pretend otherwise. If you need a wall-clock time, the target contract has to check the clock and no-op when it is early, with the upkeep firing often enough to catch the window. That is less elegant and it is the only honest version.
What state this is actually in
Live on TestNet as app 769891898, stage alpha-3. All 20 stages of the end-to-end suite pass against it on-chain, including regressions for the box-MBR underpayment, the escalation lockout, and what a losing keeper pays.
It has been through five rounds of adversarial review, four of them by language models rather than people. That is not an audit, and I want to be careful not to let the number do work it has not earned. No third party has reviewed this contract. The only money it has ever escrowed is mine.
It is upgradeable, which is a real trade. A bug found next week is fixable in place instead of requiring everyone to cancel and re-register, and in exchange you are trusting me not to change it underneath you. At four days old that is plainly the right side of the trade.
It does not stay that way by default. There is an on-chain freeze call, and the contract is upgradeable only until its creator makes it. The release process forces the question at the rc stage and requires the answer to be written down whichever way it goes, because both answers are normal here: the Foundation's randomness beacon, Reti and Folks Finance are immutable, while Tinyman, Pact and AlgoFi keep an update path. What is not acceptable is drifting into one by accident. This one will be frozen.
The honest summary from the status page is the line I keep coming back to: correctness is in good shape, and usability is completely untested. Every interaction this system has ever had was with someone who already knew how it worked. That is not a security property. It is just the shape of a thing nobody has used yet.
If you want to poke at it, the console runs against TestNet and the docs cover registering an upkeep, running a keeper, and what an Arcron-triggered call is allowed to reach. TestNet ALGO is free. Break it and tell me how.