When Self-Trigger Fails

The Game-Theory Assumption Behind Most Keeper Services

Chainlink Automation, Gelato, and OpenZeppelin Defender are designed around a single premise: someone benefits from triggering this action, so they'll pay to do it. Liquidations, yield harvests, fee collection — these work because the caller extracts value from triggering.

AutoLoop exists for the cases where that assumption breaks down.

Case 1: Inverted Interest

Pattern: Every participant loses something from triggering the loop.

Example: CrumbleCore floors take VRF damage on every tick. Every floor owner is rational to not call progressLoop() — it might pick their floor. The loop runs precisely because no rational player will run it themselves.

Why self-trigger fails: There's no positive-EV caller. A player who triggers the loop is voluntarily subjecting themselves to a damage roll. Self-incentivized triggering simply never happens — the game freezes without a neutral keeper.

Also applies to: Attrition-based games, shared-pool damage mechanics, negative-sum rounds, any loop where triggering costs the caller and benefits no single party.

Case 2: Timing Attack Surface

Pattern: Controlling when the trigger fires gives the caller an exploitable edge.

Example: In a VRF-based game, the keeper generates a proof off-chain and knows the output before submitting. If a player controls trigger timing, they can:

• Compute the VRF output from mempool-visible calldata
• Trigger only when the outcome favors them
• Withhold if the outcome is unfavorable

Why self-trigger fails: The ability to trigger == the ability to suppress. A player who can call progressLoop() can also choose not to, and that asymmetry is a structural exploit.

AutoLoop's solution: A neutral keeper has no stake in the outcome. It earns a gas fee regardless of the result, so withholding provides no benefit. Multi-controller registration means multiple independent keepers compete — if one withholds, another submits with a completely independent VRF output.

Also applies to: NFT reveals, airdrop draws, lottery winner selection, prediction market settlement, any loop where the outcome is knowable before it lands.

Case 3: Front-Running via Mempool Visibility

Pattern: The VRF proof is visible in the mempool before it lands on-chain. Anyone who can read the mempool can extract value.

Example: An NFT collection with VRF-assigned traits. If the trigger holder can see the VRF output in pending transactions, they can:

• Check which token IDs map to rare traits
• Buy tokens with rare traits from holders who don't know yet
• Selectively reveal only batches containing their own holdings

Why self-trigger fails: Even without controlling timing, a player-controlled trigger creates a mempool oracle. The reveal becomes unfair the moment it's submitted.

AutoLoop's solution: The neutral keeper submits without regard for trait value. No stake, no front-run incentive. Combined with RANDAO mixing (randomness = keccak256(vrfOutput, block.prevrandao)), the final randomness isn't fully determined until the transaction lands in a specific block.

Case 4: Shared World State with Diffuse Benefits

Pattern: The loop updates state that benefits all users equally — no single caller captures enough value to justify gas.

Examples:

• A dungeon floor advancing after all expeditions resolve (OracleRun)
• A DAO treasury rebalancing toward target weights
• An oracle settling a round before the next one can open
• A ForecasterLeaderboard distributing prizes across 500 forecasters

Why self-trigger fails: The public-goods problem. The trigger is worth total_benefit / n_users to any individual — which is often less than gas cost. Everyone waits for someone else to pay. Nobody does. The chain freezes.

Also applies to: Protocol maintenance operations, shared prize distributions, epoch-boundary state transitions, any loop where the cost is concentrated and the benefit is diffuse.

Case 5: Fair Randomness Requires Keeper + Block Independence

Pattern: Truly trustless randomness requires that neither the keeper nor the block proposer alone can determine the final outcome.

AutoLoop's answer: PhasedVRFCompatible implements a two-phase commit/settle protocol:

Phase 1 — Commit (block N):
  Keeper submits VRF proof. Contract stores vrfOutput, records settleBlock = N + 5.
  The keeper knows vrfOutput, but blockhash(settleBlock) doesn't exist yet.

Phase 2 — Settle (block N+6 or later):
  finalRandomness = keccak256(vrfOutput, blockhash(settleBlock))

Security properties:

On Ethereum mainnet with 500k+ validators, coordinating a specific set of 5 independently-assigned validators is practically infeasible.

Chainlink VRF: Single-phase. The VRF node knows the output before submitting and can withhold. RANDAO mixing is not part of the protocol. Two-phase commit/settle is not available.

The Structural Test

Before reaching for AutoLoop, ask:

1. Does triggering this loop cost or harm the caller? → Case 1 (inverted interest)
2. Does the caller knowing the outcome before submission create an advantage? → Cases 2 & 3 (timing attack, front-run)
3. Is the trigger benefit spread across many users with no individual captor? → Case 4 (diffuse benefit)
4. Does the application require randomness that no single party can influence? → Case 5 (two-phase VRF)

If any of these apply, self-incentivized triggering structurally fails. AutoLoop is the right primitive.

Live Examples on Sepolia, Base, and Arbitrum

Every AutoLoop demo contract was designed to demonstrate one or more of these cases concretely:

All 19 contracts are deployed on Ethereum Sepolia, Base Sepolia, and Arbitrum Sepolia with live worker coverage.