ERC-7946 primary sources — 2026-05-14

Project status in this pass

• No standalone ERC-7946 whitepaper or litepaper surfaced.
• The clearest current source of truth was the draft ERC itself, backed by the raw ERC markdown in the Ethereum ERCs repository and the linked Magicians discussion thread.
• The reviewed materials consistently frame ERC-7946 as unidirectional batch-transaction handoff infrastructure rather than as a generic wallet-connect or JSON-RPC standard.

Primary-source snapshots

1) Canonical ERC page

• URL: https://eips.ethereum.org/EIPS/eip-7946
• Key excerpt/signals:
  • The subtitle describes unidirectional app-to-wallet communication for private construction of transactions.
  • The abstract says the protocol allows a dApp to 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.
  • The abstract also highlights Protocol Buffers plus QR/NFC-suitable transport and the two modes: Static and Programmable.
• Why it mattered:
  • This is the clearest evidence that ERC-7946 belongs in the corpus as privacy-oriented wallet request transport rather than as a simple batching helper.

2) Raw ERC markdown / what the wallet actually receives

• URL: https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-7946.md
• Key excerpt/signals:
  • The request is encoded as a uwulink: URI carrying a base64-encoded protobuf message.
  • The top-level protobuf includes a chain ID and exactly one request type: either a static Batch or a ResolverReference.
  • The static call structure carries target address, optional ETH value, and optional calldata for each call.
• Why it mattered:
  • These details show ERC-7946 is best treated as a transport envelope for atomic wallet-executed call batches, with compact encoding as a first-order design goal.

3) Raw ERC markdown / programmable resolver control plane

• URL: https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-7946.md
• Key excerpt/signals:
  • Programmable Mode points the wallet at a resolver contract and opaque input data.
  • The resolver interface exposes getCalls(address requester, bytes calldata data) and an error-code explanation function.
  • The spec says wallets should call the resolver off-chain and avoid combining the call with others such as Multicall.
• Why it mattered:
  • This is the strongest evidence that ERC-7946 has a second control surface beyond transport: resolver selection and query behavior shape the eventual call batch without forcing the requester app to know the user’s address up front.

4) Canonical ERC page / motivation and trust boundaries

• URL: https://eips.ethereum.org/EIPS/eip-7946
• Key excerpt/signals:
  • The motivation contrasts session-heavy connectivity with one-off QR, NFC, and offline workflows.
  • It also emphasizes privacy relative to account-requesting flows and size efficiency relative to longer human-readable encodings.
  • The text explicitly cites EIP-5792 and EIP-7702 as adjacent batching abstractions that still assume an active connection.
• Why it mattered:
  • This frames ERC-7946 as a different architectural cut: it is not inventing batch execution from scratch, but relocating it into a compact one-way transport channel.

Working conclusion

ERC-7946 is best cataloged as a draft protocol for private, offline-friendly handoff of atomic multi-call wallet requests. Its distinctive contribution is to separate batch-request transport from two-way wallet sessions, while also separating direct static call payloads from programmable resolver-driven call generation.