Discussion: EIP-7702 Support on FEVM (Set EOA Account Code)

[snissn]

I’d like to open a discussion around implementing EIP-7702 in the FEVM. This EIP introduces a new transaction type (0x04) that allows EOAs to set their code to a special delegation designator (0xef0100 || address), effectively forwarding execution to a target contract. This enables EOAs to behave like lightweight smart contract wallets, unlocking features such as:

• Atomic batching (e.g., approve and transfer in a single transaction)
• Sponsored transactions with flexible delegation
• Permissioned subkeys with restricted capabilities
• Upgradeable logic while preserving the same EOA address

It’s forward-compatible with account abstraction approaches like ERC-4337, without committing to any specific standard. I’m planning to implement this for the FEVM.

I’d appreciate feedback on any concerns or suggestions around delegation designators, Filecoin’s actor model, and the delayed execution model. For example, I recall @Stebalien previously raising cases where contracts are created and then used within the same transaction—something that may require special handling in the context of Filecoin’s execution semantics.

EIP-7702 is slated for inclusion in Ethereum’s upcoming Pectra upgrade, with a tentative ethereum mainnet launch date of May 7th. Including support in FEVM would help keep us aligned with evolving wallet and tooling expectations.

Looking forward to your thoughts!

[Stebalien]

The main issue is that, given deferred execution, an "evil" account could:

1. Send a message (1) that sends away all funds via the smart contract code with nonce X.
2. Send a message (2) that uses a tone of gas with nonce X+1.

At the moment, we'll only include message 2 if the account has enough funds to cover the gas. If, when message 2 is executed, the account doesn't have the funds; we charge the miner that included the message. At the moment, we can do this reliably (mostly) because message 1 has to declare the amount of funds its sending in the message itself so the miner packing the block can keep a running total of the available balance as it packs messages, ensuring that all accounts will have enough funds to send them. I say mostly because tipsets throw a bit of a wrench in this mess but the current system is "good enough".

The solution we've discussed in the past is multi-stage execution:

1. During stage 1, we validate all messages and reserve gasLimit * gasPrice for each message in the entire tipset from each sending account.
2. During stage 2, we execute all messages.
3. During stage 3, we process refunds for any unused gas. TBH, we'd likely merge stage 2 & 3, processing refunds immediately after message execution.

This fixes the problem by reserving the funds needed to pay for gas before any accounts can "steal it" from themselves.

This change isn't actually that hard to implement and gets us much closer to supporting full account abstraction so.... I'm all for it, TBH.

[Tanisha-fil]

Hi @snissn 👋 — thanks for kicking off the EIP-7702 discussion!

Below is exactly what Core Devs need before we can add this item to the next call (the agenda is for concrete, spec-level proposals rather than early brainstorming).

✔️ Step	What to deliver	Why it matters
1 · Mini-spec snapshot	• Message encoding – how the 0xef0100‖addr delegation prefix travels inside a Filecoin message (we have no typed-tx field). • State-transition rules – set-code, delegate, revert paths. • Atomicity notes vs. Filecoin’s delayed actor-creation.	Gives implementers a crisp delta to review.
2 · Proof-of-concept branch	Minimal patch in builtin-actors or ref-fvm that: • detects the prefix • forwards execution to the target contract • reverts cleanly on malformed inputs.	Shows feasibility and lets client teams gauge effort.
3 · Open-questions list	Bullet the remaining design issues (re-entrancy, delegate to non-EVM actor, self-destruct edge cases, replay protection, etc.).	Keeps the call focused and time-boxed.

---

How to move forward

1. Publish items 1-3 (gist, doc, or branch) and link them back here.
2. Mention me once they’re up; I’ll add “EIP-7702 delegation for FEVM” to the Core Devs agenda (needs ≥ 48 h notice).
3. (Optional but useful) Open a Draft FIP with the standard header + nine narrative sections; we can iterate after the call.

If we can land the mini-spec this week, we should comfortably hit the next Core Devs call and stay aligned with Ethereum’s Pectra timeline.

Looking forward to shaping this out and please reach out if you need any help!