ERC-5792 wallet_sendCalls Explained: Batch Transactions, Status Checks, and Wallet Safety

For prerequisite reading, review TokenToolHub’s EIP-7702 guide to understand how ordinary EOAs can gain smart-account behavior without changing addresses. The Account Abstraction in Practice guide explains why batching, sponsorship, passkeys, session keys, and programmable validation increasingly belong at the wallet layer rather than inside every application.

Why wallets need a standard for multiple calls

The traditional Ethereum application model was largely built around eth_sendTransaction. A dApp prepared one transaction, a wallet asked the user to approve it, the transaction was broadcast, and the application later checked its receipt.

That model still works, but many modern user flows contain several related actions. A user might need to approve a token and then swap it. They might claim rewards and immediately stake them. They might authorize a permit, deposit assets into a vault, and delegate the resulting position. A smart-account user may want the wallet to execute several calls atomically through one account operation.

Without a standardized wallet call interface, applications have to understand the execution mechanism of each wallet or reduce every experience to a sequence of conventional transactions.

Multiple calls do not always mean multiple transactions

This distinction is the foundation of ERC-5792. An application knows the calls it wants to request. It should not have to decide whether the wallet packages them into one smart-account execution, several ordinary EOA transactions, an ERC-4337 UserOperation, an EIP-7702-enabled account execution, or another mechanism.

The wallet is in a better position to understand its account architecture, gas model, sponsorship system, security policy, supported chain, and available capabilities.

One user action can require several protocol actions

Consider a user swapping USDC through a router. If the router does not already have allowance, the user may traditionally need to approve USDC, wait for the approval transaction, return to the application, sign a swap, and wait again.

A capable wallet can potentially process the approval and swap as a coordinated batch. From the application’s perspective, the desired result is simply that those calls execute in the correct order under the required guarantees.

Wallets are becoming execution environments

EIP-7702 changed the account model by allowing EOAs to delegate execution to smart-contract code while keeping the same address. ERC-4337 wallets already support programmable execution through UserOperations. Modern wallet systems can also use paymasters, session keys, spending policies, passkeys, and recovery systems.

ERC-5792 gives applications a wallet-facing interface that can survive those implementation differences.

The API separates application intent from wallet mechanics

The application supplies ordered calls, chain context, an optional sender, atomicity requirements, and requested capabilities. The wallet decides how to satisfy those requirements using its own execution architecture.

This separation is important for interoperability. A dApp should not need a separate approval-plus-swap integration for every wallet implementation.

The four core ERC-5792 wallet methods

ERC-5792 defines four JSON-RPC methods. Three relate directly to the lifecycle of a batch, while one lets the application learn which capabilities the wallet exposes.

wallet_getCapabilities: discover what the wallet can actually do

Modern wallets do not all expose the same execution features. One wallet may support atomic batching on Base but not Ethereum. Another may support a paymaster or auxiliary funds capability. Another may be able to upgrade itself to support atomic execution only after the user explicitly approves that change.

wallet_getCapabilities gives the application a standardized way to ask.

Capabilities are account-aware

The request includes a wallet address. That matters because capabilities can depend on the selected account architecture, not merely the wallet application.

One account may be a smart contract with native batch execution. Another account inside the same wallet may still operate as a plain EOA. A third may be eligible for an EIP-7702 upgrade.

Capabilities are chain-aware

ERC-5792 structures capability responses by chain ID. This prevents an application from assuming that because atomic batching is supported on one network it must be supported everywhere.

The standard also allows wallet-wide capabilities to be reported under a special 0x0 chain entry when they apply across all relevant chains.

Live wallet responses should be treated as current

Capabilities can be cached or surfaced outside the direct RPC flow, but the specification says that when supplemental capability information conflicts with a live wallet RPC response, the live wallet response should be treated as canonical and current.

A simplified capability query

{
  "method": "wallet_getCapabilities",
  "params": [
    "0xUSER_ADDRESS",
    ["0x1", "0x2105"]
  ]
}

The exact response depends on the wallet. A wallet could report different capabilities for Ethereum and Base, or omit a chain it does not support.

Do not over-query capabilities

Capability discovery has privacy implications. A distinctive combination of features can contribute to wallet fingerprinting. Builders should request only information needed for the current user flow instead of interrogating every possible capability across every chain.

The atomic capability: supported, ready, and unsupported

The most important built-in capability in ERC-5792 is atomic. It tells the application whether the wallet can provide atomic and contiguous execution of a requested call batch on a specific chain.

Atomic support is chain-specific

A wallet reporting atomic support for Base is making that guarantee for Base. The same wallet can report unsupported for another chain.

Ready is not the same as supported

A ready wallet has a path to support atomicity but has not completed the necessary user-approved change. This can be relevant for wallets that can enable a smart-account mode or EIP-7702 delegation.

The wallet cannot silently downgrade a required atomic batch

If the application sets atomicRequired to true, atomicity is not a preference. It is a requirement. If the wallet cannot provide it, the request must not be silently converted into a non-atomic sequence.

wallet_sendCalls: the heart of ERC-5792

wallet_sendCalls asks the wallet to submit a batch of on-chain calls. The application expresses what needs to happen while leaving execution packaging to the wallet.

The current request structure includes a version, optional batch ID, optional from address, chain ID, atomicity requirement, ordered calls, and optional capabilities.

Each call is deliberately simple

The base call object can contain:

• to: the destination contract or account.
• data: calldata for the destination.
• value: native asset value attached to the call.
• capabilities: optional call-specific capability metadata.

The simplicity is intentional. The wallet API is not trying to standardize every possible smart-account implementation.

The chainId is explicit

The chain identifier is supplied in hexadecimal form. Every call in the request must be sent on that requested chain unless another capability defined outside the base standard explicitly introduces different behavior.

This is why a hypothetical bridge-plus-call workflow needs careful wording. ERC-5792 itself coordinates calls on one requested chain. A source-chain bridge call might encode destination-chain instructions for a bridge protocol, but ERC-5792 does not make the wallet magically execute a second native ERC-5792 call on another chain as part of the same base batch.

The from field can be explicit or wallet-selected

If the application supplies from, the wallet must send the calls from that address when processing the request under the standard rules. If the application omits it, the wallet should give the user an opportunity to view and select the source address during confirmation.

The wallet must preserve call order

This requirement is crucial. If the application submits approve first and swap second, the wallet must send them in that order. Reordering could make the swap fail or change the security properties of the operation.

User rejection cancels the whole request before sending

If the user rejects the ERC-5792 request, the wallet must not send any calls from that request.

An illustrative approval-plus-swap request

{
  "method": "wallet_sendCalls",
  "params": [{
    "version": "2.0.0",
    "from": "0xUSER_ADDRESS",
    "chainId": "0x1",
    "atomicRequired": true,
    "calls": [
      {
        "to": "0xTOKEN_CONTRACT",
        "data": "0xAPPROVE_CALLDATA",
        "value": "0x0"
      },
      {
        "to": "0xSWAP_ROUTER",
        "data": "0xSWAP_CALLDATA",
        "value": "0x0"
      }
    ]
  }]
}

The user sees one coordinated request, but two materially different actions are present. Call one creates spending authority. Call two consumes some or all of that authority to perform a swap.

The batch should therefore not be summarized only as Swap. The approval deserves explicit treatment.

What atomicRequired actually means

Atomicity is often described casually as one transaction, but ERC-5792 deliberately defines the requirement in terms of effects and contiguity rather than demanding one universal transaction format.

When atomicRequired is true

The wallet must execute the calls atomically. Either all calls execute successfully or no material effects from the batch appear on-chain. The calls must also execute contiguously, so unrelated transactions or calls cannot be interleaved between them.

If a wallet is in the atomic ready state and can upgrade to supported, it must complete that user-approved upgrade before submitting a batch that requires the guarantee.

Atomic does not necessarily mean one receipt

The standard explicitly avoids assuming a specific transaction architecture. An atomic batch may produce one receipt or several receipts depending on how the wallet and chain include the calls.

The important point is that wallet_getCallsStatus must report atomic: true when the wallet actually executed the batch atomically.

When atomicRequired is false

The wallet may execute calls sequentially without atomicity or contiguity guarantees. It may also choose to execute them atomically if it has that capability.

This is why builders should never interpret false as a command to make the batch non-atomic. It means atomicity is not required by the application.

Non-atomic execution creates partial-state risk

Suppose call one approves 10,000 USDC and call two attempts a swap. If the calls execute non-atomically and the approval succeeds but the swap fails, the approval may remain active.

A UI that merely says Swap failed can hide the far more important fact that a persistent permission was successfully created.

Batch call lifecycle: request to receipt verification

ERC-5792 becomes easier to understand when treated as a lifecycle rather than one RPC call. The application first learns what the wallet can support, constructs a batch, asks for confirmation, receives a batch identifier, queries execution status, and finally verifies the resulting on-chain state.

Why wallet_sendCalls returns a batch identifier instead of one transaction hash

The result of wallet_sendCalls contains an id. That identifier belongs to the wallet-level call bundle, not necessarily to one specific blockchain transaction.

This is essential because different wallets can translate the same request into different execution mechanisms.

A smart account may use one transaction

A smart wallet with a batch executor may encode all requested calls inside one transaction. In that case, the bundle can ultimately correspond to one transaction receipt.

An EOA wallet may send several transactions

If atomicity is not required and the wallet supports non-atomic batching, it may send several conventional transactions while still exposing one ERC-5792 batch identifier to the application.

An ERC-4337 wallet may use a UserOperation

The calls can be encoded inside a UserOperation and included by a bundler. The resulting transaction may contain activity from other users as well, which is why ERC-5792 restricts status receipts to logs relevant to the submitted call bundle.

An EIP-7702 wallet can use delegated account code

After Pectra, an EOA can delegate execution to wallet-vetted code that supports batching. Ethereum’s current builder guidance specifically recommends that applications ask for the outcome through interfaces such as wallet_sendCalls rather than forcing the application to manage EIP-7702 delegation itself.

This is an important design principle: the dApp requests the batch, while the wallet decides how the account should execute it.

wallet_getCallsStatus: understand what actually happened

After receiving the batch identifier, the application can call wallet_getCallsStatus. This method returns a version, batch ID, chain ID, numeric status, atomicity flag, optional receipts, and capability metadata.

The status is not a replacement for the receipts. It is a summary designed to help the application understand the batch lifecycle.

Status 100: pending

The wallet has received the batch, but on-chain execution has not completed.

Pending does not mean failure, and it does not mean every underlying transaction has already been broadcast. The wallet may still be preparing, relaying, sponsoring, or waiting for inclusion.

Status 200: confirmed

The batch has been included on-chain without reverts, and receipt information is available for the relevant calls.

Confirmed tells you the wallet considers execution successful under the ERC-5792 status model. Applications should still reconcile expected asset and permission state.

Status 400: off-chain failure

The batch was not included on-chain and the wallet will not retry it. This can result from wallet-side or infrastructure failure before chain inclusion.

The key point is that there should not be batch calls included on-chain as part of this failed attempt.

Status 500: complete chain failure

The batch reverted completely. Effects related to the requested calls should not remain, apart from gas-related consequences allowed by the chain and execution mechanism.

This is the status users often expect from the word atomic failure.

Status 600: partial chain failure

This status is especially important. It means the batch reverted partially and some changes related to batch calls may have been included on-chain.

When you see a partial failure, do not retry the original batch blindly. Determine which calls succeeded first.

Status categories leave room for extension

ERC-5792 groups status codes into broad categories. More specific statuses can be introduced through separate standards. Builders should therefore avoid logic that assumes the five currently listed values are the only statuses that can ever exist.

How ERC-5792 receipts should be interpreted

The receipts returned by wallet_getCallsStatus are a strict subset of a conventional eth_getTransactionReceipt object. They can contain logs, transaction status, block hash, block number, gas used, and transaction hash.

Receipt order follows on-chain inclusion

The specification requires the receipt array to follow the order in which the relevant transactions were included on-chain.

Atomic execution can return one or several receipts

Do not infer atomicity from receipt count. ERC-5792 explicitly allows an atomic batch to report either one receipt or multiple receipts depending on how it was included on-chain. The atomic boolean is the direct indicator.

Non-atomic execution must expose included transactions

When calls execute non-atomically, the wallet must report receipts for the transactions containing submitted calls that reached the chain, including calls that later reverted.

Logs should be scoped to the user’s call bundle

This is particularly important under ERC-4337. One bundler transaction can contain multiple users’ operations. ERC-5792 says the logs returned for your batch should include only logs relevant to your submitted calls rather than unrelated activity from the broader bundle.

Wallet upgrade logs should not contaminate the app result

If the wallet upgraded itself to obtain atomic capability before executing the requested calls, logs generated by that wallet upgrade should not appear as though they were part of the application’s batch.

wallet_showCallsStatus: let the wallet explain its own batch

wallet_showCallsStatus asks the wallet to display information about a known batch identifier. It is useful when the application wants the wallet’s own interface to show execution status or details.

The method is deliberately different from wallet_getCallsStatus. The latter returns machine-readable information to the application. wallet_showCallsStatus requests a wallet-controlled user experience.

Why this separation matters

The wallet can have information about its execution architecture, sponsorship, account upgrade, signatures, and batching model that the application should not recreate incorrectly.

For security-sensitive flows, the application can use its own status interface while also giving the user a route to the wallet’s first-party execution view.

Example 1: approval plus swap

This is one of the most obvious ERC-5792 use cases.

A user wants to swap 1,000 USDC for ETH. The swap router currently has no USDC allowance.

Traditional flow

The user signs an approval, waits for confirmation, returns to the dApp, signs the swap, waits again, and then checks the output.

ERC-5792 flow

The application sends two ordered calls:

1. Approve the router to spend the required amount of USDC.
2. Call the router to swap USDC for ETH.

Why atomicity can matter

If the approval is intended only to enable the immediate swap, the user may prefer atomic execution so that a failed swap does not leave the new allowance behind.

If atomicRequired is false, the wallet can process the calls sequentially. A failure after the approval can therefore leave a persistent token permission.

What the wallet should explain

A strong confirmation experience should show the token, spender, approval amount, swap router, amount being spent, minimum output, recipient, and whether the calls will execute atomically.

A one-line summary that says Swap 1,000 USDC is incomplete if the first call grants a larger or unlimited allowance.

What the user should verify afterward

Check the received ETH, remaining USDC, swap result, router allowance, and transaction receipts. If a larger allowance remains, decide whether it should be reduced.

For approval-specific risk, review Crypto Approval Risks.

Example 2: permit plus protocol action

An ERC-2612-compatible token can create an allowance through a signed permit. A protocol can use that permit and then immediately pull the tokens in a coordinated transaction flow.

From a user-experience perspective, this can remove a separate token-approval transaction. From a security perspective, the permit remains a real authorization.

The builder still needs to expose the permit semantics

The user should see the owner, spender, token, value, deadline, nonce, chain, and verifying contract associated with the permit.

The batch should not hide signature authority

A flow that says Deposit 1,000 USDC but also generates a long-lived permit for a much larger amount is materially different from an exact-spend approval.

Failure ordering matters

Depending on how the permit is consumed and how the protocol call executes, the final allowance state can differ. Builders should simulate and test the exact integrated path rather than treating permit as merely a gas-saving convenience.

Read EIP-2612 Permit for the underlying signed-approval model.

Example 3: claim plus stake

A protocol may let a user claim rewards and immediately stake them.

Call one: claim

The first call causes the rewards contract to transfer tokens or mint a claimable asset to the user.

Call two: stake

The second call deposits those newly obtained assets into another contract.

Ordering is mandatory

The stake call may fail if it executes before the claim. ERC-5792 requires the wallet to send calls in the application-provided order.

Atomic versus non-atomic user outcomes

With atomic execution, the user either completes both operations or the requested state transition fails as one unit. With non-atomic execution, the claim may succeed while staking fails.

That partial state is not necessarily harmful. The user may simply retain the claimed tokens. But the application must recognize it and should not tell the user that nothing happened.

Example 4: bridge plus source-chain call

Bridge workflows are frequently described as bridge-plus-call, but the execution boundary needs careful explanation.

An ERC-5792 batch has one requested chain ID. The wallet sends the requested calls on that chain. A bridge contract called on the source chain can encode instructions that another protocol later executes on the destination chain, but that destination execution belongs to the bridge or interoperability protocol’s mechanics rather than the base ERC-5792 batch.

What ERC-5792 can coordinate on the source chain

A batch could approve a bridge contract and then call the bridge. It could also perform another source-chain setup step if the application and wallet support the required execution semantics.

What ERC-5792 does not guarantee

It does not make a destination-chain bridge settlement atomically part of the original source-chain batch. Cross-chain finality, messaging, liquidity, relayers, bridge contracts, destination calls, and failure recovery remain protocol-specific.

User confirmation must distinguish the two phases

A wallet should not make Bridge and execute on destination look like a single synchronous chain operation if the destination action can fail later.

ERC-5792 and smart wallets

ERC-5792 does not define what a smart wallet is. It gives applications a way to request wallet-level call execution without caring which account model is underneath.

ERC-4337 accounts

An ERC-4337 wallet can encode several calls into one UserOperation. A paymaster can potentially sponsor gas. A bundler can include the UserOperation on-chain.

The application still interacts with ERC-5792 at the wallet boundary rather than building assumptions around the bundler architecture.

EIP-7702 delegated EOAs

EIP-7702 lets an EOA point its account code to wallet-controlled smart-account logic. That code can support batch execution while the user retains the same address.

Ethereum’s current guidance recommends that applications integrate through standardized interfaces such as ERC-5792 instead of asking users to delegate directly to app-controlled code.

Existing smart contract wallets

A multisig or smart wallet may already expose batch execution without EIP-7702. ERC-5792 can still provide the app-facing request format where supported.

Plain EOAs

A wallet can potentially accept a non-atomic ERC-5792 batch and submit sequential EOA transactions when the application does not require atomic execution.

This is why ERC-5792 should not be described simply as a smart-wallet transaction standard. It is a wallet call API that accommodates several execution architectures.

For broader account design, read Account Abstraction in Practice.

Simulation and preflight checks for batch calls

Batching increases the importance of transaction simulation because later calls can depend on state changes from earlier ones.

Simulate in the requested order

If call two assumes call one already changed allowance or token balance, simulating the calls independently against the same starting state can produce misleading results.

The simulation should model the sequence.

Simulate the same source account

Authorization checks, balances, allowances, ownership, roles, and protocol positions depend on the sender. A successful simulation from a generic address does not prove the connected wallet can execute the batch.

Simulate native value correctly

Each call can include a value field. Make sure simulations account for the same ETH or native asset amounts.

Simulate the real chain

Contract code, liquidity, oracle values, balances, and permissions differ by network. A Base simulation is not evidence for Ethereum execution.

Check allowance state before simulation

If the user already has sufficient allowance, an application may not need to include an approval call. Reducing unnecessary calls reduces attack surface and confirmation complexity.

Do not treat simulation as finality

State can change between simulation and inclusion. Slippage can worsen, a pool can move, an oracle can update, a nonce can change, a contract can be paused, or another transaction can alter relevant state.

Wallets may reject batches expected to fail

ERC-5792 permits wallets to reject a request when one or more calls are expected to fail under sequential simulation. That is a safety feature, not a guarantee that any accepted batch must succeed.

Decode the underlying calls, not only the wallet summary

ERC-5792 improves wallet interoperability, but it also creates a UX challenge: one confirmation can contain several independent contract calls.

For a high-value or unfamiliar batch, inspect each underlying call through the TokenToolHub EVM Transaction Decoder or another independent decoding workflow.

Inspect every destination

Identify the target contract for each call. A batch that interacts with three contracts has three independent destinations that require context.

Inspect every function

Do not stop after confirming the first call. Later calls can create approvals, transfer assets, change account settings, or call unfamiliar contracts.

Inspect every attached value

One call can send native ETH even if the overall interface primarily discusses tokens.

Inspect approvals separately

When one batch contains approve plus swap, the approval should be evaluated as a persistent permission rather than hidden inside a swap summary.

Inspect nested calls

A batch call may target a multicall router or smart-account executor whose calldata contains another layer of calls. The top-level ERC-5792 call list is not necessarily the deepest level of execution.

Partial execution: the risk users cannot ignore

Non-atomic batches are not inherently unsafe. They are simply different. The problem begins when an application or user assumes all-or-nothing behavior that was never guaranteed.

Approval succeeds, swap fails

The wallet now has a new token allowance but no swap output.

Claim succeeds, stake fails

The user owns the claimed reward token but has no staking position.

Deposit succeeds, follow-up configuration fails

Funds can be inside a vault while the expected delegation, lock, or strategy configuration remains incomplete.

First transfer succeeds, second transfer fails

The batch can leave assets split across destinations instead of reaching the intended final distribution.

One approval succeeds while a later revocation fails

A batch that temporarily opens and later intends to close a permission is dangerous under non-atomic execution because the cleanup call may never execute.

Status 600 is an investigation state

When the wallet reports partial failure, the safe next step is state inspection. Retrying the whole batch can duplicate successful transfers, create another deposit, claim twice if the protocol allows it, or overwrite permissions unexpectedly.

Call ordering is part of transaction intent

ERC-5792 requires the wallet to send calls in the order supplied by the application. That requirement is not merely an implementation detail. Order can determine whether the batch works and whether it is safe.

Approve before transferFrom

A spender cannot use an allowance that has not yet been created.

Claim before stake

The account may not have the stakeable asset until the claim executes.

Deposit before collateral-dependent action

A lending protocol may require collateral state before a borrow or leverage step.

Revoke after use

A batch can potentially approve an amount, use the allowance, then reduce it. This pattern only provides the intended cleanup guarantee when the wallet can provide the atomic or flow-control semantics the application relies on.

Wrong order can be dangerous even when all calls succeed

Suppose a batch transfers an NFT before revoking an operator. The result can differ from revoking first. Builders should document ordering as part of the intended state transition.

Capabilities are not permissions to hide complexity

ERC-5792 provides a general capability system so additional wallet features can evolve through separate standards. Capabilities can be attached at the batch level or to individual calls.

Required capabilities must be supported

If a request includes a capability the wallet does not support and it is not explicitly marked optional, the wallet must reject the request.

Optional capabilities can be ignored

An application can mark a capability as optional. A wallet that does not support that capability may still process the rest of the request.

Optional does not mean invisible

If an optional capability changes gas sponsorship, permissions, auxiliary funds, or another user-relevant outcome when supported, the application should make that conditional behavior understandable.

Do not build safety assumptions around an optional feature

If a security property is necessary for safe execution, it should not be treated as optional merely to increase compatibility.

Important ERC-5792 errors builders should handle

A production integration should treat wallet errors as structured workflow outcomes rather than generic failure messages.

What users should see before approving a batch

A good wallet confirmation should not make batching feel like one mysterious super-transaction. It should present the combined goal while still exposing material individual calls.

The overall intent

Examples include Approve and swap 1,000 USDC, Claim and stake 250 TOKEN, or Deposit ETH and configure vault position.

The call count

Users should know whether they are authorizing two calls or twelve.

Atomicity

The UI should communicate whether all calls are guaranteed to succeed together or whether partial execution is possible.

Every material destination

Show the protocol contracts receiving authority or assets. A call to an unfamiliar contract should not disappear inside a polished summary.

Approvals and persistent permissions

Approval calls deserve their own warning because their effect can outlive the rest of the batch.

Native value

Show ETH or other native assets attached to each material call.

Expected net asset changes

Where simulation is available, show which assets leave and which should arrive.

Failure consequences

For non-atomic execution, explain what can remain if a later action fails.

Builder checklist for a production ERC-5792 integration

Query capabilities before depending on them

Do not assume the connected wallet supports batching or atomicity merely because another wallet does.

Scope capabilities by chain

Capability support is not automatically portable across networks.

Make atomicRequired a product decision

Do not set it casually. Ask whether partial state can leave a user exposed or force complex recovery.

Preserve call order intentionally

Document why each call appears where it does.

Use exact-spend approvals where practical

Batching reduces the UX argument for permanent unlimited allowances because an approval can be coordinated with its intended use.

Simulate the full sequence

Model state changes from one call into the next.

Show persistent state separately from immediate actions

A temporary-looking swap flow may create a long-lived token permission.

Store the returned batch identifier reliably

You need it to query status and reconcile the flow.

Do not treat the batch ID as a transaction hash

It belongs to the wallet call bundle. The actual transaction hashes arrive through status receipts.

Handle status 600 explicitly

Partial failure requires state reconciliation, not a generic retry button.

Handle unknown status codes defensively

The standard allows more specific codes to be introduced. Code by category where appropriate and preserve unrecognized values for debugging.

Respect user rejection

Do not split the request into conventional transactions automatically after the user rejected the original batch.

Make fallback semantics explicit

If ERC-5792 is unsupported and you fall back to several eth_sendTransaction requests, tell the user that they will now approve separate transactions and that atomicity may differ.

Do not silently downgrade required security guarantees

If your product requires atomic approval-plus-swap execution, a non-atomic fallback changes the product semantics.

Limit capability collection

Request only what you need to reduce fingerprinting and privacy leakage.

Log enough data for support without storing sensitive information

Preserve batch ID, chain, request version, call destinations, transaction hashes, statuses and errors. Do not log private keys, seed phrases, or unnecessary user-identifying data.

Reconcile current state, not only emitted events

After an approval batch, query the actual allowance. After a deposit, query the user’s position. After a transfer, check balances and recipient state.

Fallback behavior when ERC-5792 is unavailable

ERC-5792 explicitly allows applications to fall back to conventional transaction methods when a wallet does not implement the new RPCs. That fallback must be designed carefully.

Sequential transactions are not equivalent to atomic batching

If the application normally requires approval and swap to succeed together, sending two standalone transactions changes the failure model.

More confirmations can change user intent

A user who approved one combined workflow has not necessarily agreed to a later, differently structured sequence. Show the fallback before requesting signatures.

Gas expectations may change

Several transactions can require more gas overhead than a smart-account batch.

Sponsorship may disappear

A paymaster-enabled wallet flow can become a user-funded transaction sequence if the fallback path does not support sponsorship.

Do not make unsupported wallets look broken

A clear message such as Your wallet does not support this batch mode is better than a generic RPC error. Offer a safe alternative when one exists.

Security risks ERC-5792 does not remove

ERC-5792 standardizes communication between applications and wallets. It does not automatically make the calls trustworthy.

Malicious applications can request malicious calls

A phishing interface can construct a valid ERC-5792 request that transfers assets or grants approvals.

Compromised frontends can alter one call in a legitimate batch

An attacker does not need to replace the entire flow. Inserting one malicious approval or transfer into a six-call batch may be enough.

Wallet summaries can be incomplete

Displaying Claim and Stake while hiding a third approval call defeats the security value of readable transaction confirmation.

Contract upgrades can change call semantics

A familiar proxy address may execute different implementation code after an upgrade.

Simulation can become stale

State changes between simulation and execution can alter the result.

Atomic execution does not make a malicious batch safe

Atomicity guarantees that all calls succeed together or that their material effects do not partially remain. If all calls are malicious and succeed together, atomicity only makes the attack complete.

Gas sponsorship does not mean trust

A transaction being free to the user does not make its permissions safe.

Batching can increase cognitive load

Fewer confirmation prompts sound safer, but one confirmation may carry more authority. Wallets must improve clarity as they reduce prompt count.

A safer user workflow for batch transactions

Before the request

Navigate to the application through a trusted bookmark or independently verified domain. Check protocol status if the action is high-value. Know which wallet and chain you intend to use.

At the confirmation screen

Count the calls. Identify every material destination. Compare approval amounts with the operation. Check whether the wallet reports atomic execution.

Use independent decoding

When the batch involves meaningful assets or unfamiliar contracts, decode the underlying calls outside the requesting application.

After confirmation

Store the batch or transaction reference. Wait for status. If status is partial failure, stop before retrying.

After execution

Review balances and permissions. A successful swap does not mean an unlimited approval disappeared.

Failure examples every ERC-5792 builder should test

Failure example 1: approval succeeds, swap reverts

Expected user intent: swap 1,000 USDC.

Actual non-atomic result: the router receives allowance, but the swap reverts because minimum output cannot be met.

Required UX: explain that the approval remains and offer an explicit permission review rather than simply Retry swap.

Failure example 2: first transfer succeeds, second transfer fails

A batch intends to pay two recipients. Recipient one receives funds. Recipient two’s transfer fails because of a contract condition.

A retry of the complete batch can pay recipient one twice.

Failure example 3: claim succeeds, stake contract pauses

The user receives rewards, but the staking call reverts because the destination contract was paused after simulation.

The application should show the claimed token balance rather than treating the whole workflow as undone.

Failure example 4: user rejects an atomic wallet upgrade

The connected wallet reports atomic status ready. The app requires atomic execution. The wallet asks the user to enable the required account capability, and the user declines.

The correct response is to stop. Silently resubmitting the calls separately would violate the application’s own atomic requirement.

Failure example 5: wrong chain capability assumption

The wallet supports atomic batching on Base but not another network. The dApp caches the Base capability and mistakenly assumes it applies globally.

The integration should query or respect per-chain capability state.

Failure example 6: hidden native value

A batch mainly discusses tokens, but one call attaches ETH to an unfamiliar contract. The wallet summary does not surface it prominently.

Users should reject the request until the native-value purpose is understood.

Failure example 7: malicious call appended to a legitimate batch

A compromised frontend constructs the expected approval and swap, then adds a third call transferring another token.

Independent call-by-call decoding reveals the extra destination.

Failure example 8: stale simulation

The batch simulates successfully, but pool liquidity changes before inclusion and the final swap fails. Under non-atomic execution, the earlier approval remains.

Failure example 9: status polling loses the batch identifier

The application refreshes and forgets the ERC-5792 ID. It cannot map the wallet-level request to later status information cleanly.

Persist the identifier for the lifecycle of the operation.

Failure example 10: successful status but unexpected remaining allowance

All calls execute successfully. The user receives the expected asset. However, the approval granted more authority than the swap consumed.

Status 200 means the batch succeeded. It does not mean no residual permission exists.

Privacy and wallet fingerprinting

Capability discovery improves interoperability but can expose information about wallet software and account architecture.

A rare combination of supported capabilities, chains, sponsorship systems, and smart-account features can become a fingerprint.

Applications should ask only what they need

If the user is performing one Ethereum swap, there is little reason to query every account capability on fifteen unrelated chains.

Wallets can limit capability exposure

The specification supports privacy-preserving behavior by allowing wallets to avoid exposing capabilities to untrusted callers or before the user has authorized the relevant account connection.

Current wallet response outranks stale cached capability information

From a correctness perspective, this also helps prevent a previously cached account configuration from being treated as permanently valid.

Why ERC-5792 matters more after EIP-7702

Ethereum’s account model changed significantly with Pectra. EIP-7702 gives regular EOAs a path to smart-account behavior, including batching, sponsored gas, session-key systems, and recovery-oriented logic, while preserving the existing address.

This creates a strong reason for applications to stop coding directly against one assumed account architecture.

The dApp should request an outcome

If the user needs approval plus swap, the application should express those calls and the required guarantees. The wallet can determine whether EIP-7702, ERC-4337, an existing smart contract wallet, or another mechanism is appropriate.

The dApp should not casually manage delegation

Ethereum’s EIP-7702 guidance emphasizes wallet-managed delegation and standardized wallet interfaces. Delegation targets are part of wallet security infrastructure and can exercise powerful authority.

Batching becomes a baseline wallet capability

Ethereum’s 2026 builder guidance explicitly recommends designing around wallet capabilities and using interfaces such as wallet_sendCalls rather than assuming every user is a plain ECDSA account sending one transaction at a time.

For the full context, revisit EIP-7702 and Ethereum’s post-Pectra account model.

Common ERC-5792 mistakes

Assuming wallet_sendCalls always means one transaction

It does not. The wallet may use one transaction, several transactions, a UserOperation, or another supported execution mechanism.

Assuming several calls are automatically atomic

Atomicity depends on the request and wallet capability.

Assuming atomicRequired false forces non-atomic execution

It does not. A capable wallet may still execute the batch atomically.

Assuming receipt count reveals atomicity

It does not. Use the explicit atomic field in the status response.

Assuming one chain’s capabilities apply to another

Capability support is chain-specific.

Ignoring status 600

Partial failure can leave real state changes behind.

Retrying the entire batch after partial execution

This can duplicate earlier successful calls.

Hiding token approvals inside a convenience flow

Batching does not make persistent permissions less important.

Using the dApp summary as the only confirmation

A compromised frontend can create a different call list.

Failing to preserve the batch identifier

The ID is how the application queries the wallet’s status for that request.

Treating an off-chain failure like a chain revert

Status 400 and status 500 have different implications.

Assuming a bridge destination action is part of the same ERC-5792 chain batch

The base request has one chain ID. Cross-chain execution belongs to the bridge or interoperability protocol.

Querying unnecessary capabilities

Over-querying increases fingerprinting and privacy risk.

Silently downgrading atomicity

If the application requires atomic behavior, a sequential fallback changes the security contract with the user.

Assuming success means no permissions remain

A successful batch can intentionally leave allowances, positions, operators, or other state behind.

A practical ERC-5792 review framework

Conclusion: batch the UX, not the user’s understanding

ERC-5792 gives Ethereum applications a better abstraction for modern wallet execution. Instead of assuming every account sends one conventional transaction at a time, applications can request an ordered set of calls, state whether atomic execution is required, query wallet capabilities, receive a wallet-level batch identifier, and monitor what happens through standardized status methods.

The core method, wallet_sendCalls, does not require every wallet to use the same execution architecture. An ERC-4337 smart account may package several calls into a UserOperation. An EIP-7702-enabled EOA may execute through delegated wallet code. A smart contract wallet may use its own batch executor. A conventional EOA wallet may process calls sequentially when atomicity is not required.

That flexibility is the reason the batch ID is more important than assuming one transaction hash. The application asks the wallet for execution, then uses wallet_getCallsStatus to understand whether the batch is pending, confirmed, failed off-chain, reverted completely, or failed partially.

Atomicity must be treated precisely. When atomicRequired is true, the wallet must provide the required atomic and contiguous behavior or reject the request. When it is false, the wallet can use sequential non-atomic execution or may still choose atomic execution. Builders should never infer the actual behavior from request intent alone. The status response explicitly reports whether execution was atomic.

Security remains a separate responsibility. An atomic malicious batch is still malicious. A successful batch can still leave an unlimited token approval. A non-atomic approval-plus-swap flow can leave the approval active when the swap fails. A bridge call can succeed on the source chain while destination settlement remains unresolved. A wallet summary can omit a dangerous nested call.

For that reason, high-value batch transactions should use a three-part verification model: understand the wallet confirmation, independently decode the underlying calls, and inspect the resulting receipts and state afterward. Use the TokenToolHub Transaction Decoder to inspect the actual contract actions instead of relying only on the application’s summary.

Return to the prerequisite EIP-7702 guide for the delegated-EOA account model and Account Abstraction in Practice for the broader wallet architecture. When a batch creates spending authority, revisit Crypto Approval Risks and EIP-2612 Permit.

The long-term value of ERC-5792 is not simply fewer confirmation prompts. It is a cleaner boundary between application intent and wallet execution. The application says what calls it needs and what guarantees are required. The wallet decides how its account can safely deliver them. The user should still be shown enough information to understand the authority represented by the entire batch.

FAQs

References and further learning

The following primary Ethereum standards and TokenToolHub resources provide deeper technical context on wallet call batching, EIP-7702, account abstraction, token approvals, permits, and transaction interpretation.

• EIP-5792: Wallet Call API
• Ethereum.org: Building on Ethereum in 2026
• EIP-7702: Set Code for EOAs
• Ethereum.org: Pectra EIP-7702 Guidelines
• ERC-2612: Permit Extension for EIP-20 Signed Approvals
• TokenToolHub EIP-7702 Guide
• TokenToolHub Account Abstraction in Practice
• TokenToolHub Crypto Approval Risks
• TokenToolHub EVM Transaction Decoder
• TokenToolHub EIP-2612 Permit Guide

This TokenToolHub guide is educational technical and security research. It is not financial advice, an audit, legal advice, or a guarantee that a wallet, batch, transaction, smart account, dApp, bridge, approval, protocol or simulation is safe. ERC-5792 wallet behavior depends on supported capabilities and the selected chain. Verify current wallet capabilities, underlying call data, contract addresses, approval amounts, atomicity requirements, transaction receipts and final on-chain state before approving material transactions.