Summary: ERC-7795 is best understood as wallet-side intent and prerequisite signaling infrastructure rather than as a bridge, solver, or token UX feature by itself. Its core move is to let a dapp describe the token conditions that must be true before its final transaction can succeed — enough balance, enough allowance, NFT ownership, or NFT approval — and then hand the fulfillment problem to the wallet through the EIP-5792 capability plane. The important categorization clue is that ERC-7795 does not standardize one routing engine; it standardizes how apps disclose prerequisites so wallets can decide whether to bridge, swap, approve, batch, or otherwise source the needed state before executing the main call.
What it does:
Extends EIP-5792 by adding token-prerequisite capabilities to wallet_sendCalls and wallet_getCapabilities
Defines balance and allowance requirement capabilities for ERC-20 tokens
Defines ownership and approval requirement capabilities for ERC-721 tokens
Defines balance and allowance requirement capabilities for ERC-1155 tokens
Lets wallets advertise granular support for each prerequisite type and version rather than forcing one monolithic implementation
Makes wallets responsible for ensuring the stated prerequisite is satisfied before executing the dapp’s target transaction
Key claims:
The draft ERC says it extends EIP-5792 so dapps can specify common token prerequisites for transactions, which is the clearest signal that ERC-7795 belongs in the corpus as wallet capability infrastructure rather than as an app-specific cross-chain UX hack
The motivation says dapps can usually communicate only the last desired transaction, leaving users to guess prerequisite bridge, swap, or consolidation steps, which frames ERC-7795 as a way to move that planning boundary into the wallet
The specification defines six explicit capability families — erc20MinBalance, erc20MinAllowance, erc721Ownership, erc721Approval, erc1155MinBalance, and erc1155MinAllowance — showing that the standard is trying to make prerequisite intent machine-readable across common token classes
Each capability is discoverable through wallet_getCapabilities with explicit versioning, which means wallet vendors retain meaningful control over which prerequisite-solving surfaces become portable across dapps
The usage examples say wallets SHOULD compute solutions to satisfy the requested requirements and MUST ensure those requirements are met before the main transaction executes, which is the strongest source-level evidence that solver and routing discretion concentrate at the wallet layer
The smart-contract-wallet example says prerequisite transactions MAY be signed once and sent to bundlers in the right order, which shows ERC-7795 is designed to compose with broader account-abstraction and delegated-execution rails rather than stay EOA-only
The rationale says the requirements were split into individual capabilities for granular support, clear discovery, and independent versioning, reinforcing that the main mechanism is a modular capability namespace, not a single bundled solver protocol
The security section says the ERC introduces no new trust assumptions because users already trust their wallet to craft and send transactions, which is revealing in itself: ERC-7795 expands the wallet’s role from signing endpoint to prerequisite interpreter and execution planner
Whitepaper: No standalone ERC-7795 whitepaper or litepaper surfaced in this pass. The clearest current sources were the draft ERC, the raw ERC markdown, the ERCs mirror page, and the Magicians discussion thread; see ../../whitepapers/erc-7795-primary-sources-2026-05-07.md.