Here is what it does on most of them. Your BTC becomes an ERC-20 token. To move it you sign with an EVM private key. The UTXO is gone, the multisig policy you configured is gone, the Taproot script path you set up is gone. What you hold is a balance in a contract's mapping, and what proves you own it is a secp256k1 signature over an Ethereum-format transaction.

That is not a smaller version of Bitcoin ownership. It is a different kind of object. The proof of ownership changed species: from "I can produce a witness satisfying this script" to "I hold this private key."

For a trader moving size in and out, that trade is fine and probably correct. For anyone holding BTC because of what Bitcoin ownership specifically is — a self-custody position with a script policy they chose — it is the whole ballgame, and it is the reason a great deal of Bitcoin has never touched an L2.

Why this keeps happening

Not because L2 teams are careless. Because of an account-model constraint that is easy to miss.

An EVM chain has one account type and one signature scheme. When BTC arrives, there is nowhere to put it that preserves its structure — the chain has no representation for a UTXO, no interpreter for Bitcoin script, and no way for a Bitcoin signature to authorize anything. So BTC gets converted into the only shape the chain can hold: a token balance keyed to an EVM address.

This is a structural limitation, not an oversight. An EVM L2 cannot adopt Bitcoin ownership semantics without changing its own account model, which is the one thing an L2 with users cannot do.

What we kept

ACE verifies real Bitcoin transactions against its own UTXO state. Not a Bitcoin-flavoured abstraction — actual transactions, actual script templates: P2PKH, P2WPKH, P2WSH multisig, three P2SH forms, and P2TR both key-path and script-path. Legacy and segwit SIGHASH_ALL, Taproot SIGHASH_DEFAULT and SIGHASH_ALL, including multi-input spends with mixed owners.

Which means the signing device stays your Bitcoin wallet. Our wallet crate never selects coins and never signs — it specifies and validates the two outputs that make a deposit claimable, and Bitcoin Core, Sparrow or a hardware wallet funds and signs the PSBT. Your existing setup, your existing policy, your existing key management.

Denomination stays satoshi throughout, decimals fixed at eight, with exact-satoshi minting on deposit. Nothing gets re-based into an 18-decimal token and rounded.

And canonical oBTC converts atomically between three representations — an account balance, a BVM UTXO, and order-book collateral — through an escrow account, with the represented amount tracked separately so that a synthetic UTXO is a representation and never a second mint. Total supply is unchanged by conversion. You can hold BTC in UTXO form, move it into an order book to trade, and come back, without it becoming a different asset in between.

The part that is not about ownership

Preserving the ownership form is worth nothing if the BTC behind it is not really there. That is a separate problem and it deserves separate treatment.

Deposits are permissionless. The chain runs a Bitcoin light client in consensus state: headers, chainwork, proof-of-work, difficulty retarget, median-time-past, reorg handling and confirmation depth. It anchors at a checkpoint rather than replaying from genesis, and finalized heights go into an immutable height-to-hash index so a finality check is O(1) — which matters because anyone can submit an SPV proof, and a permissionless entry point that walks ancestors is a denial-of-service surface. Nobody takes a relayer's word for a deposit.

Three thresholds stay separate. The relayer quorum that decides whether ACE accepts external testimony, the vault threshold that decides who can spend real BTC, and the capability committee that admits raw-chain transactions are distinct sets by design, and the design documents say so as prohibitions rather than preferences. Bridge losses repeat across this industry for one recurring reason: thresholds that should be independent get quietly merged, usually for operational convenience.

The signer is isolated. FROST Taproot threshold signing runs in its own process. Node and relayer never load a key package. The nonce session journal is append-only and fsync-backed, and a failed round burns its nonce anyway — because nonce reuse is the classic way threshold signature schemes leak keys, and "we'll be careful" is not a mitigation.

Reserves are checkable by outsiders. The invariant is explicit: spendable vault reserve covers circulating oBTC plus pending withdrawal liabilities, with miner fees, unconfirmed change and operator advances in separate accounting lines rather than folded in to make the numbers work. A separate read-only monitor checks solvency continuously and depends on nothing the bridge operator controls.

Controls ship closed. Deposit, withdrawal-request and signing are three independent pause switches, and their default state is all paused with a TVL cap of zero. The bridge does not open because it was deployed. It opens because someone explicitly opened it.

The exit, honestly

The strongest version of a Bitcoin L2 claim is that you can leave without anyone's cooperation. We do not have that yet, and it is important not to blur it.

There is a BitVM2 and ZK-ACE exit prototype. An operator fronts a finalized withdrawal from their own Bitcoin liquidity and recovers from a dedicated vault only against a proof binding the ACE state transition, the finality certificate, a graph-pinned validator quorum above two-thirds of stake, the immutable withdrawal record, the exact recipient script, and the confirmed Bitcoin payout with its inclusion path. There is no "verifier returned true" escape hatch anywhere in the crate, every claim binds immutable public inputs and a versioned transaction-graph commitment, and the upstream compiler commit is pinned — upgrading it produces a new program, a new graph ID and a new vault version that must repeat setup and audit.

The exit accumulator is worth a sentence on its own, because it is the design decision that makes the rest tractable: the withdrawal lifecycle is committed into four fixed storage leaves, so the prover proves the bridge transition without replaying unrelated VMs. Smaller statement, smaller proof, smaller audit surface.

What is missing is the part that matters: the n-of-n presigning ceremony has not been performed by real participants, and none of it has been audited. BitVM2's security rests entirely on that ceremony. Until it is done, the trust-minimized exit path does not exist — it is a prototype of one.

So the accurate description today is a federated Bitcoin sidechain with a BitVM2 and ZK-ACE exit prototype. Not "inherits Bitcoin's security." Not "users can always force an exit." Withdrawal liveness currently depends on a threshold of vault signers being willing to sign, and saying otherwise would be the kind of claim this industry has been punished for before.

Other things we are not claiming

This is a template subset, not a Bitcoin consensus verifier. We do not verify block inclusion for arbitrary transactions, do not do chain selection, and do not implement full script semantics. Arbitrary legacy templates, Taproot annex handling and non-ALL sighash flags are out of scope. The goal was accepting standard wallet transactions, not reimplementing Bitcoin.

Hardware wallet compatibility needs to be demonstrated, not asserted. We implement the sighash correctly and the PSBT policy is defined. Whether a specific Sparrow or Ledger flow works end to end is a testing question with a testing answer, and we have not published those results. Anyone deciding based on "should work" is deciding on less than they think.

Peg-in still waits for Bitcoin. Sub-second finality on ACE is ACE's finality. It is not Bitcoin's, it never will be, and a deposit still waits for confirmations.

What is actually different

Not "faster and cheaper with smart contracts." Every BTC L2 says that and the phrase has stopped carrying information.

The difference is that BTC changes execution environment without changing ownership form. Your Bitcoin wallet stays the signing device. UTXOs, multisig and Taproot survive. Reserves are proven by the chain rather than attested by a relayer, and the parties who could move them are separated by design rather than by policy.

That removes the single largest objection Bitcoin capital raises about every L2, and it lets institutional custody keep the signing and key-management setup it already has — which, for anyone who has watched a custody team evaluate a new chain, is most of the decision.

The rest of the pitch is still ahead of us: the ceremony, the audit, the adversarial drills on signet. Until those are done, this is a developer preview with an unusually careful architecture, and that is exactly how we describe it.

Bitcoin L2 design and its release gates are documented in the repository. Related: ZK-ACE (arXiv:2603.07974), n-VM (arXiv:2603.23670).

Every shielded transaction ever made is sitting on a public ledger right now, waiting.

That sentence is not a warning about some future protocol failure. It is a description of the present. Blockchains are append-only and public by construction, which is the property that makes them useful and also the property that makes them a perfect archive for an adversary who is patient. The ciphertext is already collected. The only missing input is the machine.

This is the ordinary "harvest now, decrypt later" argument, and most people in this industry have heard it enough times to stop listening. But it is usually made about transparent chains, where it lands weakly: a Bitcoin transaction is already public, so a future quantum computer reveals nothing about it that anyone cannot read today. The real exposure there is key recovery from published public keys — serious, but a different problem with different mitigations.

Applied to shielded pools, the same argument lands very differently. Here the whole point of the construction is that some facts stay hidden. Amounts. Counterparties. The link between an input and an output. Those facts are protected by cryptography that is recorded, permanently, alongside the thing it protects.

Two failures, and only one of them is prospective

It is worth being precise about what a cryptographically relevant quantum computer would do to a shielded pool, because the two failure modes have very different shapes.

Soundness fails forward. A pool whose proof system rests on pairings or on discrete log — Groth16, PLONK-family constructions, Halo 2's inner product argument — loses soundness against a quantum adversary. That adversary can forge a proof and mint notes that were never shielded. This is catastrophic for the pool's solvency, but it is a prospective failure. It happens from that day forward. The response is a migration: freeze the pool, change the proof system, drain under supervision. Painful, coordinated, survivable.

Confidentiality fails backward. Note encryption in the Sapling lineage — and in most designs derived from it — establishes a shared secret by elliptic-curve Diffie-Hellman between an ephemeral key published in the transaction and the recipient's key. Recover that shared secret and the note plaintext opens: amount, recipient, memo. A quantum adversary does not need to be present when the transaction is made. It needs only the transaction, which is on the chain forever.

So the entire recorded history of the pool becomes readable. Not "the pool stops being private." Every payment ever made through it becomes legible, retroactively, to anyone holding a copy of the chain.

There is no migration that fixes this. You cannot re-encrypt data that has already been published. The moment a pool's note encryption is broken, its history is broken with it, including transactions made a decade earlier by people who have since died, sold the business, or settled the lawsuit the payment was about.

That asymmetry is the whole argument. Soundness you can fix by moving. Confidentiality you cannot fix at all.

Who this actually matters to

Not, mostly, to the people who use shielded pools today.

If you are shielding to break the link between two of your own addresses, the ten-year horizon is irrelevant. By then the amount is stale, the counterparty is public knowledge, and nobody is going to fund a quantum computer to learn what you paid for in 2026.

It matters to the flows whose confidentiality has a long half-life. Payroll, where the sensitive fact is a salary structure that persists across years. Supplier settlement, where unit prices are the negotiating position for the next contract and the one after that. Treasury operations, where position sizes reveal strategy. Intercompany transfers that establish transfer-pricing history. Anything touching a merger before it is announced. Anything a regulator will look at in seven years and a competitor would pay for today.

These are the flows that an institution would move on-chain if it could, and they are precisely the flows for which "private until roughly 2035" is not a product.

What we did about it

ACE Chain's confidential notes are a dual-mode design: transparent balances are the default, confidential notes are opt-in, and both live on the same account. The privacy properties are conventional — a transfer hides its amounts and hides which notes it consumed and created. What is not conventional is what those properties rest on.

Proofs are hash-based. ZK-ACE proves with a Circle STARK over the Mersenne-31 field. There are no pairings and no discrete-log assumption anywhere in the soundness argument. A quantum adversary cannot forge a proof and mint notes that were never shielded.

Note envelopes are hybrid. Encryption uses X25519 combined with ML-KEM-768. Recovering a note requires breaking the post-quantum half as well, which is the point of a hybrid: it is no weaker than the classical scheme against a classical adversary, and it does not fall to a quantum one.

Neither of these was extra work. Both fall out of choices made elsewhere in the system for unrelated reasons — the STARK backend exists because ACE wanted a setup-free proof system for authorization compression, and the hybrid KEM exists because the wallet layer is post-quantum throughout. The privacy property is a consequence, not an initiative.

It is still worth stating plainly, because it is a checkable technical fact rather than a claim about a roadmap, and because it is the one privacy property this design has that the established pools do not.

The second problem: disclosure is all-or-nothing

A shielded pool that cannot be audited is unusable by anyone who answers to someone else, which is most institutions. So every serious design ships some form of viewing key.

The standard construction gives you a key that decrypts incoming notes, or a fuller one that decrypts everything. Both share two properties that are rarely examined: they are unbounded in time, and they are handed over rather than derived.

Unbounded in time means that disclosing one quarter to an auditor discloses every quarter — past and future, from key creation until the end of the account. That is not a disclosure. It is a surrender. An institution that needs to satisfy a regulator about Q3 does not want to hand over Q1, Q2, and everything it does in Q4.

The natural fix is to bound the key to a period. On most chains this is structurally unavailable, and the reason is worth spelling out: where the key is the identity, bounding a viewing key in time means moving funds. The viewing capability derives from the same secret that owns the notes, so to change what a viewing key can see you have to change which secret owns them — and moving notes to a new owner is a transaction, on a public ledger, that surfaces exactly the balance information the pool exists to hide. The cure administers the disease.

ACE separates identity from authorization at the account layer, and that separation reaches into the note design. Note ownership binds to a period viewing commitment rather than to the root secret. The viewing branch can rotate without a single note moving. Disclosing one period therefore discloses that period and nothing on either side of it.

Three properties follow, and each is structural rather than promised:

Boundedness. Viewing keys are per period. One period opens; its neighbours stay closed.

Completeness. The auditor derives the receiving addresses themselves and scans the chain. The discloser never hands over a list, so there is no list from which to omit an inconvenient note. A disclosure whose contents are chosen by its subject is worth nothing to the party relying on it — and most viewing-key workflows in practice are exactly that, because the subject exports the transaction set.

Non-spendability. Viewing and spending derive from different domains with no path between them. A viewing key cannot authorize a spend even if its holder is hostile. An auditor is not a threat to custody.

A smaller thing, but a nice one

Multi-asset shielded pools face a choice about whether to reveal which asset a transfer moves. Revealing it splits the anonymity set: shielded BTC only ever mixes with other shielded BTC, and a pool with five assets is five smaller pools wearing a trench coat.

The established answer is blinded asset tags — Liquid and Zano do this, and Namada's MASP achieves the same effect through per-asset value commitments. It works. It also rests on discrete log, which would forfeit exactly the post-quantum confidentiality described above.

ACE hides the asset by omission instead. A transfer never touches a transparent ledger, so it has no reason to name what it moves: the statement names nothing, and the circuit proves every note in the spend carries one asset without revealing which. An unshield must name its asset, because consensus credits that specific ledger — the same reason its amount is public.

Same property. No group assumption. It costs nothing and assumes only the hash.

What this design does not do

A privacy article that only lists strengths should not be trusted, so here is the other half.

The spender is not hidden yet. Every private operation is currently signed by an identified account, so an observer learns that account X transacted at height H. This is the largest remaining gap, and it is one where the established pools are ahead — Zcash hides the spender and has for years. The fix is known and is the same one Zcash uses: let the note proof be the authorization, since the circuit already proves knowledge of the spending key. It needs an admission path that accepts a credential-less transaction, which is node plumbing rather than circuit design. It is not done.

Arity leaks. The public statement carries no input or output counts, but the unused slots are visibly zero, so the shape of a spend is readable. Hiding it requires indistinguishable dummy notes. The layout was designed so that adding them later changes neither the statement nor the verifying key, but they are not there today.

Entry and exit are public. Shield and unshield carry a public amount and an identified transparent counterparty. Value that enters and leaves without resting in the pool gains nothing. Privacy begins at the first transfer.

The anonymity set is empty. This is the honest one. Privacy is a function of set size, and a pool that has not launched has a set of zero. The first several hundred transactions through any new shielded pool have privacy that rounds to nothing regardless of how good the cryptography is. Zcash's advantage here is years of accumulated shielded activity, and no amount of design closes that gap — only usage does.

It is not shipped. Consensus surface, wire types, statement derivation, Poseidon2 encodings, Merkle paths and value conservation are implemented. The controls are fail-closed and the pool is shut. The prover exists and the AIR is being debugged against a real trace, row by row — a process that has already surfaced genuine defects, including a limb-encoding mismatch and a conservation carry model that could not represent a borrow. Release is gated on an independent circuit audit and a public bounty period. Anyone telling you a confidential pool is ready before those two things have happened is telling you something else.

The claim

Not that this is the most private pool. On spender anonymity it is behind, and on anonymity set size it is behind by definition.

The claim is narrower and, we think, more useful: the established pools protect today's privacy, and this one is built to protect it in 2050. For most users that difference is theoretical. For payroll, supplier settlement, treasury operations and anything a regulator will examine years after the fact, it is the only difference that matters — because those are the flows where the confidentiality has to hold for longer than the cryptography underneath it currently will.

Shielded pools have a shelf life. Most of the ones in production have not priced theirs.

ACE Chain is a post-quantum Layer-1 built on identity–authorization separation. The confidential-note protocol, including the design decisions still open, is documented at docs/private-note-protocol.md. Related papers: ZK-ACE (arXiv:2603.07974), ACE-Runtime (arXiv:2603.10242), ACE-GF (arXiv:2511.20505).

A chain cannot stop someone noticing that an asset trades at different prices in two venues. That is arbitrage, it predates blockchains, and removing it would mean removing price discovery.

What a chain can address is narrower and more specific: the block producer's unilateral discretion over insertion, reordering and omission within a block it is building. That discretion is what turns a public mempool into a source of extraction. It is the part that is structural rather than economic, and it is the only part worth arguing about.

What the existing answers actually do

Each of these is a serious piece of work by serious people. The point is not that they fail — it is that they each relocate the problem to a different place, and it is worth being precise about where.

Commit-reveal. Users commit to a hash first and reveal later, so the producer cannot see transaction contents when choosing order. This hides what. It does not establish who may commit — any party can flood the commitment set with hashes it never intends to open, which is commitment stuffing, and a producer that also stuffs can shape the admissible set before anyone reveals anything.

Threshold encryption. Transactions are encrypted to a committee that decrypts after ordering is fixed. Stronger, and deployed in production. It introduces a trusted decryption committee, a decryption round-trip in the latency budget, and a collusion surface between the producer and that committee. The trust did not disappear; it moved from the producer to the committee plus the producer.

Fair-ordering oracles. An external service attests to arrival order. This shifts the honest-witness requirement to the oracle layer and adds its latency. The producer's discretion is constrained by someone else's discretion.

Proposer-builder separation. The dominant answer in practice. Builders compete to construct blocks and bid for the right to have theirs proposed. This is genuinely valuable — it decouples block construction from validation and it makes the extraction competitive rather than monopolistic. But note what it does to the extraction itself: it redistributes it. The builder still reorders. The proposer gets paid a share through the auction. The user still gets the worse fill; the proceeds are simply split differently upstream of them.

The pattern across all four is the same. Each one moves the discretion somewhere else — to whoever can stuff the commitment set, to the decryption committee, to the oracle, to the builder. None of them removes it, and the user's fill does not know the difference.

The gap nobody closes

Look at what all four lack, and the shape of the missing piece becomes clear.

None authenticates admissibility. There is no notion of which commitments the protocol is obliged to consider. Without that, "the producer must include everything admissible" is not a rule anyone can enforce, because there is no agreed set to compare the block against.

None makes omission provable. If a producer simply leaves your transaction out, you have a complaint and no evidence. Omission is invisible: an absent transaction looks identical to a transaction that was never submitted. A fault you cannot prove is a fault you cannot slash, and a fault you cannot slash is not deterred.

Call this the authenticated-admissibility gap. It is what permits commitment stuffing, selective non-opening and unprovable omission to survive every mitigation above.

Closing it

MEV-ACE is a single-slot fair-ordering protocol that ACE enforces at the block-validity layer. Four phases:

Register, off the slot's critical path. A user derives a dedicated authentication key from their identity root under an isolated context, publishes an identity commitment, and bonds slashable stake. Sybil resistance comes from the bond and a per-identity commitment quota — four by default — rather than from the cost of making a wallet.

Commit. The user broadcasts a signed commitment. Validators verify it and issue receipts. A commitment becomes admissible only once it has collected a threshold receipt bundle: q_c ≥ 2f+1, with f = (n−1)/3 taken directly from ACE's own validator set. Stuffing is bounded by the quota, and admissibility is a fact that any validator can check rather than a producer's opinion.

Order. The producer Merkle-roots the sorted admissible set, and only then computes a verifiable-delay function over the previous hash, that root and the slot number. The resulting seed drives a Fisher–Yates permutation.

Open. Users reveal. Openings clear the same receipt threshold. The producer must execute every certified opening in the permuted order.

The sequencing in phase three is the load-bearing part and it is easy to skim past. The VDF's mandatory sequential delay means the seed cannot be known until after the admissible set is locked. A producer therefore cannot compute the final order and then decide which of its own commitments to open — which is exactly the attack that a naive commit-reveal with a predictable ordering rule permits. Order-unpredictability is not a property of the shuffle; it is a property of when the shuffle's input becomes computable.

And because both commit and open certificates carry ≥ 2f+1 validator signatures, a transaction holding both has an inclusion obligation that is portable. If the producer omits it, the holder assembles those two certificates into an omission proof that any validator verifies independently. Omission stops being an ambiguous economic behaviour and becomes a protocol-detectable fault with an owner.

Where it lives matters

MEV-ACE is enforced in consensus. Validators process the commitment, opening and receipt messages; proposers build from certified executable openings; block headers commit to the producer-signed ordering material; and validators reject blocks whose material, VDF proof, admissible set, executable set or transaction order does not verify.

That is a different kind of guarantee from a relay network that a proposer may or may not opt into. There is no version of an ACE block that skips fair ordering while remaining valid.

The protocol state machine itself is an external crate — dependency-light, no_std-friendly, pinned by commit — and ACE keeps a thin adapter that maps its own consensus types onto that crate's trait surface without duplicating the logic. That is deliberate: the protocol can be specified, audited and versioned independently, and the chain's blast radius stays contained. It also means the algorithm registry maps through, so ML-DSA-44 and Ed25519 are both first-class for commitments and receipts. The fair-ordering layer is post-quantum for the same reason the rest of the chain is.

What this does not do

Our delay function is not production-grade. The devnet adapter is deterministic and cheap — suitable for wiring and tests, and explicitly labelled in the source as something a production deployment must replace with a calibrated sequential-delay implementation. Until that lands, order-unpredictability rests on an assumption we have not yet earned. This is the honest gap in what is otherwise a complete integration.

It constrains admitted transactions only. External arbitrage between ACE and a centralised venue is not touched, and no chain-level mechanism can touch it. What is removed is block-local manipulation of transactions the chain has admitted. That is a real reduction in the surface that makes sandwiching and front-running possible; it is not the elimination of MEV as an economic phenomenon, and anyone claiming otherwise is selling something.

Retrofitting this elsewhere means a hard fork. Block validity rules are the thing being changed. That is achievable — it is genuinely in the category of things another chain could do — but it is a consensus change, not a service anyone can layer on.

The bond is a barrier. Registration requires stake. That is what makes the quota meaningful and the slashing credible, and it also means participation is not free. We think it is the right trade for a fair-ordering guarantee. It is still a trade.

The claim

Ordering MEV is a regressive tax: value that ordinary users and liquidity providers lose, captured by parties positioned to see the pending set, leaking out of the protocol entirely. The mitigations in production have made it more competitive and more transparent without making it smaller from the user's side of the trade.

The difference worth arguing for is not "less MEV." It is that the producer's discretion over admitted transactions is removed rather than relocated, and that its abuse becomes something you can prove rather than something you can only suspect.

For a trader, that shows up as a fill that was not pre-taxed. For a market maker, it is one less adverse-selection term in the spread. For a wallet or an aggregator, it is a best-execution claim that survives being asked to justify itself.

Order flow is mobile. It goes where the fills are better.

MEV-ACE: arXiv:2604.07568. The consensus-side integration is in ace-consensus/src/mev_ace.rs; the protocol state machine is the external mev-ace-core crate.

ML-DSA-44 signatures are 2,420 bytes. Ed25519 signatures are 64. Verification is materially heavier. Therefore post-quantum cryptography costs throughput, and chains will adopt it when the cost comes down or when they are forced.

Every clause in that paragraph is true. The conclusion does not follow.

Signature size and verification cost are engineering problems, and engineering problems get solved by engineering. We can put a number on it: on the same chain configuration, our devnet sustains about 574 TPS under full ML-DSA-44 and about 582 under Ed25519. A three-node BFT devnet running on a single MacBook Pro M3 held 507 sustained TPS with post-quantum signatures throughout and no consensus stalls. That is not a degraded security mode. It is the same throughput class.

We did not achieve that with a clever signature scheme. We achieved it by not putting the expensive work on the dominant path — verify the credential once at admission, carry preverified state through the mempool, batch and parallelise at execution. Ordinary systems engineering.

So if the performance gap is closable, why has nobody migrated?

Because the address is the public key

On Bitcoin, an address is a hash of a public key. On Ethereum, it is the last twenty bytes of the hash of one. On Solana, the address is the public key. Every major chain hardcodes one signature algorithm into the account model itself.

This has a consequence that has nothing to do with performance: changing the signature algorithm changes the address.

Not "requires a software update." Changes the address. Which means post-quantum migration is not a cryptography deployment, it is an asset migration — every holder must move every asset to a new address derived from a new key under a new algorithm. And every system that ever recorded an address must learn the new format: wallets, block explorers, indexers, exchanges, custodians, accounting systems, the CSV your finance team exported in 2021, the smart contract with a hardcoded address that nobody can upgrade.

Now add the part that makes it genuinely unpleasant.

To move an asset to a quantum-safe address, you sign a transaction with the quantum-vulnerable key. On Bitcoin, spending from a P2PKH output publishes the public key that was previously only known by its hash. The migration transaction is the single moment of maximum exposure for that key — and it must happen for every UTXO, for every holder, in a window when everyone knows migration is underway and an adversary knows exactly where to look.

Chains with lost keys have it worse: those coins cannot be migrated by anyone, ever, and their public keys are already exposed. Chainalysis puts north of $140 billion of Bitcoin in permanently lost wallets. Whatever the true figure, none of it can move to safety.

This is why the timeline is measured in years of governance rather than months of engineering. NIST and CNSA 2.0 put the migration window at 2027–2035. That is not how long the cryptography takes. It is how long the coordination takes.

The patch, and what it costs

The standard answer on Ethereum is account abstraction: put the verification logic in a contract, and the contract can check whatever signature scheme it likes.

It works. It is a real answer and dismissing it would be dishonest. But price it:

Every transaction becomes a contract call, which costs gas and latency on every operation forever, not once. The account's security now depends on the contract's code, which is a new attack surface that did not exist when the account was a keypair. And it is not universal — externally owned accounts remain externally owned accounts. The default account type on the largest smart-contract chain stays quantum-vulnerable no matter how good the abstraction layer is, because nobody can force an upgrade on an account whose owner is not paying attention.

So the patch protects the users who act, at a permanent per-transaction cost, and leaves everyone else where they were.

What we changed

ACE derives the account address from an identity commitment — a 32-byte value — rather than from a public key. The signing algorithm is a credential bound to that identity, not the thing the identity is made of.

Concretely: a single byte on the wire selects the algorithm. Zero is Ed25519, one is Secp256k1, two is ML-DSA-44 (NIST FIPS 204), three is HMAC-SHA256. All verification flows through one dispatch point. The execution layer never branches on the choice — it receives an authenticated identity and nothing else.

Three things follow, and they are worth separating because they are usually conflated.

Adopting PQC is an account-level write. The address does not change. No assets move. There is no migration transaction, therefore no moment of maximum exposure, therefore no coordination window during which an adversary knows where to look. A user rotates a credential the way they would change a password.

Every VM inherits it. Because the post-quantum path sits in the authorization layer rather than inside any execution engine, an EVM contract call, a Solana-style program invocation and a Bitcoin script operation can all be authorized with ML-DSA-44 — without those ecosystems changing anything. Whether the user signed with Ed25519 or ML-DSA-44, the EVM engine resolves the same msg.sender. Ethereum's transaction format hardcodes (v, r, s) into its RLP structure; ours does not, because ours never assumed one algorithm.

Existing wallets keep working. Chain-native transactions from MetaMask or Phantom run alongside ACE-native post-quantum transactions, and both paths resolve to one account with one balance. A user can transact normally day to day and sign the same contract call under post-quantum protection when the amount justifies it. The choice is per transaction.

The part that cannot be copied

Everything above could be designed into a new chain by anyone who wanted to. We are not claiming an invention; identity–authorization separation is a fairly natural idea once you notice the problem.

The claim is narrower: it cannot be retrofitted.

A live chain adopting this would have to redefine what every address already issued means. Not add a new address type alongside the old one — that just gives you two account systems and the old one is still quantum-vulnerable — but change the semantics of accounts that already hold value and already appear in a million external systems. There is no governance process that produces that outcome, at any price, on a chain with real assets on it.

Which is why the interesting question about post-quantum readiness is not "which chain will adopt it first." It is "which chains were built after the problem was understood."

What this does not solve

Chain-native transactions keep classical security. If a user submits a raw Ethereum-format transaction signed with secp256k1, that transaction has secp256k1's security properties. We do not silently upgrade it, and we should not pretend otherwise. Post-quantum authorization applies on the ACE-native path, which is a choice the user makes.

We had the luxury of designing it in. This is not a strategy that Ethereum could have adopted; it is an advantage of arriving later, and arriving later has its own costs that show up in every other column of the comparison. A new chain has no users, no liquidity and no track record. We are trading those for architectural freedom, and it is not obvious that is a good trade until it is.

ML-DSA-44 is a selection, not a certainty. It is the NIST standard and it is what we ship. But the whole point of the design is that we do not have to be right about which algorithm wins — if ML-DSA-44 is broken or superseded, adding its replacement is a new tag byte and a new backend, not a migration. That property is what we are actually defending, more than the specific choice.

Throughput figures are devnet figures. End-to-end system measurements on a controlled configuration, not mainnet under adversarial load. They demonstrate that primitive verification latency is not the dominant bottleneck in this pipeline. They do not demonstrate what happens at scale, and anyone quoting them as a mainnet number — including us — would be overreaching.

The thing to take away

The industry has spent a decade treating post-quantum migration as a cryptography problem, and cryptographers have largely solved their half: the algorithms are standardised and the implementations are available in pure Rust that builds for WASM.

The unsolved half is that we built account systems where the address is a function of the public key, and then put trillions of dollars behind them. That decision was made when a signature algorithm looked like a permanent choice rather than a temporary one.

Cryptography has a shelf life. Accounts should not. What has to survive an algorithm change is the account — and on every chain where the address is the public key, it cannot.

ACE Chain is a post-quantum Layer-1 built on identity–authorization separation. Papers: ACE-GF (arXiv:2511.20505), ZK-ACE (arXiv:2603.07974), ACE-Runtime (arXiv:2603.10242). Devnet throughput methodology is documented in the repository.

The post-quantum transition is coming for blockchains — and the naive path forward is quietly catastrophic.

When NIST finalized ML-DSA (formerly Dilithium) and SLH-DSA as the post-quantum signature standards, the blockchain community breathed a sigh of relief. Just swap Ed25519 for ML-DSA and you're quantum-safe. Simple.

Except it isn't. An ML-DSA signature at NIST security level 2 is approximately 2.4 kilobytes. An Ed25519 signature is 64 bytes. That's a 37× blowup — per transaction, permanently, on every full node, in every rollup blob, across every chain that makes the switch.

At any meaningful throughput, this isn't an upgrade. It's a scalability crisis masquerading as a security fix.

The "Just Use ZK" Trap

The obvious workaround: compress the signature verification into a zero-knowledge proof. Instead of posting a 2.4KB ML-DSA signature on-chain, post a succinct ZK proof that attests to a valid signature. The blockchain verifies the small proof, never seeing the signature itself.

This sounds clean. The problem is that lattice-based signature schemes — the mathematical foundation of ML-DSA — are deeply hostile to ZK circuits. Verifying a lattice signature requires arithmetic over high-dimensional polynomial rings, NTTs, and non-native modular reductions. When you try to express that inside a ZK constraint system, you end up with circuits on the order of millions of constraints per transaction.

You've relocated the scalability burden from on-chain bandwidth to off-chain proving cost. The signature is gone from the chain, but the wallet now has to run an expensive prover for every transaction. You've traded one problem for another — and left the underlying architecture untouched.

A More Fundamental Question

This is where ZK-ACE starts with a different question entirely.

Does a blockchain actually need to verify a signature object?

At the consensus layer, what validators need to know is: was this transaction authorized by the correct identity? That's a semantic property — a statement about who approved what. A cryptographic signature is one way to express that property, but it's an implementation artifact, not the thing itself.

Traditional blockchain design conflates the two. Signatures are the mechanism by which authorization is expressed, so they become the unit of verification. This coupling drags all of the signature scheme's costs — key sizes, signature sizes, verification complexity — directly into the protocol.

ZK-ACE decouples them.

What ZK-ACE Actually Does

ZK-ACE (Zero-Knowledge Authorization for Cryptographic Entities) replaces signature objects with identity-bound zero-knowledge statements.

The core idea rests on a primitive called a Deterministic Identity Derivation Primitive (DIDP). A DIDP takes a 256-bit secret root — the Root Entropy Value (REV), essentially the identity root that lives only ephemerally in memory — and deterministically derives cryptographic keys for any algorithm and context. Given the same root and context tuple, you always get the same key. The root itself is never stored or transmitted.

From this foundation, ZK-ACE defines a simple on-chain state: for each identity, the chain stores a single compact identity commitment — a hash of the identity root, a salt, and a domain. That's it. No public keys. No signature verification keys. No algorithm-specific material.

When a user authorizes a transaction, they don't produce a signature. Instead, their wallet generates a zero-knowledge proof that attests to the following statement:

I know a secret root REV such that: (1) H(REV‖salt‖domain) equals my registered identity commitment, (2) the key derived from REV for this transaction context matches the expected authorization material, and (3) I committed to this specific transaction hash — not any other.

The chain verifies the proof. No signature object is ever produced or verified on-chain. Authorization validity is established entirely through the correctness of the ZK proof and its binding to the committed identity and transaction.

Why This Works So Well

The ZK circuit underlying ZK-ACE is remarkably small — because it contains no signature verification logic at all. The circuit only needs to prove knowledge of a preimage under a ZK-friendly hash function (like Poseidon) a small number of times. No lattice arithmetic. No NTTs. No high-dimensional polynomial reductions.

The result in numbers:

• Circle STARK backend (post-quantum-oriented, transparent setup): 341 active rows, 361 AIR constraint expressions, 14.5 ms to prove, 1.1 ms to verify, ~107 KB proofs

• Groth16/BN254 backend (compact classical proofs, EVM-compatible): 2,155 R1CS constraints, 37.3 ms to prove, 1.6 ms to verify, 128-byte proofs

For comparison: verifying an ML-DSA signature inside a ZK circuit requires on the order of hundreds of thousands to millions of constraints. ZK-ACE achieves a 500–2,300× reduction in constraint count relative to in-circuit post-quantum signature verification.

Under a mandatory per-block STARK aggregation model, the per-transaction consensus-visible footprint is approximately 160 bytes — smaller than most classical signature schemes today, and independent of whatever post-quantum algorithm the identity uses internally.

The Deeper Significance

ZK-ACE is post-quantum-ready by design. The identity commitment is proof-system-agnostic: it's just a hash. The ZK circuit contains no algorithm-specific logic. When better proof systems emerge — faster STARKs, more efficient hash functions, recursive aggregation — the authorization layer upgrades without rotating identities or redesigning circuits.

This is architecturally significant. Every other approach to post-quantum blockchain authorization couples the protocol to a specific signature scheme. ZK-ACE doesn't. The chain commits to an identity, not to a key type.

There's also a privacy property that comes for free. Because no signature object is ever posted, and the ZK proof reveals nothing beyond the authorization statement, transaction linkage attacks based on public key correlation become structurally harder. The commitment model separates what's known on-chain (the identity anchor) from what's derived in practice (the per-context keys).

What This Means for the Post-Quantum Transition

The conventional roadmap for making blockchains quantum-safe looks like: pick ML-DSA, update the signature field, accept the overhead, move on. ZK-ACE argues this roadmap is solving the wrong problem.

The overhead isn't an accident of parameter choices or implementation quality. It's structural — it comes from placing signature verification at the center of the authorization model. The only way to eliminate it is to replace that model entirely.

ZK-ACE provides the replacement: a formal authorization framework with game-based security proofs (authorization soundness, replay resistance, substitution resistance, cross-domain separation), a circuit small enough to prove in tens of milliseconds on commodity hardware, and an on-chain footprint that is smaller than classical signatures — while being architecturally ready for a world where quantum computers exist.

Post-quantum blockchains don't need bigger signatures. They need a different theory of what authorization means.

ZK-ACE is described in full in arXiv:2603.07974. The reference implementation includes both a Circle STARK backend (post-quantum-oriented, transparent setup) and a Groth16/BN254 backend (EVM-compatible), with Criterion.rs benchmarks for the unified replay-circuit path.

This article examines five industry-level problems, explains why a paradigm reconstruction is necessary, and describes how ACE Chain uses identity-authorization separation as a foundational breakthrough to unlock the solution space for all five simultaneously.

I. Five Persistent Problems

1. The Identity Model: Public Key = Identity, Structurally Locked

BTC, ETH, Solana — every existing public blockchain derives account addresses from public keys. The public key serves as both the identity identifier and the authorization credential, welded together.

This means: changing your key = changing your identity = changing your address = migrating all assets and contract relationships.

This is not implementation-level technical debt. It is a protocol-level design assumption. The first two generations built their entire ecosystems on this assumption, and it cannot be changed. The four problems that follow are all downstream consequences of this single root cause.

2. Post-Quantum Security: It's Not Just "Adding an Algorithm"

Facing the quantum computing threat, the industry's mainstream plan is "migrate to post-quantum signature algorithms in the future." But the NIST post-quantum signature standard ML-DSA-65 produces 3,309-byte signatures and 1,952-byte public keys. Placing these directly on-chain would collapse throughput back to baseline.

More critically: public keys are already exposed in on-chain history, and quantum computers can retroactively break them. Switching algorithms does not solve the problem of already-exposed public keys. Ethereum's PQ roadmap calls for "a future hard fork + full ecosystem migration" — a process measured in years, with enormous coordination costs.

3. Ecosystem Fragmentation: Bridges Are ATMs for Hackers

The EVM ecosystem and the Solana ecosystem operate in silos, connected by bridges. Bridges are the single most exploited component in blockchain — Wormhole lost 320�������,���������620 million. The Cosmos and Polkadot approach is message passing, which is fundamentally still "two independent state machines communicating." Trust assumptions and latency issues persist.

4. User Experience: Seed Phrases and Hex Addresses

12 or 24 seed words, irrecoverable if lost, transfer addresses as hexadecimal strings — the first two generations expose raw cryptographic implementation details directly to end users. The industry has been calling for mass adoption for a decade, and this barrier has never come down.

The root cause is the same: public key = identity. Account recovery means recovering the private key. The address is a hash of the public key. There is no abstraction layer that can be inserted in between.

5. Private Key Inheritance: The Digital Estate Black Hole

Lose your private key, and your assets are gone forever. On first- and second-generation chains, self-custody, inheritability, and yield generation cannot be satisfied simultaneously: hand assets to an exchange and you can inherit but lose self-custody; hold the private key yourself and your heirs get nothing when you die; multi-sig introduces trusted third parties. This is a structural impossibility triangle under the public-key-as-identity architecture.

II. One Root Cause, One Decoupling

These five problems are not isolated feature requests. They share a single root cause — the binding of public keys to identity. As long as this assumption holds, every problem can only be patched at the application layer, treating symptoms rather than the disease.

ACE Chain's core design decision is to dismantle this assumption at the protocol layer: identity-authorization separation.

The concrete implementation is the ACE-GF (Atomic Cryptographic Entity Generative Framework) identity primitive. The sole on-chain identity identifier is IdCom — an identity commitment generated as a SHA-256 hash of the identity root entropy (REV) and a salt. Signature algorithms, key pairs, and authorization methods are all replaceable components, deterministically derived from the same REV via HKDF.

Change your key without changing your identity. Change your algorithm without changing your address. The identity layer, authorization layer, and execution layer are fully decoupled.

Once this decoupling is in place, the solution space for all five problems opens simultaneously:

Post-quantum security becomes a native capability. Public keys are never exposed on-chain (IdCom is a hash, resistant to quantum retroactive attacks). Transaction authentication uses ML-DSA-44, but signatures never go on-chain (attestation verification uses HMAC, at microsecond cost). Block verification uses Stwo Circle STARK (pure hash functions, no elliptic curve dependencies). The entire verification chain — from transaction authentication to block proof — relies on no classical cryptographic hardness assumptions. No hard fork required. No ecosystem migration needed.

Multi-VM unified execution eliminates bridging. ACE Chain's n-VM dispatcher runs EVM, SVM, BVM, and TVM under a single state tree. All VMs share a unified AccountId and balance ledger. Cross-VM transfers are in-memory balance changes — no bridges, no cross-chain messaging, zero trust assumptions. Because identity is chain-level (IdCom), not VM-level (public key address), a single identity naturally maps to addresses across all VMs.

Wallet recovery and human-friendly payments. The VADAR protocol enables wallet recovery using a password and an email or phone number. Only hashes are stored on-chain — no plaintext identifiers are ever exposed. HFI Pay enables payments to email addresses or phone numbers in a "pay first, claim later" pattern, where the recipient can receive funds before even having a wallet. These are not application-layer wrappers — they are protocol-level native capabilities, made possible only because identity and keys are decoupled, creating space to insert recovery and mapping mechanisms in between.

The industry significance of this is far greater than the technical community typically recognizes. Blockchain adoption faces two barriers standing between ordinary people and the technology: wallets and payments. Performance comes third.

The first wall is the wallet. Creating a wallet means generating a private key, writing down 12 or 24 seed words, and understanding that "if you lose them, they're gone forever." More critically, those 12 words are a bare asset — no password protection, no second factor, no access control of any kind. Anyone who obtains those 12 words owns all your assets, without your authorization, irrevocably, unrecoverably. This is equivalent to asking every user to write their entire net worth on a slip of paper, then take personal responsibility for ensuring that slip is never seen by anyone and never lost. No successful internet product has ever demanded this level of security responsibility from its users, yet blockchain requires every user to be their own key manager. The vast majority of ordinary people give up at this step.

The second wall is payments. Sending money to a friend requires them to provide a 42-character hexadecimal address (0x1a2B...), copy and paste it, and if you get it wrong, the assets are permanently lost. Compare this to: WeChat Pay scans a QR code, Venmo searches a username. Blockchain's payment experience is stuck in the era of direct IP address connections — DNS hasn't been invented yet.

Ordinary people never even get to the point of caring about "is the chain fast enough" — they abandon the process during wallet setup and their first transfer.

The technical community tends to think "can't you just add a registry or build an ENS?" But the problem is: under the first two generations' architecture, application-layer wrappers cannot solve the fundamental problem. Public key = identity means account recovery equals private key recovery. The address equals a public key hash. There is no abstraction layer that can be inserted. No matter how you wrap it — custodial wallets, social recovery, MPC sharding — the underlying constraint remains: "whoever holds the private key is the account owner." ENS simply puts a label on a hex address; the underlying layer is still the public key address, and losing your private key means your ENS name can't save you either. It's a binary choice: sacrifice self-custody (hand the key to a third party) or sacrifice usability (make the user manage the key themselves).

After identity-authorization separation, both walls come down at once — and they come down at the protocol layer, not through an application wrapper on top.

Wallet recovery becomes "re-derive the identity root with a password and email, bind a new key" — no private key transfer, no third-party custody, no seed phrases. The experience is consistent with the internet's "forgot password → email verification → reset" flow, but the security model is self-custodial: only hashes are stored on-chain, and the recovery process completes locally. VADAR is a native protocol of the chain, not a proprietary solution from a particular wallet vendor — any wallet, any client can invoke the same recovery mechanism.

Payments become "send money to an email address or phone number" — the recipient doesn't even need a wallet yet; they claim first and register later. HFI Pay is likewise a protocol-layer capability, built into the chain's state machine, not a DApp's smart contract. You don't need to know the recipient's public key, just as sending an email doesn't require knowing the recipient's mail server IP address. This is the interaction paradigm that internet users are accustomed to.

The bottleneck to mass adoption has never been "is the chain fast enough." It has always been "can ordinary people use it." If this problem isn't solved at the protocol layer, no amount of application-layer polish will help. Performance is the third wall — but only those who cross the first two walls ever encounter it.

Private key inheritance becomes a protocol capability. The identity (IdCom) can be bound to an heir's new key through the VADAR recovery protocol, without transferring assets or exposing the original private key. Self-custody and inheritability are no longer in conflict.

III. Verification Architecture: From O(N) Signatures to O(1) Proofs

Identity-authorization separation also delivers a significant performance dividend: signatures vanish from the transaction critical path.

The verification model of the first two generations is per-transaction signature verification — every transaction requires verifying a digital signature, with costs growing linearly with transaction count. This is a hard constraint on the performance ceiling.

ACE Chain's verification pipeline has three layers:

1. Attestation verification (critical path): HMAC-SHA256 checks at approximately 1–5 microseconds per transaction, replacing traditional signature verification.

2. Asynchronous STARK proving (non-blocking): Authorization proofs for all transactions in a block are tiled into a single Stwo Circle STARK proof — 13 Poseidon2 permutations × N transactions, one prove, one verify.

3. O(1) block verification: Regardless of how many transactions the block contains, the verifier only needs to check a single STARK proof. Verification cost is completely decoupled from transaction count.

The STARK proof is based on Blake2s hashing and the FRI protocol, with no elliptic curve pairings. Verification itself is post-quantum secure. No trusted setup is required — a fundamental distinction from Groth16.

At the consensus level, Tendermint-style consensus votes are transmitted as P2P messages, consuming no on-chain throughput — all bandwidth is reserved for user transactions. Combined with HKDF context-isolated zero-coordination state sharding, throughput scales linearly with the number of shards in theory.

IV. MEV: From Profit Redistribution to Ordering Power Elimination

MEV (Maximal Extractable Value) is another structural problem in blockchain: the block producer can extract value from users by reordering, inserting, or censoring transactions. On Ethereum alone, cumulative extracted MEV exceeded $680 million by mid-2023.

The limitations of existing approaches:

• Commit-reveal: Hides transaction contents, but does not authenticate who is eligible to create admissible commitments, and provides no transferable proof of omission.

• Threshold encryption (Shutter): Requires a decryption committee, introducing additional trust assumptions and latency.

• Fair ordering services (Chainlink FSS): Outsources ordering to an oracle network — shifting rather than eliminating the trust assumption.

• PBS (Flashbots MEV-Boost): Transfers MEV profit from miners to builders. This is redistribution, not elimination.

In our paper MEV-ACE, we propose an identity-authenticated fair ordering protocol that leverages the ACE-GF identity system to address MEV. Three layers of mechanism:

Layer 1: Identity-authenticated admission control. Every commitment must be signed by a registered identity backed by a staking bond, with a per-identity quota per slot. Commitment stuffing (the producer fabricating many low-cost commitments to dilute the ordering pool) goes from near-zero cost to requiring real locked capital.

Layer 2: VDF-delayed random ordering. After the admissible set is locked, a Verifiable Delay Function (VDF) computes the ordering seed. The producer cannot predict final transaction positions during the commitment phase, eliminating the information advantage needed for front-running and sandwich attacks.

Layer 3: Receipt-backed accountable inclusion. Both the commit and open phases require receipts from 2f+1 validators. These receipts serve as transferable omission proofs — any participant can prove to the entire network that "this transaction should have been included but was dropped by the producer." The producer cannot silently censor transactions.

Formal proofs show that, under standard cryptographic assumptions and correctly calibrated economic parameters, MEV-ACE simultaneously satisfies three security properties: order-unpredictability, commitment authenticity, and accountable inclusion. When the producer's and users' bonds exceed the maximum single-slot gain from violation, honest execution is the producer's best response.

MEV-ACE targets proposer-controlled ordering MEV (front-running, sandwich attacks, censorship), which constitutes the vast majority of MEV losses in historical on-chain data. Information-based MEV — such as cross-domain arbitrage and oracle price retroaction — falls outside the protocol's scope, but its share is comparatively limited and does not rely on producer privilege, making it closer to normal market efficiency than structural exploitation of users.

The entire protocol completes within a single slot, requires no threshold decryption committee, and is natively compatible with post-quantum signatures (ML-DSA-44).

V. Defining Generations: What Constitutes "Third Generation"

There is no industry-consensus standard for "which generation." But if we use foundational paradigms — identity model, verification model, security model — as the basis for classification:

The first generation solved trustless value transfer. The second generation solved programmable application ecosystems. The third generation solves the structural defects caused by the architectural assumptions of the first two — security, performance, user experience, ecosystem fragmentation, MEV. The common root cause of these problems is the binding of public keys to identity, and ACE Chain dismantles this assumption at the protocol layer.

This is not incremental improvement. The paradigm has changed.

VI. Honest Boundaries

Finally, a clear statement of what has not yet been achieved:

• Sharding performance is a theoretical model. The zero-coordination state sharding architecture has been implemented, but linear scaling in a distributed multi-node environment has not yet been validated at production scale.

• MEV-ACE has not yet been integrated into mainnet. The paper has completed formal analysis; protocol implementation and parameter calibration are next steps.

• The tension between privacy and compliance. IdCom hides identity material, but transactions from the same IdCom can be correlated. A "auditable by regulators, private to the public" selective disclosure scheme is still in design.

• Information-based MEV is outside MEV-ACE's scope. Cross-domain arbitrage, oracle retroaction, and other MEV based on public information require orthogonal mechanisms such as batch auctions or delayed disclosure.

Building infrastructure for the future requires equal honesty about what has been accomplished and what remains to be done.

References

• ACE Chain Whitepaper: acechain.io/ACE_Chain_Whitepaper.pdf

• ACE-GF: Atomic Cryptographic Entity Generative Framework — arXiv:2511.20505

• ZK-ACE: Zero-Knowledge Authorization for Cryptographic Entities — arXiv:2603.07974

• AR-ACE: Attestation Runtime for ACE Chain — arXiv:2603.07982

• n-VM: Multi-VM Unified Execution Architecture — arXiv:2603.23670

• CT-DAP: Context-Isolated Trust Domain Attestation Protocol — arXiv:2603.07933

• VA-DAR: Vendor-Agnostic Deterministic Artifact Resolution — arXiv:2603.02690

• HFI Pay: Human-Friendly Identifier Payment Protocol — arXiv:2603.26970

• AESP: ACE Economic Security Protocol — arXiv:2603.00318

• ACE Runtime: ZKP-Native Blockchain Runtime — arXiv:2603.10242

• MEV-ACE: Identity-Authenticated Fair Ordering (forthcoming)

Bitcoin's security stack has three quantum-vulnerable layers. The current post-quantum roadmap — including BIP-360 — addresses only one of them.

This article presents three independently deployable directions and analyzes the design tradeoffs of each.

The Three Vulnerable Layers

Layer 1: P2P Transport

BIP-324 uses secp256k1 ECDH for session key establishment. A quantum adversary can record all P2P traffic today and decrypt it once a cryptographically relevant quantum computer arrives — this is the harvest-now-decrypt-later attack. Even if on-chain authorization is fully quantum-safe, the recorded transport traffic still exposes transaction content, IP-to-transaction linkage, and propagation timing.

Layer 2: On-chain Authorization

Classical ECDSA and Schnorr signatures are directly vulnerable to Shor's algorithm. Post-quantum replacements (ML-DSA, SLH-DSA) produce signatures of 2.4–8 KB per transaction — a 30–125x increase. This is not an optimization problem. It is a structural one.

Layer 3: The Identity Model

This is the least discussed and most fundamental issue. Bitcoin's key management (BIP-32/39) relies on a persistent master seed. Under the "public key = identity" assumption, replacing the signature algorithm means replacing every user's on-chain identity — each account requires state migration, every contract referencing legacy addresses needs updates. There is no clean upgrade path.

Direction A: Hybrid KEM Transport for BIP-324

Replace the secp256k1 ECDH key exchange in BIP-324 with a hybrid KEM + ECDH construction. The hybrid model guarantees security is never worse than current BIP-324 — even if the PQC KEM is later found to have weaknesses.

Handshake overview using ML-KEM-768 as an example:

• Initiator sends: ElligatorSwift-encoded ECDH pubkey (64 B) + ML-KEM encapsulation key (1,184 B)

• Responder sends: ElligatorSwift-encoded ECDH pubkey (64 B) + ML-KEM ciphertext (1,088 B)

• Both sides derive: ss_combined = HKDF-SHA256(salt, ss_ecdh || ss_kem, info)

• Session keys derived from ss_combined via the existing BIP-324 key schedule

Wire cost: +2,272 bytes per handshake, one-time only. At 8–10 outbound connections, approximately 18–23 KB additional data per node — negligible relative to block relay.

Negotiated via a service bit (NODE_PQC_TRANSPORT), with automatic fallback to standard BIP-324 for non-supporting peers. Post-handshake packet sizes are unchanged.

The security model is straightforward: the hybrid is secure if either ECDH or ML-KEM-768 remains unbroken. Harvest-now-decrypt-later resistance, with zero regression risk.

Direction B: Algorithm-Agnostic Identity Commitment

Every existing approach — P2TR, BIP-360/P2MR — anchors the on-chain identity to a specific public key or a Merkle root of public keys. This means changing the signature algorithm requires changing the on-chain identity. There is no way around it under the current model.

A different approach: anchor to the identity itself, not to any specific key.

How the identity model works

The identity root is a 256-bit entropy value, but unlike a BIP-32/39 master seed, it is never stored persistently. It is sealed into a 74-byte encrypted artifact (via Argon2id + AES-256-GCM-SIV) and reconstructed ephemerally only when needed, then immediately zeroized from memory. There is no master seed at rest to back up or protect.

From this single identity root, keys for any algorithm are derived via HKDF with context tuples (AlgID, Domain, Index). Adding a new PQC algorithm requires only a new AlgID — the identity root, sealed artifact, and all existing keys remain unchanged. No on-chain migration, no rekeying.

The on-chain commitment is always 32 bytes:

ID_com = SHA-256(identity_root || salt || domain)

Comparison with existing approaches:

This requires a new SegWit witness version deployed via soft fork. The identity derivation model is formalized in ACE-GF (IETF individual draft).

Direction C: ZK Authorization with Mandatory Proof Aggregation

Compressing PQC signatures inside ZK circuits requires expressing lattice arithmetic in-circuit — on the order of millions of constraints. Beyond the cost, there is a more fundamental problem: pairing-based SNARKs (Groth16, PLONK with KZG) rely on discrete-log assumptions that Shor's algorithm breaks. Using them for "post-quantum authorization" merely shifts the quantum vulnerability from the signature to the verifier.

A different approach: prove authorization directly from the identity root using only ZK-friendly hash evaluations.

The prover demonstrates: "I know an identity root such that (i) it matches the on-chain commitment, and (ii) it authorizes this specific transaction."

This circuit requires approximately 4,000 R1CS constraints — roughly three orders of magnitude smaller than in-circuit ML-DSA verification. A reference implementation using Circle STARKs (hash-based, no trusted setup, post-quantum secure) achieves approximately 15 ms proving and 1.1 ms verification, single-threaded on Apple M-series. Details in ZK-ACE.

The aggregation architecture resolves the proof size problem

Individual STARK proofs are approximately 50–100 KB — larger than signatures. But:

1. Wallets generate per-transaction proofs off-chain

2. Block builders recursively aggregate all proofs into a single per-block proof (~100–200 KB, regardless of transaction count)

3. Consensus verifies one proof per block (constant time) + per-transaction binding checks (lightweight hash/lookup)

Net per-transaction on-chain data: approximately 160 bytes (public inputs only), compared to approximately 2,452 bytes for direct ML-DSA-65 signatures — a roughly 15x reduction.

Because the on-chain identity commitment depends only on the hash function, not the proof system, upgrading to a better prover in the future requires updating only the verifier. On-chain commitments and the identity layer are unchanged. Bitcoin does not get locked into a specific proof system at the consensus level.

Honest caveat: Mandatory proof aggregation significantly increases the computational burden on block builders, which could create centralization pressure. This tradeoff deserves careful analysis and should not be dismissed.

The Broader Point

These three directions are independently deployable and can be combined. The underlying question is whether Bitcoin's PQC roadmap should be scoped beyond the signature layer.

BIP-324 sessions recorded today are decryptable by a future quantum adversary. The BIP-32/39 identity model has no clean upgrade path under quantum migration. Both problems are as real as the signature vulnerability — they are simply less visible because they do not yet have active BIP proposals.

The quantum threat to Bitcoin is a full-stack problem. The response should be too.

@0xJasonw

Research: ACE-GF · ZK-ACE · IETF Draft

In 2024, NIST finalized its post-quantum cryptography standards. Lattice-based signature schemes such as ML-DSA (formerly Dilithium) are positioned to replace classical public-key signatures as the primary defense against quantum adversaries. Yet when engineers began seriously considering deploying these schemes on blockchains, a structural contradiction emerged:

The size of post-quantum signatures is inherently at odds with a blockchain's sensitivity to data.

The numbers make the tension concrete:

This is not a 10% increase. It is a 30–40× jump in magnitude. In a blockchain environment where every transaction must be received, verified, and permanently recorded by every consensus participant, this translates directly: per-transaction authorization data grows from under 100 bytes to several kilobytes.

The problem compounds in rollup architectures. EIP-4844 introduced blob space that is explicitly constrained and economically priced. Large post-quantum signatures compress effective throughput and raise the marginal cost of every transaction included on the base layer.

II. The Intuitive Fix That Doesn't Hold: Stuffing Verification into ZK Circuits

The cryptography community's most natural response was: move post-quantum signature verification off-chain and into a zero-knowledge proof circuit.

The logic sounds reasonable. Rather than posting a 2,420-byte signature on-chain, verify it off-chain and submit only a succinct ZK proof—which under Groth16 occupies just 128 bytes.

But this path carries a fundamental problem that is easy to underestimate.

Verifying a lattice-based signature inside a ZK circuit requires implementing high-dimensional algebraic arithmetic as circuit constraints:

• Number Theoretic Transforms (NTTs): over degree-256 polynomial rings in Z_q with q = 2²³ − 2¹³ + 1, each requiring O(n log n) multiplications;

• Non-native modular arithmetic: emulating a 23-bit modulus over a ≈254-bit proof-system field, requiring range-check gadgets per limb;

• Rejection sampling and hint reconstruction: logic with data-dependent branching.

The structural lower bound for ML-DSA L2 verification inside a ZK circuit is on the order of millions of R1CS constraints.

In other words, this approach merely relocates the scalability burden—from on-chain data to off-chain prover computation. The bottleneck persists; it has simply changed address.

III. The Paradigm Shift: Authorization Is Not Signature Verification

This is precisely the core insight behind ZK-ACE (Zero-Knowledge Authorization for Cryptographic Entities).

At the consensus layer, blockchains do not inherently require verification of a specific cryptographic signature object. What consensus requires is assurance that a given transaction was authorized by the correct entity under the system's rules.

A signature is one implementation mechanism for expressing authorization—not the authorization semantics themselves. Traditional designs conflate "verifying a signature" with "verifying authorization," but these two concerns are separable.

ZK-ACE chooses to prove the semantic property of authorization directly: that an identity consistent with an on-chain commitment has authorized this specific transaction. Signature objects never appear in the circuit, and never appear on-chain.

IV. How ZK-ACE Works

The Identity Layer: The Deterministic Identity Derivation Primitive (DIDP)

ZK-ACE treats a DIDP (Deterministic Identity Derivation Primitive) as a black-box building block. The canonical instantiation is ACE-GF—a seed-storage-free cryptographic identity framework.

ACE-GF's central idea is a clean separation between identity and authorization:

• The Root Entropy Value (REV) is a 256-bit random value that serves as the sole source of entropy for all derived keys. It is never stored persistently—it exists only ephemerally in memory during execution;

• The REV is encrypted using AES-GCM-SIV (a nonce-misuse-resistant authenticated encryption scheme), producing a Sealed Artifact—the only object that needs to be stored;

• An authorization credential (such as a user passphrase) is processed through Argon2id to derive the unsealing key, which temporarily reconstructs the REV when needed;

• All cryptographic keys are derived via HKDF combined with an explicit context tuple Ctx = (AlgID, Domain, Index), ensuring that keys under different contexts are computationally independent.

This design delivers:

• Stateless credential rotation: changing credentials does not change the identity root or any derived keys;

• Immediate revocation: removing a credential component permanently blocks access, with no server-side state required;

• Non-disruptive PQC migration: adding a post-quantum algorithm requires only assigning a new AlgID—existing classical keys and identity commitments are unaffected.

The On-Chain Anchor: The Identity Commitment

Each identity participating in ZK-ACE maintains a compact identity commitment on-chain:

IDcom = H(REV ∥ salt ∥ domain)

This 32-byte hash value is the sole persistent on-chain identity anchor. The REV itself, all derived keys, and any post-quantum signature objects are absent from the chain entirely.

The ZK Circuit: Five Core Constraints

The ZK-ACE circuit requires only five constraints to be satisfied:

C1: Commitment Consistency

H(REV ∥ salt ∥ domain) = IDcom

The prover controls an identity root consistent with the on-chain anchor.

C2: Deterministic Derivation Correctness

target = H(Derive(REV, Ctx))

The target-binding hash is consistent with derivation from the identity root under the specified context. The derived key itself is never exposed—only a hash commitment to it appears on-chain.

C3: Authorization Binding to TxHash

Auth = H(REV ∥ Ctx ∥ TxHash ∥ domain ∥ nonce)

The authorization is bound to a specific transaction, preventing substitution attacks.

C4: Anti-Replay Two canonical modes are supported:

• Nonce registry mode: rp_com = H(IDcom ∥ nonce), with the chain enforcing monotonicity;

• Nullifier set mode: rp_com = H(Auth ∥ domain), with the chain maintaining a spent-nullifier set.

C5: Domain Separation and Context Consistency The domain value is enforced consistently across all commitment and binding computations. A proof generated for one chain cannot satisfy the verifier's checks on a different chain.

Proof System Architecture: Pluggable Backends

ZK-ACE implements a pluggable backend architecture, allowing the same circuit semantics to be proven under fundamentally different proof systems. The reference implementation provides two backends selectable via a compile-time feature flag:

Circle STARK backend (default, post-quantum secure). Built on Stwo, this backend operates over the Mersenne-31 field using Poseidon2 hash (width=16, x⁵ S-box) and the FRI protocol. Verification relies only on hash functions—no elliptic curve assumptions—making it fully post-quantum secure. The setup is transparent: no trusted ceremony is required.

Groth16/BN254 backend (compact classical proofs). Built on arkworks, this backend uses Poseidon hash over the BN254 scalar field with R1CS constraints and pairing-based verification. It produces the smallest possible proofs (128 bytes) but relies on elliptic curve assumptions that are not quantum-resistant.

The two backends serve complementary roles:

This architecture allows deployments to choose: use the STARK backend today for post-quantum security with mandatory aggregation, or the Groth16 backend for EVM-native compatibility with minimal on-chain footprint. A single feature flag switches between them—application code and circuit semantics remain identical.

Constraint Scale: An Order-of-Magnitude Gap

The ZK-ACE circuit is intentionally minimal. Measured constraint counts for each backend:

These counts are not directly comparable—an AIR constraint over a 16-column trace encodes more logic per row than a single R1CS multiplication gate—but both are extraordinarily compact by ZK circuit standards.

For reference, the structural lower bound for in-circuit ML-DSA L2 verification is on the order of millions of R1CS constraints. ZK-ACE's circuit is roughly three orders of magnitude smaller. This is not the result of parameter tuning. It is a consequence of architectural choice: proving authorization semantics directly, rather than emulating signature verification inside a circuit.

Performance Benchmarks

Measured on Apple Silicon (Criterion.rs medians, single-threaded):

Circle STARK backend (Stwo):

Groth16/BN254 backend:

Several observations warrant attention:

The STARK backend is faster than Groth16 in both proving and verification. This may seem counterintuitive—STARKs are often associated with larger proofs and heavier verification—but the result is a direct consequence of the underlying field arithmetic. Mersenne-31 field operations (31-bit) are an order of magnitude cheaper than BN254 scalar field operations (254-bit), and STARK proving requires no elliptic curve multi-scalar multiplications. For small circuits like ZK-ACE, this arithmetic advantage dominates.

Verification latencies of 1–1.5 ms are well within budget for both L1 and rollup settings. For comparison, an secp256k1 ECDSA verification on the same hardware takes approximately 50–100 µs; the ZK-ACE overhead is roughly 10–15× that of a classical signature check, but replaces what would otherwise be a multi-kilobyte post-quantum signature.

The STARK proof size (~105 KB) is not an on-chain cost. Under the mandatory aggregation architecture (Section IV below), individual STARK proofs are verified off-chain by the block builder. The builder produces a single aggregated proof per block. Per-transaction on-chain data consists only of the five public input fields—approximately 160 bytes—regardless of the number of transactions in the block.

On-Chain Data Comparison

With the STARK backend and mandatory per-block aggregation:

The STARK aggregation model achieves a 23–45× reduction in per-transaction on-chain authorization data compared to direct post-quantum signatures. Even the Groth16 model achieves a 10–20× reduction. Both figures are derived entirely from protocol structure—not from implementation-level optimization.

V. Security: Four Formal Guarantees

ZK-ACE provides game-based, reduction-based security proofs under standard cryptographic assumptions:

Authorization Soundness: Any adversary without knowledge of REV cannot forge an accepting authorization proof. The reduction proceeds through knowledge soundness of the proof system, collision resistance of H, and DIDP identity-root recovery hardness.

Replay Resistance: In nonce mode, a replayed proof fails the monotonicity check. In nullifier mode, the same authorization parameters produce the same nullifier, which is already present in the spent set. In both cases, the only path to causing a second acceptance reduces to the authorization soundness game.

Substitution Resistance: Proofs are cryptographically bound to their public inputs. An adversary cannot rebind a valid proof to a different transaction hash or target. This reduces directly to the public-input binding property of the proof system.

Cross-Domain Separation: The domain parameter is embedded in every commitment and binding computation. A proof generated for one chain or application cannot pass verification in another. This reduces to collision resistance of H and public-input binding.

The Circle STARK backend additionally provides post-quantum verification security: the FRI-based verifier relies only on hash function collision resistance (Blake2s), with no dependence on elliptic curve discrete logarithm or pairing assumptions. Under the STARK backend, the entire authorization path—from identity commitment through proof generation to on-chain verification—is post-quantum secure.

VI. From On-Chain Authorization to Mempool Propagation: AR-ACE

ZK-ACE addresses the on-chain authorization problem. In the mempool propagation layer, a symmetric problem is taking shape.

The Bandwidth Crisis in Post-Quantum Mempools

In distributed block construction, large numbers of objects—blob roots, consensus-layer signature aggregates, execution-layer transactions—must be broadcast so that builders can discover and include them. In a post-quantum setting, proving the validity of these objects calls for STARKs, and a single STARK proof is on the order of 128 KB even in size-optimized implementations.

If every object were propagated together with its own full STARK proof, relay bandwidth would scale linearly with the number of objects—quickly reaching untenable levels.

Buterin proposed recursive STARKs as a solution: each node periodically produces one recursive proof attesting to the validity of all objects it holds, and broadcasts that single proof to its peers. This caps per-node proof bandwidth at roughly 128 KB × degree / tick interval (approximately 2 MB/s for d=8, T=0.5s). It is an elegant approach—but it still requires every node on the path to continuously generate and forward STARK proofs.

AR-ACE: Moving Proofs Off the Propagation Path

AR-ACE (ACE-GF-based Attestation Relay for PQC) poses a more fundamental question:

Must validity proofs appear on the propagation path at all?

A relay node's decision to forward an object requires only a lightweight assurance that the object is eligible for relay—not a full validity proof. Validity need only be proven once, at the point of inclusion, by the builder.

AR-ACE's design separates these concerns cleanly:

Submitters compute objHash = H(obj) and produce a compact attestation:

Attest = Sign(sk, objHash ∥ domain ∥ nonce)

Relay nodes verify only that Attest is well-formed and correctly bound to objHash and domain. They do not verify the object's full validity. They do not generate, hold, or forward any STARK or other validity proof.

The builder collects objects and attestations from the network, selects a set to include, and produces one aggregated validity proof (e.g., a recursive STARK) over the selected set. This single proof is published with the block.

The proof-off-path property: validity proofs are entirely absent from the propagation path, existing only once at the builder.

Bandwidth Comparison

Compared to recursive STARK propagation, AR-ACE eliminates proof traffic from the relay path entirely. Each relay link carries only the object and a compact attestation of tens to hundreds of bytes.

The Advantage of ACE-GF Instantiation

When attestation keys are derived via ACE-GF using a dedicated context Ctx_relay = (AlgID, MEMPOOL-ATTEST, domain):

• The same REV that backs on-chain ZK-ACE authorization derives the relay attestation key—one identity root, one backup, no separate key management;

• The relay attestation key is cryptographically isolated from on-chain authorization keys—a compromised relay-only key exposes nothing about on-chain identity;

• Assigning an ML-DSA AlgID makes the entire propagation path PQC-consistent without changing identity or backup procedures;

• Deterministic derivation ensures that the same identity and context always produce the same attestation key, enabling straightforward auditing and attribution.

VII. The Complete Stack: Three Layers, One Root

Viewed together, the three papers describe a coherent post-quantum blockchain identity, authorization, and propagation stack:

┌────────────────────────────────────────────────────┐
│                  ACE-GF (Identity Layer)           │
│   REV → Sealed Artifact → Context-Isolated Keys   │
│   No seed storage · Stateless rotation · PQC-ready│
└──────────────────────┬─────────────────────────────┘
                       │
           ┌───────────┴───────────┐
           ▼                       ▼
┌──────────────────────┐   ┌───────────────────────────┐
│       ZK-ACE         │   │         AR-ACE            │
│   (On-Chain Auth)    │   │   (Mempool Propagation)   │
│                      │   │                           │
│ Circle STARK (PQ)    │   │ Lightweight Attest relay  │
│  + Groth16 (compat)  │   │ Proof-off-path design     │
│ Prove: 21 ms         │   │ Single aggregated proof   │
│ Verify: 1.1 ms       │   │ at builder                │
│ ~160 B/tx (aggreg.)  │   │ Zero proof bandwidth      │
└──────────────────────┘   └───────────────────────────┘

Each layer applies the same architectural principle: move heavyweight cryptographic artifacts off the paths that require large-scale replication, replacing them with succinct proofs or lightweight attestations, with full verification performed once at the endpoint.

VIII. Why This Matters

For the Post-Quantum Migration Path

The challenge of post-quantum migration is not only developing new primitives—it is controlling their cost within the constraints that blockchain systems can tolerate. ZK-ACE demonstrates that this goal does not require incremental compression of signature sizes. It requires questioning the design assumption that signature objects need to be in the consensus path at all.

With the Circle STARK backend, ZK-ACE achieves what was previously considered a tradeoff: post-quantum security without sacrificing verification performance. The entire authorization path—identity commitment, proof generation, on-chain verification—relies only on hash functions, with no elliptic curve assumptions. This is not a theoretical property; it is measured: 21 ms prove, 1.1 ms verify, transparent setup, no trusted ceremony.

For Account Abstraction

ZK-ACE is a natural fit for ERC-4337-style account abstraction. Under AA, account validation logic is defined by smart contract code. ZK-ACE can serve directly as a validator module, replacing signature-object checks with zero-knowledge proof verification—bringing post-quantum authorization semantics to the chain without modifying the base protocol.

For Long-Lived Digital Entities

ACE-GF separates key material from identity: keys can be rotated, algorithms can be migrated, and devices can be replaced—while the identity commitment remains stable on-chain. This provides a trust-minimized identity infrastructure for long-lived digital entities, whether AI agents, decentralized services, or large-scale IoT deployments.

For Rollups

Through batch aggregation and recursive proof composition, ZK-ACE allows a single recursive proof to cover the authorization validity of an entire batch of transactions, amortizing per-proof cost toward zero. Combined with AR-ACE's propagation-layer design, this constitutes an end-to-end scalable authorization architecture for post-quantum blockchain systems.

Conclusion

The evolution of cryptographic standards consistently prompts a re-examination of system architecture. The arrival of post-quantum signatures has exposed a long-unexamined design assumption in blockchain authorization: treating the signature object as the primary unit of verification, rather than treating authorization itself as a semantic property that can be proven independently.

ZK-ACE and AR-ACE do not propose new cryptographic primitives. Their contribution is to redefine the problem: authorization need not depend on signature objects; propagation need not carry validity proofs. Within this framework, the tension between post-quantum security and blockchain scalability transforms from a structural conflict into a tractable engineering problem.

The reference implementation is open-source: github.com/acechain-io/zk-ace

This article is based on the following technical publications:

• ACE-GF: A Generative Framework for Atomic Cryptographic Entities (arXiv: https://arxiv.org/abs/2511.20505)

• ZK-ACE: Identity-Centric Zero-Knowledge Authorization for Post-Quantum Blockchain Systems (arXiv: https://arxiv.org/abs/2603.07974)

• AR-ACE: ACE-GF-based Attestation Relay for PQC (arXiv: https://arxiv.org/abs/2603.07982)

STARKs — scalable, transparent, post-quantum-secure proofs of computational integrity — are among the most significant cryptographic inventions of the past decade. Yet in today's blockchain landscape, they are deployed almost exclusively as optimization tools: compressing rollup state, batching signature verifications, shrinking on-chain data. Powerful as these applications are, they assign STARKs a subordinate role — serving primitives (signatures, state roots) that remain architecturally central.

Identity–authorization separation, as instantiated in ZK-ACE and AR-ACE, changes this relationship. By removing signatures from the consensus path entirely, it creates an architecture where the proof system is the authorization primitive — not a wrapper around one. In this model, every transaction's authorization flows through a STARK proof. Block verification collapses from O(N) per-transaction signature checks to a single O(1) aggregated proof. And STARKs' three defining properties — scalability, transparency, and post-quantum security — shift from nice-to-have optimizations to consensus-critical parameters.

This article argues that this pairing is not incidental. STARKs and identity–authorization separation are structural complements: each resolves the other's core limitation. Together, they define an architecture that is natively ready for the post-quantum era — not as a migration target, but as a starting point.

The Irony of How We Use STARKs Today

Eli Ben-Sasson and his co-authors introduced STARKs in 2018 with a specific vision: scalable, transparent arguments for computational integrity. No trusted setup. No elliptic curve assumptions. Verification time polylogarithmic in the computation size. Prover time quasilinear. And security grounded in collision-resistant hash functions — a foundation that remains secure against known quantum algorithms.

These properties make STARKs arguably the most future-proof proof system available. And yet, look at how the industry deploys them:

• Rollup compression. STARKs verify that a batch of L2 transactions was executed correctly, so that L1 doesn't have to re-execute them. The proof attests to the integrity of someone else's computation.

• Signature aggregation. Multiple ECDSA or EdDSA signatures are verified inside a STARK circuit, producing a single proof that "N valid signatures exist." The proof attests to the validity of another cryptographic primitive.

• State compression. Merkle proofs, storage proofs, and state diffs are wrapped in STARK proofs for succinct on-chain verification. The proof makes existing data structures smaller.

Every one of these is a legitimate, valuable application. But notice the pattern: in each case, the STARK proof is in service of something else. The signature is the trust anchor. The state root is the canonical reference. The L1 consensus mechanism is the final arbiter. STARKs make these things more efficient, but they do not replace them.

Consider the post-quantum signature problem. ML-DSA (the NIST-standardized lattice-based signature scheme) produces signatures of approximately 2,420 bytes — 38× larger than Ed25519. The natural response is: verify the ML-DSA signature inside a STARK circuit, post the succinct proof on-chain, problem solved.

But look at what this actually does. The lattice arithmetic that makes ML-DSA quantum-resistant is computationally expensive. Moving it inside a STARK circuit does not eliminate that cost — it shifts it from the verifier to the prover. The prover must now perform full ML-DSA verification plus the overhead of arithmetization and proof generation. We have traded on-chain bloat for off-chain computational bloat. The signature — the original source of the problem — remains at the center of the architecture.

The STARK, in this model, is doing janitorial work: cleaning up after a primitive that was not designed for the environment it now operates in. It is as if we built a Formula One engine and used it to tow a trailer — impressive engineering, misapplied.

What Changes When You Remove the Signature

Identity–authorization separation, as proposed in the ACE-GF framework, makes a structural adjustment: the identity root (a deterministic reconstruction from a sealed artifact and credentials) is decoupled from per-transaction authorization. Authorization becomes a separate, pluggable layer.

ZK-ACE takes this separation to its logical conclusion on the consensus path. Instead of generating a signature and then compressing it into a proof, ZK-ACE removes the signature entirely. The prover demonstrates in zero knowledge that:

1. Their identity is consistent with an on-chain commitment.

2. The transaction has been authorized according to the policy governing that identity.

No signature is generated. No signature is transmitted. No signature is verified — not on-chain, not off-chain, not inside a circuit. The proof does not attest that "a valid signature exists somewhere." It directly attests that "this transaction is authorized by this identity."

This is not a compression of the same statement. It is a different statement — a simpler one, a more direct one, and one that is native to what proof systems do best: proving computational claims.

The moment you remove the signature, several things happen simultaneously:

The proof system moves from periphery to center. In the signature-compression model, the trust chain is: identity → key → signature → proof. The proof is the outermost layer, furthest from the trust anchor. In the direct-authorization model, the trust chain is: identity → commitment → proof. The proof is the authorization. It is not optimizing another primitive; it is the primitive.

Post-quantum bloat becomes irrelevant. ML-DSA's 2,420-byte signatures do not need to be compressed, because they do not exist. The on-chain footprint is determined by the proof size and the commitment size — both independent of the underlying signature scheme's parameters.

Prover efficiency improves structurally. Proving "I know credentials that reconstruct an identity consistent with this commitment, and I authorize this transaction" is a fundamentally lighter statement than proving "I verified a valid ML-DSA signature." The lattice arithmetic that dominates ML-DSA verification is no longer inside the circuit. The prover's work is proportional to the complexity of the authorization statement, not the complexity of a signature verification.

O(N) to O(1): The Block-Level Collapse

ZK-ACE handles individual transaction authorization. The block-level collapse emerges from the full stack: AR-ACE optimizes the relay layer (proof-off-path propagation, so mempool bandwidth does not scale with proof size), while ACE Runtime's Attest–Execute–Prove pipeline aggregates all per-transaction authorization proofs into a single block-level proof at the builder stage.

In today's blockchains, block verification requires O(N) independent signature checks — one per transaction. This is a fundamental bottleneck. Solana, for example, requires every validator to run a GPU dedicated to parallelizing Ed25519 signature verification. Post-quantum signatures would make this dramatically worse: each verification becomes ~10× more expensive in compute, and the data to verify is ~38× larger.

Aggregation schemes exist (BLS signatures, for instance), but they are limited to specific signature schemes, require a pairing-friendly curve, and are not post-quantum secure.

The ZK-ACE + ACE Runtime stack takes a different approach. Since every transaction's authorization is already a zero-knowledge proof (via ZK-ACE), the block builder can aggregate all per-transaction proofs into a single block-level proof. One proof covers the entire block. Validators verify one proof, regardless of how many transactions the block contains.

O(N) → O(1).

This is not achievable in the signature-based model, because signatures are scheme-specific objects that do not compose naturally. You cannot take N Ed25519 signatures and produce a single "super-signature" without changing the scheme (and even BLS aggregation, which supports this, is not post-quantum secure). But zero-knowledge proofs do compose: a proof of N valid proofs is itself a proof. Recursive composition is a native property of proof systems.

The implication is precise: the O(N) → O(1) collapse is only possible because signatures were removed. It is not a feature of better signature schemes or faster verification hardware. It is a structural consequence of making the proof system the authorization primitive.

Why STARKs — Specifically

The direct-authorization model does not technically require STARKs. Any succinct proof system could, in principle, fill this role. But STARKs possess three properties that make them the most natural fit for a consensus-critical authorization layer in a post-quantum blockchain:

1. Post-Quantum Security by Construction

STARKs rely on collision-resistant hash functions — no elliptic curves, no pairings, no lattice assumptions. Their security is not "believed to be quantum-resistant" in the way that lattice-based schemes are; it rests on a problem (finding hash collisions) for which no quantum speedup beyond Grover's square root is known, and the hash output length can be adjusted to compensate.

In the direct-authorization model, this matters enormously. If the proof system is the authorization primitive — if every transaction's validity depends on it — then the proof system's security assumptions become the chain's security assumptions. A proof system that requires a trusted setup, or relies on discrete-log hardness, or depends on pairing assumptions, introduces quantum vulnerability at the most critical layer of the stack.

STARKs do not introduce these vulnerabilities. The consensus path is post-quantum secure not because of a migration, but because the foundational primitive was never classically dependent.

2. Transparency (No Trusted Setup)

SNARKs that require a structured reference string (SRS) — Groth16, original PLONK, KZG-based systems — introduce a trust assumption at the very foundation of the proof system. If the SRS generation ceremony is compromised, proofs can be forged.

In a rollup context, this risk is bounded: the worst case is a fraudulent state transition, which can be caught by other mechanisms. But in the direct-authorization model, a forged proof means a forged authorization — the ability to spend someone else's assets. The trust assumption becomes existential.

STARKs eliminate this entirely. Verification requires only public randomness (derived from the proof itself via Fiat-Shamir), not a pre-generated secret. The authorization layer has no trapdoor.

3. Scalability for Block-Level Aggregation

AR-ACE's O(1) block verification relies on recursive proof composition: the block builder generates a proof that attests to the validity of all per-transaction proofs. The efficiency of this recursion is determined by the proof system's verification complexity — because the "inner" verification becomes the circuit that the "outer" proof must prove.

STARK verification is polylogarithmic in the computation size. This means the recursive overhead grows slowly as block sizes increase. For a system targeting hundreds of thousands of transactions per block, this scaling property is not an optimization — it is a structural requirement.

The Natural Alliance

The pairing between STARKs and identity–authorization separation is not a coincidence of design choices. It reflects a deeper structural alignment:

Each column was designed independently. STARKs were invented to prove computational integrity at scale. Identity–authorization separation was designed to decouple identity from per-transaction signing. But the requirements of one align remarkably well with the capabilities of the other.

STARKs without identity–authorization separation remain optimization tools — compressing signatures, batching verifications, shrinking data. Powerful, but peripheral.

Identity–authorization separation without STARKs could work with other proof systems, but would inherit their limitations: trusted setup risks on the consensus-critical path, quantum vulnerability in the authorization layer, or verification overhead that undermines block-level aggregation.

Together, they form an architecture where:

• Every transaction is authorized by a STARK proof — no signatures on the consensus path.

• Every block is verified by a single aggregated STARK proof — O(1) regardless of transaction count.

• The entire consensus path is post-quantum secure by construction — no migration needed when quantum computers arrive.

• The authorization layer has no trapdoor, no trusted setup, no ceremony — the security model is as clean as the hash function it rests on.

A Twenty-Year View

The post-quantum transition is not a distant hypothetical. NIST finalized its first post-quantum standards in 2024. The NSA's CNSA 2.0 suite requires transition to post-quantum algorithms by 2035. "Harvest now, decrypt later" attacks mean that data encrypted or signed today is already at risk from future quantum capabilities.

For blockchains, the stakes are especially high. Every transaction ever recorded on a public ledger is permanently visible. Every public key ever exposed is a potential target. And the immutability that makes blockchains trustworthy also makes them impossible to retroactively patch.

The industry's current approach — migrate to post-quantum signature schemes — addresses the immediate vulnerability but inherits all the structural costs: bloated signatures, expensive verification, O(N) scaling, and the certainty that another migration will be needed when today's "post-quantum" schemes are broken or superseded.

The STARK + identity–authorization separation architecture offers a different posture: build on a foundation that does not need to migrate. Hash-based proof systems do not become obsolete when a new quantum algorithm is discovered. They do not require parameter updates when NIST revises its security levels. They do not force asset migration when cryptographic generations change. The identity root is algorithm-agnostic; the authorization layer is proof-based; the proof system is hash-based. The entire stack is designed to outlast any individual cryptographic assumption.

This is not a claim that the architecture is permanent or beyond improvement. It is a claim that its security model degrades gracefully and upgrades cleanly — that the twenty-year horizon is one it can navigate without the kind of disruptive migrations that signature-based systems will inevitably face.

Twenty years from now, the blockchains that survive will not be the ones that migrated fastest to post-quantum signatures. They will be the ones that were built on primitives that did not require migration in the first place.

Open Questions

• Prover cost at scale. Direct authorization proofs are structurally lighter than signature-verification proofs, but absolute prover performance for hundreds of thousands of transactions per block remains an engineering challenge. Hardware acceleration (FPGAs, ASICs for NTT) is an active area, but production readiness is unproven.

• Recursive proof overhead. AR-ACE's block-level aggregation relies on efficient recursive composition. The concrete overhead of STARK-in-STARK recursion at production block sizes needs benchmarking beyond analytical models.

• Ecosystem adoption. This architecture cannot be retrofitted onto existing chains. It requires new infrastructure — wallets, SDKs, developer tooling — built around proof-based authorization rather than signature-based authorization. The cold-start problem is real.

• Proof system evolution. STARKs are not static. Circle STARKs, DEEP-FRI, and other advances continue to improve concrete performance. The architecture should be designed to absorb these improvements without structural changes — but validating this adaptability requires implementation experience.

Conclusion

STARKs were invented to prove computational integrity at scale, without trusted setup, with security rooted in hash functions. Identity–authorization separation was designed to decouple identity from per-transaction signing, making the proof system — rather than the signature — the authorization primitive. Neither was designed with the other in mind. But their structural alignment is striking: what one provides maps closely to what the other requires.

The result is an architecture where STARKs are no longer doing janitorial work — compressing bloated signatures, batching redundant verifications, optimizing around primitives that were not designed for the post-quantum world. Instead, they occupy the role they were built for: scalable, transparent, quantum-resistant proofs of computational claims. The claim is simply: "this transaction is authorized by this identity." The mathematics does not change. What changes is whether we ask the mathematics to serve a peripheral role or a foundational one.

For the next twenty years — the window in which quantum computing will transition from theoretical threat to practical capability — the blockchain industry faces a choice. It can continue to build on signature-based authorization and absorb the escalating costs of each cryptographic migration. Or it can build on proof-based authorization, where the consensus path is post-quantum secure by construction, block verification is O(1), and the authorization primitive is the most powerful tool in the cryptographer's arsenal, finally deployed at the center of the architecture rather than at its edges.

The alignment between STARKs and identity–authorization separation is not a product decision. It is a structural observation: these two ideas, developed independently, address each other's core limitations. Recognizing that — and building on it — may open a cleaner path to the next generation of blockchain infrastructure.

This article builds on the architecture described in Rethinking What We Assumed About Blockchain. The underlying protocols — ZK-ACE, AR-ACE, and ACE Runtime — are available on arXiv.

Contact: jason@acechain.io · @0xJasonw

Since Bitcoin, blockchains have treated identity, authorization, and control as a single object — the private key. That compression served the ecosystem well for over a decade, but it is now under strain from multiple directions at once. Consider, for example, the post-quantum threat: every on-chain transaction today exposes the sender's public key, and "harvest now, decrypt later" (HNDL) attackers are already archiving blockchain data for future quantum decryption. The private-key-as-identity model makes this exposure structural — the public key is the identity, so it cannot be hidden. Meanwhile, the signatures designed to resist quantum attack (e.g., ML-DSA) are an order of magnitude larger than their classical counterparts, making consensus-path verification disproportionately expensive. Institutions entering the space need conditional, revocable control that a permanent private key cannot express. AI agents need to transact autonomously within bounded authority. Wallet recovery still reduces to safeguarding a single master backup. Cross-chain identity fragments across every network a user touches. And the cost of “every node verifies every signature” scales linearly in ways that post-quantum cryptography will make dramatically worse.

This article explores a structural adjustment: separating identity binding from per-transaction authorization. In this model, the identity root — reconstructed deterministically from a sealed artifact and credentials — anchors who you are. Authorization — zero-knowledge proofs, HMAC attestations, policy gates — becomes a separate, context-specific layer for what may be done. ACE-GF (Atomic Cryptographic Entity Generative Framework) provides one concrete instantiation of this separation.

Pushing it through the full stack — not just key management — opens a design space where many outcomes are unavailable today or reachable only at enormous cost: authorization without parking full signature objects on the consensus path; conditional control without chain-specific contract logic; wallet recovery without a single master seed; unified identity across execution environments without bridges; payments to human-readable identifiers without publishing address mappings; and identity continuity across cryptographic generations, so that a routine PQC upgrade does not mean migrating every user’s assets to a new identity.

The architecture is meant to be built as a new chain or layer, not patched onto existing assumptions. Developers get a stack where identity, authorization, and execution evolve independently — and where succinct proof systems serve as load-bearing authorization infrastructure, not merely compression around signatures. Institutions get conditional control and revocation expressed in cryptographic structure rather than contract code. End users get recovery and payments that do not reduce to a mnemonic or a globally visible identifier-to-address map. The open questions — engineering feasibility, ecosystem adoption, operational reliability — are addressed at the end.

Introduction

In January 2009, the first Bitcoin transaction embedded a simple but powerful idea: a private key signs a message, the network verifies the signature, and that's all you need. Identity is the key. Authorization is the signature. Control is possession.

This compression — identity, authorization, and control collapsed into a single cryptographic object — has defined every blockchain built since. It was elegant. It was sufficient. And for nearly two decades, no one seriously questioned it.

But the pressures summarized above are not isolated issues with isolated fixes. They share a common root: the private key is being asked to do too many jobs at once. The industry's response, so far, has been to optimize within the existing framework — compress signatures with zero-knowledge proofs, wrap keys in smart contract wallets, build bridges between fragmented identities, add multisig layers for governance. Each solution addresses a symptom while preserving the root assumption.

What if we questioned the assumption itself?

ACE-GF (Atomic Cryptographic Entity Generative Framework) proposes a seemingly small but structural adjustment: separating identity binding from per-transaction authorization. The identity root — a deterministic, ephemeral reconstruction from a sealed artifact and authorization credentials — becomes the anchor. Authorization becomes a separate, pluggable layer that can be instantiated differently depending on context: a zero-knowledge proof for on-chain consensus, an HMAC attestation for mempool relay, a policy gate for AI agent transactions.

This single separation, followed to its logical conclusions, forces us to rethink eight assumptions that the entire blockchain stack is built on. Not as incremental improvements, but as structural redesigns — the kind that become possible only when you change what's at the foundation.

ACE-GF: A Concrete Instantiation

In ACE-GF's construction, a 256-bit Root Entropy Value (REV) exists only ephemerally in memory — sealed under the user's passphrase at rest, and used to derive context-isolated keys for all target environments before being zeroed. Identity and authorization are two independent pipelines that meet only at this ephemeral point:

Pipeline 1 (left) derives all cryptographic material from the REV — each algorithm and domain gets an independent key family via context-isolated HKDF, and adding PQC is just a new derivation context. Pipeline 2 (right) controls who can access the identity — credentials seal and unseal the REV, and can be rotated or revoked without changing the identity itself. The REV exists only in memory during the Unseal operation, never at rest.

This is one concrete instantiation of identity–authorization separation. The sections below work through eight consequences; the article closes with a full-stack synthesis.

1. Control ≠ Holding a Private Key

The assumption we've accepted: Control over digital assets is equated with permanent possession of a private key. Transferring control means transferring the key itself.

Why it's breaking: This model forces a binary: you either have the key (full control) or you don't (no control). There is no native way to express control that is temporary, conditional, delegated, or revocable. Inheritance, regulatory supervision, institutional governance — all require nuanced control semantics that a single private key fundamentally cannot represent. Every workaround (multisig, smart contracts, custodians) adds complexity while pushing the actual control logic outside the cryptographic trust boundary.

After separation: When identity and authorization are independent, control becomes a question of which authorization paths are currently constructible, not who holds a secret. The identity root remains stable and unchanged; what varies is whether the credentials needed to activate a particular authorization path are available. New paths can be created, existing paths can be made dormant, and active paths can be permanently destroyed — all without modifying the identity itself or touching on-chain state.

This reframes control from a static property (possession) to a dynamic one (activation). Section 3 below explores the concrete mechanisms — dormant authorization paths, destructible factors, condition-triggered activation — that make this work in practice.

Why it matters: The "key = control" model was designed for a world of self-custodied bearer assets. As crypto assets enter regulated financial systems — RWA tokenization, institutional custody, estate planning — the inability to express conditional, revocable control at the cryptographic layer is becoming a structural barrier, not just a UX inconvenience.

2. Transaction Authorization ≠ Carrying a Signature

The assumption we've accepted: Every transaction must carry a cryptographic signature, and consensus nodes verify each signature individually.

This is perhaps the most deeply embedded assumption in all of blockchain — so natural that questioning it feels almost heretical. Satoshi's original Bitcoin transaction is, at its core, a signed message. Every chain since has preserved this model: produce a signature, attach it to the transaction, have every node verify it independently.

Why it's breaking: In two directions simultaneously. First, verification cost scales linearly with transaction volume — O(N) signature verification per block is a core bottleneck for high-performance chains, forcing Solana to require every validator to run a GPU just for signature verification. Second, post-quantum signatures (e.g., ML-DSA at NIST Security Level 2) are approximately 2,420 bytes — roughly 38× larger than Ed25519's 64 bytes. Directly posting them on-chain would make rollup calldata and L1 block sizes unacceptable.

The current mitigation path — and its ceiling. The widely discussed approach is to compress post-quantum signatures using zero-knowledge proofs: verify the signature inside a ZK circuit, publish only the succinct proof on-chain. This is a natural application of proof systems — elegant, even. Use the proof to attest that a valid signature exists without transmitting it.

But look at what this actually does to the proof system. The lattice arithmetic that makes post-quantum signatures secure is expensive. Moving it inside a ZK circuit does not eliminate that cost — it shifts it from the verifier to the prover. The prover must now perform the full signature verification inside the circuit, plus the overhead of proof generation. We have traded on-chain data bloat for off-chain computational bloat. The signature — the original source of the problem — remains at the center of the architecture. The proof system, no matter how powerful, is reduced to a compression utility for another primitive.

Consider the irony: STARKs were invented to provide scalable, transparent, post-quantum-secure proofs of computational integrity. They are among the most powerful cryptographic tools ever built. And in the signature-compression model, we are asking them to do janitorial work — making bloated signatures fit where they otherwise wouldn't.

After separation: Step back and ask: what does the consensus layer actually need? Not the signature itself, but the semantic guarantee that this transaction was authorized by the correct identity.

ZK-ACE takes this literally. Instead of compressing a post-quantum signature into a proof, it removes the signature from the consensus path entirely. The prover demonstrates in zero knowledge that their identity is consistent with an on-chain commitment and that the transaction has been authorized — without generating, transmitting, or verifying any signature object. The proof does not attest that "a valid signature exists somewhere." It directly attests that "this transaction is authorized by this identity."

The implications ripple through the entire stack. Block-level verification shifts from O(N) individual signature checks to a single aggregated proof — O(1). Post-quantum signature bloat becomes irrelevant, because there are no signatures on the consensus path to bloat. And the role of proof systems in the architecture undergoes a fundamental inversion.

In the compression model, the proof system is subordinate to the signature scheme — it exists to make signatures fit where they otherwise wouldn't. The signature is the primitive; the proof is the optimization.

In the direct-authorization model, this hierarchy flips. The proof system is the authorization primitive. Its expressiveness, its scalability properties, its post-quantum security, its prover efficiency — these are no longer nice-to-have optimizations. They are load-bearing structural requirements of the consensus mechanism itself. Every transaction's authorization flows through the proof system, not because it makes the system faster, but because the proof is the authorization.

This is the environment that scalable, transparent proof systems — STARKs being the canonical example — were built for. Not compressing signatures into smaller signatures, but providing direct, scalable attestations of computational statements. The statement is simply: "this transaction is authorized by the identity committed on-chain." The mathematics doesn't change. What changes is whether we ask the mathematics to serve a peripheral role or a foundational one.

Why it matters: Post-quantum migration is a universally acknowledged necessity, but the industry lacks viable paths that do not introduce significant performance degradation. Bypassing signatures to prove authorization directly offers a structural resolution — one that positions succinct proof systems at the very center of the blockchain trust model, rather than at its periphery.

3. Conditional Control ≠ Smart Contract Logic

The assumption we've accepted: When asset control needs to be conditional — activated upon inheritance, delegated under regulatory supervision, shared across institutional governance — the solution is a smart contract, a custodian, or a multisig arrangement.

Why it's breaking: Each of these approaches conflates control with something it shouldn't be tied to. Smart contracts enable conditional execution, but at the cost of on-chain state mutation, oracle dependencies, code immutability risks, and chain-specific logic — a conditional transfer on Ethereum has no meaning on Solana. Multisig and threshold signature schemes distribute control across parties, but require persistent availability of all participating keys, and changing conditions means resharing or migrating assets. Custodial solutions externalize control to intermediaries, sacrificing the very property that makes crypto assets distinctive: cryptographic self-sovereignty.

The core problem is deeper: in the current model, transferring control means transferring a key or its authority. There is no native cryptographic mechanism for control that is temporarily inactive, conditionally enabled, and revocable without state changes.

After separation: CT-DAP (Condition-Triggered Dormant Authorization Paths) models control rights as dormant authorization paths — composed of user-held credentials and one or more administrative authorization factors held by independent custodians. A control right is cryptographically nonexistent until all required factors are simultaneously available. The key insight: control of encrypted assets need not be transferred; it can be activated.

An inheritance path, for example, consists of the heir's credentials plus an administrative factor held by a legal executor. Under normal conditions, the heir cannot reconstruct the authorization path — the factor simply doesn't exist in their possession. Upon the triggering event, the executor releases the factor, and the path becomes constructible. Revocation is achieved by destroying the administrative factor — immediate, permanent, no on-chain transaction required, no state mutation, no key rotation.

This works because identity–authorization separation makes authorization factors independent of the identity root. Destroying or releasing a factor does not affect the underlying identity or any other authorization path derived from it.

Why it matters: As regulated financial products — estate planning, institutional custody, compliance-governed accounts — move onto blockchain infrastructure, the industry needs conditional control that is cryptographically enforceable, legally auditable, and chain-agnostic. Expressing these control semantics at the cryptographic layer, rather than in contract code or custodial agreements, means the enforcement mechanism is portable across chains and verifiable without trusting any intermediary's execution.

4. Wallet Recovery ≠ Backing Up a Seed

The assumption we've accepted: Deterministic wallet recovery relies on persistent backup of a master seed — typically stored as a mnemonic phrase.

Why it's breaking: The mnemonic user experience is catastrophic. It is essentially a human-readable encoding of a high-entropy key, requiring users to securely store 12–24 words on a physical medium with zero tolerance for error. Numerous users have permanently lost assets due to lost mnemonics. More fundamentally, the master seed is a single point of failure — once compromised, all keys derived from it, past and future, are irreversibly exposed.

Passkeys and WebAuthn improve local authentication but do not constitute a complete decentralized recovery protocol. Smart contract recovery (e.g., social recovery) requires pre-configured guardians, is visible on-chain, and is chain-specific.

After separation: ACE-GF eliminates the concept of a "master seed." The identity root exists only ephemerally in memory, deterministically reconstructed from a sealed artifact and authorization credentials, never persistently stored. On this foundation, VA-DAR builds a decentralized discovery-and-recovery layer: users need only an identifier (e.g., email) and a recovery passphrase for cross-device recovery, while the registry's discovery identifier is passphrase-derived, preventing attackers from enumerating wallet holders by traversing identifiers.

The prerequisite for recovery is no longer "you safeguarded that piece of paper," but "you remember your email and passphrase."

Why it matters: Wallet recovery is one of the last barriers to cryptocurrency mass adoption. A recovery scheme that is vendor-agnostic, chain-agnostic, enumeration-resistant, and PQC-ready directly impacts the onboarding path for the next billion users.

5. Paying Someone ≠ Knowing Their Address

The assumption we've accepted: Sending cryptocurrency requires the sender to know the recipient's on-chain address. Human-friendly identifier schemes (e.g., ENS, Solana Name Service) map identifiers directly to addresses via public registries, making the mapping globally visible.

Why it's breaking: Opaque hexadecimal addresses are a primary UX barrier to cryptocurrency adoption. Yet naïve identifier-to-address mapping introduces a critical privacy vulnerability: anyone who knows a user's email, phone number, or social handle can derive their on-chain address and inspect their entire transaction history, balances, and counterparty relationships. For public figures, a single known identifier can reconstruct a complete financial profile across every supported chain.

Stealth-address schemes (e.g., ERC-5564) mitigate linkability but still require the sender to know the recipient's public key or meta-address, and the recipient must scan every transaction to detect incoming payments. Neither approach achieves the UX simplicity of "send to email" with full privacy.

After separation: HFIPay decouples identifier routing, sender-side quote verification, and on-chain claim authorization. The sender specifies only a human-friendly identifier; a relay privately resolves it off-chain, derives a one-time deposit address, and commits only a per-intent blinded binding plus the quoted payment tuple on-chain. The chain sees neither the identifier nor a reusable recipient tag. The recipient later claims by proving in zero knowledge — via ZK-ACE — that the funded intent's blinded binding matches a handle derived from the same deterministic identity, authorizing release to a chosen destination. In a verified-quote deployment, the relay furnishes a sender-verifiable proof that the quoted binding is tied to the attested recipient, preventing recipient substitution before funding.

This mirrors the ACE pattern: human-readable routing and relay resolution sit outside the authorization boundary; the ledger enforces only blinded commitments and zero-knowledge authorization that the claim is consistent with the bound identity — identifier resolution and on-chain settlement are separate layers, as in the rest of the stack.

The relay is non-custodial by design: it is a privacy and availability dependency, but it cannot redirect funds. Claim authorization lives on-chain, enforced by the same zero-knowledge proof layer that authorizes regular transactions.

Why it matters: "Send crypto to an email address" is a long-sought UX goal, but every prior approach sacrificed either privacy (public registries) or decentralization (custodial intermediaries that can redirect funds). HFIPay achieves the UX target without either tradeoff. When composed with an n-VM architecture, the same claim mechanism extends to cross-chain settlement, making "send to email on any chain" a single unified flow.

6. Cross-Chain ≠ Bridging

The assumption we've accepted: Users maintain different key pairs and addresses on different chains, and cross-chain asset transfers rely on bridges — third-party systems that lock, mint, and verify.

Why it's breaking: Bridges are the single largest source of security failures in decentralized finance. Between 2021 and 2024, bridge exploits resulted in losses exceeding $2.8 billion. The root cause is identity fragmentation: the same user is an entirely different cryptographic entity on EVM, SVM, Bitcoin, and TVM, and cross-chain operations must establish trust between these different entities through external systems.

Existing multi-VM projects (Movement Labs, Eclipse, Sei v2) attempt to run multiple execution environments on a single chain, but typically subordinate one VM to another. Identity remains fragmented across VMs, and token transfers still require bridge-like mechanisms.

After separation: When the identity layer is decoupled from the execution environment, a single 32-byte identity commitment can deterministically generate native addresses for each VM through context-isolated HKDF derivation. Chain- and VM-specific parameters are folded entirely into the derivation context, so the identity anchor stays fixed while each execution environment gets its own isolated address family — the commitment does not depend on any particular VM's signing rules or address format. n-VM builds on this to construct a multi-VM Layer-1 architecture where EVM, SVM, BVM, and TVM coexist as co-equal execution environments on the same chain, sharing consensus, state, and a unified token ledger. Cross-VM token transfers are atomic operations on the same ledger, not bridge transactions.

Why it matters: Cross-chain interoperability is a decade-old unsolved problem. Starting from identity-layer unification, the "cross-chain" problem can be redefined as "cross-VM calls on the same chain," architecturally eliminating the need for bridges.

7. Verification ≠ Every Node Doing the Same Work

The assumption we've accepted: In blockchain networks, every node performs the same verification workflow for every transaction — including signature verification, transaction execution, and state transition.

Why it's breaking: This model leads to resource waste at two levels. At the network layer, if every propagated object carries a full validity proof (approximately 128 KB in post-quantum settings), relay bandwidth grows linearly with object count. At the execution layer, every validator independently performs O(N) signature verification, and in post-quantum settings must handle bloated signature data.

After separation: Identity–authorization separation enables verification responsibilities to be stratified by role. At the network layer, AR-ACE implements "proof-off-path" propagation — relay nodes forward transactions with only lightweight attestations (identity-bound commitments), without generating or carrying full validity proofs. Proof generation happens once, at the end of the pipeline, when the builder aggregates an entire block's worth of authorization statements.

At the execution layer, ACE Runtime replaces per-transaction signature verification with HMAC-based attestations — approximately 1 microsecond per transaction — and moves zero-knowledge proof generation off the critical path into a parallel pipeline phase. The three-phase Attest–Execute–Prove architecture targets 400 ms block times and sub-second cryptographic finality on commodity hardware, without requiring validators to run GPUs.

The result is a layered verification architecture where each role performs only the work appropriate to its responsibilities: relay nodes perform the lightest admission checks, validators handle attestation verification and transaction execution, and builders perform aggregated proof generation. The builder's aggregated proof — a single succinct attestation covering all transactions in the block — is where the full weight of the proof system is brought to bear. Because this happens exactly once per block rather than once per transaction, it is where scalable, transparent proof systems deliver their maximum leverage: one proof, full block coverage, post-quantum security by construction.

Why it matters: Blockchain scalability bottlenecks largely stem from the implicit assumption that "all nodes do the same work." Proposer-builder separation is already an industry trend, but identity–authorization separation provides a clean cryptographic foundation for this stratification — the authorization layer can be instantiated differently at each tier (HMAC at relay, attestation at validator, aggregated ZK proof at builder) without compromising the end-to-end security guarantee.

8. Agent Autonomy ≠ Economic Sovereignty

The assumption we've accepted: When AI agents participate in economic activity, they are either fully trusted (given a wallet) or fully untrusted (every transaction manually approved).

Why it's breaking: This binary model is unsustainable as agent capabilities grow rapidly. Full trust means an agent can unilaterally drain a wallet — an unacceptable risk. Per-transaction approval negates the entire value of agent automation — if every operation requires human confirmation, the agent is nothing more than a glorified form-filling tool.

After separation: Identity–authorization separation naturally provides a foundation for layered control over agent economic behavior. Deterministic policy can constrain or trim the effective authorization path available to each agent — limits, allowlists, and budgets determine which transactions may be authorized — without rotating the identity root or changing its on-chain commitments. AESP defines the central invariant "economically capable but never economically sovereign": agents possess cryptographic identities and transaction capabilities, but every economic action must pass through deterministic policy gates (per-transaction limits, address allowlists, budgets, time windows), with actions that fail policy checks escalated to human approval. Each transaction uses an HKDF-derived ephemeral address, and different agent contexts are cryptographically isolated — the transaction patterns of a user's procurement agent and investment agent cannot be correlated by on-chain observers.

Why it matters: AI agents are evolving from information-processing tools into economic actors. What the industry needs is not "bigger wallets for agents" or "more frequent human approvals," but a protocol-level boundary definition — specifying what agents can do autonomously, what they cannot, and how to escalate when boundaries are exceeded. The absence of standardization at this layer will become a structural barrier to scaling the agent economy.

Full Stack Architecture

The eight rethinks above are not independent observations. They are logical consequences of the same structural separation applied at different levels of the blockchain stack:

One primitive, one separation, eight rethinks — covering the full trust stack from key management to the agent economy.

What holds this architecture together is not a shared codebase or a monolithic protocol, but a shared structural insight: the conflation of identity with authorization was a reasonable simplification in 2009, but it has become the load-bearing constraint that limits what blockchains can express. Relaxing it — carefully, with formal security guarantees at each layer — opens design space that was previously inaccessible.

There is a deeper consequence worth noting. In the pre-separation world, proof systems occupy a specific and somewhat constrained niche: they compress rollup state, they enable private computations, they make existing data structures smaller. Valuable work, but peripheral to the core trust model. The chain's trust ultimately rests on signatures.

In the post-separation architecture, proof systems move to the center. ZK-ACE makes the proof the authorization primitive for every transaction. AR-ACE funnels all authorization through a single builder-generated proof per block. ACE Runtime builds its entire execution pipeline around the Attest–Execute–Prove cycle. HFIPay's claim authorization is a zero-knowledge proof. Even cross-VM identity verification in n-VM can be instantiated as proof-based attestation.

The authorization layer is the proof layer. The proof system's properties — scalability, transparency, post-quantum security, prover efficiency — are no longer features of an optimization tool. They are the consensus-critical parameters that determine what the chain can do and how fast it can do it. Proof systems designed for this role — scalable, transparent, quantum-resistant by construction — are not just compatible with this architecture. They are its natural foundation.

Open Questions

Any challenge to long-standing paradigms must honestly face its own uncertainties:

• Engineering feasibility. Performance figures in the papers come from analytical modeling and component-level benchmarks. The engineering complexity of an end-to-end system — state management, error handling, debugging toolchains — has not yet been validated in production.

• Ecosystem adoption path. Restructuring at the identity layer means this cannot be deployed as an incremental upgrade to existing chains. It must be built as a new chain or Layer-2 from scratch, significantly raising the bar for market adoption.

• Operational reliability. In the seed-storage-free model, simultaneous availability of the sealed artifact and authorization credentials is a prerequisite for system availability. Real-world performance at scale — including credential loss rates, recovery success rates, and user cognitive burden — requires deployment data.

• Security under adversarial conditions. Formal proofs are based on mature standard assumptions, but the security of composed protocols under adversarial conditions still requires independent audits and long-term operational validation.

• Proof system maturity. The architecture's reliance on succinct proofs as the authorization primitive means that prover performance, proof size, and verification cost are no longer peripheral concerns — they are consensus-critical parameters. Continued advances in proof system engineering are a prerequisite for production viability.

Conclusion

For nearly two decades, the blockchain industry has been building on assumptions inherited from a 2009 whitepaper: private key as control, signature as authorization, seed as identity, bridge as cross-chain, address as payment target. Each assumption was reasonable when it was made. Each has become a structural constraint as the demands on blockchain systems have expanded beyond what Satoshi could have anticipated.

Identity–authorization separation does not claim to solve all of these problems. It claims something more specific: that many of these constraints share a common root — the conflation of identity with authorization — and that carefully separating them, with formal guarantees at each layer, opens design paths that were previously invisible.

One thread runs through all eight rethinks. The separation transforms proof systems from an optimization layer into foundational infrastructure. In the current paradigm, zero-knowledge proofs make existing primitives more efficient — smaller signatures, compressed rollups, private computations. In the separated paradigm, proofs become the mechanism through which authorization itself is established. Every transaction on the chain passes through a proof system not because it makes the system faster, but because the proof is the authorization. This is not a marginal change in how we use these cryptographic tools. It is a reclassification of what role they play.

Whether these paths lead to production systems remains to be demonstrated. The distance from papers to working infrastructure, from proof of concept to ecosystem adoption, is often longer than the research itself. But the question is worth asking: are the things we've taken for granted for nearly twenty years truly the only way to build a blockchain — or are they simply the first way?

All papers referenced in this article are available on arXiv and in the papers repository. A formal protocol specification of ACE-GF is available as an IETF Internet-Draft.

arXiv links: ACE-GF · ZK-ACE · AR-ACE · ACE Runtime · VA-DAR · CT-DAP · AESP · n-VM · HFIPay

Contact: jason@acechain.io · @0xJasonw