Summary: ERC-7946 is best understood as a one-way transaction-request transport for wallets rather than as another generic wallet-connect flow or a thin wrapper around wallet_sendCalls. Its core move is to let an application hand a wallet a compact uwulink: payload containing an atomic batch of calls without establishing a two-way session or learning the user’s address at request time. The most useful architectural split is between three layers that are often flattened together: transport of the request itself, optional onchain or resolver-driven generation of the concrete call batch, and actual wallet-side execution plus confirmation. That makes ERC-7946 a strong comparison point for EIP-5792, WalletConnect URI/session flows, and older payment-request URIs: it pushes multi-call execution into an offline-friendly, privacy-oriented handoff channel while moving real control into resolver contracts, wallet decoding/presentation, and the RPC path used to materialize calls.
What it does:
Defines a compact uwulink: URI format for sending an EVM batch-transaction request from an app to a wallet
Uses Protocol Buffers encoding so requests fit better into low-bandwidth channels like QR codes, NFC tags, and links
Supports Static Mode, where the payload directly includes the list of calls to execute atomically
Supports Programmable Mode, where the payload references a resolver contract plus input data and the wallet fetches the final call list with an off-chain call
Carries an explicit chain ID so the wallet can switch or reject based on the intended execution chain
Lets apps request multi-step operations such as approval plus action in one wallet-confirmed batch without first creating a persistent wallet session
Key claims:
The draft abstract says UWULink lets applications request a wallet to make a batch of contract calls in one atomic transaction without a two-way connection or revealing the user’s address to the requester, which is the clearest reason to catalog it as privacy-oriented handoff infrastructure rather than a generic wallet UX tweak.
The motivation explicitly frames UWULink as a response to the limits of session-based connectivity and to the size constraints of QR/NFC transport. That makes its main novelty not batching alone, but offline-friendly and lower-friction delivery of batched requests.
The spec requires all calls in the batch to execute atomically, so ERC-7946 is closer to transport for wallet-side batch execution than to a loose payment-request URI. If any call reverts, the whole batch should revert.
The binary protobuf schema is analytically important because it marks a deliberate design break from longer human-readable URI payloads. ERC-7946 is trying to make app-to-wallet transaction construction compact enough for posters, POS terminals, and device-to-device scanning workflows.
Programmable Mode introduces a separate control plane that should not be flattened into the transport layer. The wallet calls a resolver contract’s getCalls(address requester, bytes data) function off-chain to derive the actual batch, which means authority partially shifts into resolver logic, contract standardization, and whatever RPC path the wallet uses to query it.
The resolver interface is a subtle trust-model clue: because the wallet supplies the requester address to the resolver, the requester app may stay blind to the address at request time while dynamic call generation can still depend on that address downstream.
The draft status matters. ERC-7946 is currently most useful as a comparison-ready transport design for private batch requests, not as evidence of broad production adoption yet.
Whitepaper: No standalone ERC-7946 whitepaper or litepaper surfaced in this pass. The clearest primary materials were the ERC page, the raw ERC markdown in the Ethereum ERCs repository, and the linked Magicians discussion thread; see ../../whitepapers/erc-7946-primary-sources-2026-05-14.md.