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!

[snissn]

Thank you everyone for the valuable discussion so far. Following up on @Tanisha-fil's requirements for moving forward and addressing the architectural points raised by @Stebalien, we have formalized the implementation strategy for EIP-7702 on FEVM and drafted a comprehensive FIP.

Below is a summary of the value proposition and the specifics of our proposed implementation.

What EIP-7702 Does and Why It Matters for Filecoin

EIP-7702 (Set Code for EOAs) is a crucial update as the Ethereum ecosystem evolves toward enhanced wallet functionality and account abstraction. It allows standard Externally Owned Accounts (EOAs)—the typical user wallet—to delegate execution capabilities to a smart contract.

This effectively lets an EOA behave like a smart contract wallet without requiring the user to migrate assets or change their address. The primary benefits for the Filecoin ecosystem are:

1. Enhanced User Experience (Batching): It enables atomic operations, such as combining an ERC-20 approval and a subsequent DEX swap into a single transaction. This significantly reduces friction for users interacting with DeFi and other dApps on Filecoin.
2. Ethereum Tooling Compatibility: As EIP-7702 is included in Ethereum's now live Pectra upgrade, supporting it ensures that modern wallets, SDKs, and infrastructure work seamlessly on FEVM.
3. Advanced Features: It facilitates use cases like sponsored transactions (paymasters) and granular permission scoping for standard EOAs.

FEVM Implementation Details

Our approach integrates EIP-7702 entirely within the existing EVM actor architecture, avoiding modifications to the core Filecoin account actors.

1. The ApplyAndCall Entrypoint

The new 0x04 transaction type is routed exclusively to a new FRC-42 method on the EVM actor: ApplyAndCall.

• Behavior: ApplyAndCall atomically processes the transaction's authorization_list—validating signatures (using the 0x05 domain separator), checking nonces, and updating delegations—and then executes the outer transaction call.

2. State Management (Internal HAMTs)

We extend the EVM actor's state with three new HAMTs to manage the delegations internally:

• delegations: Maps the EOA (authority) to the delegate contract.
• delegation_nonces: Tracks nonces for each authority to prevent replay.
• delegation_storage: Maps the authority to a dedicated storage root CID. This ensures isolated and persistent storage when executing delegated code under the EOA's authority.

3. Atomicity and Persistence (Spec Compliance)

Crucially, the implementation adheres to the EIP-7702 atomicity model for security:

• Nonce increments and delegation mappings are flushed and persisted before the outer call is executed.
• Even if the outer call reverts, these changes persist, preventing authorization replay.
• ApplyAndCall always returns ExitCode::OK, embedding the outer call's actual status (success/revert) and return data in its response.

4. Interpreter Semantics

The FEVM interpreter is updated to handle delegated calls:

• CALL Behavior: When a CALL targets a delegated EOA, the interpreter uses an internal InvokeAsEoa trampoline to execute the delegate's code within the authority's context (using the authority's dedicated storage and balance).
• Depth Limit: We enforce a strict delegation depth limit of 1 to prevent recursion issues.
• Pointer Semantics: EXTCODE* opcodes (e.g., EXTCODESIZE) correctly operate on the 23-byte virtual pointer code (0xEF0100 || address), not the delegate's code.
• SELFDESTRUCT: SELFDESTRUCT is treated as a no-op in delegated contexts to protect the actor state.

Addressing Execution Concerns

The concerns raised by @Stebalien regarding deferred execution and gas payment security are critical. The suggestion to adopt tipset-wide multi-stage execution with upfront gas reservation (reserve gasLimit*gasPrice per message before execution, then exec+refund) to prevent same-account drain-then-burn and avoid miner-charged gas is listed as a requirement for the builtin-actors PR and the FIP proposal is being updated to reflect this.

Next Steps

We have prepared a full Draft FIP detailing the specification, rationale, comprehensive test plan (covering validation, atomicity, and interpreter semantics), and security considerations based on this strategy. We welcome community review of the draft FIP (PR forthcoming) and look forward to discussing this further.

[snissn]

On further thinking and review I think it makes more sense to consider the resolution to the gas pre‑reservation concerns raised by @Stebalien as a separate FIP. It’s orthogonal to 7702: pre‑reservation alters the consensus execution pipeline for all messages, while 7702 is about EOA delegation semantics. Refining the gas pre-reservation is an orthogonal change to EOA and resolves the concern.

Splitting them lets us stage, benchmark, and activate the economic change independently, without slowing down the EOA feature. It also makes review cleaner—miners’ incentives, packer behavior, and test vectors for reservation deserve focused scrutiny that would bloat the 7702 spec.

[snissn]

Here is a discussion for the related Multi‑Stage Gas Reservation feature: #1210