RandProofAutomation
General-purpose decentralized upkeep: watch any contract's own condition — a deadline, a threshold, a state — and let the keeper network call it the moment it's due. Chainlink-compatible or native. Same keepers, same network.
Live and proven.
Two interfaces, one keeper network.
Implement the existing standard so current contracts and tooling work unchanged — while offering a better primitive alongside it.
Identical signatures to Chainlink's AutomationCompatibleInterface — checkUpkeep(bytes) and performUpkeep(bytes). A contract already integrated with Chainlink Automation registers here with zero logic changes; only the registration target changes.
A simpler primitive — nextDeadline() and performUpkeep(bytes) — for raffles, auctions, epochs, and anything with a natural deadline. Keepers read every registered client’s nextDeadline() in one batched view call and know exactly when to come back. No per-cycle checkUpkeep simulation.
Verification by construction, not committee.
Clients fund a balance and pay 0.00005 ETH per performUpkeep — matching the proven fund-and-pay model, with automation cost kept economically separate from randomness fees.
The condition being checked — a deadline, or whatever checkUpkeep verifies — is public and independently verifiable on-chain. There's no off-chain claim to dispute.
Any keeper may call performUpkeep for any eligible client; the client’s own guard conditions, re-checked inside its own performUpkeep, prevent a wrongful execution from doing anything.
The 3-of-5 production Safe can pause the registry but cannot touch escrowed client balances or redirect executions.
Two findings, both fixed before deploy.
A pre-deployment adversarial pass found and closed two real issues. 25 tests cover both interfaces' full lifecycle, mode isolation, pause switches, balance enforcement, and both fixes.
A malicious client’s performUpkeep could recurse back into the registry. Fixed with an explicit reentrancy guard on both performNativeUpkeep and performCompatibleUpkeep — the unguarded version now reverts immediately.
A client could drain its balance in the same block a keeper’s pending performUpkeep landed. Fixed with a 1-hour withdrawal delay (requestWithdrawal / executeWithdrawal) — the same unbonding pattern used across the product family.
Honest gas numbers.
The Native path's advantage is off-chain keeper operating cost — one batched nextDeadline() read instead of per-client checkUpkeep simulation — not per-transaction gas.
Compatible or native — your call.
// Chainlink-compatible path — zero logic changes
function checkUpkeep(bytes calldata) external view
returns (bool upkeepNeeded, bytes memory performData);
function performUpkeep(bytes calldata performData) external {
// your own guards re-verified here
}
// Or the native path — deadline-shaped conditions
function nextDeadline() external view returns (uint256);