Partly — and further along than the phrase usually implies. Pearl's proof of work depends on no elliptic-curve cryptography at all. Its post-quantum signature scheme is not a future plan: it has been live in consensus since genesis, and a fully post-quantum transaction has already been made on mainnet. What is not post-quantum is the default spend path, which uses Schnorr signatures, like Bitcoin.
What's already quantum-resistant
The proof of work
Pearl's mining is a proof of useful work: miners perform large matrix multiplications and prove they did so correctly. There is no elliptic-curve cryptography anywhere in that process, so the part of Pearl that secures the chain's history is not exposed to the attack that threatens signatures.
A caveat worth stating plainly: "no elliptic curves" is not the same as "no quantum effect at all." Quantum search algorithms offer a modest speedup against the hash-based components of any proof-of-work system, and the question of quantum advantage on the matrix-multiplication workload itself is genuinely open. What we can say is that mining has no cryptographic cliff edge of the kind signatures have.
The zero-knowledge proofs
Pearl's block certificates — the succinct proofs that a miner's work was valid — are built on Plonky2, a proof system whose security rests solely on hash functions rather than on pairing-friendly elliptic curves. Hash-based proof systems are expected to remain secure against quantum adversaries.
They also require no trusted setup. That property is about soundness rather than quantum resistance: with no setup ceremony, there is no secret trapdoor that could ever be used to forge a proof, and no participant anyone has to trust to have destroyed it.
What isn't
Spending PRL normally means producing a Schnorr signature. Pearl standardises on Taproot, and Schnorr rests on elliptic-curve cryptography — the part a sufficiently large quantum computer would break. That machine does not exist, and estimates for when it might vary widely, but the risk is real enough to prepare for.
What Pearl has built
XMSS signatures
Pearl implements OP_CHECKXMSSSIG, an opcode that verifies signatures from the eXtended Merkle Signature Scheme — a hash-based scheme believed to remain secure against quantum attack. It has been enabled in consensus since genesis. There is no pending soft fork and no activation flag: a transaction unlocked by an XMSS signature validates on mainnet today.
Pearl's parameters use SHAKE256 with a 256-bit hash. Two details matter for anyone assessing this seriously:
- The parameter set is custom. It targets roughly 256-bit classical security, which corresponds to approximately 128-bit security against a quantum adversary. The configuration is not one of the sets standardised in RFC 8391, which defines only larger tree heights.
- XMSS is stateful and limited. Each key pair can produce at most 32 signatures, and each must use a distinct index. Reusing an index under the same key pair is catastrophic — it allows an attacker to recover the key and forge signatures. This is inherent to the scheme, not a Pearl limitation, and it is the main reason post-quantum signing needs careful tooling rather than a simple toggle.
Signatures are 2,340 bytes, considerably larger than Schnorr's 64.
Pay-to-Merkle-Root
Pearl implements P2MR, the output type proposed in BIP-360, and it too has been active since genesis. P2MR works like Taproot but removes the quantum-vulnerable key-path spend, requiring every spend to go through a script path and Merkle proof.
This matters because a quantum attacker's opportunity comes largely from published public keys. A Taproot output always commits to an internal key that a quantum adversary could attack; a P2MR output never exposes one. Combining the two features — a P2MR output whose script tree contains an XMSS key — gives an address with no elliptic-curve exposure at all.
Proven on mainnet
This is not theoretical. A fully post-quantum transaction has already been mined on Pearl mainnet: both the output it spends and the output it creates are P2MR addresses locked to XMSS keys, with no elliptic-curve signature anywhere in the spend. It was unlocked by a 2,340-byte XMSS signature carried in the witness alongside the leaf script and Merkle proof.
You can inspect it on the block explorer. The full construction — key derivation, address derivation, and the exact transaction — is reproducible from the test suite in pull request #111.
What's coming
The consensus primitives are finished; the wallet experience is not. Today, using the post-quantum path means constructing transactions directly rather than clicking a button, which puts it within reach of technical users but not of everyone. Full wallet support for post-quantum key derivation, address generation, and signing is planned for the near future.
We would rather ship the consensus rules early and the convenience layer second than the other way around. The part that is hard to change later is already done.
What this means for you practically
- Your PRL is not at quantum risk today. No quantum computer can break Schnorr signatures now.
- You don't need to do anything. The default Taproot address is the right choice for almost everyone right now.
- If you're technical and want it today, you can have it. P2MR and XMSS are both live on mainnet, and the construction is documented and reproducible.
- There is no future flag day. The post-quantum verification rules are already enforced by every node. What changes over time is how easy they are to use, not whether the network accepts them.
- Don't let anyone use "quantum risk" to rush you. A message urging you to move funds to a "quantum-safe address" is a scam. See How Pearl will and won't contact you.
Why build this in early?
Retrofitting cryptography into a live chain with real value is far harder than shipping it from the start. Chains that didn't plan for it face a coordination problem under time pressure — the worst conditions for consensus changes. Pearl chose to carry the cost upfront.
Read more
Full specifications for the XMSS parameters and P2MR are in Section 5.2 of the Pearl whitepaper. The implementation is public in the xmss/ directory at github.com/pearl-research-labs/pearl.