eBay knew by the early-to-mid 2000s that its original architecture had a scaling ceiling. The rewrite was expensive and unglamorous, and it took years. But it happened anyway, because traffic and cost pressure forced it. The signature scheme used by most major blockchains has a ceiling too: a fault-tolerant quantum computer. The difference between the two isn't whether the old system can keep running. Both do. It's what the old system is like while it runs: eBay's was slow. A blockchain's is exposed.

[Audit status update] Based on all received feedback, we have finalized the decision on the consensus layer integration for the mainnet stack. After careful consideration, we selected Lighthouse by Sigma Prime. As discussed previously, Lighthouse is the most widely used consensus client and is considered semi-official due to its broad adoption among node operators. This choice best meets the technical and policy requirements of our strategic partners. What happens next: Step 1: We are currently preparing the official Go-Ethereum based execution client to be compatible with the modified Lighthouse consensus client. Step 2: Once these modifications are ready, we will submit the execution client to the auditors, expected by end of next week. Step 3: Once the required Lighthouse modifications are completed, we will also submit the consensus client to the auditor. Just to clarify, the above steps do not alter the mainnet launch timeline, as these processes are fully parallel.

We built for a future where quantum-safety and auditability are mandatory, but public network dependency is optional. Thanks to the hybrid architecture, enterprises can keep their data private while still achieving trust by anchoring proofs to the public blockchain. On the budget side, there is one batched transaction instead of thousands. The cost model changes from per-transaction to predictable operational cost. Public-chain immutability without having to pay public-chain fees on internal operations. Both sides are quantum-safe, protected by NIST-standard post-quantum cryptography. Cost and auditability are often a tradeoff. This architecture doesn't require enterprises to choose.

[Audit status update] We know many of you are eagerly waiting for the final audit phase to begin, and we want to keep you posted. All the crucial and most challenging parts of the system have been successfully ported to Go-ethereum, the official Ethereum execution-layer client. This part is ready for auditing. Where we are now: To meet our strategic customers' requirements, we rebased our solution on top of the official Ethereum implementation and replaced all Ethereum-related components with their official counterparts. One part of the stack - the consensus layer - does not have an official Ethereum implementation. This means our customers need to align on which consensus client they are willing to accept before we submit this final component in the last audit phase. The two options are: A ) Caplin by Erigon, a Golang-based consensus implementation we currently use already deployed and tested on our testnet. B ) Lighthouse by Sigma Prime, the most widely used Rust-based consensus client, which could be considered semi-official due to its broad usage among node operators. We are working on a joint decision which is technically sound and policy-wise acceptable for all parties involved. What happens next: We expect a final decision next week, so we can move forward. Once the decision is made we will update you again.

The blockchain that survives the upcoming decade won't be the fastest. It will be the one that was built against a threat many teams still consider theoretical.

Within six months, three different groups published papers that point to the same direction. March 2026: Google's whitepaper shows that quantum computers can crack the digital signatures protecting Bitcoin and much of the internet's logins with roughly 20 times fewer qubits than experts had been assuming. Fewer qubits means sooner. September 2026: IonQ went further and published the first fully compiled blueprint for the attack, every operation compiled down to the error-correction circuits a real machine would run. Their number was 20,000 qubits in under 26 days, and their own roadmap says they'll have that around 2028. September 2026: ECDSA Fail was something else. It was an open competition with over a hundred researchers alongside some AI agents who managed to cut the cost of one of the attack's core steps (elliptic-curve point addition) by 86%. The three results don't share the qubit count. What they have in common is that none of them frames the threat as hypothetical. Google wrote recommendations for the blockchain industry. IonQ briefed the US government before they published their paper. The ECDSA Fail competitors said that the bottom line is not that a quantum attack happens tomorrow. The bottom line is that upgrading to PQC takes years, and you can't retroactively protect a key that is already exposed. The message stems from the pattern: new estimates come in lower than the last and the systems at risk are slow to migrate. A cryptographically relevant quantum computer doesn't create the exposure, it capitalizes on it.

You believe that your crypto is safe because you keep good habits. It is not. It's as safe as the wallet architecture of the exchange you keep it on. And you didn't pick that. Glassnode data suggests that Binance and Bitfinex labeled Bitcoin balances show a comparatively high share of quantum-vulnerable addresses under their methodology (85% and 100%), while Coinbase labeled balances were mainly non-exposed. Same blockchain, very different exposures. Exposed public keys are not a problem today. They become a problem the day a quantum computer can derive the private keys from them. You didn't choose with this in mind. You chose the exchange based on fees, or their app or on a friend's recommendation. The wallet hygiene came packed, just like their terms of service.

US Executive Order 14412, two important post-quantum migration deadlines: - Key establishment by 31 December 2030. - Digital signatures by 31 December 2031. The twelve months gap between the deadlines is telling. Signature migration has always been slow. It took about twenty years to retire SHA-1, and that was relatively easy to agree on. A public ledger is a very demanding case. In most software, cryptographic upgrades are a central decision. A blockchain's signature scheme isn't. No vendor can upgrade it, and no entity can change it alone: it's hardcoded into the protocol. Legacy commitments stay on the chain immutably, permanently. This immutability means there is no erase option. Choosing a blockchain is an investment in its ability to stay secure for decades to come.

"No one's in control" is a double-edged sword. The myth: no entity controls crypto, so the upgrade cannot be messed with. The reality: no entity controls crypto, so nobody is in charge of implementing the upgrade. Your coins sit on chains that often cannot agree on block sizes, gas limits or on the real fork. Now you expect that same network to switch from ECDSA to post-quantum cryptography with one accord? Decentralization was meant to make blockchain more secure and resilient. Turns out that it is also a reason for delay when the countdown to Q-Day has started. To wait for the consensus to protect your assets is a risk you can't afford to take.