HIP-1340: EOA Code Delegation (#1340)

Signed-off-by: Lukasz Gasior <lukasz.gasior@swirldslabs.com>
Signed-off-by: Michael Garber <michael.garber@hashgraph.com>
Co-authored-by: Kiran Pachhai <kiran.pachhai@hashgraph.com>
Co-authored-by: Michael Garber <michael.garber@hashgraph.com>
Co-authored-by: Nana Essilfie-Conduah <56320167+Nana-EC@users.noreply.github.com>

Author: 4 people

HIP/hip-1340.md

@@ -2,17 +2,18 @@
 hip: 1340
 title: EOA Code Delegation
 author: Lukasz Gasior (@lukasz.gasior), Luke Lee (@luke.lee)
-working-group: TBD
+working-group: Fernando Paris(@Ferparishuertas), Luis Mastrangelo(@acuarica), Nana Essilfie-Conduah (@Nana-EC) 
 type: Standards Track
 category: Service
 needs-hiero-approval: Yes
 needs-hedera-review: Yes
 hedera-review-date:
 hedera-acceptance-decision:
-status: Review
+status: Last Call
+last-call-date-time: 2026-02-09T07:00:00Z
 discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/pull/1340
 created: 2025-11-13
-updated: 2026-01-21
+updated: 2026-01-26
 ---
 
 ## Abstract
@@ -87,7 +88,7 @@ message Account {
 }
 ```
 
-For EVM compatibility, Hedera Smart Contract Service will assemble the correct Delegation Indicator (i.e. prefix the `delegation_address` with `0xef0100`) for any bytecode queries of an EOA.
+For EVM compatibility, Hiero Smart Contract Service will assemble the correct Delegation Indicator (i.e. prefix the `delegation_address` with `0xef0100`) for any bytecode queries of an EOA.
 
 For external observers, for example those using ContractGetBytecode queries, the code of an EOA will no longer be fixed to the account facade proxy code (the impact on the facade proxy mechanism has been described in more detail below). It will be either empty (no delegation) or an EVM-compatible Delegation Indicator.
 
@@ -117,7 +118,7 @@ message AccountInfo {
 
 #### Updating Code Delegation of an EOA
 
-We propose to enable two ways of setting/updating the Code Delegation. One using Hedera-specific API, and another one using a new EVM transaction type following the specification of EIP-7702.
+We propose to enable two ways of setting/updating the Code Delegation. One using Hiero-specific API, and another one using a new EVM transaction type following the specification of EIP-7702.
 
 ##### Updating Code Delegation Via CryptoCreate or CryptoUpdate Transaction
 
@@ -229,7 +230,7 @@ The following checks will be applied before executing the EVM code of the target
 - targetting a system account address results in a no-op code execution
 - targetting an existing EOA with empty code results in a no-op code execution
 - targetting an existing EOA, which itself contains code delegation results in literal execution of the delegation indicator (which will fail since `0xef` is a banned op code)
-- targetting an existing contract with non-empty code results in the execution of its EVM code, with the exception of calls matching one of Hedera Account Service proxy methods (described in detail below)
+- targetting an existing contract with non-empty code results in the execution of its EVM code, with the exception of calls matching one of Hiero Account Service proxy methods (described in detail below)
 
 In case Code Delegation points to another delegation, creating a potential chain or loop of delegations, only the first one will be resolved and the code of the target address will be interpreted literally, even if it's a Delegation Indicator.
 
@@ -240,7 +241,7 @@ native `ContractCallTransaction` and native `ContractCreateTransaction`.
 
 ### Example User Flows
 
-Below we present two complete example user flow diagrams: one utilizing an EVM type 4 transaction (e.g. when the user uses standard Ethereum-compatible tools) and another one demonstrating the Code Delegation feature using solely Hedera-native operations.
+Below we present two complete example user flow diagrams: one utilizing an EVM type 4 transaction (e.g. when the user uses standard Ethereum-compatible tools) and another one demonstrating the Code Delegation feature using solely Hiero-native operations.
 
 Ethereum-compatible example utilizing an EVM type 4 transaction:
 
@@ -272,7 +273,7 @@ Execution Logic Changes:
 
 ### Impact on Proxy/Facade Calls
 
-HIP-218, followed by HIP-719 (later extended by HIP-755 and HIP-906) introduced the concept of proxy/facade calls, where a call can be made directly to an EVM address of a Hedera-native entity (e.g. an HTS token or an account).
+HIP-218, followed by HIP-719 (later extended by HIP-755 and HIP-906) introduced the concept of proxy/facade calls, where a call can be made directly to an EVM address of a Hiero-native entity (e.g. an HTS token or an account).
 The implementation of this facility currently relies on an intermediate, hardcoded and dynamic piece of EVM code that is being run when such a call is made.
 While functional, this has two main downsides:
 
@@ -332,7 +333,7 @@ Hooks have a dedicated storage namespace, so the fact that Code Delegation might
 
 Mirror Node will be impacted in the following ways:
 
-- `CryptoCreate` / `CryptoUpdate` transaction body will be updated
+- `CryptoCreate` / `CryptoUpdate` transaction body parsing in the imported will be updated
 - A new field will be added to the `Account` entity
 - EOA storage slots will be mutable
 - The code (as returned by ContractGetBytecode) of HTS tokens and HSS schedule addresses will be updated to a Delegation Indicator targetting a corresponding System Contract address
@@ -561,16 +562,16 @@ to
 
 The security is in the hands of the user - EOA owner - as they are the ones deciding which contract code they wish to delegate the execution to. If any System Contract is called within the delegated contract code, it will have full EOA rights, as it is executed in the context of EOA. This complies to the V2 security model, as it's only the user who can set up the delegation in the first place.
 
-In summary, there are no new threats or risks for Hedera, aside the inherent risks of the EIP-7702 Code Delegation adoption within the Ethereum Ecosystem.
+In summary, there are no new threats or risks for Hiero networks, aside the inherent risks of the EIP-7702 Code Delegation adoption within the Ethereum Ecosystem.
 There is a considerable amount of educational materials (articles, blog posts) in the Ethereum community that explain the inherent risks of EIP-7702 and establish best practices for using this feature.
 
 Code Delegation directly to System Contracts will be forbidden for regular EOA accounts (no-op, as described in the appropriate section above) and will only be permited for the following native entities: Token Proxy Account, Schedule Proxy Account to facilitate the proxy/facade mechanism described earlier.
 
 ## How to Teach This
 
-Hedera will support EIP-7702-like EOA Code Delegation, with the following modifications:
-- Hedera's account creation cost will be charged when setting Code Delegation for new accounts
-- Users can use either Ethereum-compatible tools or Hedera native transactions to modify their Code Delegations
+Hiero will support EIP-7702-like EOA Code Delegation, with the following modifications:
+- Hiero's account creation cost will be charged when setting Code Delegation for new accounts
+- Users can use either Ethereum-compatible tools or Hiero native transactions to modify their Code Delegations
 - Delegations to functions matching the signatures of HAS will not work (HAS calls have precedence)
 - HTS/HSS proxy/facade calls remain unchanged from user’s perspective