Update Backwards Compatibility Section

Update backwards compatibility section. 

Signed-off-by: Keith Kowal <keith.kowal@swirldslabs.com>

Author: Reccetech

HIP/hip-1340.md

@@ -545,8 +545,40 @@ SDKs will also need to support the new field in CryptoCreate / CryptoUpdate tran
 - The explorer should show the new/modified authorizations that have been set while processing `EthereumTransaction` (V4), `CryptoUpdate` or `CryptoCreate`.
 
 ## Backwards Compatibility
+HIP-1340 introduces EOA code delegation by adding an optional delegation_address field to Hedera accounts and enabling delegation configuration through both Ethereum Type 4 transactions, and native HAPI transactions.
+The proposal is backward compatible at the protocol, data model, and transaction validity levels. No existing accounts are invalidated, and no previously valid transactions become invalid. However, the proposal expands the execution semantics of EOAs and invalidates certain historical assumptions about EOA behavior.
+
+### Behavioral Assumption Changes
+Although backward compatible in terms of transaction validity and account structure, HIP-1340 expands EOA behavior and invalidates certain prior assumptions, including:
+- The assumption that EOAs always have empty bytecode.
+- The assumption that calls to EOAs never execute code.
+- The assumption that msg.sender == tx.origin occurs only in the topmost execution frame.
+
+After delegation is enabled on an account:
+- eth_getCode(account) may return non-empty code.
+- Calls to an EOA may trigger delegated execution.
+- msg.sender == tx.origin may occur in deeper execution frames due to delegation semantics.
+
+These behavioral changes are opt-in and apply only to accounts with a configured delegation_address. Accounts without delegation behave exactly as they did prior to this HIP.
+
+### Delegation Applicability Across Account Types
+Delegation is a protocol-level feature and may be applied to all Hedera account types. HIP-1340 does not change any existing account characteristics. Hedera currently supports three account configurations:
+- ED25519 accounts
+- ECDSA accounts with an Account Alias derived from AccountID (Long-zero alias)
+- ECDSA accounts with an Account Alias derived from the public key
+The mechanism used to configure delegation depends on the transaction path.
+
+#### Ethereum Transaction Path (Type 4)
+Only ECDSA accounts with an Account Alias derived from the public key are capable of submitting Ethereum transactions on Hedera. Consequently:
+Only these accounts may configure or update delegation via Ethereum Type 4 transactions (as defined by EIP-7702).
+This limitation reflects existing Ethereum transaction compatibility rules and is not introduced by HIP-1340.
+ED25519 accounts and ECDSA accounts using AccountID-derived (Long-zero) aliases cannot submit Ethereum transactions and therefore cannot use the Type 4 configuration path.
+
+#### Native HAPI Transaction Path
+All account types may configure or update delegation via native HAPI transactions (e.g., CryptoCreate, CryptoUpdate).
+Once delegation is configured, execution semantics are uniform across account types.
+Native HAPI transaction behavior — including CryptoTransfer signature validation and authorization requirements — remains unchanged by this proposal.
 
-The change itself is backwards compatible, but it significantly modifies the behavior of calls to EOAs and invalidates some previous assumptions, for example that the code of an EOA is always empty or that `msg.sender == tx.origin` only happens in the topmost execution frame.
 
 ## Security Implications