Checks that could not fail, and a guard that could not act

A week reading a daemon’s shadow ledger against the code that wrote it. The daemon holds a concentrated liquidity range, stakes it, harvests, and refuses to act when the world looks wrong, and it cannot be armed until a gate of criteria passes. Several of those criteria could not have failed.

The stake criterion asks whether any open position is unverified. The query was status open and verification timestamp null, and the single update that sets the status sets the timestamp, so open implies verified by construction. It returned nothing in every possible state of the database. Its own comment said it should always be empty, which was true for the wrong reason: not because every stake was verified, but because the question could not be asked. It had been counting toward three criteria met.

Two more reported figures nobody had computed. A seven day line queried from seven days ago with no upper bound, so it covered eight days and one of them was in the future, and the only number on that digest that looked like a tolerance breach belonged to a day outside it. A span criterion measured the age of the run from the first tick inside the window it was measuring, so it could never exceed the requirement: it printed not met beside 10,080 ticks spanning 7.0 days, because the comparison used 6.9993 and the display rounded.

Then the guard, which grades a finding as allow, downgrade, close or halt. Five of the seven graduated outcomes had nowhere to land, because the field a downgrade writes to had nothing reading it. The two that appeared to work did so only because the policy independently checked the same condition on its own path.

The most expensive was a gas cap guard reading an estimate the simulator never populated, so it never ran. The cap was 400,000 and the same deposit burns 410,531 on one path and 392,631 on another. From the outside, a check that passes and a check that cannot fail look exactly alike.