[tracking] prepare_eip7702_authorization — gated on Ledger Live + WalletConnect 7702 primitive support

[szhygulin]

Status: 🟡 Tracking — gated on Ledger Live + WalletConnect 7702 primitive support

What needs to be true to unblock:

• Ledger Live routes 7702 signing requests to the device over WalletConnect
• WalletConnect 2.x exposes a standardized 7702 primitive in the eip155 namespace — either a dedicated eth_signAuthorization / wallet_signEIP7702Authorization method, OR ERC-5792 wallet_sendCalls carrying setCode authorizations as part of a batched-calls payload

Either path closes the gap; the wallet_sendCalls route is the more likely one (see #505 for why).

What's verified today (2026-04-28):

• ✓ Ledger Ethereum app firmware supports 7702 authorization + type-4 tx signing since v1.17.0 (2025-05-05). Device-firmware implementation allowlist enforced at the hardware layer (EF simple7702 only as of v1.20.0; MetaMask Gator was added in v1.18 then removed 2025-12-02).
• ✗ Ledger Live → device routing of 7702 over WC: vendor's own statement: "only the simple 7702 contract is compatible with your Ledger signer at the device level — and it is not yet available to use via Ledger Live" — Pectra announcement, 2025-05-07. No later vendor reversal found.
• ✗ WalletConnect 2.x has no standardized 7702 RPC method in the eip155 namespace (WC namespaces spec).
• ✗ viem signAuthorization is local-key-only (viem docs) — no JSON-RPC bridge for external signers like WC.

Verification details: rnd verification comment.

Design decisions already captured — do NOT redo at unblock time:

• #504 — Curated MCP-side / skill-side implementation allowlist is moot. Device firmware enforces the allowlist at the strongest possible layer (hardware; can't be bypassed by compromised MCP / agent / skill).
• #505 — Build against ERC-5792 wallet_sendCalls, not against bare eth_signAuthorization. Industry direction; what Ledger Live is most likely to expose first.
• Project memory project_ledger_live_eip7702_wc.md + feedback_no_curated_allowlists_for_security.md — for high-blast-radius security flows, design around user echo-back + agent-assisted verify + 2nd-LLM cross-check, not whitelisted contract sets.
• Skill v8 §16 unconditional refusal is the load-bearing defense until this lands. Inv Add Base network support (chainId 8453) #14 verify-block (#460) still applies once we ship — even with a hardware allowlist, the user re-states the implementation address before signing.

How to close this issue:

1. Re-verify the precondition with the rnd skill: recheck Ledger Live release notes (https://support.ledger.com/article/What-s-new-in-Ledger-Live), Ledger ETH app CHANGELOG (https://github.com/LedgerHQ/app-ethereum/blob/develop/CHANGELOG.md), WC eip155 namespace spec, and any new viem JSON-RPC bridge for signAuthorization.
2. If unblocked: design per [security] EIP-7702 builder should target ERC-5792 wallet_sendCalls, not bare eth_signAuthorization #505 (ERC-5792-shaped tool, not bare authorization emitter), trust the device-firmware allowlist per [security] EIP-7702 implementation allowlist is enforced in device firmware — MCP/skill allowlists are moot #504, implement, ship, and close this issue along with [security] EIP-7702 implementation allowlist is enforced in device firmware — MCP/skill allowlists are moot #504 + [security] EIP-7702 builder should target ERC-5792 wallet_sendCalls, not bare eth_signAuthorization #505.
3. If still blocked: no action — keep waiting.

---

Original spec (filed 2026-04-28 AM)

Tracking issue for the MCP-side prepare_eip7702_authorization builder, paired with the eventual skill v9 release that introduces the curated implementation allowlist. Companion to #455 (the design issue) and the v8 forward-looking refusal in vaultpilot-security-skill#19 §16.

Why this is filed now

Skill v8 ships §16 saying "EIP-7702 setCode REFUSED UNCONDITIONALLY until skill v9 ships an implementation allowlist." Without an MCP-side implementation tracking issue, the design (#455) sits in skill text with no MCP-side counterpart on the roadmap.

Scope (as originally proposed — superseded by #504, #505 above)

Build prepare_eip7702_authorization(implementation, delegator, chainId, nonce) returning an unsigned authorization tuple per EIP-7702. Safeguards baked in:

1. Curated implementation allowlist — superseded: device firmware enforces it ([security] EIP-7702 implementation allowlist is enforced in device firmware — MCP/skill allowlists are moot #504).
2. chain_id ≠ 0 enforcement — hard refuse on chain_id = 0 (cross-chain replay risk too large to mitigate any other way). STILL APPLIES.
3. Paired revocation tuple — emitted alongside install so the user can revert. STILL APPLIES.
4. Inv Auto-discover Morpho Blue positions via event-log scan #12.5 hard-trigger — second-LLM check is a precondition, not opt-in. STILL APPLIES.
5. Out-of-band re-statement — user pastes the implementation address back before signing, defeating agent-side address swaps. STILL APPLIES (Inv Add Base network support (chainId 8453) #14).

Source

Adversarial smoke-test 2026-04-28 scripts 139, 140. See #455 for the full design proposal.

[szhygulin]

Cross-ref #460: the implementation-address slot in an EIP-7702 setCode authorization is a durable on-chain object selected from a multi-candidate set — i.e. an Invariant #14 instance. The revised design (per local plan, 2026-04-28) drops the curated allowlist proposed in #455 and instead applies Inv #14 directly:

• Source from authority outside MCP → user verifies address themselves; agent assists by reading bytecode / Etherscan via its own RPC trust path
• Surface verbatim with provenance → echo-back / out-of-band re-statement before signing
• Byte-equality-check → user pastes implementation address back; mismatch refuses
• 2nd-LLM cross-check is the layer that catches both compromised-MCP and compromised-agent simultaneously

Kept from original design: chain_id ≠ 0 hard refuse, paired revocation tuple. Skill v8 §16 unconditional refusal remains the load-bearing defense until this ships.

[szhygulin]

Hardware path verification (2026-04-28, via rnd skill) — re-deferring.

Verified the actual signing path before writing code:

Layer	Status	Source
Ledger ETH app firmware 7702 support	✓ since v1.17.0 (2025-05-05)	app-ethereum CHANGELOG
Device-firmware implementation allowlist	✓ enforced on-device; EF simple7702 only as of v1.20.0 (MetaMask Gator removed 2025-12-02)	CHANGELOG v1.18, v1.20
Ledger Live → device routing of 7702	✗ "not yet available to use via Ledger Live"	Ledger Pectra blog, 2025-05-07
WC 2.x standardized 7702 RPC	✗ no method in eip155 namespace; industry direction is ERC-5792 wallet_sendCalls	WC namespaces spec
viem signAuthorization for external signer	✗ local-key-only	viem docs

Verdict: even with a perfect MCP-side builder, there is no end-to-end path to get a 7702 authorization signed by the user's hardware as of 2026-04-28. Ship date depends on Ledger Live exposing 7702 over WC.

Two findings worth keeping:

1. The MCP-side / skill-side allowlist debate is moot — the device firmware itself enforces an implementation allowlist at the strongest layer (hardware, can't be bypassed by compromised MCP/agent/skill). Re-confirms the rejection of a curated MCP allowlist in #481 above.
2. Re-open against ERC-5792 wallet_sendCalls, not bare eth_signAuthorization. That's where the industry is heading and what Ledger Live is most likely to expose first.

Re-open preconditions (any one):

• Ledger Live release notes confirm 7702 routing over WalletConnect.
• A WC RPC method or ERC-5792 path is standardized end-to-end.
• Empirical confirmation: dApp triggers 7702 via WC, device receives and displays the authorization.

Skill v8 §16 unconditional refusal remains the load-bearing defense. Plan retained at claude-work/plan-eip7702-authorization-builder.md for resumption.

[szhygulin]

Consolidating #504 and #505 into this tracker

Two scope-amending findings (originally filed as separate issues, now consolidated here):

---

From #504 — implementation allowlist is moot (Ledger device enforces on-firmware)

Finding: the Ledger ETH app firmware itself enforces an EIP-7702 implementation allowlist on-device. Any MCP-side or skill-side curated implementation allowlist proposed in this issue is redundant with hardware enforcement (the strongest layer — can't be bypassed by compromised MCP / agent / skill).

Evidence (verified 2026-04-28 via rnd skill):

• app-ethereum CHANGELOG:
  • v1.17.0 (2025-05-05) — Added: EIP-7702 authorization signing, Type 4 transaction signing
  • v1.18.0 (2025-08-05) — Changed: EIP-7702 implementation allowlist enforcement at signing time

Scope amendment for this issue: drop the curated MCP/skill allowlist requirement (originally listed as safeguard #1 in #455 / this tracker). The on-device firmware check covers it. The remaining safeguards (chain_id ≠ 0, paired revocation tuple, mandatory second-LLM, out-of-band re-statement) all still apply.

---

From #505 — target ERC-5792 `wallet_sendCalls`, not bare `eth_signAuthorization`

Finding: when implementing this builder, design against ERC-5792 `wallet_sendCalls` as the wallet-side RPC, not against a bare `eth_signAuthorization` / `wallet_signEIP7702Authorization` method.

Why (verified 2026-04-28 via rnd skill):

• WalletConnect 2.x has no standardized 7702 RPC method. WC namespaces spec lists only `eth_sendTransaction`, `eth_signTransaction`, `personal_sign`, `eth_signTypedData`, `eth_sign`. No `eth_signAuthorization`. A bare-RPC design has no transport.
• ERC-5792 standardizes `wallet_sendCalls` for batched/sponsored transactions including 7702 auth tuples. Multiple wallet vendors (Safe, Coinbase Smart Wallet, Ambire) target it.
• Ledger Live's WC bridge is the gating constraint for our flow regardless — if it doesn't carry the chosen RPC method, the builder is shelfware.

Scope amendment for this issue: the RPC method choice is not an open question — design against `wallet_sendCalls` per ERC-5792. Document at implementation time that Ledger Live WC support for `wallet_sendCalls` is the load-bearing external dependency.

---

#504 and #505 closed as consolidated into this issue.