Skip to main content
This is a reference for the verification API’s payload adapter. For apps you can use inside a Desk, see Desk apps.
venue: alchemy. Over MCP, evm also works. Over HTTP, evm, evmtransaction, alchemymcp, ethereum, eth, erc20, onchain, base, arbitrum, optimism and polygon also resolve to it. This adapter reads any EVM transaction request, whatever composed it. Alchemy’s MCP server gives agents chain data and simulation but no execution, so an agent using it builds the transaction itself and signs it elsewhere. This is where that transaction is checked.

What to send

The eth_sendTransaction request object: {from?, to, value?, data or input, chainId}, bare or wrapped in {transaction} or {tx}. Without venue, it is detected when it has calldata, or when it moves a positive value and also has chainId or from. A bare {to, value} is too generic to detect. Alchemy is the last adapter tested, so a transaction to a contract another adapter knows, such as a Uniswap router or a Dimes vault, is classified there. The summary names the chain and decodes recipient, spender, owner and raw amount from the calldata. Native values are converted from wei.

Live lookup

For the three ERC-20 action types, the adapter reads symbol() and decimals() from the token contract with eth_call through a public RPC node, and converts the raw amount to token units. It covers Ethereum, OP Mainnet, BNB Smart Chain, Gnosis, Polygon PoS, Base, Arbitrum One, Avalanche C-Chain, Linea, Scroll, Sepolia and Base Sepolia. The timeout is 3.5 seconds; results are cached for 5 minutes, and failures for 30 seconds. The symbol is what the contract reports about itself, not proof that it is the real asset. Pin token addresses in your rules. When the token cannot be read, or the chain is missing or not covered, a note says its identity is unverified and tells the judge to lean ESCALATE if your rules depend on it.

Notes the classifier adds

  • A missing chainId, and a testnet chain.
  • An approval of 2^256 - 1, the unlimited sentinel, or of 2^128 or more. An approval moves nothing when signed but lets the spender take the owner’s balance of that token later.
  • transferFrom spends an existing allowance, possibly from a wallet other than the signer’s.
  • Native value sent along with an ERC-20 call.
  • Calldata that matches an ERC-20 selector but is not validly encoded.
  • An unknown selector. The note tells the judge to lean ESCALATE unless your rules cover that contract and function.

Example

From an MCP client

Instruct the agent to call verify_intent before signing any transaction it composed, with your rules as intent, the exact transaction request as action and venue: "alchemy", and to act only on ALLOW. To have Chance hold the key and sign only what passes, use an escrow wallet: escrow_execute and POST /api/v1/wallets/{id}/propose take a raw EVM transaction, simulate it, judge it against the wallet’s rules and sign it only if it passes.