Qairos

Post-quantum security for Ethereum . We watch for the moment quantum computers can break ECDSA keys, and keep your assets safe when it comes.

[Qairos @Qairos_app]

QAIROS $QRS is live.

CA: 0xe0bc2162104f64d0b399dede94aa72d0001a3fd1

Qairos is post-quantum security for Ethereum L1: generate a quantum-resistant key (NIST FIPS 204), register it on-chain, and keep a recovery kit for the day today's keys are no longer enough.
https://t.co/2uAI9Ztuzk

[Qairos @Qairos_app]

Qairos feature: Ark 🛟

Menu: Register PQ key

What it does
Locks a fingerprint of your post-quantum key on-chain today, so you can prove later that it was yours before any break.

The formula
commitment = keccak256(pqPublicKey ‖ salt ‖ address)

Mechanism
1. Generate your ML-DSA key
2. The app picks a random 32-byte salt
3. It hashes pk + salt + your address into one 32-byte commitment
4. You call QairosArk.commit(commitment) from your wallet
5. The contract stores the commitment, timestamp, and block
6. You download a recovery kit (pk, salt, address, commitment)

The key rule
pre-Moment = firstBreakTime == 0 OR committedAt < firstBreakTime

After the first warning-tier break, existing entries can't be overwritten. Someone holding your old ECDSA key can't replace your proof.

The hash reveals nothing. Without the kit, nobody knows your key or salt.

⚠️ The kit isn't a wallet backup. Keep it private.

https://t.co/2uAI9ZsWJM

[Qairos @Qairos_app]

Qairos feature: Post-quantum key 🔑

Menu: Register PQ key

What it does
Generates an ML-DSA-44 key pair, the lattice-based signature standard NIST published as FIPS 204.

The formula
seed = keccak256("qairos-mldsa" ‖ QRNG ‖ CSPRNG)
(sk, pk) = ML-DSA-44.KeyGen(seed)

Mechanism
1. The app asks for 32 bytes from a quantum random source (QRNG)
2. It mixes them with 32 bytes from your browser's secure randomness
3. The mixed seed generates your key pair
4. Everything stays in your browser: no transaction, no gas, no server

Sizes
→ Public key: 1,312 bytes
→ Signature: 2,420 bytes
→ ECDSA for comparison: 33-byte key, 65-byte signature

Post-quantum keys are bigger. That's the price of security that doesn't depend on elliptic curves.

https://t.co/2uAI9ZsWJM

[Qairos @Qairos_app]

Why this matters:

Everyone argues about when quantum computers will break crypto. Few actually measure it.

Break the Curve turns the math behind every Ethereum key into open, on-chain challenges, so security is proven by testing, not by opinions.

[Qairos @Qairos_app]

Something is coming 👀

BREAK THE CURVE: Qairos Contest Season 01

6 tiers of elliptic-curve challenges on Ethereum L1. Solve k·G = Q, commit, reveal. The contract picks the winner. No judges, no entry fee.

Prizes and start date announced soon.

https://t.co/KYIj4UEFew

[Qairos @Qairos_app]

Something is coming 👀

BREAK THE CURVE: Qairos Contest Season 01

6 tiers of elliptic-curve challenges on Ethereum L1. Solve k·G = Q, commit, reveal. The contract picks the winner. No judges, no entry fee.

Prizes and start date announced soon.

https://t.co/KYIj4UEFew

[Qairos @Qairos_app]

@kn1ghtdegen @dingalingts Appreciate it 🙏

That's the whole point: if the key never touches a server, there's nothing to hack on our side. Post-quantum keys generated locally in seconds.

7 more features coming in this series 👀

[Qairos @Qairos_app]

Qairos feature: Post-quantum key 🔑

Menu: Register PQ key

What it does
Generates an ML-DSA-44 key pair, the lattice-based signature standard NIST published as FIPS 204.

The formula
seed = keccak256("qairos-mldsa" ‖ QRNG ‖ CSPRNG)
(sk, pk) = ML-DSA-44.KeyGen(seed)

Mechanism
1. The app asks for 32 bytes from a quantum random source (QRNG)
2. It mixes them with 32 bytes from your browser's secure randomness
3. The mixed seed generates your key pair
4. Everything stays in your browser: no transaction, no gas, no server

Sizes
→ Public key: 1,312 bytes
→ Signature: 2,420 bytes
→ ECDSA for comparison: 33-byte key, 65-byte signature

Post-quantum keys are bigger. That's the price of security that doesn't depend on elliptic curves.

https://t.co/2uAI9ZsWJM

[Qairos @Qairos_app]

Qairos feature 2/8: Sign & verify $QRS

Menu: Sign

What it does
Signs any message with your ML-DSA-44 key. Anyone can check that it's authentic and unchanged.

The formula
σ = ML-DSA.Sign(sk, message)
ML-DSA.Verify(pk, message, σ) → true / false

Mechanism
1. Create a key, or reuse the one from your Ark session
2. Write a message (a statement, an instruction, a proof)
3. Sign it and get the signature σ
4. Share message + pk + σ
5. Anyone can verify. Change even one character and verification returns false

Why it's post-quantum
ECDSA's security rests on the discrete log problem, which Shor's algorithm breaks. ML-DSA rests on lattice problems (Module-LWE / SIS), which have no known efficient quantum attack.

Note: this signs messages, not Ethereum transactions. ETH transfers still use your normal wallet.

[Qairos @Qairos_app]

Qairos feature: Post-quantum key 🔑

Menu: Register PQ key

What it does
Generates an ML-DSA-44 key pair, the lattice-based signature standard NIST published as FIPS 204.

The formula
seed = keccak256("qairos-mldsa" ‖ QRNG ‖ CSPRNG)
(sk, pk) = ML-DSA-44.KeyGen(seed)

Mechanism
1. The app asks for 32 bytes from a quantum random source (QRNG)
2. It mixes them with 32 bytes from your browser's secure randomness
3. The mixed seed generates your key pair
4. Everything stays in your browser: no transaction, no gas, no server

Sizes
→ Public key: 1,312 bytes
→ Signature: 2,420 bytes
→ ECDSA for comparison: 33-byte key, 65-byte signature

Post-quantum keys are bigger. That's the price of security that doesn't depend on elliptic curves.

https://t.co/2uAI9ZsWJM

[Qairos @Qairos_app]

Quantum security just became one of crypto's hottest narratives.

@NEARProtocol co-founder @ilblackdragon says NEAR accounts can become quantum-resistant with a simple key update, no asset migration needed.

That works because NEAR accounts aren't tied to one key. You can rotate keys and keep the account.

Ethereum is different.

An Ethereum EOA address is derived from its ECDSA public key. You can't swap that key. When the time comes, you'd have to move everything to a new account.

The Ethereum roadmap is already preparing for this. @VitalikButerin has written openly about quantum risk, and @drakefjustin's Lean Ethereum vision includes post-quantum signatures at the protocol level.

But protocol upgrades take years. Users need a way to prepare now.

That's why Qairos is building on Ethereum:

◆ Create a post-quantum key (ML-DSA, NIST FIPS 204) in your browser
◆ Register a commitment on-chain today, so you can prove the key was yours before any break
◆ An on-chain Oracle that rises only when real elliptic-curve challenges are broken: evidence, not hype
◆ A Vault recovery path that opens once the alarm trips

Different chains, different designs, same direction. The question is no longer "if" but "how do we migrate?"

Qairos is live on Ethereum mainnet. Still early, unaudited, and open to feedback.

https://t.co/2uAI9Ztuzk

[The Rollup @therollupco]

NEAR co-founder @ilblackdragon says any @NEARProtocol user can make their account quantum resistant today, without moving a single asset.

"We've designed NEAR with quantum in mind in 2018."

"Anyone individually right now can effectively update their account without moving any assets."

"Without needing to withdraw from wallets, pay taxes, do any of this."

"You can literally just update the keys to be post quantum right now."

[Qairos @Qairos_app]

Quantum security is now a headline topic at TOKEN2049.

The conversation has moved from "is this real?" to "how do we migrate?" That's the right shift.

Every chain will answer it differently. For Ethereum, Qairos is building the preparation layer: post-quantum keys accounts can register early, plus an on-chain signal that tracks real progress on breaking elliptic-curve keys.

[Qairos @Qairos_app]

Great to see quantum security on the main stage at TOKEN2049. A year ago this was a niche topic.

We're working on the same question for Ethereum accounts at Qairos. Looking forward to the talk 👀

[NEAR Protocol @NEARProtocol]

https://t.co/2s8jQZVBit

[Qairos @Qairos_app]

This works on @NEARProtocol because accounts aren't tied to one key. You can swap keys and keep the account.

Ethereum EOAs are different: your address is derived from your ECDSA public key. You can't "update" that key. You'd have to move everything to a new account.

That's the gap Qairos is building for:
◆ Register a post-quantum key (ML-DSA) for your account today
◆ Prove it was yours before any break
◆ Have a recovery path ready, instead of a last-minute migration

Account design decides how painful the post-quantum transition will be. @General_Illia

[Cointelegraph @Cointelegraph]

🔥 UPDATE: NEAR co-founder Illia Polosukhin says NEAR accounts can become quantum-resistant with a key update, with no asset migration needed.

[Qairos @Qairos_app]

Really sorry, that's a painful one.

If the seed was ever imported into MetaMask, treat that whole seed as burned, Ledger included. Make a fresh seed on the device, never type it anywhere, and move whatever's left.

Also: ignore anyone who DMs you offering "recovery". Those are almost always scams. Take the break, you've earned it.

[Qairos @Qairos_app]

@ohyishi Great breakdown. Layers 1–3 protect the box, layer 4 protects the trust.

The next step for layer 4: post-quantum signatures. Firmware keys live for years, so they're the first that should migrate.

That's the layer we focus on at Qairos for Ethereum.

[Qairos @Qairos_app]

@Tangem Removing the seed phrase removes a whole class of attacks 👏

We're working on another layer: making Ethereum accounts ready for post-quantum signatures, so keys stay safe as cryptography evolves.

[Qairos @Qairos_app]

Post-quantum on testnet is a good start for any chain.

The harder part is migration: getting millions of users onto new keys before they need them.

That's what Qairos is building for Ethereum. Register a post-quantum key early, prove ownership later.

[That Martini Guy ₿ @MartiniGuyYT]

Justin Sun says TRON’s post-quantum cryptography is now live on testnet.

The goal is to prepare the network for future threats from quantum computing, which could eventually undermine the cryptography protecting blockchain transactions.

TRON says it is ready to bring quantum-resistant technology to mainnet when needed.

The important distinction is that this is still testnet deployment, not a completed mainnet upgrade.

Quantum threats may not be an immediate danger, but the race to prepare crypto infrastructure has already begun.

[Qairos @Qairos_app]

Good to see more chains taking this seriously. The testnet vs mainnet distinction matters.

On Ethereum, we're building Qairos: post-quantum keys (ML-DSA, NIST FIPS 204) that accounts can register early, plus an on-chain signal that tracks real progress on breaking elliptic-curve keys.

Preparing early beats migrating in a panic.

[Qairos @Qairos_app]

Agreed, different wallets come with different risks.

The one we're focused on is how keys are generated. Weak entropy breaks a key before any attacker even shows up.

That's what we're building at Qairos: multi-source entropy (QRNG + local CSPRNG) and post-quantum keys for Ethereum accounts.

[Qairos @Qairos_app]

The worst incident here wasn't a hack. It was weak randomness.

Keys are only as strong as their entropy. Qairos mixes multiple sources when generating post-quantum keys, so no single source can compromise them.

Different layers, different risks. Stay SAFU.

[CZ 🔶 BNB @cz_binance]

Stay SAFU out there!

FWIW, I am not against hardware wallets, or self-custody. Different wallets/product for different use cases. All have different security implications and best practicies. YZiLabs invested in OneKey, SafePal (hardware wallets), TrustWallet (mobile), etc.

[Qairos @Qairos_app]

Qairos is live on Ethereum mainnet. Six contracts that get Ethereum accounts ready for post-quantum security:
◆ Oracle : public quantum threat level (0–5)
◆ Canary : a ladder of ECDLP bounties. A broken rung is an early warning
◆ Ark : commit a post-quantum key hash today, recover with it later
◆ Vault : ETH that moves to your PQ recovery address if the threat trips
◆ Market : predict when the canary keys fall
◆ Insurance : event-based cover priced from that

market Oracle 0x3039E2c775d37225f6DaAcaaD858A88d6ABBD9D2 Canary 0xd16f9099888AA56b328c91B90ca5FeA0531c4B9f Ark 0x41D5FF38ca6a8d185D05306d836D5BE986Ee47d7 Vault 0xd207cF263bF288aDd199ca6777b413A68494961a Market 0xeD77cA63F7eCB92F6569d4b6c6F9A8a9CEe139E5 Insurance 0x2D90C8ADB951f3f9286ac239ff7e3d641d057902

[Qairos @Qairos_app]

Protect your Ethereum account for the post-quantum era, in three steps.

1. Generate a post-quantum key
An ML-DSA-44 key (NIST FIPS 204), created in your browser. It never leaves your device.

2. Register it on-chain
Only a hash goes on Ethereum. It proves the account is yours, and your recovery kit stays offline.

3. Protect your contracts
The Qairos Contract Wizard builds vaults and treasuries that lock sensitive functions when a security alert is active, with recovery through your post-quantum key.

Ethereum is planning its own post-quantum upgrade around 2029. Preparing your keys early is the calm, simple way to be ready.

Status: working prototype, open source. Audit and testnet come before mainnet.

https://t.co/2uAI9Ztuzk

[Qairos @Qairos_app]

"About a 20% chance" that quantum computers capable of breaking today's cryptography arrive before 2030.

That's the forecast @VitalikButerin pointed to, as covered by @Cointelegraph. The median estimate sits closer to 2040. But the real message isn't the date. It's the lead time.

Here's what the piece gets right, and why it matters for every Ethereum holder.

1. Where the risk actually is
Ethereum accounts are secured by ECDSA on the secp256k1 curve. An address stays relatively safe while only its hash is known. The moment an account sends a transaction, its public key is on-chain, permanently. A sufficiently powerful future quantum computer is expected to be able to work backwards from that public key. The risk isn't Ethereum's hashing or data structures. It's exposed public keys.

2. Nobody can break Ethereum today
Today's quantum hardware is nowhere near that point. Google's Willow chip has 105 physical qubits; credible estimates for breaking 256-bit elliptic curves run far higher. Most expert estimates for "Q-Day" sit in a 10 to 20 year window, with no consensus on an exact date.

3. So why act now?
Because migrations take years. Wallets, custodians, DAOs, bridges and contracts all have to move, and the oldest accounts are the most exposed. Waiting until the danger is obvious leaves no time to respond calmly. The article's analogy fits: you reinforce bridges before the earthquake, not during it.

4. Ethereum's last-resort plan
In 2024 Vitalik outlined an emergency hard fork for a sudden quantum attack: roll back blocks, freeze legacy ECDSA accounts, and let real owners prove ownership and move funds into quantum-resistant smart contract wallets. It's explicitly a last resort, not Plan A. And it depends on one thing: being able to tell the real owner apart from an attacker holding the same old key.

5. What actually needs to change
· Accounts that can switch signature schemes, through account abstraction
· NIST post-quantum signatures such as ML-DSA (FIPS 204)
· Crypto-agile infrastructure across wallets, rollups and contracts
· For individuals: upgradeable wallets, no address reuse, and readiness to migrate

6. Where Qairos fits
Qairos is built for exactly this preparation window.
· Generate an ML-DSA-44 key (NIST FIPS 204) in your browser. It never leaves your device.
· Register its hash on Ethereum now. If ECDSA is ever compromised, a key registered before that moment is proof of ownership an attacker cannot fake.
· Keep a recovery kit offline to move funds to a fresh, safe address.
· Use the Contract Wizard to build vaults and treasuries that lock sensitive functions when a security alert is active, and open only through a post-quantum key.

Protocol upgrades protect the network. They don't automatically prepare your old account, your DAO treasury, or the contract you deployed years ago. That gap is where Qairos works.

No panic. Just preparation, while everything is still safe.

[vitalik.eth @VitalikButerin]

Now, the quantum resistance roadmap.

Today, four things in Ethereum are quantum-vulnerable:

* consensus-layer BLS signatures
* data availability (KZG commitments+proofs)
* EOA signatures (ECDSA)
* Application-layer ZK proofs (KZG or groth16)

We can tackle these step by step:

## Consensus-layer signatures

Lean consensus includes fully replacing BLS signatures with hash-based signatures (some variant of Winternitz), and using STARKs to do aggregation.

Before lean finality, we stand a good chance of getting the Lean available chain. This also involves hash-based signatures, but there are much fewer signatures (eg. 256-1024 per slot), so we do not need STARKs for aggregation.

One important thing upstream of this is choosing the hash function. This may be "Ethereum's last hash function", so it's important to choose wisely. Conventional hashes are too slow, and the most aggressive forms of Poseidon have taken hits on their security analysis recently. Likely options are:

* Poseidon2 plus extra rounds, potentially non-arithmetic layers (eg. Monolith) mixed in
* Poseidon1 (the older version of Poseidon, not vulnerable to any of the recent attacks on Poseidon2, but 2x slower)
* BLAKE3 or similar (take the most efficient conventional hash we know)

## Data availability

Today, we rely pretty heavily on KZG for erasure coding. We could move to STARKs, but this has two problems:

1. If we want to do 2D DAS, then our current setup for this relies on the "linearity" property of KZG commitments; with STARKs we don't have that. However, our current thinking is that it should be sufficient given our scale targets to just max out 1D DAS (ie. PeerDAS). Ethereum is taking a more conservative posture, it's not trying to be a high-scale data layer for the world.
2. We need proofs that erasure coded blobs are correctly constructed. KZG does this "for free". STARKs can substitute, but a STARK is ... bigger than a blob. So you need recursive starks (though there's also alternative techniques, that have their own tradeoffs). This is okay, but the logistics of this get harder if you want to support distributed blob selection.

Summary: it's manageable, but there's a lot of engineering work to do.

## EOA signatures

Here, the answer is clear: we add native AA (see https://t.co/YD9nIpsxcC ), so that we get first-class accounts that can use any signature algorithm.

However, to make this work, we also need quantum-resistant signature algorithms to actually be viable. ECDSA signature verification costs 3000 gas. Quantum-resistant signatures are ... much much larger and heavier to verify.

We know of quantum-resistant hash-based signatures that are in the ~200k gas range to verify.

We also know of lattice-based quantum-resistant signatures. Today, these are extremely inefficient to verify. However, there is work on vectorized math precompiles, that let you perform operations (+, *, %, dot product, also NTT / butterfly permutations) that are at the core of lattice math, and also STARKs. This could greatly reduce the gas cost of lattice-based signatures to a similar range, and potentially go even lower.

The long-term fix is protocol-layer recursive signature and proof aggregation, which could reduce these gas overheads to near-zero.

## Proofs

Today, a ZK-SNARK costs ~300-500k gas. A quantum-resistant STARK is more like 10m gas. The latter is unacceptable for privacy protocols, L2s, and other users of proofs.

The solution again is protocol-layer recursive signature and proof aggregation. So let's talk about what this is.

In EIP-8141, transactions have the ability to include a "validation frame", during which signature verifications and similar operations are supposed to happen. Validation frames cannot access the outside world, they can only look at their calldata and return a value, and nothing else can look at their calldata. This is designed so that it's possible to replace any validation frame (and its calldata) with a STARK that verifies it (potentially a single STARK for all the validation frames in a block).

This way, a block could "contain" a thousand validation frames, each of which contains either a 3 kB signature or even a 256 kB proof, but that 3-256 MB (and the computation needed to verify it) would never come onchain. Instead, it would all get replaced by a proof verifying that the computation is correct.

Potentially, this proving does not even need to be done by the block builder. Instead, I envision that it happens at mempool layer: every 500ms, each node could pass along the new valid transactions that it has seen, along with a proof verifying that they are all valid (including having validation frames that match their stated effects). The overhead is static: only one proof per 500ms. Here's a post where I talk about this:

https://t.co/rAUSJjW7WL
https://t.co/EtXpkaDll5

[Qairos @Qairos_app]

@VitalikButerin laid out four areas of Ethereum's cryptography that need post-quantum upgrades.

One of them is user accounts: letting every account use any signature scheme, including lattice-based ones.

That's exactly the layer Qairos works on. Generate an ML-DSA-44 key (lattice-based, NIST FIPS 204), register it on-chain, and be ready when account-level signature agility lands.

[vitalik.eth @VitalikButerin]

Now, the quantum resistance roadmap.

Today, four things in Ethereum are quantum-vulnerable:

* consensus-layer BLS signatures
* data availability (KZG commitments+proofs)
* EOA signatures (ECDSA)
* Application-layer ZK proofs (KZG or groth16)

We can tackle these step by step:

## Consensus-layer signatures

Lean consensus includes fully replacing BLS signatures with hash-based signatures (some variant of Winternitz), and using STARKs to do aggregation.

Before lean finality, we stand a good chance of getting the Lean available chain. This also involves hash-based signatures, but there are much fewer signatures (eg. 256-1024 per slot), so we do not need STARKs for aggregation.

One important thing upstream of this is choosing the hash function. This may be "Ethereum's last hash function", so it's important to choose wisely. Conventional hashes are too slow, and the most aggressive forms of Poseidon have taken hits on their security analysis recently. Likely options are:

* Poseidon2 plus extra rounds, potentially non-arithmetic layers (eg. Monolith) mixed in
* Poseidon1 (the older version of Poseidon, not vulnerable to any of the recent attacks on Poseidon2, but 2x slower)
* BLAKE3 or similar (take the most efficient conventional hash we know)

## Data availability

Today, we rely pretty heavily on KZG for erasure coding. We could move to STARKs, but this has two problems:

1. If we want to do 2D DAS, then our current setup for this relies on the "linearity" property of KZG commitments; with STARKs we don't have that. However, our current thinking is that it should be sufficient given our scale targets to just max out 1D DAS (ie. PeerDAS). Ethereum is taking a more conservative posture, it's not trying to be a high-scale data layer for the world.
2. We need proofs that erasure coded blobs are correctly constructed. KZG does this "for free". STARKs can substitute, but a STARK is ... bigger than a blob. So you need recursive starks (though there's also alternative techniques, that have their own tradeoffs). This is okay, but the logistics of this get harder if you want to support distributed blob selection.

Summary: it's manageable, but there's a lot of engineering work to do.

## EOA signatures

Here, the answer is clear: we add native AA (see https://t.co/YD9nIpsxcC ), so that we get first-class accounts that can use any signature algorithm.

However, to make this work, we also need quantum-resistant signature algorithms to actually be viable. ECDSA signature verification costs 3000 gas. Quantum-resistant signatures are ... much much larger and heavier to verify.

We know of quantum-resistant hash-based signatures that are in the ~200k gas range to verify.

We also know of lattice-based quantum-resistant signatures. Today, these are extremely inefficient to verify. However, there is work on vectorized math precompiles, that let you perform operations (+, *, %, dot product, also NTT / butterfly permutations) that are at the core of lattice math, and also STARKs. This could greatly reduce the gas cost of lattice-based signatures to a similar range, and potentially go even lower.

The long-term fix is protocol-layer recursive signature and proof aggregation, which could reduce these gas overheads to near-zero.

## Proofs

Today, a ZK-SNARK costs ~300-500k gas. A quantum-resistant STARK is more like 10m gas. The latter is unacceptable for privacy protocols, L2s, and other users of proofs.

The solution again is protocol-layer recursive signature and proof aggregation. So let's talk about what this is.

In EIP-8141, transactions have the ability to include a "validation frame", during which signature verifications and similar operations are supposed to happen. Validation frames cannot access the outside world, they can only look at their calldata and return a value, and nothing else can look at their calldata. This is designed so that it's possible to replace any validation frame (and its calldata) with a STARK that verifies it (potentially a single STARK for all the validation frames in a block).

This way, a block could "contain" a thousand validation frames, each of which contains either a 3 kB signature or even a 256 kB proof, but that 3-256 MB (and the computation needed to verify it) would never come onchain. Instead, it would all get replaced by a proof verifying that the computation is correct.

Potentially, this proving does not even need to be done by the block builder. Instead, I envision that it happens at mempool layer: every 500ms, each node could pass along the new valid transactions that it has seen, along with a proof verifying that they are all valid (including having validation frames that match their stated effects). The overhead is static: only one proof per 500ms. Here's a post where I talk about this:

https://t.co/rAUSJjW7WL
https://t.co/EtXpkaDll5