EIP-8215: Hash-Committed Account (HCA)

EIPs
1

Update (April 2026): A formal EIP draft has been submitted as EIP-XXXX. This thread serves as the official discussion forum per the EIP preamble discussions-to field.

I have been researching Ethereum’s post-quantum landscape and identified a structural gap that I have not seen addressed in any existing proposal. I am posting here to gather technical feedback alongside a formal EIP draft.

The gap

The Ethereum community is making strong progress on post-quantum security:

  • EIP-8141 — flexible signature schemes via frame transactions

  • EIP-7932 — post-quantum algorithm registry and precompiles

  • EIP-7864 — unified binary state tree using quantum-safe hash functions

Each of these proposals changes how you sign, verify, or store.

None of them change how the address is derived.

After all three proposals are fully deployed, the Ethereum address derivation formula remains:

address = keccak256(public_key)[12:]

The public key is still the seed of every EOA identity. The first transaction permanently exposes that key on-chain via ecrecover. A Cryptographically Relevant Quantum Computer running Shor’s algorithm needs only that exposed public key to recover the private key.

This is not a signature problem. It is a commitment problem.

The address derivation layer is the only layer in Ethereum’s post-quantum roadmap without a quantum-safe upgrade path.

The concept — Hash-Committed Account (HCA)

A new Ethereum account type where the address commits to an authentication policy tree — not a public key:

auth_root = merkle_root([leaf_0, leaf_1, ..., leaf_n])
address   = keccak256(tagged_hash("HCAAddr", auth_root))[12:]
leaf_n    = version_byte || EVM bytecode spending condition

No public key enters the address derivation or commitment chain at any point. A quantum computer observing the address learns nothing — there is no algebraic structure to attack.

Spending flow

When sending a transaction from an HCA account, the witness contains:

witness = {
    leaf_script,    // the spending condition being used
    merkle_proof,   // proof that leaf_script ∈ auth_root
    witness_data    // signature or other data the leaf requires
}

Verification:

  1. Hash leaf_script → leaf_hash

  2. Walk merkle_proof from leaf_hash → recomputed root

  3. Assert recomputed root == authRoot stored in account state

  4. Execute leaf_script in restricted EVM context (read-only, gas-capped)

  5. If valid, execute the transaction. msg.sender = HCA address.

No ecrecover. No public key recovery. Sender address is an explicit field in the transaction body — consistent with EIP-8141’s frame transactions.

Signature-scheme agnostic

HCA does not mandate a signature scheme. Leaf version 0x01 uses ECDSA and works today. Leaf version 0x02 dispatches to EIP-7932’s algorithm registry — Falcon, Dilithium, SPHINCS+ work when standardized. HCA defines the commitment structure. The signature scheme is a leaf-level concern.

How HCA differs from Account Abstraction

I want to address this directly because it is the most common question.

Account abstraction (EIP-8141, ERC-4337, EIP-7702) changes how transactions are validated — it decouples signature verification from ECDSA. HCA changes what the address itself commits to — it decouples address derivation from public keys.

These are orthogonal layers:

EIP-7864  →  quantum-safe state storage       (how data is stored)
EIP-7932  →  quantum-safe algorithm registry   (which algorithms exist)
EIP-8141  →  quantum-safe validation           (how you sign)
HCA       →  quantum-safe address derivation   (what your address commits to)

Even with EIP-8141 fully deployed, a new EOA’s address remains keccak256(pubkey)[12:]. The public key is still baked into identity at birth. HCA eliminates this residual dependency.

The analogy: BIP-360’s P2MR exists in Bitcoin alongside Taproot. Taproot enabled script-path spends. P2MR provides the purpose-built quantum-safe output type that commits only to a Merkle root with no key-path spend. HCA is to EIP-8141 what P2MR is to Taproot.

What HCA solves and what it does not

Solves: Long-exposure quantum attacks — eliminated by design. No public key is ever committed to the address or exposed on-chain through address derivation. A CRQC has no key to run Shor’s algorithm against.

Does not solve: Short-exposure attacks (breaking a key during the ~12 second mempool window). Full protection against short-exposure attacks requires post-quantum signature schemes inside leaf scripts, which HCA is explicitly designed to support.

Does not require: Forced migration of existing EOAs. HCA is opt-in. All existing accounts are completely unaffected.

Urgency

This is not speculative. Government mandates exist:

  • CNSA 2.0 (NSA, 2022) — PQ migration for software by 2030, full upgrade by 2033

  • NIST IR 8547 (2024) — ECDSA deprecated after 2030, disallowed after 2035

  • Google Quantum AI (March 30, 2026) — ECDLP-256 breakable with fewer than 500,000 physical qubits in minutes. 20x reduction from prior estimates. 2029 internal migration deadline.

  • Ethereum Foundation (pq.ethereum.org, 2026) — “The work must begin well before the threat arrives.”

HCA’s migration across wallets, DeFi protocols, exchanges, and L2s will itself take years. Starting now is not early.

Design summary

Element Design
Account state One new 32-byte authRoot field alongside nonce, balance, codeHash
Address length 20 bytes (keccak256(tagged_hash("HCAAddr", auth_root))[12:]) for EVM compatibility
Domain separation BIP-340 tagged hash convention: `keccak256(SHA256(tag)
Leaf versioning 1-byte prefix per leaf for forward compatibility with PQ opcodes
authRoot rotation Via dedicated rotation leaf type — a leaf whose sole purpose is authorizing a new authRoot
Transaction type New EIP-2718 envelope with explicit from, leaf_script, merkle_proof, witness_data
Leaf execution Restricted EVM context: read-only, MAX_LEAF_GAS = 100,000, no state mutation
Gas cost Merkle proof: ~80 gas/level + 200 base. Depth-3 tree: ~440 gas (vs 3,000 for ecrecover)

Open questions for the community

  1. Does the community recognize this gap? Is there a reason the commitment structure should remain at the application layer (via CREATE2 + smart contract wallets) rather than the protocol layer (via a native account type)?

  2. authRoot rotation: Is a dedicated rotation leaf the right mechanism, or should HCA define a protocol-level SET_AUTH_ROOT opcode?

  3. EIP-7864 interaction: How should authRoot be stored given the state tree hash function is still TBD between BLAKE3 and Poseidon2? HCA’s internal tree uses keccak256 — the two trees are independent, but should they align?

  4. Timing: Is this appropriate for Hegota (H2 2026) or should HCA target a later fork?

  5. Prior art: Have I missed any proposal that addresses public key removal at the address derivation level specifically?

Resources

I welcome all technical objections, alternative approaches, and prior art references. Looking forward to the discussion.

2

Following community feedback on how EIP-8215 relates to EIP-8141, I’ve written a detailed comparison. TL;DR: EIP-8141 fixes authorization (VERIFY frame). EIP-8215 fixes identity commitment (address derives from Merkle root, not pubkey). Even with 8141, addresses still commit to a public key — that’s the layer HCA closes. Full comparison: https://github.com/eth-hca/research/blob/main/Hca_vs_eip8141.md

3

In my view yes, there is a path to achieve the same result (addresses that commit to non-ECDSA spending conditions + migration of existing addresses) in a more Ethereum-y way — and I’ll explain what I mean by that.

Let’s say EIP-7997: Deterministic Factory Predeploy is added in Glamsterdam. Here is your scheme for making addresses that commit to access control logic and don’t touch secp256k1 at all: write a contract that implements the access control you want on your account. Then, simulate deterministic deployment using the factory, and record the address it is deployed at. Now the only contract that can ever be deployed at that address is the account. This is the case regardless of quantum, of whether it’s already been deployed or the hash preimage has been revealed, anything.

I can write a code sample to show how it looks. (As an aside, we can do it today with ERC-7955: Permissionless CREATE2 Factory or Arachnid’s Deterministic Deployment Proxy. It’s effectively the same thing, just a bit less “pure” since an EOA is involved in deriving the address of the factory. And technically the second one can be frontrun)

If you want to rotate keys, there needs to be a path to do it in the smart contract in question, and you need to write something into the chain to invalidate the old keys. This is analogous to a rotation leaf as I understand it.

As far as existing accounts go, there is some work in EIP-7851: Deactivate a Delegated EOA's Key to allow disabling secp256k1. Either way it requires a protocol change.

Now regarding Ethereuminess, it comes down to minimalism and principle of least astonishment. Currently, EVM code can only be executed from the blockchain state. In HCA, we break this expectation and instead load hash-committed code from calldata. It’s surprising. Of course we can make this work, but it adds edge cases and cognitive load to the core protocol. If we can achieve the same benefits with just a super simple EIP like EIP-7997, or none at all, and standard smart contracts, we should do it instead.

Regardless, thank you for putting in all this work! IMHO this would be terrific in a UTxO-style blockchain environment, but the EVM just works differently.

4

Thanks for engaging with this seriously — this is exactly the kind of pushback I need.

You’re right that CREATE2 can produce addresses that don’t touch secp256k1. I won’t pretend otherwise. But I think “same result” understates the gap. Let me explain what I mean concretely.

Condition privacy. This is the big one. Say I set up an account with 8 spending paths: daily key, recovery key, 2-of-3 multisig, timelock, hardware wallet, social recovery, dead man switch, and a future PQ leaf. With HCA, when I spend using my daily key, the chain sees only that one leaf and its Merkle proof. The other 7 paths remain completely hidden — nobody knows they exist, what logic they contain, or how many there are. With a CREATE2 wallet, the entire contract code is deployed on-chain and publicly readable. Everyone can see every spending path, every condition, every fallback. You can’t selectively reveal one path without exposing the whole thing. This isn’t a minor difference — it’s a fundamental property that smart contracts can’t replicate without something like MAST, which is basically what HCA is.

State cost. A smart contract wallet is code + storage slots. Even a minimal one is a few KB. HCA adds 32 bytes (the authRoot) to the account object. The tree metadata lives client-side. At 100M accounts this gap is enormous. And with statelessness on the roadmap, smaller account objects matter more, not less.

No infrastructure dependency. CREATE2 wallets need the ERC-4337 stack to work as first-class accounts — bundlers, entry point contract, paymasters. HCA validates at the protocol level. The from field is explicit in the transaction, no ecrecover, no bundler. It works like an EOA from the user’s perspective.

On “surprising”: Fair point, and I take it seriously. But EIP-7702 already introduced “set code on an EOA from an external source.” The direction Ethereum is heading — flexible code sources, not just state-resident code — is consistent with what HCA does. It’s a new pattern, but not an alien one.

On “Ethereum-y”: This is your strongest argument and I respect it. Minimalism is real. My honest position: if the commitment structure lives at the application layer (CREATE2 + 4337), you get quantum-safe addresses but you lose condition privacy and you pay the state cost. If it lives at the protocol layer (HCA), you get both. Whether that tradeoff justifies a new account type is a design philosophy question and I think reasonable people can disagree.

I’d genuinely welcome the code sample you offered — comparing a CREATE2 wallet flow against HCA’s flow side by side would make this way more concrete for everyone reading.