10. RandProofAutomation: General-Purpose Decentralized Upkeep

[Layer 1: Core]

RandProofRNG (Section 7) and EntropyAttestation.sol (Section 9, AV-108) replace Competitor VRF: a client requests randomness, gets a verifiable callback. That leaves a separate job unreplaced: watching an arbitrary client contract's own business condition -- a raffle's end time, an auction's close, any deadline- or state-based trigger -- and calling that contract's own action function once the condition is met. A centralized keeper wallet or Chainlink Automation performs this job today; RandProofAutomation is RandProof's general-purpose, decentralized replacement for it, usable by any client contract, not built around any one team's specific business logic.

10.1 Two Interfaces, One Keeper Network

RandProofAutomation exposes two interfaces side by side, the same approach EVM-equivalent chains take toward the EVM standard: implement the existing interface so existing contracts and tooling work unchanged, while also offering a better primitive alongside it.

• IRandProofUpkeepCompatible (the Chainlink-mirror path): Identical function signatures to Chainlink's AutomationCompatibleInterface -- checkUpkeep(bytes) and performUpkeep(bytes). A contract that already implements Chainlink Automation registers here with zero changes to that logic; only the registration target changes. This was designed and tested directly against the real shape of a production Chainlink-Automation-integrated raffle contract's checkUpkeep/performUpkeep functions, including multi-item batch processing in a single performUpkeep call.

• IRandProofUpkeepNative (the RandProof-native path): A simpler interface -- nextDeadline() and performUpkeep(bytes) -- for the common case where a client's condition is naturally deadline-shaped (raffles, auctions, epochs). No off-chain checkUpkeep simulation call is needed at all: a keeper reads nextDeadline() across every registered Native-mode client in one batched call and knows exactly when to come back. This is the same scheduling optimization a well-built centralized keeper script already does by hand (smart-timer scheduling against the soonest known deadline, batched multicall reads, proactive rescheduling on new-item events) -- RandProofAutomation makes that pattern available natively to any registered client instead of requiring every team to reinvent it.

10.2 Design Decisions

• Payment model: Per-call fee, paid by the client contract per performUpkeep execution, matching Chainlink Automation's own proven model (fund a balance, pay per execution) rather than bundling automation cost into RandProofRNG's entropy fee. Automation and randomness are economically different jobs -- a client's condition may be checked many times before it is ever true, while gas is only spent the moment performUpkeep actually executes. Bundling the two risks a hidden cross-subsidy, the same class of problem this whitepaper's own audit log already caught once (AV-51, static fee drift).

• Trust model: No committee or dispute mechanism for triggering, unlike EntropyAttestation.sol's unsigned-source problem. The condition being checked (a deadline, or whatever checkUpkeep's own logic verifies) is itself public and independently verifiable on-chain -- there is 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, are what prevent a wrongful execution from doing anything.

10.3 What This Audit Found and Fixed (AV-113, AV-114)

A pre-deployment adversarial pass against RandProofAutomation.sol, the same discipline applied to EntropyAttestation.sol and LivenessGuard.sol before either touched a testnet, found 2 real issues before any deployment. Both are detailed as formal findings in Section 29 (AV-113, AV-114) and summarized here.

• AV-113 [MEDIUM]: Unbounded reentrant calls into the registry. A malicious client's performUpkeep calling back into the registry's own performNativeUpkeep for itself does eventually revert and roll back cleanly -- but only because the EVM's own gas and call-stack-depth limits stop the unbounded recursion, confirmed directly by timing the unguarded version (it hung for an extended period before failing) against the fixed, guarded version (reverts immediately). Relying on the EVM's own limits as the only protection is fragile and expensive for the calling keeper to discover by losing gas to a failed transaction. Fixed with an explicit reentrancy guard on both performNativeUpkeep and performCompatibleUpkeep.

• AV-114 [LOW]: Instant withdrawal could strand a keeper's already-completed work unpaid. A client owner could withdraw their entire automation balance to zero in the same block a keeper's pending performUpkeep transaction would land, leaving that keeper unpaid for real off-chain monitoring work already done. No funds were stolen -- this is an economic griefing risk against keepers, not a fund-safety bug -- but it is real. Fixed with a 1-hour withdrawal delay (requestWithdrawal / executeWithdrawal), the same unbonding-period pattern already used in EntropyAttestation.sol and LivenessGuard.sol.

Both fixes have direct regression tests confirming the original issue is closed. 25 tests pass in total, covering both interfaces' full lifecycle, mode isolation, pause switches, balance enforcement, and both reentrancy fixes.

10.4 Honest Gas Comparison

Measured directly, the on-chain gas cost of a single performNativeUpkeep call and a single performCompatibleUpkeep call are essentially the same -- there is no meaningful per-transaction gas saving from the Native path, and this whitepaper does not claim one where the data does not show it.

The real, meaningful advantage of the Native path is off-chain keeper operating cost, not on-chain gas: Compatible mode requires a keeper to run a checkUpkeep simulation against every registered client every cycle to discover what is due, while Native mode lets a keeper read every registered client's nextDeadline() in one batched, free view call and compute the single soonest wake time across its entire watch-list directly. This is a genuine operating-cost and latency advantage for a keeper running many clients at once, even though it does not show up as a smaller number in a single-call gas benchmark.

10.5 Honest Status

RandProofAutomation.sol is implemented and tested (25 passing tests, 2 adversarial findings identified and fixed with regression tests) but has not yet had an external security audit, and is not yet integrated with RandProofRNG, EntropyAttestation.sol, or LivenessGuard.sol -- it is the third independent, standalone module in this product family, following the same staged build-then-test-then-audit posture as the other two. A client using RandProofRNG for randomness and RandProofAutomation for upkeep triggering today would integrate with each separately; they are not currently wired together into one combined product.