04 Prague and EIP-7702: get ready

EIP-7702 in one slide

• New tx type 0x04 (set-code tx) with an authorization_list
• Each tuple [chain_id, address, nonce, y_parity, r, s] is signed by an EOA
• EOA code becomes the delegation indicator 0xef0100 || address (23 bytes)
• Calls to the EOA run the delegate's code in the EOA's context (its storage, balance)
• Delegating to address(0) clears it
• Source: https://eips.ethereum.org/EIPS/eip-7702

Why builders care

• Batching: approve + swap / pay in one tx
• Sponsorship: someone else pays gas
• Privilege de-escalation: session keys with limits
• Persistent until changed; not a one-off script

Status (checked 2026-10-21)

• Ethereum: live since Pectra, activation epoch 364032 (https://eips.ethereum.org/EIPS/eip-7600)
• XDC devnet: 7702 active since block 3,000,600 (xdc.dev, "EIP-7702 is available on devnet now")
• XDC Apothem (51): Prague at block 84,333,000 (XDPoSChain v3.0.0-testnet-1 release notes, github.com/XinFinOrg/XDPoSChain/releases)
• XDC mainnet (50): no Prague block announced yet; stays Cancun → prep now, ship later

Security points from the EIP

• Delegate must authenticate callers (msg.sender == address(this) or a signature)
• Signed payloads need nonce, target, calldata, value, gas (replay / griefing)
• Front-running of initialization: no initcode, verify setup data is signed by the EOA
• Storage collisions when switching delegates → namespaced storage (ERC-7201)
• tx.origin == msg.sender no longer means "top-level EOA call"

Prep checklist for existing XDC contracts

• Grep for tx.origin checks and extcodesize == 0 "is EOA" checks
• Do not assume an EOA cannot have code or run logic on receive
• Test with Foundry: evm_version = "prague", vm.signAndAttachDelegation
• Local chain: anvil --hardfork prague, cast send --auth <impl>

→ Lab 3