Skip to main content
wallet_sendCalls (EIP-5792) sends multiple calls in a single user operation. All calls succeed together or revert together. The user approves once.

When to use it

  • ERC-20 approve + spend in one click.
  • Batch state changes that should atomically commit.
  • Multi-token settlement.

Send a batch

The from field is rewritten to the user’s smart account. The popup shows a single approval covering both calls. The request resolves directly with transactionHash and userOpHash once the batch lands, there is no separate id to poll.

With wagmi

Wagmi exposes useSendCalls for the same flow:

Status tracking

wallet_getCallsStatus and wallet_showCallsStatus are not implemented, in either a Mini App or a standalone application. Do not build a flow around either method. Read the transactionHash returned directly from wallet_sendCalls and, if you need a receipt, look it up with your own RPC client or waitForTransactionReceipt.

Atomicity is always guaranteed

atomicRequired is part of EIP-5792, where it lets a wallet fall back to executing calls sequentially. It has no effect here. Startale accounts pack every batch into a single UserOperation, so all calls land together or none do, whatever you pass. Set atomicRequired: true anyway. It is the honest declaration of what your batch needs, and it keeps your code correct against any other EIP-5792 wallet.

What happens underneath

wallet_sendCalls is the EIP-5792 wrapper. Under it, every entry of calls is packed into a single ERC-4337 UserOperation and submitted through the bundler. Either the whole batch lands or none of it does. This is also the only path that carries a custom paymaster. Capabilities travel on wallet_sendCalls and not on eth_sendTransaction, so a standalone application that sponsors gas should send through this method even when the batch contains a single call. See Gas in a standalone application.