Defer EntryPoint v0.8 / EIP-7702 — revisit only if Heima adopts Prague (do NOT adopt 7702)

[hanwencheng]

Summary

Track — and explicitly defer — moving the ERC-4337 stack to EntryPoint v0.8 / EIP-7702. This is a no-op for AgentKeys today and should only be revisited if Heima adopts a Prague/Pectra runtime for its own ecosystem reasons. Even then, do not adopt EIP-7702 for the master account.

Context: the master-account auth model is decided in #164 (ERC-4337 v0.7, P-256 passkey, Solution A). Plan: docs/plan/chain/erc4337-master-account.md.

Why v0.8 is deferred (not adopted)

v0.8 feature	For	Reaches our P-256 passkey master?
EIP-7702 (EOA → smart account)	give an existing secp256k1 EOA AA powers	No — counter to the design. #164's thesis is no exportable secp256k1 key. 7702's authority is the EOA's secp key → re-introduces the software root we are removing. We have no legacy EOA; the master is born as a CREATE2 passkey account. Requires Prague (type-4 txs) Heima lacks (it executes Cancun, #168).
EIP-712 userOpHash	human-readable signing for EOA / hardware wallets	No. A WebAuthn authenticator signs sha256(authData‖sha256(clientDataJSON)) with challenge=userOpHash; it never renders EIP-712. v0.7's userOpHash already commits entryPoint+chainId — binding is equivalent.
gas tweaks / struct decoupling	micro-opt	Negligible vs the ~707k P-256 verify.

Cost/benefit

Enabling v0.8 would require a Heima Prague/Pectra runtime upgrade (~7 parachain-team-days) for ~zero AgentKeys benefit, and its headline feature is actively contrary to the no-secp-key design.

Action

• Defer. Do not build v0.8 prep into Migrate master authority to an ERC-4337 P-256 smart-account (resolves §11 gating findings) #164.
• Migrate master authority to an ERC-4337 P-256 smart-account (resolves §11 gating findings) #164 E2 keeps the EntryPoint address + userOpHash construction behind a config interface so a future v0.8 move (if Heima goes Prague anyway) is a config swap, not a redesign.
• Revisit this issue only if/when Heima ships Prague for other reasons — and even then, evaluate without 7702.

See also

• The genuinely valuable chain-upgrade ask is RIP-7212 (P-256 precompile), which is independent of Pectra — tracked separately.

[hanwencheng]

Closing as non-actionable — a 'defer / do not adopt' tracker is noise. The v0.8 / EIP-7702 rationale (counter to the no-secp-key design; needs Prague) is captured in the #164 plan (docs/plan/chain/erc4337-master-account.md §2). The actionable chain-upgrade ask is #170 (RIP-7212 P-256 precompile).