ERC-7902 primary sources — 2026-05-15

Project status in this pass

  • No standalone ERC-7902 whitepaper or litepaper surfaced.
  • The clearest source of truth was the draft ERC itself, backed by raw ERC markdown and implementation-facing wallet API documentation.
  • The sources consistently frame ERC-7902 as the AA-specific capability layer on top of EIP-5792, not as a standalone smart-account system.

Primary-source snapshots

1) Canonical ERC page

  • URL: https://eips.ethereum.org/EIPS/eip-7902
  • Key excerpt/signals:
    • The abstract says EIP-5792 already provides a baseline wallet-to-dapp API with extensible capabilities, and ERC-7902 defines AA-specific capabilities on top of that surface.
    • The draft names five concrete capability families: eip7702Auth, staticPaymasterConfiguration, validityTimeRange, multiDimensionalNonce, and accountAbstractionGasParamsOverride.
    • The specification says AA actions in this context must be single-chain and atomic.
  • Why it mattered:
    • This is the clearest evidence that ERC-7902 belongs in the corpus as capability-negotiation infrastructure for advanced wallet behavior, not as a full AA protocol.

2) Raw ERC markdown

  • URL: https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-7902.md
  • Key excerpt/signals:
    • The raw markdown makes the typed interfaces legible, including the exact field shapes for paymaster configuration, validity windows, nonce components, and AA gas overrides.
    • The draft explicitly says the gas-override capability is low-level and generally best reserved for tightly coupled apps or debugging.
    • The security section says wallets must maintain a strict shortlist of trusted delegation targets for eip7702Auth.
  • Why it mattered:
    • These details show that ERC-7902 is standardizing how dangerous AA-specific controls are proposed and mediated, while still leaving the wallet as the decisive safety boundary.

3) Alchemy wallet_getCapabilities documentation

  • URL: https://www.alchemy.com/docs/wallets/api-reference/smart-wallets/wallet-api-endpoints/wallet-get-capabilities
  • Key excerpt/signals:
    • The example response includes atomic, paymasterService, and eip7702Auth capability objects returned through wallet_getCapabilities.
    • The docs frame the method as the place where applications discover wallet-supported capabilities for a given account and chain.
  • Why it mattered:
    • This is useful implementation-facing evidence that ERC-7902-style AA capability negotiation is already showing up in live wallet API surfaces rather than staying entirely at the draft-spec layer.

4) Alchemy EIP-7702 guide

  • URL: https://www.alchemy.com/docs/wallets/transactions/using-eip-7702
  • Key excerpt/signals:
    • The guide says EIP-7702 is enabled by default in its wallet APIs and gives access to smart-wallet capabilities like gas sponsorship and batching while keeping the same address.
    • It explains that delegation and transaction signing are prepared together, sometimes producing multiple signature requests the app must route back.
    • It distinguishes default 7702-delegated flows from non-7702 smart-account mode.
  • Why it mattered:
    • This makes the practical role of eip7702Auth easier to understand: ERC-7902 is not abstract capability theory alone, but part of a real execution path where wallets decide when and how EIP-7702 delegation is introduced.

Working conclusion

ERC-7902 is best cataloged as the AA-specific capability layer above EIP-5792. The decisive evidence in this pass was the draft ERC’s typed capability objects, the raw spec’s explicit low-level warning and trusted-delegation requirements, and live wallet API docs already exposing eip7702Auth as a discoverable wallet capability.