EIP-5792 Wallet Call API: Batching, Capabilities, and Atomicity

Approving several wallet prompts just to complete one onchain task is slow, confusing, and easy to abandon. EIP-5792 addresses that interface problem by letting a dapp submit an ordered group of calls through one wallet request. But a shorter flow is not automatically safer. Understanding the EIP-5792 Wallet Call API belongs in any practical guide to crypto wallet security.

This guide explains the finalized interface standard, what wallet_sendCalls does, how a dapp checks support and status, and where atomicity can be misunderstood. It is educational, not financial advice (NFA). A batch can contain approvals, transfers, or contract interactions with irreversible effects, so inspect every action, use only funds you can afford to lose, and do your own research (DYOR).

What Is the EIP-5792 Wallet Call API?

EIP-5792 is a final Ethereum interface standard that defines four wallet-facing JSON-RPC methods:

• wallet_sendCalls asks a wallet to submit a batch of onchain write calls.
• wallet_getCallsStatus returns the status and relevant receipts for a submitted batch.
• wallet_showCallsStatus asks the wallet to display information about a known batch.
• wallet_getCapabilities reports features that an authorized account can use on particular chains.

The standard complements the older eth_sendTransaction flow. It does not prescribe one account implementation or transaction envelope. A traditional externally owned account (EOA) might turn a non-atomic batch into several transactions, while a smart account might execute several calls inside one transaction.

Think of the API like giving a courier one manifest containing several stops. The manifest preserves the requested order, but it does not prove that every stop will happen in one indivisible trip. The dapp has to request the required guarantee, and the wallet has to advertise and honor it.

How wallet_sendCalls Works

A request includes a version, chain ID, an optional sender, an atomicRequired flag, and an ordered calls array. Each call can contain a destination (to), calldata (data), and native value (value). The wallet must keep calls on the specified chain and preserve their order.

{
  "version": "2.0.0",
  "from": "0xYourAccount",
  "chainId": "0x1",
  "atomicRequired": true,
  "calls": [
    { "to": "0xToken", "data": "0xApproveData" },
    { "to": "0xProtocol", "data": "0xDepositData" }
  ]
}

This simplified example resembles an approval followed by a deposit. The actual hexadecimal calldata determines the action; labels in a dapp are not authoritative. A trustworthy wallet should decode and simulate the calls when it can. You should confirm the contracts, amounts, spender, chain, and expected balance changes.

If the user rejects the request, the wallet must not send any call from the batch. If the wallet accepts it, wallet_sendCalls returns a batch identifier rather than necessarily returning a transaction hash. That distinction matters because one batch can map to one or several underlying transactions.

Capability Discovery Is Per Chain

Before relying on batching, a connected dapp can call wallet_getCapabilities for an authorized address and optional chain list. The response is keyed by hexadecimal chain ID because an account may support different features on Ethereum mainnet and an L2.

The built-in atomic capability has three states:

If the atomic capability is absent for a chain, EIP-5792 says the wallet does not support batching there unless another capability overrides that interpretation. Live wallet responses are the current source of truth when they conflict with cached or out-of-band capability data.

Capabilities can extend the request. For example, ERC-7677 defines a paymasterService capability for compatible account-abstraction wallets. Unsupported capabilities must cause rejection unless the dapp explicitly marks them optional. “Optional” changes fallback behavior; it does not make a capability trustworthy.

Atomic and Non-Atomic Batches Are Different

Atomic execution means all calls succeed together or no material effects remain onchain. Contiguous execution means unrelated transactions or calls cannot be interleaved with the batch. With atomicRequired: true, the wallet must provide both guarantees or reject the request.

With atomicRequired: false, a wallet may execute calls sequentially without either guarantee. It may still choose atomic execution if available. This flexibility supports EOAs, but it creates an important user risk: an early call can succeed while a later call fails.

Imagine approving a token in the first transaction and attempting a swap in the second. If the swap fails in a non-atomic flow, the approval may remain. You have spent gas and may have left a token allowance active even though the intended outcome never occurred. That is why batch status, receipts, and post-transaction allowance checks matter.

The EIP also warns developers not to assume that an “atomic” batch always becomes one transaction. Atomicity describes the observable execution guarantee, not a universal packaging format.

Tracking a Batch After Submission

The batch ID returned by wallet_sendCalls is passed to wallet_getCallsStatus. The response includes a numeric status, chain ID, an explicit atomic boolean, and—when available—receipts containing only logs relevant to the submitted calls.

For atomic execution, the status response may contain one receipt or multiple receipts depending on how calls reached the chain. For non-atomic execution, it contains receipts for included transactions, including calls that reverted. The specification says wallets should retain a queryable batch status for 24 hours after submission.

wallet_showCallsStatus serves a different purpose: it asks the wallet to show its own information about a known batch and returns no status object on success. A dapp should use wallet_getCallsStatus for programmatic tracking and treat the wallet display as a user-facing inspection surface.

Security and Privacy Risks

Batching reduces prompt fatigue, but it concentrates authority into one confirmation. Check these risks before approving:

1. Hidden consequential calls. A harmless-looking transfer can sit beside an unlimited approval or delegated action. Review the full ordered list.
2. Partial execution. A non-atomic batch can leave approvals, transfers, or other state changes behind when a later call fails.
3. Misleading presentation. Human-readable labels depend on wallet decoding. Verify contract addresses and simulated asset changes rather than trusting a dapp summary.
4. Capability mismatch. Support varies by account and chain. Do not assume a feature seen on one network exists on another.
5. Status confusion. A batch ID is not necessarily a transaction hash. Follow the batch status and inspect every resulting receipt.
6. Fingerprinting. Capability queries can reveal wallet-software characteristics. The EIP discourages over-querying and capability oversharing.

Pair call inspection with clear signing practices. A polished confirmation screen cannot make an unknown spender, excessive allowance, or malicious destination safe.

A Practical Approval Checklist

Before accepting an EIP-5792 batch, verify:

• the active account and hexadecimal chain ID match your intention;
• every destination contract is expected and independently verified;
• every token amount, native value, spender, and allowance is bounded;
• the wallet shows whether atomic execution is required and supported;
• simulation shows the complete balance and approval changes;
• optional capabilities, including any paymaster, have clear consequences;
• you know how to inspect the batch status and resulting receipts;
• a failed non-atomic flow will not leave dangerous permissions behind.

Smart-account features can make these flows more capable. Our account abstraction guide explains the account model, while the ERC-4337 paymaster guide in this cluster covers who may pay fees and why “gasless” does not mean costless or risk-free.

FAQ

Does EIP-5792 make every batch one transaction?

No. The interface can represent one or several underlying transactions. Atomicity is an execution guarantee negotiated through atomicRequired and wallet capabilities, not a promise about transaction count.

Can a regular EOA use wallet_sendCalls?

Yes, if its wallet supports the method. Without an account mechanism that executes multiple calls atomically, the wallet may submit separate transactions when atomic execution is not required.

Does an atomic batch make approvals safe?

No. Atomicity only controls whether the batch’s effects stand together. It does not prove that a spender, amount, contract, or dapp is legitimate.

What happens when a wallet does not support EIP-5792?

Unsupported methods should return errors. A dapp may fall back to serial eth_sendTransaction requests or report that the wallet is unsupported. The fallback can have different atomicity and confirmation behavior, so it should be explicit.

The Bottom Line

EIP-5792 gives dapps and wallets a common language for ordered call batches, capability discovery, and status tracking. Its key lesson is precise: batching and atomicity are related, but they are not synonyms. Read the full batch, confirm the chain-specific guarantee, simulate consequences, and inspect the final receipts.

This article is educational and not financial advice. Onchain actions can be irreversible and crypto assets are volatile; use only funds you can afford to lose and always DYOR.

Sources

• EIP-5792: Wallet Call API
• EIP-1193: Ethereum Provider JavaScript API
• ERC-7677: Paymaster Web Service Capability
• ERC-4337: Account Abstraction Using Alt Mempool