QoreChain is a Layer 1 blockchain designed around post-quantum cryptography and AI-native infrastructure. Its architecture combines mandatory post-quantum signatures on its native transaction path with EVM, CosmWasm and SVM execution environments, while its PRISM system is designed to use deterministic machine learning to adjust network parameters within predefined limits.
The project is led by Liviu Epure, whose work spans post-quantum blockchain architecture, cryptographic agility, AI security and quantum-resistant authentication.
In this interview, Epure discusses why he believes post-quantum security needs to be built into blockchain infrastructure from the outset, how QoreChain approaches migration across different execution environments, and what role AI could play in managing blockchain infrastructure.
U.Today: You began working on digital-asset security before QoreChain evolved into a post-quantum, AI-native Layer 1. What problem originally convinced you that blockchain infrastructure needed to be redesigned rather than simply upgraded?
Liviu Epure: The moment was not a quantum paper. It was watching how upgrades actually happen on live networks.
Every serious change to a running chain is a negotiation. A signature scheme change touches every wallet, every exchange integration, every hardware device and every dormant account whose owner will never come back to migrate. The larger and older the network, the longer that negotiation takes, and the people who lose are those who are not paying attention. On most chains, a dormant address protected by a classical key is not "upgradable" at all. Nobody can move it except the owner, and the owner is gone.
That told me that the security assumptions of a ledger have to be chosen at genesis because they are the one thing you cannot really change later without leaving people behind. The same logic applies to execution. If you want one account to work across Ethereum, Cosmos and Solana tooling, you build the account model that way from the start rather than bolting bridges on afterward.
So QoreChain was not designed as "a better chain." It was designed around the question: What has to be true on day one so that we never have to ask users to migrate under pressure?
U.T.: You have argued that the "harvest now, decrypt later" threat makes post-quantum migration a present-day issue rather than something that can wait for quantum computers. What blockchain data do you think is most vulnerable to this threat today?
L.E.: The honest answer is that "harvest now, decrypt later" is mostly a confidentiality threat, and public blockchains have very little confidentiality to lose. Everything is already public. The real quantum risk on a ledger is forgery, not decryption: the ability to compute a private key from a public key and sign as someone else.
The most exposed data, in order, are public keys that are already on-chain. On Bitcoin and Ethereum, a public key is revealed the first time an address spends. Every address that has ever sent a transaction has its public key sitting in the ledger permanently, waiting. That is the largest pool of exposed value in the industry, and it cannot be retroactively hidden.
Next are long-lived keys that sign many times, such as validator keys, multisig signers, bridge attestation keys and exchange hot wallets. A single break there does not steal one account. It compromises a system.
Finally, there is anything encrypted with classical key exchange that has been recorded, including node-to-node traffic, custody and RPC channels, and wallet backups protected by classical schemes. This is the true harvest-now case, and it is mostly off-chain infrastructure around the chain rather than the chain itself.
So the priority is not "encrypt the blockchain." It is to stop publishing classical public keys for value you intend to hold for a decade and move signing to standardized post-quantum schemes while migration is still a choice.
U.T.: QoreChain currently uses mandatory hybrid PQC signatures on its native transaction path, while post-quantum enforcement across EVM and SVM is being introduced in stages. What have you learned from this staged migration that you would apply to other blockchain networks?
L.E.: Three things, each of which cost us something.
First, mandate the post-quantum component. Do not make it optional. On our native lane, every transaction must carry an ML-DSA-87 signature. The classical co-signature exists for tooling compatibility, but it is not the security anchor. The lesson from every "optional" scheme in the industry is that optional means almost nobody uses it.
Second, compatibility is the whole migration problem, not the cryptography. Our public roadmap put mandatory post-quantum enforcement on the EVM lane in the third quarter of 2027 because the obstacle looked immovable: MetaMask does not implement eth_signTransaction, so there is no moment in the flow where a wallet could attach a second post-quantum signature to an Ethereum transaction.
We spent months trying to solve the wrong problem. The answer was not to change how an EVM transaction is signed. It was to change what authorizes it. In the release going out now, an account with no registered post-quantum key cannot transact on the EVM lane at all. An account with one opens a bounded authorization window, signed with ML-DSA-87 on the native lane, that specifies how many blocks, how many transactions and how much value, including fees, it covers.
Inside that window, MetaMask, Hardhat and Foundry work unmodified. The SVM lane, which is closed pending an audit, reopens under the same rule. That brings mandatory post-quantum authorization to all three lanes by early October 2026 instead of late 2027.
The lesson for other networks is simple: if your migration plan depends on every wallet vendor changing its signing flow, you will wait years. Move the requirement to a layer you control.
Third, post-quantum signatures do not fix anything above the signature. On August 21, a missing authorization check in our SVM lane was exploited. The signatures worked perfectly. The code moving value simply never asked whether the signer was authorized to do so.
A network that treats "post-quantum" as a security strategy rather than one layer of security is going to learn that lesson the way we did. Our post-mortem is public precisely so that others do not have to.
U.T.: Your work proposes AI directly inside blockchain infrastructure. What made you believe machine learning should become a protocol-level component?
L.E.: Because the parameters that matter most on a chain are set by humans once and then almost never revisited.
Block timing, gas pricing, fee floors and validator incentives are constants on most networks, adjusted by governance votes months apart, usually after the damage has occurred. Meanwhile, network conditions change by the minute. The gap between how often conditions change and how often parameters change is where congestion, fee spikes and validator drop-off live.
The alternative is not "let a model run the chain." It is to give the protocol a bounded, deterministic optimizer that observes the network and nudges parameters within limits set by governance. The human still decides the envelope. The model decides where inside that envelope the chain sits right now.
Putting it inside the protocol rather than using it as an external service was a hard requirement for one reason: every validator has to compute the same answer. An off-chain model that different nodes call at different times produces consensus failures.
PRISM runs as chain logic, using fixed-point integer arithmetic, so it is part of state, replayable and auditable like any other module. That constraint shaped the whole design.
U.T.: QoreChain’s PRISM is designed to adjust parameters such as block timing and gas pricing dynamically. What signals does the system use as inputs, and how do you prevent short-term market or network anomalies from causing excessive parameter changes?
L.E.: PRISM consumes an observation vector built from on-chain state at epoch boundaries: block time and its variance, gas utilization and fee levels, transaction volume and pending demand, validator participation and signing behavior, and the recent history of its own outputs. Everything in that vector comes from consensus state, so every validator sees the same input.
The protection against overreaction is structural, not statistical.
Bounded actions. Each parameter has a governance-set floor, ceiling and maximum per-epoch step. The model can propose a change, but it cannot exceed those limits.
Epoch cadence. Adjustments apply at epoch boundaries, not per block. A single unusual block cannot move anything.
Circuit breaker. If the proposed action falls outside the safe envelope, or the observation itself is outside its expected range, the output is discarded and the chain falls back to the last known-good static parameters. A fallback is not a failure. It is the default.
Determinism. Fixed-point integer mathematics, no floating-point calculations and no external calls. The model cannot receive a different input on one validator than on another.
The design principle is that PRISM can only ever make the chain slightly better or leave it unchanged. It cannot make it worse than the static configuration because the static configuration is what it falls back to.
U.T.: How do you handle key generation, storage, rotation and recovery for post-quantum validator keys?
L.E.: Validator identity on QoreChain has two parts: the consensus key that signs blocks and the post-quantum account key registered on-chain through our PQC module.
Generation follows the FIPS 204 specification for ML-DSA-87 using audited implementations, with the same byte-compatible library family we ship to clients, using Rust FFI over the fips204 crate. We deliberately did not write our own lattice arithmetic.
Storage is operator-controlled. Our reference deployment keeps keys on isolated hosts behind the sentry layer, with the signing state file protecting against double-signing. We recommend and use hardware-backed storage where available.
Rotation is a first-class on-chain operation. A validator registers a new post-quantum key through the PQC module, the network recognizes the new key from the next block, and the old one is retired. The registration message supports algorithm identifiers, so a future move from ML-DSA-87 to another standardized scheme is a re-registration rather than a hard fork.
Recovery is the honest weak point of the whole industry, and we are not going to pretend otherwise. A lost validator key means re-registering under a new one, with the operator's bond and reputation carried by the on-chain identity rather than by the key material.
What we refuse to do is build a "recovery backdoor" because a recovery path for the operator is also a recovery path for an attacker.
Your recent research covers everything from post-quantum blockchain architecture to quantum random number generation and ML-based authentication. What common security problem connects these different areas of research?
The same problem appears in three places: every security guarantee is only as strong as the layer underneath it, and the industry keeps auditing the top layer while assuming the bottom one is secure.
In the paper on quantum random number generation and ML-based authentication, I laid out a four-layer model, and it is the model QoreChain is built on.
Layer one is entropy. A pseudo-random generator is deterministic. An adversary who learns its state can replay every key it ever produced. Quantum sources give you randomness certified by physics rather than by an algorithm, with measurable min-entropy. The point of starting there is that a post-quantum signature scheme seeded from weak randomness is not post-quantum at all.
Layer two is the primitives: lattice-based key encapsulation and signatures, which is exactly what ML-KEM and ML-DSA provide in production on our chain.
Layer three is authentication. Cryptography proves that a key signed something. It does not prove that the right person is holding the key or that they are allowed to do what they are doing. Machine learning applied to behavior and context turns that from a one-time check at login into a continuous one.
Layer four is privacy. Hash-based zero-knowledge proofs such as zk-STARKs let you prove a claim without revealing the underlying data, and they remain secure against quantum attack because they rely on hashes rather than discrete logarithms.
The common thread is that each layer answers a different question, and a system is only secure if every question gets answered. QoreChain has layer two in production, a STARK verifier in its rollup kit for layer four, and the incident on August 21 was precisely a failure at layer three: the signature was valid, but authorization was never checked.
That is why I keep the questions separate. Who signed, whether they are who they claim to be, and what they are allowed to do are three different proofs.
U.T.: The PKI Consortium is now working on a Post-Quantum Cryptography Maturity Model. What does it actually mean for an organization to be "quantum-ready"?
L.E.: Working on the PQC Maturity Model inside the PKI Consortium has made me allergic to "quantum-ready" as a badge. It is not a state you reach. It is a set of things you can prove, and the model's value is in being precise about which is which.
The first thing I argued for in the working group is that a maturity level is not "how much post-quantum cryptography you have." Every requirement in the model is one of three things: a capability you have built, a disclosure you have published or a gate you have passed. A level is a set of gates passed plus complete disclosure at that level. Otherwise, organizations self-assess at level four because they bought a product with ML-KEM in it.
The second is scope. The model should record what changes because of the migration and only what an assessor can verify from documentation in days, not months of laboratory work. It is not a replacement for FIPS 140-3 or Common Criteria.
Take the randomness question that came up in the group. Where your entropy comes from is an inventory question and belongs at the level where you inventory your cryptography. How much entropy your parameter set actually requires is a certification question and belongs at the top. Confusing the two either makes the model useless or makes it unaffordable.
Third, and this is the part I bring from running a ledger, the model currently assumes you can retire an old verification path. A certificate chain gets re-signed and the old one expires. In an append-only system, every signature ever produced must remain checkable under the rules the network runs today, and you cannot force every participant to upgrade at once.
That is the hardest cryptographic agility case there is. The answer is not "make the system agile," but "make the migration executable under the constraint that nothing can be undone." Long-term archiving is the same problem in different clothes, which is why I think whatever the model says about archives should also apply to append-only systems. I have proposed defining how the levels apply when the "vendor" is a protocol and the "organization" is a distributed set of operators.
So, quantum-ready means you know where every algorithm is, you have published what you have changed, you have passed the gates you claim and you have a migration path that works without rewriting history. QoreChain contributes the production evidence for that last point, including the cost of getting it wrong.
U.T.: AI systems themselves are becoming critical infrastructure and therefore potential targets. Do you think the industry is paying enough attention to protecting AI models?
L.E.: No, and the gap is in the same place it was for blockchain ten years ago: everyone secures the model's outputs, and nobody secures its inputs and integrity.
Three things worry me.
First, model integrity. If an AI system influences infrastructure decisions, an attacker who can alter its weights or training data has a quieter and more durable attack than many conventional exploits.
Second, input integrity. A model that consumes data from sources an adversary can influence is a model an adversary can steer.
Third, the provenance. Very few deployed models can prove which version is running, on which data and with which parameters.
Our answer inside QoreChain is narrow but concrete. PRISM's parameters are part of chain state, so any change to them is a governed, signed and replayable transaction. Its inputs come only from consensus state. Its outputs are bounded.
It is small on purpose: tens of thousands of parameters, not billions, because a model you can audit is worth more in infrastructure than a model you have to trust.
The industry will get there. The question is whether it gets there before or after the first incident in which a manipulated model, rather than a bug, is the root cause.
U.T.: Could AI itself help manage the transition to post-quantum cryptography, for example by identifying vulnerable cryptographic dependencies, prioritizing migration or monitoring for anomalous cryptographic activity?
L.E.: Yes, and this is one of the few places where I think the benefit is immediate rather than speculative.
Inventory is the hardest part of migration, and it is a pattern-recognition problem: finding every place where a classical algorithm is used across codebases, configurations, dependencies and binaries, including the ones nobody documented. That is a job for tooling that reads code and infrastructure at scale, and language models are good at it today.
Prioritization is next. Given an inventory, which exposures matter first? That is a function of data lifetime, key lifetime and reachability, and it can be scored automatically.
Monitoring is the third: watching for anomalous cryptographic activity, such as an old algorithm reappearing after migration, a certificate issued with the wrong parameters or signing patterns that do not match an operator's baseline.
We already apply the first idea in a small way. The QoreX wallet includes a Q-Day Scanner that tells a user which of their addresses on other chains have exposed public keys. Our Studio audits contracts for cryptographic misuse alongside classic vulnerabilities. Neither replaces a cryptographer. Both make the cryptographer's list shorter.
U.T.: What safeguards does QoreChain use against adversarial inputs, model manipulation or feedback-loop attacks?
L.E.: We separate the two AI surfaces because the threat models are different.
For PRISM, the on-chain optimizer, its only inputs are consensus states, so an adversary can influence it only by influencing the chain itself, which is expensive and visible. Its actions are bounded by governance-set limits, applied at epoch boundaries, and pass through a circuit breaker that discards anything outside the safe envelope.
Its parameters live in state, so changing the model is a governed transaction rather than a file replacement. Feedback loops are limited by construction. The model's own recent outputs are part of its observation, and the step size per epoch is capped, so it cannot chase itself into an extreme.
For the Studio, the contract-generation and audit tooling, it is advisory and off-chain. Nothing it produces reaches the chain without a human signing a transaction. Prompt injection or model manipulation there produces bad advice, not bad state, and we treat its output the way you treat any code review: as a starting point that the developer owns.
And for the one thing that cannot be automated, the SVM incident on August 21 was not an AI failure, but it taught us that the most dangerous input to any system is the one the code forgot to validate. That principle, validate at the boundary and assume the boundary is hostile, now applies to every module, including models.
U.T.: If we look five to 10 years ahead, what does a genuinely quantum-resistant and AI-native digital infrastructure look like to you, and what needs to happen between today's experimental systems and that future?
L.E.: In 10 years, I expect "post-quantum" to be as invisible as "TLS" is today. Nobody will advertise it because everything will have it. Signatures will be lattice- or hash-based by default, keys will rotate routinely, and the idea that a public key sits exposed on a ledger for years will look as careless as unencrypted HTTP does now.
AI in infrastructure will be small, bounded and auditable rather than large and trusted. Optimizers inside protocols, verifiers inside pipelines and monitors inside networks, each with a defined envelope and a fallback. General-purpose models will stay at the edge, helping humans rather than replacing the control plane.
What has to happen between here and there?
Standards have to finish becoming defaults. FIPS 203, 204 and 205 exist. Libraries, hardware and wallets have to ship them without a flag.
Production experience has to be published, including the failures. The industry learns from post-mortems, not white papers. We published ours.
Inventory tooling has to become ordinary, so that "where is our cryptography?" is a query, not a six-month project.
And the systems that survive will be the ones built on the assumption that every layer will eventually fail: the signature, the code above it and the model beside it. Designing for that is what "resistant" will actually mean.
U.T.: Most people will never read a FIPS document. What does post-quantum security change for someone who just holds a few tokens in a wallet?
L.E.: Nothing today, and that is the point. A wallet on QoreChain works like any other wallet: you create it, send, receive and manage your assets. The difference is what happens 10 years from now.
On a classical chain, the public key of any address that has ever sent a transaction is exposed forever, and one day that exposure could become a theft vector. On QoreChain, the signature protecting your balance is designed around a quantum-resistant threat model. You do not have to do anything, migrate anything or understand anything. Your keys simply do not become obsolete because the hardware landscape changes.
The one practical thing we ask of users is the same as everywhere: keep your recovery phrase offline. Our QoreX wallet was built so that you write it down once and never type it again. Device linking works without it.
U.T.: Your network was exploited on August 21, and you rolled back 25 minutes of history. Why should a user trust a chain that has already done that once?
L.E.: Because of what we did with it. A missing authorization check in one execution lane let a single transaction move 83% of the supply. We halted the chain within 25 minutes, restored every balance and published the exact code, timeline and amount that left, 4 million QOR, which we cover from our insurance fund.
No user lost funds, and no user's own transaction was canceled. We verified that transaction by transaction before the board voted.
The rollback broke a rule we had set for ourselves, and we said so on the record rather than calling it maintenance. Trust is not the absence of incidents. It is whether the people running the system tell you the uncomfortable number before you ask for it.
Every figure in our post-mortem can be checked on the public chain, and we would rather you check than believe us.
U.T.: A Solidity developer already has Ethereum and a dozen L2s. What concretely changes for them on QoreChain, and what stays the same?
L.E.: What stays the same is everything they touch: MetaMask, Hardhat, Foundry, ethers.js and standard JSON-RPC. The contract deploys unchanged.
What changes is underneath. Their contract shares a ledger with CosmWasm contracts and, when the lane reopens after an audit, with Solana programs. A single user key resolves to a 0x address, a Cosmos address and an SVM address, so onboarding a user from any ecosystem is one flow.
Their users' native transactions are post-quantum signed without the developer writing cryptography. The Studio generates and audits code for QoreChain and 16 other chains, with a quantum-readiness score. There is also a 416 million QOR Builders Fund with a published vesting policy for teams building something real.
Two honest caveats: the SVM lane is closed today pending an external audit, so Solana teams should start on EVM or CosmWasm. From the next release, an EVM account needs a registered post-quantum key and an open authorization window before it can transact. QoreX handles this for the user, while the SDK exposes the functionality to integrators.
U.T.: Your bug bounty opened on September 1. What have researchers found, and how do you decide what to disclose?
L.E.: More than we expected, which is the outcome we wanted. So far, the reports fall overwhelmingly into one class: authorization and validation gaps at module boundaries, the same family as the August 21 incident, plus several findings about differences between documented and shipped behavior.
Our disclosure rule is simple: we publish once a fix is live, in the same detail we used for the August post-mortem, and we credit the researcher. We do not publish the location of an unpatched issue because that would amount to publishing an exploit.
Where a report affects an upstream dependency that other chains share, we follow the upstream embargo. The program runs until the end of February with a dedicated pool, and reports made before the program opened are paid at full rates retroactively.
Dan Burgin
U.Today Editorial Team
