Post-quantum signature checks for QRL 2.0 smart contracts
Our go-qrl pull request is merged: an ML-DSA-87 verification precompile that takes the 64-byte digests QRL wallets sign, and a SHAKE256 precompile to rebuild them on-chain.
On 19 October the QRL core team merged our pull request cyyber/go-qrl#244 into go-qrl, the QRL 2.0 execution client. It gives smart contracts two building blocks they did not have before: verifying an ML-DSA-87 signature over the exact message a QRL wallet signs, and computing SHAKE256 on-chain.
What changed
- ML-DSA-87 verification at 0x03 now takes a 64-byte message. QRL wallets and the QRL Connect SDK sign 64-byte SHAKE256 digests (the QRL-SIGN-MSG-v1 and QRL-SIGN-TYPED-v2 schemes). With the precompile accepting that 64-byte frame, a contract can check a wallet signature directly.
- SHAKE256 at 0x06. A contract can rebuild the digest a wallet signed from the original message on-chain. KECCAK256 cannot produce SHAKE256, so without this precompile a contract would have to trust a digest supplied by the caller.
- One precompile set. Both live in QRL 2.0’s single precompile set, next to the existing XMSS verifier at 0x07, with no extra activation rules.
The 64-byte digest keeps 256-bit collision resistance, which matches the security level of ML-DSA-87 itself and the reasoning behind QRL 2.0’s 64-byte addresses.
Why it matters
Smart contracts on Ethereum check wallet signatures all the time. On QRL 2.0 every account signs with ML-DSA-87, a NIST-standardised post-quantum scheme, and until now a contract could not check those signatures itself. With these precompiles it can, using the same message formats the wallets already produce. That brings the familiar signature-based patterns to QRL 2.0, with post-quantum security:
- Multisig and smart-contract wallets: owners approve a transaction by signing it off-chain, and the wallet contract checks every approval before it executes.
- Gasless transactions: a user signs a request, a relayer submits it and pays the fee, and the contract confirms that the user really signed it.
- Token permits: a token approval given as a signature, so a dApp can approve and spend in a single transaction.
- Signed vouchers: allowlist mints, airdrop claims or lazy-minted NFTs, where a project signs a voucher off-chain and the contract checks it when someone redeems it.
- Off-chain votes and orders: DAO votes or exchange orders collected off-chain and settled on-chain against their signatures.
- Oracles and bridges: a contract that accepts a price or a cross-chain message only when enough known signers have signed it.
Closer to home, we plan to use it for signed orders in QuantaSwap and for proofs of name ownership in QNS, the QRL Name Service.
Compiler support
The compiler side has shipped as well. Hyperion v0.2.0, released on 19 October, includes our mldsa87verify builtin (cyyber/hyperion#19), which calls the 0x03 precompile with the right framing. A shake256 builtin for 0x06 is in review in cyyber/hyperion#18.
Thanks and what is next
Thanks to the QRL core developers for the reviews that shaped this change, including folding both precompiles into the single precompile set. The precompiles ship with the next go-qrl release that the QRL 2.0 testnet runs. We will follow up with an example contract that verifies a signature from MyQRLWallet once they are live on testnet.