Cowrie Research

eip-5792

3 min read

EIP-5792 (Wallet Call API)

  • Name: EIP-5792 (Wallet Call API)
  • URL: https://eips.ethereum.org/EIPS/eip-5792
  • Category: wallet-to-dapp RPC standard / smart-account capability-discovery interface / transaction-batching control-plane infrastructure
  • Summary: EIP-5792 is best cataloged as wallet control-plane infrastructure rather than as a wallet feature checklist or a smart-account implementation itself. Its core contribution is to replace the old one-transaction-at-a-time wallet RPC model with a standardized interface for submitting batches of calls, checking their status, surfacing whether they executed atomically, and discovering wallet capabilities such as paymaster support. The important categorization clue is that EIP-5792 standardizes the negotiation boundary between apps and wallets: it tells dapps how to request richer execution behavior from whatever wallet the user already has, without hard-coding to one vendor’s proprietary RPCs.
  • What it does:
    • Defines wallet_sendCalls so apps can ask wallets to process multiple onchain write calls in one request
    • Defines wallet_getCallsStatus and wallet_showCallsStatus so apps can track a submitted call batch and hand off status display to the wallet
    • Defines wallet_getCapabilities so apps can query what execution features a wallet supports on which chains
    • Introduces atomicRequired and a standardized atomic capability so wallets can explicitly communicate whether a batch will execute atomically and contiguously
    • Standardizes how capabilities are passed globally or per call, including optional capability flags
    • Provides a status-code model for pending, confirmed, offchain-failure, full-revert, and partial-revert batch outcomes
  • Key claims:
    • The final EIP says it adds JSON-RPC methods for sending multiple calls from a user wallet and checking their status, which makes it a wallet-interface standard rather than an application-specific batching scheme
    • The motivation section explicitly says eth_sendTransaction and eth_getTransactionReceipt no longer meet modern developer demands and cannot accommodate new transaction formats, framing EIP-5792 as a control-plane upgrade for wallet interactions
    • The specification says wallet_sendCalls batches {to, data, value} tuples and allows applications to request wallet capabilities such as paymaster-service support through a structured capabilities field
    • When atomicRequired is true, the EIP says wallets MUST execute all calls atomically and contiguously or reject the request, which makes the atomicity contract an explicit part of the interface instead of wallet-specific guesswork
    • The EIP says unsupported non-optional capabilities MUST cause rejection, while optional capabilities may be ignored, which is an important design choice for avoiding silent vendor-specific behavior drift
    • The wallet_getCallsStatus result requires an explicit atomic field and standardized batch status codes including 100, 200, 400, 500, and 600, showing the spec is standardizing not just submission but post-submission observability
    • The wallet_getCapabilities section says capability objects may also appear out of band, but live wallet RPC responses should be treated as canonical when they conflict, which makes the wallet the authoritative source of currently supported execution features
    • WalletConnect’s implementation docs say it supports EIP-5792 and map the standard into CAIP-25 session and scoped properties, which is good evidence that the EIP is turning into real ecosystem plumbing rather than staying a paper-only interface
    • WalletConnect’s docs also spell out the atomic capability states supported, ready, and unsupported, which helps clarify how wallets expose upgradeable-versus-native atomic execution in practice
  • Whitepaper: No standalone EIP-5792 whitepaper or litepaper surfaced in this pass. The canonical source of truth was the final EIP itself, with WalletConnect documentation providing a concrete implementation view; see ../../whitepapers/eip-5792-primary-sources-2026-05-07.md.
  • Sources:

Internal linkages

  • Session and capability-negotiation neighbor: caip-25.

  • Immediate smart-account execution context: erc-4337.

  • Product layer where this interface becomes real developer plumbing: walletconnect.

  • Reusable lens: when a wallet claims batching or gasless UX, the real question is which capabilities it will expose cleanly versus keep proprietary.

  • Last reviewed: 2026-05-24 UTC

Graph View

Backlinks