Developer guide

EVM

5 min read

Supported networks

Direct EVM transfers work across every enabled EVM network through one relayer and authorization model. See the Roadmap for which networks and execution modes are currently available.

Transfer lifecycle

Create a quote through the official SDK, accept it with an idempotency key, then follow the asynchronous operation and its events. The platform validates the tenant context, policy and quote before it creates a signature request or submits a transaction. A submitted transaction is never assumed successful: receipts and ERC-20 Transfer logs are used during reconciliation.

Three independent choices, not one mode

A deployment answers three separate questions, and mixing them into a single setting is what once let a change of execution path change which account the money came from:

  • Account model decides the wallet's address, and is fixed for the life of the account. EVM accounts are EIP-7702: the wallet's own EOA authorizes delegation to the approved account implementation, so it gains behaviour while keeping its address.
  • Execution protocol decides only how a command travels. ERC-4337 wraps it in a UserOperation through the EntryPoint; direct relayer broadcasts a validated transaction. Both drive the same account, at the same address, and a deployment can move between them without touching a balance.
  • Gas sponsorship decides who pays: the Paymaster, or the relayer. Neither has authority to move funds or change account configuration.

On the ERC-4337 path the sponsorship is not optional. A UserOperation here is always paid by the deployment's Paymaster: there is no self-funded mode in which the account pays its own gas, and there is nothing to send in a request to ask for one or to decline it. A deployment that defines no Paymaster refuses ERC-4337 execution rather than falling back to one that would, so what an integration meets in that case is a refusal and never a charge it did not expect. An account paying its own network fee is what the UTXO families do — Bitcoin and Cardano take it from the coins being spent — and that is a different execution path, not a variant of this one.

An address therefore never depends on how an operation is executed. Changing protocol or sponsorship never migrates an account, moves a balance or changes an address.

A send split across networks

When the network you name cannot cover the amount on its own but the networks together can, the platform splits the send into one same-chain transfer per network holding part of the balance. Nothing is bridged and no third party charges a fee: each leg leaves from the network its balance already sits on.

The sender sees one quote and one confirmation. That quote carries legs — the amount and fees per network — and a totalDebit equal to the sum of the legs. A quote without legs is a single transfer.

What a consumer has to know to render it correctly:

  • Cost, network and transaction are per leg. A split ran one transaction per network, each with its own gas and its own payer, so there is no single figure that describes it. transactions names each hash with the network it settled on; the operation's chainId and transactionHash name one network, which for a send that used several is the first of them. See Costs and platform accounts.
  • If one leg fails after another already settled, the operation is partial — never presented as completed. Nothing is reversed automatically, the ledger holds only what actually happened, and a retry executes only the failed legs.
  • destinationKind says what the destination is. An external_address will receive several transfers on several networks, irreversibly, and its owner is not part of the conversation: disclose that before the sender confirms.

Insufficient balance is refused only when the sum across networks falls short too, and the refusal states the aggregate figures.

Safety boundaries

Network and asset manifests restrict what can be reached. A deployment must match its chain ID and contract bytecode before calls are made. Ambiguous broadcasts enter broadcast_unknown; reconciliation determines the result before any retry.

See Security and key management and the Roadmap for current network availability.

Capabilities in this area

This area covers the capabilities below. The Roadmap states the current availability of each one.

  • Mock end-to-end EVM transfers — The whole transfer runs against an in-memory chain that always returns the same result: quote, confirmation, execution, reconciliation and events. It is the profile the Sandbox uses by default, so an integration can be written and tested before any network access is granted.

  • Direct transfers on Anvil — Transfers are sent as ordinary EVM transactions to a local Anvil node. The adapter builds the transaction, asks the gateway to sign it and broadcasts it, and the receipt comes back from a real EVM implementation.

  • Native EIP-7702 — The user's account signs an authorization that points its address at the Account Core contract. From then on it validates operations with the contract's logic while keeping the same address. Delegating, revoking the delegation and pointing at another implementation all work.

  • ERC-4337 with Paymaster — The operation travels as a UserOperation to an EntryPoint contract through a bundler, and a Paymaster contract pays the gas. This is what lets a user send a token without holding the network's native coin.

  • Arbitrum Sepolia via API, SDK and Sandbox — The API, the SDK and the Sandbox all reach Arbitrum Sepolia. A transfer started from any of the three ends in a transaction hash that can be looked up in a public block explorer.

  • Base Sepolia via API, SDK and Sandbox — The same three surfaces reach Base Sepolia, a network on a different rollup. Chain identifiers, contract addresses and RPC endpoints come from configuration, so enabling another EVM network is an entry in a manifest.

  • ERC-4337 on Base Sepolia — Sponsored execution on a public network needs an external bundler, a Paymaster with funds and a simulation before submitting. The work covers connecting those pieces and switching to a second bundler when the first one rejects the operation or does not answer.

  • Mainnet — Execution on EVM networks where the funds are real. It depends on the custody, security and operational capabilities listed in the other areas being finished first.