pallet-revive: EIP-7702 (continued) by pgherveou · Pull Request #10936 · paritytech/polkadot-sdk

pgherveou · 2026-01-29T15:44:25Z

Continuation of #10851.
evm-test-suite PR paritytech/evm-test-suite#141

This PR implements EIP-7702 ("Set EOA Account Code") for pallet-revive, enabling Externally Owned Accounts (EOAs) to designate a contract whose code will be executed on their behalf when they are called.

What is EIP-7702?

EIP-7702 lets an EOA sign an authorization that says "when someone calls me, execute contract X's code". When a transaction includes these authorizations, any subsequent calls to the delegated EOA will execute the target contract's code: but using the EOA's own storage and balance. This enables smart account patterns (batching, gas sponsorship, etc.) without requiring account abstraction (ERC-4337) or proxy contracts.

For background:

Changes

Pallet integration

The eth_call dispatchable now accepts and processes an authorization list before executing the call.

Note: Updating this dispatchable's signature should be safe: it is not dispatched directly by users but is the inner call of eth_transact, which is signed by an Ethereum wallet and submitted via eth-rpc.

Authorization processing

The Transaction7702 type (with its authorization_list) was already defined and parsed: this PR adds the actual processing logic.

process_authorizations validates each entry (chain ID, signature, nonce, account type), creates the authority account if needed, and sets or clears the delegation. Invalid authorizations are silently skipped per spec.

Key semantics:

Authorizations always succeed: a type-4 transaction is only valid if the origin has enough gas to cover the worst case for every authorization entry. Processing itself cannot fail.
Authorizations are not reverted: if the transaction's call fails and its state changes revert, the delegation changes from authorization processing persist.

Revive-specific complexity: In Revive the per-authorization pre-dispatch weight/gas is higher than EVM because:

An authorization can touch a new account, so the gas must cover the existential deposit (ED) for account creation.
Code is shared across contracts (same blob for init and runtime), so delegating to a contract requires a code lockup deposit and increments a refcount on the code hash to prevent deletion while delegated.

Storage changes

A new AccountType::DelegatedEOA variant is introduced:

delegate_target: Option<H160>: the contract address this EOA delegates to.
contract_info: ContractInfo: storage accounting (child trie, base deposit) for delegated EOAs.

Key behaviors:

Once delegated, an account transitions from EOA to DelegatedEOA permanently.
Clearing delegation sets delegate_target = None but the account stays DelegatedEOA.
Delegated EOAs get their own child trie for storage, keyed by the EOA's address (not the target).
Re-delegating to a different target preserves the child trie (storage survives across target changes).
Code refcounts are managed: setting delegation increments the target's code refcount, clearing it decrements.

Execution changes

During a call, the runtime resolves delegation:

If the callee is an EOA with a delegate_target, code is loaded from the target contract but execution uses the EOA's storage.
Constructors skip delegation lookup (can't deploy via delegation).
No chain following: delegation is resolved at most once. If A delegates to B and B delegates to C, calling A looks up code at B directly (without following B's delegation to C). If B is an EOA, calling A behaves like calling a plain EOA.

Benchmarks

process_new_account_authorization(n): worst case: creates N new accounts with delegations.
process_existing_account_authorization(n): best case: processes N authorizations for existing accounts (used for weight refund calculation).

RPC integration

eth-rpc supports submitting and dry-running EIP-7702 transactions.
eth_getCode returns the 0xef0100 || address prefix for delegated EOAs (per EIP-7702 spec).

…time_dev --bump patch'

pgherveou · 2026-02-02T19:24:06Z

/cmd bench --runtime dev --pallet pallet_revive

0xRVE · 2026-03-11T14:30:51Z

+			Some(new_hash) != old_code_hash
+		{
+			if let Err(e) = CodeInfo::<T>::increment_refcount(new_hash) {
+				log::warn!(target: LOG_TARGET, "increment_refcount({new_hash:?}) failed: {e:?}");


Should be silently failing?

shouldn't happen since we know that new_hash is the hash of an existing contract.

0xRVE · 2026-03-11T14:31:02Z

+			Some(old_hash) != target_code_hash
+		{
+			if let Err(e) = CodeInfo::<T>::decrement_refcount(old_hash) {
+				log::warn!(target: LOG_TARGET, "decrement_refcount({old_hash:?}) failed: {e:?}");


Should be silently failing?

shouldn't happen since we decrement the code_hash of the previous contract

0xRVE · 2026-03-11T14:31:30Z

+				*delegate_target = None;
+				if !contract_info.code_hash.is_zero() {
+					if let Err(e) = CodeInfo::<T>::decrement_refcount(contract_info.code_hash) {
+						log::warn!(target: LOG_TARGET, "decrement_refcount({:?}) failed: {e:?}", contract_info.code_hash);


Should be silently failing?

same answer

0xRVE · 2026-03-11T14:57:24Z

+					origin,
+					amount,
+					Some(exec_config),
+				)?;


if charge_deposit or refund_deposit fail, the previous elements of authorization_list are not reverted because this is executed outside the transaction context (as stated in a comment in eth_call). Do I understand this correctly?
Either way, if one authorization fails then all of them or part of them are not executed.
Should these also be continue?

Maybe wrap each authorization in a with_transaction?

so first we process the authorisations then the transaction execute, if any authorisation fails because we don't have enough gas then everything revert. This should not happen in practice cause validating the transaction ensure we have enough gas to pay for the worst case.

0xRVE · 2026-03-11T14:59:17Z

+		}
+
+		if !account_exists {
+			Pallet::<T>::charge_deposit(None, origin, &account_id, ed, exec_config)?;


See my comment: https://github.com/paritytech/polkadot-sdk/pull/10936/changes#r2918942672

0xRVE · 2026-03-11T15:23:18Z

+	/// Returns the net deposit change.
+	///
+	/// Note: the target's `code_hash` is snapshotted at delegation time. This is fine
+	/// because `set_code` (the only way to change a contract's code) requires root.


If root calls set_code on a contract that is used a delegate then its code is changed.
But the refcount is not updated, i.e. old codehash has refcount but new codehash does not.

set_delegation: increment refcount on old_hash. set_code: old_hash becomes new_hash in the contract that is delegated to. clear_delegation: decrement refcount on new_hash

We would end up with an orphaned ref and possible underflow on refcount[new_hash]?

If you clear_delegation that will decrement the refcount on the old_hash the delegated contract is still pointing to, so that should be fine.

You could say that, then it's not great cause your delegated contract is now pointing to something different than the contract, but since that's the root operation, that should not happen outside of dev, (unless this is done through governance, but I don't see why one would do that)

0xRVE · 2026-03-11T15:52:56Z

+		new_accounts: result.new_accounts,
+		existing_accounts: result.existing_accounts,
+	});
+	result.weight_refund = worst_case_weight.saturating_sub(actual_weight);


This doesn't refund skipped authorizations. So if any authorization was skipped we overcharge.

overcharging if you have added garbage should be fine.

0xRVE · 2026-03-11T16:23:21Z

 			transaction_encoded: Vec<u8>,
 			effective_gas_price: U256,
 			encoded_len: u32,
+			authorization_list: Vec<evm::AuthorizationListEntry>,


We should cap the size of this vec

Not sure if that's necessary, since eth_call is created through the eth_transact

I agree, gas limit would make this low risk.

On the other hand: a BoundedVec would be a cheap insurance against future call path without gas validation.

0xRVE · 2026-03-11T17:16:02Z

+				}
+			}
+			StorageDeposit::Refund(refund)
+		})


What happens if the DelegatedEOA writes some storage (and pays deposit) and then clears delegation? Will that deposit be locked forever? will some other account be able to clear it?

no one will be able to clear it until they restore a delegation with a contract that let you free that storage.

The EOA owns the storage so it just needs to delegate to a contract that allows to clear those specific storage keys?

if you clear the delegation and delegate call to your address, it's like doing a delegate call to a regular EOA, so it essentially does nothing since there are no code anymore to delegate to

I am confused. If a non-contract account creates a delegation to a contract account, then the non-contract account becomes the EOA account right?
Then it writes some storage and clears the delegation. Then the only way for the EOA to retrieve its deposit is to re-create the same delegation and make the delegate clear the storage? Or is there another way?

0xRVE · 2026-06-02T08:37:52Z

closed in favor of #12229

pgherveou and others added 3 commits January 30, 2026 12:32

[pallet-revive] Enforce weight limit on dry-run RPC calls

5159714

Merge branch 'master' into pg/dry-run-limit

0dbe292

Update from github-actions[bot] running command 'prdoc --audience run…

9863ccf

…time_dev --bump patch'

pgherveou force-pushed the pg/eip-7702 branch from b1522d8 to 21967d3 Compare January 30, 2026 16:38

fix clippy

5a19887

pgherveou marked this pull request as ready for review February 2, 2026 19:24

pgherveou and others added 23 commits February 3, 2026 14:39

Merge branch 'master' into pg/dry-run-limit

6958438

wip: eip7702 in pallet-revive

68f3951

fix tests

3256eb1

add signature verification tests

4fc3fd5

fix refunds

a44c297

nit

a274d85

refactor exports

5800853

nit

a35da08

wip: eip7702 in pallet-revive

8dfa361

fix tests

2c307d2

nit

90e6a45

remove some unused items

5a62904

add some runtime tests

d4e0c1f

simple refactors

73dc658

consolidate rlp encoding of authorization list entry

f7bd7e9

use an enum variant to represent delegation target

fff6f2f

refactor signature verification

3d81cb9

add benchmarks for authorization processing

3953619

revert fmt changes

cf66d2c

final fmt fix

f81fe5d

remove remaining cosmetic changes

8edf11d

rename some variables

2f439b5

add benchmarks

4d76cff

pgherveou added 12 commits March 9, 2026 21:36

simplify

622bbae

simplify

b91690f

fixes

9a9eb2d

use a new variant instead of updating the EOA

59d7962

fix fmt

f7b720e

Skipping clear delegation for non-existent account

4159078

nit

4724849

clean up

704437b

fix

1254be7

fmt

f537d3e

fix tests

67193d8

fix breaking change in tracing

aadeda5

pgherveou changed the title ~~pallet-revive: EIP-7702 Set EOA Account Code (continued)~~ pallet-revive: EIP-7702 (continued) Mar 10, 2026

pgherveou added the feature label Mar 10, 2026

attempt to fix differential tests

0c11f70

pgherveou requested review from a team as code owners March 11, 2026 09:21

pgherveou removed the feature label Mar 11, 2026

0xRVE reviewed Mar 11, 2026

View reviewed changes

Fix

9e6aaf0

paritytech-review-bot Bot requested a review from a team March 12, 2026 13:25

PR review

7bfab2f

0xRVE approved these changes Mar 18, 2026

View reviewed changes

pgherveou added this to [preview] release tracker Mar 18, 2026

github-project-automation Bot moved this to Todo in [preview] release tracker Mar 18, 2026

pgherveou removed this from [preview] release tracker Mar 19, 2026

pgherveou requested a review from athei March 20, 2026 08:33

minor security reco

b066266

0xRVE closed this Jun 2, 2026

Conversation

pgherveou commented Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What is EIP-7702?

Changes

Pallet integration

Authorization processing

Storage changes

Execution changes

Benchmarks

RPC integration

Uh oh!

pgherveou commented Feb 2, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xRVE commented Jun 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

pgherveou commented Jan 29, 2026 •

edited

Loading