ERC-7795 primary sources — 2026-05-07
Project status in this pass
- No standalone ERC-7795 whitepaper or litepaper surfaced.
- The clearest source of truth was the draft ERC itself, backed by the raw ERC markdown and the ERCs mirror page.
- The main mechanism signal across sources was consistent: ERC-7795 uses the EIP-5792 capability plane to let dapps express token prerequisites while wallets retain discretion over how those prerequisites get fulfilled.
Primary-source snapshots
1) Canonical ERC page
- URL: https://eips.ethereum.org/EIPS/eip-7795
- Key excerpt/signals:
- The abstract says ERC-7795 extends EIP-5792 so dapps can specify common token prerequisites before a transaction executes.
- The motivation says dapps can usually only communicate the final action, leaving users to guess bridge, swap, or consolidation steps.
- The specification anchors everything in
wallet_sendCallsandwallet_getCapabilitiesrather than inventing a separate RPC family.
- Why it mattered:
- This is the clearest evidence that ERC-7795 belongs in the corpus as wallet intent and prerequisite-routing infrastructure.
2) Raw ERC markdown / capability taxonomy
- URL: https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-7795.md
- Key excerpt/signals:
- The draft defines six requirement capabilities: ERC-20 minimum balance, ERC-20 minimum allowance, ERC-721 ownership, ERC-721 approval, ERC-1155 minimum balance, and ERC-1155 minimum allowance.
- Each capability has independent versioning and is exposed through
wallet_getCapabilities. - Dapps may opt out and fulfill requirements themselves.
- Why it mattered:
- These details show that the standard is building a modular prerequisite namespace rather than one monolithic solver workflow.
3) Raw ERC markdown / wallet execution responsibility
- URL: https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-7795.md
- Key excerpt/signals:
- The usage examples say wallets SHOULD compute solutions to satisfy the requested requirements.
- Wallets MUST ensure the prerequisites are met before the requested transaction is executed.
- The smart-contract-wallet example allows prerequisite transactions to be signed once and sent to bundlers in the right order.
- Why it mattered:
- This is the strongest source-level evidence that ERC-7795 shifts solver and routing discretion toward the wallet and account-abstraction stack.
4) ERCs mirror page
- URL: https://ercs.ethereum.org/ERCS/erc-7795
- Key excerpt/signals:
- The mirror reproduces the same abstract, motivation, and capability schemas from the draft ERC.
- It emphasizes that the requirements are token-standard-specific capabilities layered onto EIP-5792.
- The visible examples reinforce that ERC-7795 is targeting practical cross-chain or multi-step fulfillment UX, not only static balance checks.
- Why it mattered:
- This provided a second canonical rendering of the draft and made the wallet-prerequisite-control-plane framing easier to confirm.
5) Magicians discussion thread
- URL: https://ethereum-magicians.org/t/erc-7795-wallet-call-token-capabilities/21426
- Key excerpt/signals:
- The discussion link itself is attached as the canonical debate venue in the ERC metadata.
- Search-result context for the thread matches the draft’s framing: the problem is missing communication between dapps and wallets around transaction requirements.
- Why it mattered:
- Even without pulling a rich thread transcript in this pass, the discussion venue confirms that the proposal is being framed as wallet-dapp coordination infrastructure.
Working conclusion
ERC-7795 is best cataloged as wallet prerequisite and intent-fulfillment infrastructure. The decisive evidence in this pass was the draft’s use of EIP-5792 capability discovery, its explicit taxonomy of token requirement capabilities, and the source text assigning wallets the job of computing and enforcing prerequisite satisfaction before the main transaction runs.