Ethereum Keeper Reward Profitability Preflight

Use this skill before calling a public harvest, earmarkRewards, liquidate, checkpoint, or settlement function whose reward may go to msg.sender.

Objective

Produce an evidence record containing: block number, exact calldata, simulated caller asset delta, gas estimate, executable exit quote, maximum fee, safety haircut, and net profit in ETH. Never send merely because the call succeeds or returns true.

Hard gates

1. Work on a pinned recent block or record the latest block used.
2. Simulate from the exact candidate EOA. A call from a multicall contract can redirect the caller reward and produce the wrong answer.
3. Measure asset balance changes, not function return values.
4. Include the reward-token-to-WETH exit transaction and approvals in cost unless the goal explicitly accepts the token as final value.
5. Require the EOA to afford gasLimit × maxFeePerGas + value before submission. A profitable reward cannot rescue an underfunded EOA from Ethereum's upfront balance check.
6. Add at least a 20% gas buffer and a price/slippage haircut. Reject stale or non-executable web quotes.
7. Re-simulate immediately before signing. Abort on a changed reward, nonce, base fee, pool state, or competing keeper transaction.

State-override method

When sequential eth_call requests cannot observe a temporary caller reward, compile a tiny runtime helper and temporarily install its runtime bytecode at the candidate EOA using the third eth_call state-override parameter. The helper must:

• read the reward token's balanceOf(address(this));
• call the target keeper function;
• read the balance again;
• return after - before.

Call the overridden EOA from a throwaway address. Inside the helper, the target sees the overridden EOA as msg.sender, so the returned delta matches the reward an ordinary transaction from that EOA would receive. The override exists only for that read-only simulation and never changes chain state.

Minimal Solidity shape:

interface Target { function run(uint256 id) external returns (bool); }
interface ERC20 { function balanceOf(address) external view returns (uint256); }
contract RewardProbe {
    Target constant TARGET = Target(TARGET_ADDRESS);
    ERC20 constant REWARD = ERC20(REWARD_TOKEN);
    function probe(uint256 id) external returns (uint256 delta) {
        uint256 beforeBalance = REWARD.balanceOf(address(this));
        TARGET.run(id);
        delta = REWARD.balanceOf(address(this)) - beforeBalance;
    }
}

Adapt the function signature and constants, compile with optimization, and put only evm.deployedBytecode.object in the override's code field. Never deploy the probe.

Batch workflow

1. Read pool/task count from the target registry.
2. Batch no more than the RPC provider's documented request limit.
3. Record success, revert reason, and reward delta for every identifier.
4. Sort by executable ETH value, not raw token units.
5. Run eth_estimateGas only for the strongest candidates.
6. Obtain an onchain quoter result or simulate the complete exit route.
7. Compute:

netWei = exitWeiAfterSlippage - keeperGas - approvalGas - exitGas - bribeWei

1. Submit only when netWei remains positive under the buffered max fee and exceeds the required minimum profit.

Evidence template

{
  "chainId": 1,
  "block": 0,
  "target": "0x...",
  "calldata": "0x...",
  "rewardToken": "0x...",
  "rewardAmount": "0",
  "exitQuoteWei": "0",
  "gasEstimate": "0",
  "gasLimitBuffered": "0",
  "maxFeePerGasWei": "0",
  "allInCostWei": "0",
  "netWei": "0",
  "decision": "reject",
  "reason": ""
}

Dated validation case

On Ethereum mainnet on September 27, 2026, this method found a gross caller incentive of about 1.2795 CRV for one Convex pool. The direct call's gas estimate was about 719,439. With gas near 10.18 gwei and CRV near 0.0001281 ETH, the reward was about 0.000164 ETH while keeper gas alone was roughly 0.0073 ETH. The correct decision was reject. This case demonstrates why successful simulation is not the same as profit.

Output discipline

Return the top candidates with reproducible inputs and a clear send/reject decision. Do not claim earnings until a finalized receipt and post-transaction balances prove them. Do not expose private keys, API tokens, or signed raw transactions in logs.