Exploring Pectra: How Blockscout is integrating EIP-7702

The Pectra hardfork introduces significant updates to Ethereum's functionality, focusing primarily on validator improvements, scalability optimizations and user experience improvements. Central to these updates is EIP-7702, which implements new account abstraction features that substantially enhance the network's programmability.

EIP-7702 establishes a new transaction type that enables externally owned accounts (EOAs) to utilize smart contract code during execution. Once the bytecode is set in an initial authorization transaction, an EOA can continue to utilize the code until they explicitly revoke or revise the delegation. This update bridges the gap between regular EOA wallets and smart contracts, allowing EOAs to access a more flexible and powerful transaction framework. 

With EIP-7702 in place, EOAs can batch transactions and complete DeFi transactions in a single step (rather than the current 2 step approve+spend flow), pay gas fees with different tokens, pay 0 personal gas fees with sponsored transactions (when combined with ERC-4337 paymasters), and leverage additional use cases via smart contract logic. EOAs can now delegate functionality to smart contracts, enabling wallet-like behavior depending on the delegated contract’s capabilities.

In this article we highlight the specific changes introduced by EIP-7702 and describe some common use cases. We also detail the updates we’ve made at Blockscout to help you identify and explore EIP-7702 transactions.

What changes does EIP-7702 introduce?

EIP-7702 introduces an important change that gives EOAs access to additional functionality when sending a transaction. A new transaction type (known as type 0x04 or set_code) provides the option to add authorizations to a transaction. An authorization delegates an existing smart contract to an EOA, allowing an EOA to obtain and execute code.

The new “authorization list” property controls these assignments. The authorization list contains a set of tuples (chain_id, contract_address, nonce, signature (y_parity, r, s)) that assign a contract_address to the EOA specified in the signature fields. This authorization persists until it is replaced or deleted in a future transaction.

Here are the example RLP-encoded fields submitted in a EIP-7702 enabled transaction. The fields follow the same structure as EIP-1559 transactions, with the addition of authorization_list as a new parameter.

rlp([
   chain_id,
   nonce,
   max_fee_per_gas, 
   max_priority_fee_per_gas,
   gas_limit,
   destination,
   value,
   data,
   access_list,
   "authorization_list",
   signature
])

The authorization_list parameter includes the following fields:

authorization_list = 
[[chain_id, contract_address, nonce, signature(y_parity, r, s)], ...]

• chain_id authorizes the address to act on behalf of the EOA on a specific chain. Prior to execution a check is performed to determine that the chain_id either matches the current chain or is set to 0, which designates all chains. It is possible to set this value to 0, but can result in issues if the EOA transaction nonce or contract address differs across chains. 
• contract_address is set to the 0x address of the existing smart contract which will act on the EOA owner’s behalf. 
• nonce - nonce of the EOA, preventing replay attacks. It increments after a transaction is authorized.
• signature - a signature from the EOA confirming the owner wants to set an authorization and that the update is approved by the EOA owner.

Use cases

EIP-7702 vastly expands what accounts can do, building a bridge between the current EOA limitations and a future where account abstraction is built natively into Ethereum. With EIP-7702 in place, EOAs can access new abilities including:

• Batched Operations: Multiple operations can be combined into a single transaction. This can include the approve/spend flow as well as more complex operations where the output from the first operation is used as an input for the second operation. This saves on gas costs and time.
• Sponsored Transactions: A secondary account can pay for the primary EOA’s transaction. This can open up a use case where the primary EOA sends any ERC-20 token to a secondary account, and the secondary account then pays for the transaction using the native coin. The secondary account can also pay for the EOA’s transactions in a sponsorship capacity (ie Dapps providing gas payments as an incentive for usage).  
• Advanced sign-in methods: Accounts can authorize sign in via biometrics, social features or other ways. 
• Account recovery methods: Keys can be split amongst multiple users, providing a backup mechanism to recover an account if the primary key is lost.
• Granular privileges: Account privileges can be revoked or approved over time. Limited keys can be created that can only access certain functions (like the ability to only spend a specific token like USDC) within the EOA.
• ERC-4337 compatibility: UserOperations are now available to EOAs. Any ERC-4337 operations that are currently performed by smart contract wallets (common operations include multi-sign functionality, transaction bundling, and paymaster utilization) can now be submitted directly to bundlers from EOAs. 

Since EOAs are leveraging code to enhance functionality, new use cases will arise over time as developers and projects explore what is possible.

Blockscout support for EIP-7702

We’ve made several changes to Blockscout to provide additional visibility into EIP-7702 transactions. These updates highlight EOA’s that have authorized code (EOA + code) and classify transactions that utilize tx-type-4 during execution.

On the backend we’ve created new tables to store signed authorizations and parse and save authorization tuples from the RPC response, then updated the frontend to display this information on various pages.

EOA + Code Address details 

The tag EOA+code is added to an address once it has authorized a contract delegation via EIP-7702. This tag is displayed on the address details page and with the  + symbol on the address icon. Mousing over the icon also shows the EOA + verified code tag. If the code is verified the + is green, if not verified, the +symbol is white.

On the address details page you will see the Delegated to field denoting the delegated (authorized) contract for that EOA when it exists. This field displays either the contract name (if verified) or the delegated contract address hash if unverified.

EIP-7702 Transaction details

EIP-7702 transactions include the Authorizations tab which shows the address (authorized/delegated contract), authority (EOA), chain, and nonce specified in the transaction.

If the transaction uses ERC-4337 UserOps, Blockscout also displays the user operation details relevant to the actual action executed by the EOA. In this example we see the target address and decode the internal calldata, showing that it was an ERC20 transfer.

For additional transaction details, scroll down to the details link to expand details about the transaction, including its status as Txn-type-4.

Charts and Stats

We’ve also added several new charts to the charts and stats section which show the number of new EIP-7702 authorizations per day as well as the growth in authorizations over time. These charts will illustrate adoption of this new standard as EIP-7702 transactions continue to gain traction.

Conclusion

EIP-7702 represents a significant evolution in Ethereum's infrastructure, bridging the gap between traditional EOAs and smart contracts. By allowing externally owned accounts to temporarily leverage smart contract functionality, this update dramatically expands what users can achieve on the network - from batched transactions and gas sponsorship to advanced account recovery and privileged access controls. 

Blockscout has implemented comprehensive support for these new transaction types, making it easy to identify and explore EIP-7702 interactions through clear visual indicators and detailed transaction information. EIP-7702 and the larger Pectra hardfork promises to enhance both the scalability and user experience of the Ethereum ecosystem, moving the network closer to native account abstraction while maintaining compatibility with existing infrastructure.