Native Key Delegation for EOAs

Abstract

This EIP extends the delegation designator system introduced by EIP-7702 to support native key delegation — permanently converting an EOA’s authentication from ECDSA over secp256k1 to an alternative signature scheme. A new code prefix 0xef0101 designates an account whose authentication key is an ML-DSA-44 public key embedded directly in the account’s code field. Once set, the original ECDSA key is rendered permanently inert. A single new transaction type supports both ECDSA-signed key migration and ML-DSA-44-authenticated transaction origination. Accounts may be created without any party ever possessing the ECDSA private key, using a crafted-signature technique analogous to Nick’s method (ERC-2470) for keyless contract deployment.

Motivation

EIP-7702 brought code delegation to EOAs but retained ECDSA over secp256k1 as the sole native authentication mechanism. This constrains the ecosystem to a single signature scheme with known limitations:

• Quantum vulnerability. secp256k1 ECDSA is vulnerable to quantum attacks. Native key delegation with ML-DSA-44, a NIST-standardized post-quantum scheme, directly addresses this threat. The framework generalizes to future post-quantum schemes via additional 0xef01XX designators.
• Hardware ecosystem mismatch. Secure enclaves and hardware security modules increasingly ship with native support for signature schemes beyond secp256k1. Forcing ECDSA introduces bridging complexity and enlarges the trusted computing base.
• Smart contract wallet overhead. Smart contract wallets and EIP-7702 code delegation can achieve alternative authentication today, but at the cost of EVM execution for every transaction validation. Native key delegation moves signature verification into the protocol, eliminating per-transaction contract overhead.
• Provably rootless accounts. The crafted-signature creation path produces accounts where the ECDSA private key never existed, providing a cryptographic guarantee — not merely a procedural one — that no backdoor key can override the installed scheme.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Constants

Delegation Designator Space

EIP-7702 defines the code prefix 0xef0100 for code delegation. This EIP extends the 0xef01XX namespace:

An account whose code is exactly 0xef0101 || pubkey (1,315 bytes) is a native-key account. The 1,312-byte pubkey is an ML-DSA-44 public key used for all subsequent transaction authentication.

Native Key Transaction (Type 0x06)

A new EIP-2718 transaction type serves both native key migration and native-key-authenticated transaction origination:

0x06 || rlp([
    chain_id,
    nonce,
    max_priority_fee_per_gas,
    max_fee_per_gas,
    gas_limit,
    to,
    value,
    data,
    access_list,
    native_key_authorization_list,
    sender,
    signature
])

The fields chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, and access_list follow the same semantics as EIP-4844. A null to is not valid.

The sender field determines the transaction’s authentication mode:

• ECDSA mode (sender is empty): The transaction is signed with ECDSA. signature is 65 bytes, encoding y_parity || r || s. The transaction sender is recovered via ecrecover. Any EOA may submit this transaction; the submitter need not be the authority whose key is being set.
• ML-DSA-44 mode (sender is 20 bytes): The transaction is signed with ML-DSA-44 by the native-key account at sender. signature is 2,420 bytes.

The signing payload for both modes is:

tx_hash = keccak256(NATIVE_KEY_TX_TYPE || rlp([
    chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas,
    gas_limit, to, value, data, access_list,
    native_key_authorization_list, sender
]))

In ECDSA mode, sender is empty in the payload, so the signing domain is distinct from ML-DSA-44 mode where sender is 20 bytes.

Native Key Authorization Tuple

The native_key_authorization_list supports two tuple formats: ECDSA-signed tuples for initial key migration, and native-key-signed tuples for key rotation. Tuples are distinguished by element count: 6 elements for ECDSA, 5 for native key. Tuples with any other element count are invalid.

ECDSA-Signed Authorization (Key Migration)

Each ECDSA-signed entry has the form:

ecdsa_auth = [chain_id, pubkey, nonce, y_parity, r, s]

The authorization message is:

msg_hash = keccak256(NATIVE_KEY_MAGIC || rlp([chain_id, pubkey, nonce]))

The authority is recovered via ecrecover(msg_hash, y_parity, r, s).

Native Key Authorization (Key Rotation)

Each native-key-signed entry has the form:

native_key_auth = [chain_id, new_pubkey, nonce, authority, signature]

The authorization message is:

msg_hash = keccak256(NATIVE_KEY_MAGIC || rlp([chain_id, new_pubkey, nonce, authority]))

The authority is stated explicitly. Its currently installed native key is used for verification. The authority address is included in the signed message to prevent cross-account replay.

Transaction Validation

Future EIPs may modify this verification procedure to account for non-ML-DSA-44 native key delegations.

If sender is empty (ECDSA mode):

1. Verify signature is exactly 65 bytes. Otherwise the transaction is invalid.
2. Parse y_parity = signature[0], r = signature[1..33], s = signature[33..65].
3. Recover the transaction sender via ecrecover(tx_hash, y_parity, r, s). If recovery fails, the transaction is invalid.
4. Proceed with standard sender validation (nonce, balance, etc.).

If sender is 20 bytes (Native Key mode):

1. Verify sender’s code begins with ML_DSA_44_DESIGNATION and is exactly 1,315 bytes. Otherwise the transaction is invalid.
2. Add sender to accessed_addresses (as defined by EIP-2929).
3. Extract pubkey = sender.code[3..1315].
4. Verify ML_DSA_44_Verify(pubkey, tx_hash, signature) per FIPS 204¹ Section 6 (Algorithm 3). The following strictness requirements apply:
   • All encodings MUST be canonical per FIPS 204. Non-canonical encodings of public keys or signatures MUST be rejected.
   • The signature vector z coefficients MUST satisfy the norm bound check as specified in FIPS 204. Implementations MUST NOT skip or relax this check.
   • The hint vector h MUST have exactly the number of ones indicated by the signature metadata; duplicate or out-of-order indices MUST be rejected.
   • Implementations MUST produce identical accept/reject decisions for every possible (pubkey, message, signature) triple. Implementors should validate against a shared test vector suite and should not rely on library defaults. If verification fails, the transaction is invalid.
5. Verify nonce == sender.nonce. Otherwise the transaction is invalid.
6. Proceed with standard transaction execution.

ML_DSA_44_VERIFY_COST is added to the transaction’s intrinsic gas cost in native key mode, replacing the implicit ecrecover cost.

If sender is any other length, the transaction is invalid.

Authorization List Processing

The native_key_authorization_list is processed before transaction execution but after the sender’s nonce is incremented, mirroring EIP-7702 semantics. The list MAY be empty.

For each ECDSA-signed tuple [chain_id, pubkey, nonce, y_parity, r, s], in order:

1. Verify chain_id is 0 or equals the current chain ID. Otherwise skip.
2. Verify pubkey is exactly 1,312 bytes. Otherwise skip.
3. Verify nonce < 2^64 - 1. Otherwise skip.
4. Verify s <= secp256k1n / 2, as per EIP-2. Otherwise skip.
5. Set msg_hash = keccak256(NATIVE_KEY_MAGIC || rlp([chain_id, pubkey, nonce])).
6. Set authority = ecrecover(msg_hash, y_parity, r, s). If recovery fails, skip.
7. Verify authority’s code is empty or begins with 0xef0100. Otherwise skip.
8. Verify authority’s nonce equals nonce. Otherwise skip.
9. Add authority to accessed_addresses (as defined by EIP-2929).
10. Increment authority’s nonce by one.
11. Set authority’s code to ML_DSA_44_DESIGNATION || pubkey.
12. Charge PER_NATIVE_AUTH_BASE_COST gas, plus PER_EMPTY_ACCOUNT_COST if the account was previously empty.

For each native-key-signed tuple [chain_id, new_pubkey, nonce, authority, signature], in order:

1. Verify chain_id is 0 or equals the current chain ID. Otherwise skip.
2. Verify new_pubkey is exactly 1,312 bytes. Otherwise skip.
3. Verify nonce < 2^64 - 1. Otherwise skip.
4. Verify authority’s code begins with ML_DSA_44_DESIGNATION and is exactly 1,315 bytes. Otherwise skip.
5. Extract current_pubkey = authority.code[3..1315].
6. Set msg_hash = keccak256(NATIVE_KEY_MAGIC || rlp([chain_id, new_pubkey, nonce, authority])).
7. Verify ML_DSA_44_Verify(current_pubkey, msg_hash, signature) using the same verification constraints as Type 0x06 native key mode. If verification fails, skip.
8. Verify authority’s nonce equals nonce. Otherwise skip.
9. Add authority to accessed_addresses (as defined by EIP-2929).
10. Increment authority’s nonce by one.
11. Set authority’s code to ML_DSA_44_DESIGNATION || new_pubkey.
12. Charge PER_NATIVE_AUTH_BASE_COST gas.

If multiple tuples (of either type) target the same authority, the last valid tuple wins.

ECDSA Rejection Rule

Once an account’s code is set to 0xef0101 || pubkey:

• ECDSA-signed transactions (Types 0x00–0x04, and Type 0x06 in ECDSA mode) whose recovered sender is a native-key account MUST be rejected during transaction validation.
• EIP-7702 authorization tuples whose recovered authority is a native-key account MUST be rejected.

The account is permanently governed by its embedded native key. The ECDSA private key — whether unknown, destroyed, or still held — has no protocol significance. Key rotation is accomplished via native-key-signed authorization tuples, not ECDSA.

Keyless Account Creation (Crafted-Signature Method)

An account MAY be created where no party has ever possessed the ECDSA private key:

1. The creator generates an ML-DSA-44 keypair (sk, pk).

2. The creator computes the authorization message for a fresh (nonce-0) account:

   msg_hash = keccak256(NATIVE_KEY_MAGIC || rlp([chain_id, pk, 0]))

3. The creator selects r as the x-coordinate of a secp256k1 curve point whose discrete logarithm is unknown (e.g., output of hash-to-curve on a public seed), and selects an arbitrary non-zero s.

4. The creator computes authority = ecrecover(msg_hash, y_parity, r, s). This yields a deterministic address for which no party knows the private key.

5. Any party funds authority with ETH.

6. Any party submits a Type 0x06 transaction (ECDSA mode) containing the authorization tuple [chain_id, pk, 0, y_parity, r, s].

The account at authority is now authenticated exclusively by the ML-DSA-44 key pk. Because deriving the ECDSA private key from the recovered public key requires solving the Elliptic Curve Discrete Logarithm Problem, the account is provably rootless — no ECDSA backdoor exists.

The authority address is deterministic given (chain_id, pk, r, s, y_parity), enabling counterfactual address computation and pre-funding before the Type 0x06 transaction is submitted.

Recommended construction for r: Compute r_seed = keccak256("nkd-v1" || chain_id || pk), then find the smallest valid secp256k1 x-coordinate ≥ r_seed mod p. Set s = 1. This makes the derivation publicly verifiable: anyone can reproduce the computation and confirm that no trapdoor was used.

Transaction Origination

This EIP extends the EIP-3607 exception established by EIP-7702: accounts whose code begins with 0xef0101 MAY originate transactions (via Type 0x06 in ML-DSA-44 mode), in addition to accounts whose code begins with 0xef0100.

Key Rotation

A native-key account holder MAY rotate their native key by including a native-key-signed authorization tuple in a Type 0x06 transaction. The tuple [chain_id, new_pubkey, nonce, authority, signature] is signed by the currently installed native key and, when processed, replaces the account’s code with ML_DSA_44_DESIGNATION || new_pubkey.

Key rotation does not require the original ECDSA key and works identically for ephemeral-key and crafted-signature (rootless) accounts. The rotation is atomic: it is applied during authorization list processing, before transaction execution.

Because the authorization tuple is included in a Type 0x06 transaction, the rotation may be submitted by any party — the native-key account holder need not be the transaction sender. This enables gas sponsorship for key rotation.

Interaction with EIP-7702

Code-Reading Operations

Code-Execution Operations

CALL (0xf1), CALLCODE (0xf2), DELEGATECALL (0xf4), and STATICCALL (0xfa) targeting a native-key account execute no code. The account behaves as an EOA for execution purposes.

Rationale

Permanent Delegation

Native key delegation is permanent. Once an account’s code is set to 0xef0101 || pubkey, the ECDSA key is dead — the protocol will never accept it again. This is a deliberate and safe design choice for two reasons.

First, permanence is safe because the new key is the root key. The holder of the installed ML-DSA-44 private key can always rotate to a new key via a native-key-signed authorization tuple. There is no loss of authority: the account owner retains full, exclusive control through the current native key. Reverting to ECDSA would only re-introduce a weaker authentication scheme with no benefit.

Second, permanence eliminates the entire class of “dormant key” attacks. If the conversion were revocable, a leaked or quantum-broken ECDSA key could always hijack the account by reverting the delegation. Irreversibility means there is no second key to protect, no fallback to worry about, and no ambiguity about which key controls the account. For crafted-signature accounts this is a mathematical guarantee (the ECDSA key never existed). For ephemeral-key accounts it is a protocol-enforced guarantee independent of key destruction procedures.

The permanence also simplifies the security model: validators need only check the account’s code prefix to determine the authentication scheme. There is no need to track historical key states or handle mixed-mode authentication.

Embedded Keys vs. Contract Delegation

EIP-7702 delegates to code at an address. Native key delegation embeds the key directly in the account’s code field. This is the correct design because:

1. No code execution is involved. The key authenticates transactions at the protocol level. There is no contract to delegate to.
2. Self-contained verification. Validators verify signatures without loading external code or crossing the EVM boundary.
3. No delegation chain concerns. EIP-7702 must handle chains of ef0100 pointers. Native key accounts are terminal — no indirection.
4. Minimal storage. 1,315 bytes per account vs. a full contract deployment.

Native-Key Accounts as Pure EOAs

Native-key accounts intentionally have no code execution capability. They cannot use EIP-7702 code delegation for batching, sponsorship, or privilege de-escalation. This is a deliberate scope constraint, not an oversight.

The purpose of this EIP is to replace the authentication primitive, not to replicate the full EIP-7702 feature set. Combining native key authentication with code delegation is a valid goal but introduces significant complexity: the account’s code field would need to encode both a delegation target and an authentication key, and the interaction between the two must be carefully specified. A future EIP may define a combined designator (e.g., one that embeds both a pubkey and a delegation address) or allow 0xef0101 accounts to also carry 0xef0100 delegation. This EIP provides the authentication foundation that such extensions would build on.

Post-Quantum Readiness

This EIP directly addresses the post-quantum threat by deploying ML-DSA-44, a NIST-standardized post-quantum signature scheme (FIPS 204¹), as the first native key scheme. Deploying post-quantum authentication before quantum computers threaten existing cryptography gives the ecosystem time to migrate accounts at its own pace rather than under emergency conditions.

The migration path is straightforward. A single Type 0x06 transaction (in ECDSA mode) atomically replaces an account’s authentication scheme. Because the 0xef01XX prefix space is extensible, future signature schemes slot directly into the same framework. The migration is one transaction, one block, one atomic state change — no intermediate contract deployments, no multi-step approval chains, and no window during which the account is authenticated by both the old and new key.

The crafted-signature path further strengthens this: new accounts can be created directly under ML-DSA-44, bypassing ECDSA entirely. The combination of in-place migration for existing accounts and native creation for new accounts provides a complete migration path without requiring a new account model or a hard fork beyond the initial activation of the relevant 0xef01XX designator.

Choice of ML-DSA-44

ML-DSA-44 (FIPS 204¹) was selected as the initial native key scheme for the following reasons:

1. Post-quantum security. ML-DSA-44 provides NIST Level 1 security (128-bit post-quantum), comparable to the ~128-bit classical security of secp256k1 ECDSA. Unlike Ed25519 or secp256r1, it is not vulnerable to quantum attacks.
2. NIST standardization. FIPS 204 is a finalized, published standard with an established ecosystem of implementations. This provides the normative stability required for a consensus-critical specification.
3. Implementation maturity. ML-DSA has the broadest library support of any post-quantum signature scheme, reducing the risk of consensus-critical implementation divergence across Ethereum clients.
4. Reasonable size tradeoffs. ML-DSA-44 public keys (1,312 bytes) and signatures (2,420 bytes) are larger than classical schemes but remain practical for on-chain use. Future schemes with better size profiles (e.g., FN-DSA under FIPS 206, when finalized) can be added via new 0xef01XX designators without modifying this EIP.

secp256r1 (P-256) ECDSA was considered but rejected: it is not post-quantum, and its verification is already well served by existing precompile proposals. Ed25519 was considered but provides no quantum resistance, and the “test the migration path with a non-PQ scheme first” argument is weaker than deploying quantum resistance directly.

Scheme-Specific Prefixes

Using distinct 3-byte prefixes per scheme (0xef0101 for ML-DSA-44, 0xef0102 for a future scheme, etc.) rather than a generic prefix with a scheme byte:

1. Fixed code sizes. Each scheme has a known pubkey length. The code size is fixed and can be validated without parsing.
2. Independent activation. Each scheme is its own EIP. Consensus clients can support schemes incrementally.
3. No version negotiation. The prefix fully determines the verification algorithm.

Single Transaction Type with Dual Authentication Mode

This EIP uses a single transaction type (0x06) for both setting native keys (ECDSA mode) and originating transactions from native-key accounts (ML-DSA-44 mode). The sender field acts as the discriminant: empty for ECDSA, 20 bytes for native key mode. This avoids consuming two EIP-2718 type numbers and enables a capability that two separate types could not: a native-key account can submit migration authorizations for other accounts in the same transaction it uses to send value or call contracts.

The native_key_authorization_list may be empty in either mode. In ECDSA mode, a transaction with an empty list is invalid (there is no reason to use Type 0x06 without authorizations or ML-DSA-44 signing). In ML-DSA-44 mode, an empty list is the common case — a native-key account simply sending a transaction.

ML-DSA-44 does not support public key recovery from signatures. The sender address must be stated explicitly in ML-DSA-44 mode. This is a departure from Ethereum’s “recover sender from signature” convention, but provides a tangible benefit: transaction deserialization no longer requires an elliptic curve operation.

This EIP was initially specified as two transaction types, 0x5 to set native key delegations, and 0x6 to dispatch transactions from native key delegated accounts. Making a single tx type to serve both needs and all future extensions reduces protocol complexity footprint.

Crafted-Signature Creation

The crafted-signature method is strictly stronger than the ephemeral-key method:

The technique is battle-tested: Nick’s method and ERC-2470 use identical cryptographic reasoning for keyless contract deployment.

Omitted Features

This EIP deliberately omits EIP-7702 code delegation and EIP-4844 blob carrying for native-key accounts. Neither omission is fundamental. Code delegation could be added via a new delegation designator that embeds both a pubkey and a delegation target. Blob support could be added via a new transaction type that combines ML-DSA-44 authentication with blob fields. Both are deferred to keep this EIP focused on the authentication primitive.

Backwards Compatibility

This EIP introduces new behavior gated behind a new transaction type and an explicit opt-in authorization. No existing accounts or transaction types are affected unless the account owner explicitly converts via a native key authorization.

1. New delegation designator (0xef0101). No conflict with 0xef0100 or pre-EIP-3541 contracts, which cannot have 0xef-prefixed code.
2. New transaction type (0x06). Standard EIP-2718 typed transaction rollout. Unrecognized types are ignored by older clients.
3. Extended EIP-3607 exception. Transaction origination is now permitted for both 0xef0100 and 0xef0101 code prefixes.
4. ECDSA rejection for converted accounts. This is a new validation rule, but applies only to accounts that explicitly opted in. No existing account is affected without an explicit on-chain authorization.

Test Cases

Pending.

Security Considerations

Post-Quantum Threat Model

The post-quantum threat to Ethereum accounts is not uniform. It depends on whether the account’s authentication key is exposed on-chain:

Any account whose authentication key is quantum-vulnerable and exposed on-chain is vulnerable at rest to a quantum attacker who can recover the private key. This applies to ECDSA-signed transactions (which expose the secp256k1 public key) and EIP-7702 delegations (which can be overwritten by recovering the authorizing ECDSA key). Native-key accounts delegated to ML-DSA-44 are not vulnerable at rest or in flight, as ML-DSA-44 is a post-quantum scheme — neither the authorization signature nor the installed key is quantum-recoverable. Only accounts that have never exposed a public key on-chain (nonce-0 EOAs) and native-key accounts delegated to a post-quantum 0xef01XX scheme are safe at rest.

ECDSA Key Exposure Window (Ephemeral Key Path)

When creating an account via the ephemeral key path, the ECDSA private key exists in memory for the duration of the authorization signing. Implementors should prefer the crafted-signature path. When using ephemeral keys, implementors must generate and destroy the key in a secure, memory-safe context and must not persist the key to disk.

ML-DSA-44 Implementation Correctness

The ML-DSA-44 verification algorithm is specified precisely in the Type 0x06 native key mode validation rules to prevent consensus-critical divergence between implementations. The specification requires canonical encoding of all values, strict norm bound checking for signature coefficients, and rejection of malformed hint vectors (including duplicate or out-of-order indices). This last requirement addresses a known malleability vector in ML-DSA implementations.

Consensus-critical divergence between ML-DSA-44 implementations is a chain-split risk. All implementations must produce identical accept/reject decisions for every possible (pubkey, message, signature) triple. Implementors should validate against a shared test vector suite and should not rely on library defaults, as different libraries may implement different strictness levels for encoding validation.

Front-Running

Native key authorization tuples can be observed in the mempool and front-run. The impact is limited: the front-runner can cause the native key to be set earlier than intended, but the resulting account state is identical (the pubkey is embedded in the tuple). A front-runner cannot substitute a different key.

Replay Protection

• Cross-chain. chain_id in both authorization tuples and type 0x06 transactions. Setting chain_id = 0 in an authorization permits intentional multi-chain use.
• Same-chain. Nonce in both authorization tuples and transactions.

Account Recovery

Native key delegation is irreversible by design. Loss of the ML-DSA-44 private key results in permanent loss of access to the account and all associated assets. This is the same failure mode as losing a secp256k1 key for a standard EOA.

Native-key accounts as specified in this EIP have no on-chain recovery path. Because they cannot execute code (no EIP-7702 delegation), smart-contract-based social recovery is not available. Users who require recovery guarantees should evaluate whether native key delegation is appropriate for their use case, or wait for a future EIP that combines native key authentication with code delegation.

Cross-Chain Authorization Replay

Authorization tuples with chain_id = 0 are valid on all EVM chains. For the crafted-signature creation path, this means an attacker who observes the authorization tuple can replay it on any chain, establishing the same account (same address, same native key) on chains the creator did not intend. The account state on those chains (pre-existing balance, nonce, or code) may differ from the creator’s expectations.

Creators who do not intend multi-chain deployment should set chain_id to the target chain. Creators who intentionally use chain_id = 0 for multi-chain deployment should be aware that any party can trigger the migration on any chain once the authorization tuple is public.

Transaction Pool Considerations

Native-key accounts share the same transaction pool challenges as EIP-7702 delegated accounts: a key rotation could invalidate pending transactions. Clients should accept at most one pending Type 0x06 transaction per native-key account to minimize the number of transactions that can be invalidated by a single state change.

Deterministic Keyless Addresses

The crafted-signature method produces addresses that depend on (chain_id, pk, r, s, y_parity). Users should use the recommended deterministic r construction to ensure addresses are publicly reproducible. Non-deterministic r values are not unsafe but prevent third-party verification that the account is provably rootless.

{
  "type": "standard",
  "id": 1,
  "author": [
    {
      "literal": "National Institute of Standards and Technology"
    }
  ],
  "title": "Module-Lattice-Based Digital Signature Standard",
  "DOI": "10.6028/NIST.FIPS.204",
  "URL": "https://csrc.nist.gov/pubs/fips/204/final",
  "original-date": {
    "date-parts": [
      [2024, 8, 13]
    ]
  }
}

Copyright

Copyright and related rights waived via CC0.