# ERC-5792: Wallet Call API

Source: https://www.eipsfordesigners.com/standards/ERC-5792
Agent brief: https://www.eipsfordesigners.com/standards/ERC-5792/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/ERC-5792
Last reviewed: 2026-04-05
Last updated: 2026-04-05

| 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=ERC-5792 |

## UX Impact

Apps can request multiple calls executed atomically — approve+swap+stake in one wallet popup instead of three. Design implications: design multi-action confirmation screens showing all operations, indicate atomicity guarantees ('all or nothing'), show capability badges for wallet features, build paymaster URL configuration. Design decisions: how to present batched operations (list vs grouped), handle partial wallet support gracefully, balance information density in confirmation dialogs — too little is risky, too much causes fatigue. Referenced across 4 pain points — Signing Fatigue (High), Missing Signing Context (Medium), Redundant Token Approvals (High), and Token Approval Management (High). Batching via wallet_sendCalls is High priority.

## Summary

ERC-5792 is the "Wallet Call API" — a standard way for dApps to send batched operations to wallets and discover what capabilities the wallet supports. Instead of guessing if a wallet can batch transactions or sponsor gas, dApps can ask. And wallets can execute multiple calls atomically. It bridges EIP-7702 and ERC-4337 capabilities to a consistent API.

## For Designers

- You can wallet_getCapabilities() returns supported features in the interface.
- You can wallet_sendCalls() works across all supporting wallets in the interface.
- You can wallet_getCallsStatus() for bundled operation status in the interface.

## 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

- Check capabilities, fall back gracefully.
- Hide unsupported features from UI.
- Clear: "If any fails, none execute".
- The flow is a single low-risk transfer where batching adds confusion.

## 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() works across all supporting wallets

### 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

### Ignoring capability responses

Severity: high

Offering features wallet doesn't support

Instead: Hide unsupported features from UI

### Not explaining atomicity

Severity: medium

Users don't understand all-or-nothing

Instead: Clear: "If any fails, none execute"

## 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

## On Monad

### Batch Execution

Ethereum: Batch confirms in 12+ seconds

Monad: Sub-second batch confirmation

Design implication: Complex operations feel instant

## Key Takeaways

- ERC-5792 = standard wallet capability API
- Always check capabilities before offering features
- Batch calls execute atomically
- Fall back gracefully for non-supporting wallets
- Track batch status with wallet_getCallsStatus

## 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
- All execute atomically

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

## Technical Notes

ERC-5792 adds three methods: wallet_getCapabilities() returns supported features per chain, wallet_sendCalls({ calls[], capabilities }) submits batched operations, wallet_getCallsStatus(id) tracks completion. Capabilities include atomicBatch, paymasterService, auxiliaryFunds. Compatible with both EIP-7702 and ERC-4337 wallets.