12. RandProof Sentinel: Keeper-Consensus Triggered Execution

[Layer 1: Core, Design Stage]

RandProofAutomation (Section 10) replaces Chainlink Automation for the single-keeper, deterministically-verifiable case: any keeper can independently confirm a deadline or a checkUpkeep result and call performUpkeep, since the condition itself is public on-chain state with nothing to dispute. RandProof Sentinel is the next evolution of that automation layer, built specifically for the remaining case Section 10 does not cover: workflows where the action being triggered is consequential enough, typically an irreversible fund transfer or a multi-step settlement chain, that a single keeper’s claim should not be trusted alone, even when the underlying condition is itself deterministic and public.

Sentinel does not replace RandProofAutomation. A client contract may use RandProofAutomation directly for routine upkeep (Section 10’s deadline and checkUpkeep triggers) and use Sentinel only for the subset of its automation needs where execution itself, not just detection, warrants N-of-M keeper consensus before funds move.

12.1 Why a Second Automation Product, Not a Modification to Section 10

RandProofAutomation’s trust model (Section 10.2) is explicit and correct for its scope: no committee or dispute mechanism for triggering, because the condition being checked is itself public and independently verifiable, and the client’s own guard conditions re-checked inside performUpkeep are what prevent wrongful execution. Retrofitting a consensus requirement onto every RandProofAutomation call would tax the large majority of upkeep workloads, billing cycles, epoch rollovers, deadline checks, that have no need for it and were already measured and priced (Section 10.4) on the assumption that any single keeper’s call is sufficient. Sentinel is scoped narrowly to the workloads that do need consensus, and is offered as a separate, explicitly opt-in product rather than a mode flag inside RandProofAutomation.

12.2 Three Trigger Types

Sentinel exposes three trigger types. The first two mirror the detection logic already proven in RandProofAutomation; what Sentinel adds is the consensus-gated execution phase that follows detection.

Scheduled Trigger

A contract registers a call to function F on contract C at or after time T, optionally repeating on an interval. Detection requires no consensus, identical in spirit to RandProofAutomation’s Native nextDeadline() check; any keeper can verify block.timestamp independently.

Conditional Trigger

A contract registers a public view function and asks Sentinel to call function F once that view function returns true. As with RandProofAutomation’s Compatible mode, the view function itself is deterministic and publicly readable, so any keeper can independently confirm the result without off-chain computation.

Event Trigger

A contract registers a call to function F on contract C whenever contract D emits event E matching a filter. Keepers watch chain logs rather than polling state, the mechanism RandProofRNG’s own fulfillment callback already depends on internally.

12.3 The Execute Phase: Where Sentinel Diverges From RandProofAutomation

Detection (all three trigger types) requires a single keeper’s call, exactly as in RandProofAutomation. Execution is where Sentinel adds N-of-M keeper consensus, using the same commit-reveal pattern EntropyAttestation.sol already uses for randomness fulfillment:

• Commit: each assigned keeper submits a blinded commitment, keccak256(execution_ready_flag plus keeper_secret), once it has independently confirmed the trigger condition.

• Reveal: each keeper reveals its flag and secret; the contract verifies each reveal against its commitment.

• Execute: once min_keepers reveals agree the condition is met, any keeper, or the contract itself, may call executeTask(), which performs the registered function call.

12.4 Reference Implementation: Multi-Step Settlement Chains

[Layer 2: Production Deployment]

The motivating use case for Sentinel is a settlement sequence with more than one consequential step, where Section 10’s own client, AGENT5050, needs to chain a randomness fulfillment into a prize transfer without a single keeper’s unverified claim being the only thing standing between a winner-selection event and an irreversible payout:

Steps 1 through 3 could in principle be served by RandProofAutomation alone, since each is independently deterministic and publicly verifiable. Step 4 is where Sentinel’s consensus requirement applies, because it is the one step in the chain where a wrongful single-keeper call would move funds irreversibly.

12.5 Keeper Economics

• Detection fee: a small, fixed fee paid to whichever keeper first reports a Scheduled or Conditional trigger met, matching RandProofAutomation’s existing per-call fee model (Section 10.2) rather than introducing a new pricing mechanism for the part of the flow that has not changed.

• Execution fee: split among the keepers who provided valid commit-reveal attestations during the Execute phase, paid on successful executeTask() completion.

• Registration bond: contracts registering high-value Execute-phase tasks post a bond proportional to the task’s fee_per_execution, refundable on cancellation, to discourage spam registration of consensus-gated tasks specifically, since these carry a higher keeper-coordination cost than Section 10’s single-keeper workloads.

12.6 Threat Model

12.7 What Sentinel Does Not Claim

• Sentinel does not validate that a registered target function is safe, economically sound, or free of bugs; it proves the trigger condition was met and that N-of-M keepers agreed before execution, not that the execution itself was a good idea.

• Sentinel does not provide sub-second execution guarantees; the Execute phase’s commit-reveal consensus introduces latency comparable to RandProofRNG’s own existing fulfillment time, not instant settlement.

• Sentinel does not replace RandProofAutomation for workloads where Section 10’s existing single-keeper trust model is already sufficient; using Sentinel for every upkeep call would be over-engineering, not added safety.

12.8 Honest Status

RandProofSentinel.sol exists as an architectural and interface-level design in this document and has not yet undergone implementation, testing, or the adversarial audit process applied to RandProofAutomation.sol (AV-113, AV-114) or EntropyAttestation.sol. It is positioned explicitly as the next evolution of the automation layer Section 10 already shipped and tested, not as a replacement for it, and is not yet integrated with RandProofRNG, RandProofAutomation, or RandProofCompute.