# EIP-5792: Wallet Call API

Source: https://www.eipsfordesigners.com/standards/EIP-5792
Agent brief: https://www.eipsfordesigners.com/standards/EIP-5792/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/EIP-5792
Last reviewed: 2026-09-18
Last updated: 2026-09-18

| Field | Value |
| --- | --- |
| Status | Final |
| Chain | both |
| Category | Transaction Friction |
| Journey stages | Executing Transactions |
| Detailed guide | Yes |
| Official specification | https://eips.ethereum.org/EIPS/eip-5792 |
| Discussion search | https://ethereum-magicians.org/search?q=EIP-5792 |

## UX Impact

EIP-5792 lets apps request wallet-mediated call batches and inspect capabilities/status. Atomicity is requested with atomicRequired and depends on the wallet's atomic capability per chain; render sequential/partial results and paymaster policy separately.

## Summary

EIP-5792 defines wallet_sendCalls, wallet_getCallsStatus, and wallet_getCapabilities for wallet-mediated call batches. Atomicity is capability- and request-dependent: use atomicRequired: true only when the wallet advertises the atomic capability for the target chain, and show the status result.

## For Designers

- Query wallet_getCapabilities per target chain before showing batching, atomicity, or paymaster controls.
- Use atomicRequired: true only when the wallet advertises the atomic capability.
- Show the returned atomic result and provide a sequential or partial-execution recovery path.

## Applicability

### When to Use

- Your product addresses: dApps can't know what wallet supports.
- Your product addresses: no standard for batched calls.
- Your UI should wallet_getCapabilities() returns supported features.
- You are designing a capability detection experience with visible states and recovery paths.

### When to Avoid

- The wallet does not advertise the required capability for the target chain.
- The flow cannot explain or recover from sequential or partially completed calls.
- The app needs an all-or-nothing guarantee that the wallet has not returned.

## Problems It Solves

### dApps can't know what wallet supports

Impact: high

Old way: Try features, catch errors, guess based on wallet name

New way: wallet_getCapabilities() returns supported features

### No standard for batched calls

Impact: high

Old way: Each smart wallet has different batch interface

New way: wallet_sendCalls gives supporting wallets a shared call-batch request shape; atomic execution remains capability-dependent

### Can't check call status after submission

Impact: medium

Old way: Poll blockchain, hope for the best

New way: wallet_getCallsStatus() for bundled operation status

## Anti-Patterns

### Assuming all wallets support batching

Severity: critical

EOAs without 7702 can't batch

Instead: Check capabilities, fall back gracefully

### Promising all-or-nothing without checking capability

Severity: critical

wallet_sendCalls permits sequential execution when atomicity is not required or unavailable.

Instead: Set atomicRequired: true only when the atomic capability is advertised; otherwise explain sequential or partial results.

### Ignoring capability responses

Severity: high

Offering features wallet doesn't support

Instead: Hide unsupported features from UI

## UI Components

### CapabilityChecker

Queries and displays wallet capabilities
States: checking, ready, no-support
Props: walletProvider, onCapabilities

### BatchCallBuilder

UI for building batched operations
States: building, ready, submitting
Props: calls[], onSubmit

### CallStatusTracker

Shows status of batched call
States: pending, confirmed, failed
Props: callId, onStatusChange

## Key Takeaways

- EIP-5792 standardizes wallet call submission, status, and capability discovery.
- Query wallet_getCapabilities for the target chain before offering a feature.
- The capability name is atomic; atomicity is requested with atomicRequired and reported in status.
- Render a sequential or partial-execution path when atomic support is absent.
- Paymaster service and other capabilities are wallet/service policies, not universal guarantees.

## UX Patterns

### Capability Detection

Check wallet features before offering them

User flow:

- dApp connects to wallet
- Calls wallet_getCapabilities
- Parses supported features
- Shows/hides UI based on capabilities
- Only offers what wallet supports

Mockup registry key: `concept/session-permissions` (React UI on the live standard page).

### Batched Transaction

Multiple operations in one request

User flow:

- dApp builds array of calls
- Uses wallet_sendCalls
- Wallet shows combined preview
- User approves once
- Show the wallet's returned atomic result and update each call state

Mockup registry key: `concept/bundled-defi` (React UI on the live standard page).

## Technical Notes

EIP-5792 adds wallet_getCapabilities, wallet_sendCalls, and wallet_getCallsStatus. Calls can request atomicRequired; true requires the wallet to support atomic execution for that chain, while false permits sequential execution. The atomic capability is named atomic and can report supported, ready, or unsupported state. Paymaster service is a separate capability.