Revoke.cash integration #2375

Before filing

• I searched open and closed issues for this proposal.
• I checked the docs and the current behaviour on staging.
• This is one change, not several. (Several means several issues.)

Reason: what you cannot do today

I am building a Revoke.cash integration for KeeperHub. When a workflow already has a token address and spender address, I want it to answer whether that spender is listed in a known approval exploit on the selected chain, and make the matching incident details available to later workflow steps.

This is the smaller, independent part of the approval-safety problem discussed in #2331. It does not depend on the outcome of the approval-enumeration or indexer discussion there.

The existing check-allowance action can read the current ERC-20 allowance for a known owner and spender, but it does not associate that spender with known exploit records. Today, each integration must fetch and interpret RevokeCash/approval-exploit-list itself, or hard-code the addresses.

The upstream list is an incident list. Its records contain a slug, name, description, date, amount, affected addresses identified by chainId and address, article URLs, and sometimes fixed. Matching means that a supplied spender address equals a listed address on the same chain. The token address identifies the approval being examined; it is not part of the upstream exploit match.

Reason: what the workaround costs

Every integration that needs this check must independently implement source retrieval, chain-aware address matching, incident retrieval, source drift handling, and lookup-error handling. A copied list becomes stale and loses the incident context that explains a match.

A native read action would make the evidence available to conditions, notifications, and audit-oriented workflow outputs without embedding a custom lookup in every project.

This is a consistency and developer-experience improvement. It does not claim that a missing match means a wallet is safe, or that a match proves the wallet was exploited.

Scope: what this touches, and what it does not

This proposes one credential-free action in a Revoke.cash plugin (or in the Web3 plugin if triage prefers that location): match supplied approval pairs against the public RevokeCash/approval-exploit-list and return the matching incident evidence.

It touches the new action schema, its step implementation, a small retrieval/matching helper, tests, and action documentation.

It does not change existing action response shapes or defaults. It does not discover wallet approvals, query historical logs, call Revoke.cash's private website API, run its indexer, read current allowances, inspect Permit2 state, sign transactions, revoke approvals, rank risk, or automatically block a workflow. Existing check-allowance and approve-token actions remain separate and unchanged. No database migration, wallet permission change, or pricing change is proposed.

This is one change: a read-only known-exploit lookup. Approval discovery, allowance verification, revocation, and automatic policy decisions can each be correct and useful independently, so they are outside this issue.

Plan: what you propose

Add an action named check-approval-exploits with:

• a required EVM network;
• a required template-compatible list of { tokenAddress, spenderAddress } pairs, initially bounded to 100 entries; and
• the standard read failure option, failing the step by default.

The action will normalize EVM addresses and compare both normalized spender address and exact numeric chain ID. It will preserve the input token address and input index so results remain associated with the supplied approval pair. It will return every incident that matches a pair, rather than only the first match.

Plan: alternatives you considered

• Do nothing / implement it in each integration: works, but repeats source and matching logic for every builder.
• Fold it into An agent cannot discover which token approvals a wallet has granted #2331: unnecessary coupling. Approval enumeration needs a data source; this action checks pairs a workflow already has against a public record set.
• Use Revoke.cash's website approvals endpoint or run its indexer: outside this scope and not required for the public exploit list.
• Hard-code affected spenders: simple, but loses automatic updates, revision traceability, and incident context.
• Accept one pair per action: smaller input shape, but repeats dataset retrieval in workflows that need to check several known approvals. Triage can choose the scalar shape if that better fits existing loop behavior.
• Automatically revoke or block on a match: separate policy and signing decisions. This action should return evidence for the workflow author to use.

Scope: compatibility

• Changes an existing response shape, status code, CLI flag, or default.
• Adds, removes, or upgrades a dependency.
• Changes database schema or requires a migration.
• Touches authentication, permissions, validation, or spend limits.
• Changes pricing, plan limits, or anything a user is charged.