aegis protocol

Your keys should outlive the quantum computer. Hash-only accounts for every chain.

5BHTmt8bnEizr5tcokZTWoHjMmptR29Me6MqLrVWpump

[aegis protocol @aegisprotocolon]

Our original contributions (can be verified)

Account state is carried by the UTXO lineage itself. The root, recovery root, epoch, cached subtree root, and nextIdx are all encoded into three Tapscript leaves, and the output spent each time becomes the next state. All previous on-script hash signature schemes were one-time commitments or BitVM-style off-chain states; no one has put a sustainable, stateful account into the UTXO chain.

Chain-Cached Hypertree. Subtree roots are only put on-chain once every 1,024 spends (execFirst), and afterwards each spend only includes one bottom-layer tree (exec). This is how we ported EVM's CCHS directly onto Bitcoin and measured the difference between 3,300 vB and 6,336 vB—the "cache once, amortize a thousand times" structure has no precedent in Bitcoin hash signature discussions.

Key rotation as protocol-level leaves (recover, 3,207 vB). The recovery tree allows the account to switch an entire signature tree without changing the address lineage; other solutions require migration once the leaves are exhausted.

No elliptic curve keys at all. Internal keys are NUMS points, no key path, and there are no reversible objects for Shor in both static and mempool contexts. Most designs discussed in BIP-360 still retain EC coexistence.

Actually executed. Inquisition signet block 325,621 had six consecutive spends; the wallet’s self-built spends were then packaged, and the CI re-ran the entire lineage on the Inquisition regtest node. Most similar works remain on mailing lists or regtest scripts.

@toly @VitalikButerin

[aegis protocol @aegisprotocolon]

@VitalikButerin

We put a post-quantum account on Bitcoin and spent from it.

On Bitcoin Inquisition signet, an Aegis UTXO carries its whole account state — root, recovery root, epoch, cached subtree, next index — in three Tapscript leaves. There is no elliptic-curve key anywhere: the internal key is a NUMS point, and each spend is one WOTS+ signature verified in Script over the transaction's own sighash.

Measured, not estimated: 3 300 vB per cached spend, 6 336 vB for the first spend of a subtree, 3 207 vB to rotate keys. Six consecutive spends in block 325 621; spends built by the wallet itself mined after. Every txid is in the repo.

This is the first hash-based account whose state lives in the UTXO lineage itself — no counter contract, no trusted server, nothing for Shor to invert. https://t.co/yeAvd47DtY

[aegis protocol @aegisprotocolon]

@VitalikButerin

We put a post-quantum account on Bitcoin and spent from it.

On Bitcoin Inquisition signet, an Aegis UTXO carries its whole account state — root, recovery root, epoch, cached subtree, next index — in three Tapscript leaves. There is no elliptic-curve key anywhere: the internal key is a NUMS point, and each spend is one WOTS+ signature verified in Script over the transaction's own sighash.

Measured, not estimated: 3 300 vB per cached spend, 6 336 vB for the first spend of a subtree, 3 207 vB to rotate keys. Six consecutive spends in block 325 621; spends built by the wallet itself mined after. Every txid is in the repo.

This is the first hash-based account whose state lives in the UTXO lineage itself — no counter contract, no trusted server, nothing for Shor to invert. https://t.co/yeAvd47DtY

[aegis protocol @aegisprotocolon]

MIT student here. I built Aegis, a hash-only account protocol, and I'd like real criticism before I trust it.

Design: WOTS+ (w=16, 67 chains) over a 10+10 hypertree, tweaked hashing with a per-account pkSeed. The verifier is a contract, so the top layer is verified once per 1,024 leaves and the subtree root is cached on chain; routine spends carry one bottom-layer signature (2.5 KB EVM, 864 B Solana). Index discipline: on-chain nextIdx per lane, record-before-sign on the client. Transition logic proved in Lean 4; the reduction to (second-)preimage resistance is argued in the spec, not machine-checked.

Where I'm least sure: – is caching the subtree root on chain introducing any attack I haven't modelled (the proof abstracts the hash)? – the C-20 set (n=24, w=256) for Solana: the multi-user term is closed by pkSeed, but I have no written single-tree constants – Bitcoin: lifting the sighash with a Schnorr check against G + CSFS, then verifying WOTS+ over it in Tapscript. Is there a binding gap I'm missing?
, proofs and signet txids in the repo. Please tell me what breaks. https://t.co/4mbk4ZH35Y

[aegis protocol @aegisprotocolon]

MIT student here. I built Aegis, a hash-only account protocol, and I'd like real criticism before I trust it.

Design: WOTS+ (w=16, 67 chains) over a 10+10 hypertree, tweaked hashing with a per-account pkSeed. The verifier is a contract, so the top layer is verified once per 1,024 leaves and the subtree root is cached on chain; routine spends carry one bottom-layer signature (2.5 KB EVM, 864 B Solana). Index discipline: on-chain nextIdx per lane, record-before-sign on the client. Transition logic proved in Lean 4; the reduction to (second-)preimage resistance is argued in the spec, not machine-checked.

Where I'm least sure: – is caching the subtree root on chain introducing any attack I haven't modelled (the proof abstracts the hash)? – the C-20 set (n=24, w=256) for Solana: the multi-user term is closed by pkSeed, but I have no written single-tree constants – Bitcoin: lifting the sighash with a Schnorr check against G + CSFS, then verifying WOTS+ over it in Tapscript. Is there a binding gap I'm missing?

Unaudited. Spec, proofs and signet txids in the repo. Please tell me what breaks. https://t.co/4mbk4ZH35Y

[aegis protocol @aegisprotocolon]

MIT student here. I built Aegis, a hash-only account protocol, and I'd like real criticism before I trust it.

Design: WOTS+ (w=16, 67 chains) over a 10+10 hypertree, tweaked hashing with a per-account pkSeed. The verifier is a contract, so the top layer is verified once per 1,024 leaves and the subtree root is cached on chain; routine spends carry one bottom-layer signature (2.5 KB EVM, 864 B Solana). Index discipline: on-chain nextIdx per lane, record-before-sign on the client. Transition logic proved in Lean 4; the reduction to (second-)preimage resistance is argued in the spec, not machine-checked.

Where I'm least sure: – is caching the subtree root on chain introducing any attack I haven't modelled (the proof abstracts the hash)? – the C-20 set (n=24, w=256) for Solana: the multi-user term is closed by pkSeed, but I have no written single-tree constants – Bitcoin: lifting the sighash with a Schnorr check against G + CSFS, then verifying WOTS+ over it in Tapscript. Is there a binding gap I'm missing?

in the repo. Please tell me what breaks. https://t.co/4mbk4ZH35Y

[aegis protocol @aegisprotocolon]

New: Aegis is now a browser extension.

One 24-word phrase, one password, and the Protect / Spend panels open in a side panel — no MetaMask in the loop. Gas is paid by a key derived from the same phrase; it holds nothing, so even a quantum break of it costs you gas money, not your assets.

Same code as the web wallet: hash-only CCHS accounts on 14 EVM chains, Bitcoin signet, tokenised RWAs checked against the issuer's allowlist before anything moves.

Phrase encrypted locally (AES-256-GCM, PBKDF2 600k). No content scripts, no remote code.

Build from source and load unpacked https://t.co/Cd0bQiksDA

[aegis protocol @aegisprotocolon]

Audit Report ：https://t.co/en8t0f0cgv

[aegis protocol @aegisprotocolon]

To be clear: Aegis is not built for one memecoin, and not built for Solana alone.

It is a chain-agnostic post-quantum account protocol. CCHS rests on one assumption — the hash function the chain already runs: keccak256 on EVM, sha256 on Solana, OP_SHA256 on Bitcoin. Any chain with a hash opcode can run it.

One mnemonic, one independent key tree per chain, the same signature, cache and recovery logic everywhere: · 14 EVM chains (contracts + deterministic factory, same address on every chain) · Solana mainnet live — any SPL / Token-2022 asset · Bitcoin signet (OP_CAT covenant UTXO account) · TRON byte-identical; Move / CosmWasm / NEAR / Starknet / TON adapters in the repo

What it protects is the asset itself: ETH, SOL, BTC, ERC-20, SPL, memecoins — anything an address can hold. Shor breaks ECDSA and ed25519 on every chain alike; hash signatures survive it on every chain alike.

https://t.co/yeAvd475Eq

5BHTmt8bnEizr5tcokZTWoHjMmptR29Me6MqLrVWpump

[aegis protocol @aegisprotocolon]

A quantum computer steals coins by turning a public key into a private key. An Aegis account has no public key on chain, only a hash — so there is nothing to turn.

------ $aegis

[aegis protocol @aegisprotocolon]

@El_heisenberg https://t.co/yEzxP4f4hn

These are all the audits we've gone through, and you can also check them yourself.

[aegis protocol @aegisprotocolon]

If you give it a try and read GitHub carefully, you'll find that everything works out and is very safe.

[aegis protocol @aegisprotocolon]

A quantum computer steals coins by turning a public key into a private key. An Aegis account has no public key on chain, only a hash — so there is nothing to turn.

------ $aegis

[aegis protocol @aegisprotocolon]

@El_heisenberg You can do an in-depth analysis of the library using any free audits and AI.

[aegis protocol @aegisprotocolon]

A quantum computer steals coins by turning a public key into a private key. An Aegis account has no public key on chain, only a hash — so there is nothing to turn.

------ $aegis

[aegis protocol @aegisprotocolon]

@VitalikButerin You wrote that hash-based beats lattice-based wherever hash-based is possible. I'm an MIT student and I spent the past months trying to make it possible for accounts. Before I trust it, I'd rather hear from you where it breaks.

Aegis / CCHS: WOTS+ (w=16, 67 chains) over a 10+10 hypertree, tweaked hashing with a per-account pkSeed, keccak or SHA-256 only. The verifier is a contract, so the top layer is checked once per 1,024 leaves and the subtree root is cached on chain; a routine spend carries one bottom-layer signature, 2.5 KB. Index discipline is on-chain nextIdx per device lane plus record-before-sign on the client. Those transition rules are proved in Lean 4; the reduction to (second-)preimage resistance is only argued in the spec.

What I'm least sure about: – does caching subtree roots in contract storage open anything the proof's hash abstraction hides? – for the n=24, w=256 set I use on Solana, the multi-user term is closed by pkSeed, but I don't have single-tree constants written down – on Bitcoin signet I lift the sighash with a Schnorr check against G + CHECKSIGFROMSTACK and verify WOTS+ over it in Tapscript. Is there a binding gap?

Also: is this the kind of account the EIP-8141 path would want to absorb, or does it fight it?

Unaudited. Spec, Lean proofs, signet txids all in the repo. https://t.co/4mbk4ZH35Y

[aegis protocol @aegisprotocolon]

New in the Aegis wallet: tokenised real-world assets.

BUIDL, USDY, OUSG, USTB, BENJI, PAXG and XAUt now sit in the Protect panel on every chain their issuer supports. Most of these tokens refuse addresses the issuer hasn't registered — so the wallet asks the token first, shows you the answer, and never spends a one-time key on a transfer that would fail. Treasuries and gold behind a hash-only account, same mnemonic, no public key on chain.

5BHTmt8bnEizr5tcokZTWoHjMmptR29Me6MqLrVWpump

$aegis

[aegis protocol @aegisprotocolon]

@toly We built the thing the Winternitz Vault pointed at: a hash-only account on Solana, not a one-shot vault.

– 2^20 one-time keys per account from one mnemonic, no address change per spend – Hypertree upper layers cached on chain once per 1,024 spends, so a routine spend is one 864 B signature – Fits a v0 tx with a lookup table: 1,090 of 1,232 bytes – 616–708K CU measured on the SBF build – Program is on mainnet-beta; verifier shared with EVM, Bitcoin signet and five other targets via one fixture set – Transition logic machine-checked in Lean 4; seven static scanners, reports in repo

Unaudited, open source, no token. Would value your read on the CU budget and the PDA layout. https://t.co/wf9yzwJWSs

[aegis protocol @aegisprotocolon]

Why Aegis is real quantum protection
Quantum computers have exactly two known attacks that matter for cryptography. Real quantum protection has to answer both.

1. Shor's algorithm: private key from public key. This is the fatal one. Polynomial time, effective against ECDSA, Schnorr, Ed25519 and RSA alike. Every account on Bitcoin, Ethereum and Solana today is an elliptic-curve public key; when Shor arrives, all of them fall.

2. Grover's algorithm: faster brute force against hash functions. Only a square-root speed-up: a preimage search on a 256-bit hash drops from 2^256 to 2^128. That is not a break, it is halving the bit count, and it is the floor NIST accepted when it standardised SPHINCS+/SLH-DSA.
Aegis's whole design is one sentence: remove from the account everything with structure Shor can exploit, and leave only hashes. The account on chain is two hash roots. A signature is a set of Winternitz one-time hash chains. Verification is hashing forward and comparing. No elliptic curves, no lattices, no pairings; Shor has nothing to act on. What remains is Grover, and Grover leaves 128 bits on a 256-bit hash.
Which quantum attacks it defends against

Long-range attacks (harvest now, break later). The attacker downloads the chain today, waits for a quantum computer, then derives private keys from historical public keys and spends dormant coins. 6.9 million BTC sit in that category. An Aegis account at rest shows only hash roots. There is no public key, so there is nothing to harvest.

Short-range attacks (the mempool race). A conventional account reveals its public key when it broadcasts; an attacker derives the private key before confirmation and outbids the transaction with a higher fee. An Aegis spend reveals one one-time key that is valid for one message digest only. Using it to sign a different target requires inverting hash chains or finding a second preimage: a 2^128 Grover problem, not a Shor problem. The on-chain nextIdx retires the index at the same time.
Address-reuse attacks. Bitcoin users are told never to reuse addresses because one spend exposes the key forever. Aegis uses a fresh leaf on every spend and the exposed key is consumed on inclusion; reuse does not exist at the protocol level, so the user cannot get it wrong.

Key-recovery from the seed derivation. Every key is derived with HKDF and SHA-256 from the mnemonic; there is no elliptic-curve step anywhere in the path from mnemonic to on-chain root. A quantum attacker who sees every signature you ever made still faces 2^128 to reach the master.
Multi-user and cross-chain attacks. Attacking many accounts at once normally gives a quantum adversary a batch advantage. Every Aegis hash is tweaked with a per-account pkSeed and every chain, epoch and tree has its own domain-separated key, so no work done against one account or one chain transfers to another. This is closed by construction, not by argument.

Quantum collision attacks. Brassard–Høyer–Tapp gives collisions at 2^85 on a 256-bit hash. CCHS does not depend on collision resistance: the signer never gets to choose both sides of a hash, the message digest binds the lane nonce and index, and the tweaked hashing makes every node a distinct target. The security argument reduces to (second-)preimage resistance, which is where the 2^128 figure comes from; the spec's conservative accounting for the chain and node paths quotes 2^113.

What it does not defend, said plainly
A compromised device. If malware holds your mnemonic or your signing session, no signature scheme helps. A break of SHA-256 or keccak themselves, beyond Grover; that is the single stated assumption. The consensus layer of the chains we run on: validator signatures on Ethereum, Solana and elsewhere are still elliptic-curve, and that migration belongs to those protocols. Coins already sitting at exposed addresses; those must be moved, and Aegis is a place to move them.

That is the claim: against Shor, nothing to attack; against Grover, 128 bits; against the attacks people are actually afraid of on chain today, a concrete answer for each. And the whole of it is running code, not a roadmap.

5BHTmt8bnEizr5tcokZTWoHjMmptR29Me6MqLrVWpump

[aegis protocol @aegisprotocolon]

1/ Bitcoin has no contracts, so we made the account a UTXO lineage in Tapscript. Here is what happened when we ran it on Bitcoin Inquisition signet, where OP_CAT and OP_CHECKSIGFROMSTACK are active.

2/ Funded one account output: tb1p0e85juwrcgztj52ytssg652tw8xx4yvmfhr8nnmdu539a2l5wmkq8wezc3. Internal key is a NUMS point — no key path, nothing for Shor to invert. The only way out is a script leaf that verifies a WOTS+ hash signature.

3/ Six spends, one lineage, every leaf type: execFirst 6f7145ee… 6,336 vB exec f87840b8… 3,300 vB exec 06d82ae3… 3,300 vB recover 7400ea6e… 3,207 vB (epoch 0 → 1) execFirst 765cb6b4… 6,334 vB exec 4963ebf7… 3,269 vB All six confirmed in block 325,621.

4/ Each spend consumed the account UTXO and created its successor at the same script, plus a 2,000 sat payment back to the faucet. The witness holds the one-time signature, the Merkle path and the sighash lifted onto the stack via a Schnorr check against G + CHECKSIGFROMSTACK, so the hash signature commits to every input and output.

5/ Real-world friction we hit and kept: the signet miner was skipping 1.1 sat/vB, so the first five sat unmined for four blocks. The sixth spend was signed from the master key alone, with no state but the current UTXO, at 4.3 sat/vB as a CPFP child. The whole package confirmed together. A lineage can be continued by anyone holding the key.

6/ Then the wallet, in a browser. Faucet sent 50,000 sat to a fresh account. First spend (execFirst) signed in 4.4 s, relayed, mined: f5293b7d82fc7d28… in block 325,625. Reloaded the page, the wallet rebuilt the account state from https://t.co/jMEmFO9wPb in about 2 s by decoding the witness, and the next exec signed in 0.5 s and was accepted by the node.

7/ One thing the chain taught us: these transactions are non-standard to vanilla Bitcoin Core, so https://t.co/jMEmFO9wPb couldn't see them until they were mined. The wallet now broadcasts through a small relay to an Inquisition node. Code is in the repo.

8/ CI reproduces this on every commit: a real Inquisition 29.4 regtest node, standardness on, the full execFirst → exec → exec → recover → execFirst lineage.

9/ What's missing is not ours to add. Mainnet lacks both opcodes; OP_CAT there is OP_SUCCESS, which would make any such output anyone-can-spend. We won't deploy to mainnet until Bitcoin activates them. Signet is the live network, and it is labelled that way

5BHTmt8bnEizr5tcokZTWoHjMmptR29Me6MqLrVWpump

$AEGIS

[aegis protocol @aegisprotocolon]

1/ Bitcoin has no contracts, so we made the account a UTXO lineage in Tapscript. Here is what happened when we ran it on Bitcoin Inquisition signet, where OP_CAT and OP_CHECKSIGFROMSTACK are active.

2/ Funded one account output: tb1p0e85juwrcgztj52ytssg652tw8xx4yvmfhr8nnmdu539a2l5wmkq8wezc3. Internal key is a NUMS point — no key path, nothing for Shor to invert. The only way out is a script leaf that verifies a WOTS+ hash signature.

3/ Six spends, one lineage, every leaf type: execFirst 6f7145ee… 6,336 vB exec f87840b8… 3,300 vB exec 06d82ae3… 3,300 vB recover 7400ea6e… 3,207 vB (epoch 0 → 1) execFirst 765cb6b4… 6,334 vB exec 4963ebf7… 3,269 vB All six confirmed in block 325,621.

4/ Each spend consumed the account UTXO and created its successor at the same script, plus a 2,000 sat payment back to the faucet. The witness holds the one-time signature, the Merkle path and the sighash lifted onto the stack via a Schnorr check against G + CHECKSIGFROMSTACK, so the hash signature commits to every input and output.

5/ Real-world friction we hit and kept: the signet miner was skipping 1.1 sat/vB, so the first five sat unmined for four blocks. The sixth spend was signed from the master key alone, with no state but the current UTXO, at 4.3 sat/vB as a CPFP child. The whole package confirmed together. A lineage can be continued by anyone holding the key.

6/ Then the wallet, in a browser. Faucet sent 50,000 sat to a fresh account. First spend (execFirst) signed in 4.4 s, relayed, mined: f5293b7d82fc7d28… in block 325,625. Reloaded the page, the wallet rebuilt the account state from https://t.co/jMEmFO9wPb in about 2 s by decoding the witness, and the next exec signed in 0.5 s and was accepted by the node.

7/ One thing the chain taught us: these transactions are non-standard to vanilla Bitcoin Core, so https://t.co/jMEmFO9wPb couldn't see them until they were mined. The wallet now broadcasts through a small relay to an Inquisition node. Code is in the repo.

8/ CI reproduces this on every commit: a real Inquisition 29.4 regtest node, standardness on, the full execFirst → exec → exec → recover → execFirst lineage.

9/ What's missing is not ours to add. Mainnet lacks both opcodes; OP_CAT there is OP_SUCCESS, which would make any such output anyone-can-spend. We won't deploy to mainnet until Bitcoin activates them. Signet is the live network, and it is labelled that way

5BHTmt8bnEizr5tcokZTWoHjMmptR29Me6MqLrVWpump

$AEGIS

[aegis protocol @aegisprotocolon]

1/ We just added Mythril to the scanner set for Aegis. That makes seven: Slither, MIESC, PostQuant, Audit Forge, SolidityScan, Aderyn, Mythril.

2/ Mythril (symbolic execution): no issues in AegisCCHS, AegisCCHSK or the factory. Its only Medium is in a legacy helper that holds no funds — an immutable read flagged as state access. Written up.

3/ Aderyn: 5 High, all triaged. CREATE2 init-code hashing, signer-chosen forwarding calls, correct Yul shift order, a vendored verifier's early return. None touches funds.

4/ Everything is reproducible: .github/workflows/audit.yml runs Aderyn and Mythril on demand, reports are committed under audit/, the reading is in SECURITY.md §3.1.

5/ None of this is an audit, and the repo says so in the first line of SECURITY.md. What the tools can't see — WOTS+ arithmetic and index discipline — is covered by Lean 4 proofs, model checks with seeded bugs, Foundry and cross-language fixtures. more external audit https://t.co/OZnpc6CV7P

5BHTmt8bnEizr5tcokZTWoHjMmptR29Me6MqLrVWpump

$aegis