Cowrie Research

eip-5792-primary-sources-2026-05-07

3 min read

EIP-5792 primary sources — 2026-05-07

Project status in this pass

  • No standalone EIP-5792 whitepaper or litepaper surfaced.
  • The clearest current source of truth was the final EIP itself, with WalletConnect documentation providing concrete ecosystem implementation guidance.
  • The sources consistently frame EIP-5792 as a wallet RPC/control-plane standard for batched execution and capability discovery.

Primary-source snapshots

1) Canonical EIP page

  • URL: https://eips.ethereum.org/EIPS/eip-5792
  • Key excerpt/signals:
    • The abstract says the EIP defines new JSON-RPC methods that let applications ask wallets to process a batch of onchain write calls and check their status.
    • It also says applications can request that calls make use of wallet capabilities previously expressed by the wallet.
    • The motivation says eth_sendTransaction and eth_getTransactionReceipt no longer meet modern developer demands or new transaction formats.
  • Why it mattered:
    • This is the clearest evidence that EIP-5792 is a boundary/interface upgrade between apps and wallets rather than a wallet-brand feature list.

2) Raw EIP text / wallet_sendCalls

  • URL: https://raw.githubusercontent.com/ethereum/EIPs/master/EIPS/eip-5792.md
  • Key excerpt/signals:
    • wallet_sendCalls accepts a batch of {to, data, value} tuples plus global and call-level capability objects.
    • The spec says wallets MUST preserve call order, keep the batch on one chain, and reject the entire request if the user rejects it.
    • When atomicRequired is true, wallets MUST execute all calls atomically and contiguously or reject.
    • Unsupported non-optional capabilities MUST cause rejection, while optional capabilities may be ignored.
  • Why it mattered:
    • These rules show the standard is doing real control-plane work: request formatting, execution guarantees, and capability negotiation.

3) Raw EIP text / status and observability model

  • URL: https://raw.githubusercontent.com/ethereum/EIPs/master/EIPS/eip-5792.md
  • Key excerpt/signals:
    • wallet_getCallsStatus returns an explicit atomic field plus structured receipts.
    • The EIP defines status codes for pending (100), confirmed (200), offchain failure (400), full onchain revert (500), and partial revert (600).
    • It requires logs to include only those relevant to the submitted call batch, even when a broader ERC-4337 bundle contains unrelated activity.
  • Why it mattered:
    • This makes EIP-5792 more than a submission API; it also standardizes the post-submission observability surface apps can depend on.

4) Raw EIP text / wallet_getCapabilities

  • URL: https://raw.githubusercontent.com/ethereum/EIPs/master/EIPS/eip-5792.md
  • Key excerpt/signals:
    • wallet_getCapabilities returns capability objects keyed by chain ID.
    • The EIP says the same capability objects may also appear out of band, but live wallet RPC responses should be treated as canonical if they conflict.
    • It positions the ecosystem to define additional capabilities in separate ERCs over time.
  • Why it mattered:
    • This is the strongest source-level evidence that EIP-5792 is building a durable, extensible wallet-feature negotiation layer rather than a one-off batching API.

5) WalletConnect implementation docs

  • URL: https://docs.walletconnect.network/wallet-sdk/android/eip5792
  • Key excerpt/signals:
    • WalletConnect says it supports EIP-5792 and lists the four core methods directly.
    • The docs map capabilities into CAIP-25 sessionProperties and scopedProperties, showing how capability negotiation is carried through real wallet-dapp sessions.
    • They document the atomic capability states supported, ready, and unsupported, plus implementation guidance for wallet_sendCalls and status responses.
  • Why it mattered:
    • This is good evidence that EIP-5792 is becoming actual ecosystem plumbing and not just a dormant paper standard.

Working conclusion

EIP-5792 is best cataloged as wallet call/control-plane infrastructure. The decisive evidence in this pass was the EIP’s explicit replacement of the legacy eth_sendTransaction model with batched call submission, standardized atomicity guarantees, capability discovery, structured status reporting, and WalletConnect’s concrete session-layer implementation guidance.

Graph View