Local verification of EVM exact/eip3009 payment payloads.

Runs the full facilitator verify checklist from the exact-EVM scheme specification locally, so an Elixir resource server can cryptographically verify payments instead of trusting a remote facilitator's verify endpoint. The checks mirror the reference TypeScript/Go/Python facilitator engines check for check.

Verification levels

The :level option is required and explicit — a level whose capabilities are unavailable returns an error instead of silently downgrading:

• :structural — pure checks, no cryptography and no RPC: scheme, network, and EIP-712 domain requirements; payload shape; payTo recipient equality; exact amount equality; and the validAfter/validBefore window with the reference implementations' 6-second settlement buffer.

• :signature — everything in :structural, plus EIP-712 digest recomputation and EOA signature recovery (requires the optional ex_keccak and ex_secp256k1 dependencies, otherwise {:error, :missing_dependency}). Smart-wallet signatures (ERC-1271 / ERC-6492) cannot be proven without RPC and are rejected with {:error, {:invalid, :smart_wallet_requires_rpc}} — fail closed, never assume.

• :full — everything in :signature, plus on-chain checks over a configured X402.RPC endpoint (otherwise {:error, :rpc_not_configured}): chain-id cross-check, signature routing by payer bytecode (EOA ecrecover when the payer has no code, strict ERC-1271 isValidSignature when it does — no ECDSA fallback, matching on-chain SignatureChecker semantics), ERC-6492 counterfactual handling, asset bytecode presence, balanceOf funding, and an eth_call simulation of transferWithAuthorization with failure diagnosis (nonce already used, insufficient balance, token domain mismatch, ...).

ERC-6492 counterfactual signatures (fail-closed)

A wrapped signature from an undeployed wallet is never accepted on the strength of the wrapper alone (the reference Go design):

• the deployment factory must appear in :eip6492_allowed_factories (default [] — all counterfactual payments are rejected with {:invalid, :eip6492_factory_not_allowed} until factories are explicitly trusted), and
• validity is proven only by an atomic Multicall3 simulation that deploys the wallet and executes the transfer in a single eth_call. With simulate: false counterfactual payments are rejected with {:invalid, :undeployed_smart_wallet}.

Example

{:ok, payload} = X402.PaymentSignature.decode_and_validate(header, requirements)

{:ok, rpc} = X402.RPC.new(rpc_url: "https://sepolia.base.org", finch: MyApp.Finch)

case X402.Verify.EVM.verify(payload, requirements, level: :full, rpc: rpc) do
  {:ok, %{payer: payer}} -> grant_access(payer)
  {:error, _reason} -> deny_access()
end

The result never silently downgrades: {:ok, result} means the payment passed every check the stated :level includes, and result.level echoes that level.

Structural-only verification is pure and needs no optional dependency:

iex> requirements = %{
...>   "scheme" => "exact",
...>   "network" => "eip155:84532",
...>   "amount" => "10000",
...>   "asset" => "0x036CbD53842c5426634e7929541eC2318f3dCF7e",
...>   "payTo" => "0x209693Bc6afc0C5328bA36FaF03C514EF312287C",
...>   "maxTimeoutSeconds" => 60,
...>   "extra" => %{"name" => "USDC", "version" => "2"}
...> }
iex> payload = %{
...>   "x402Version" => 2,
...>   "accepted" => requirements,
...>   "payload" => %{
...>     "signature" => "0x" <> String.duplicate("11", 65),
...>     "authorization" => %{
...>       "from" => "0x857b06519E91e3A54538791bDbb0E22373e36b66",
...>       "to" => "0x209693Bc6afc0C5328bA36FaF03C514EF312287C",
...>       "value" => "10000",
...>       "validAfter" => "0",
...>       "validBefore" => "32503680000",
...>       "nonce" => "0x" <> String.duplicate("ab", 32)
...>     }
...>   }
...> }
iex> {:ok, result} = X402.Verify.EVM.verify(payload, requirements, level: :structural)
iex> {result.level, result.payer}
{:structural, "0x857b06519e91e3a54538791bdbb0e22373e36b66"}