Customer: QANplatform
Service: Cryptography Security Audit (ECDSA ↔ ML-DSA-65 Protocol)
Hacken conducted a cryptography audit of QAN XLINK, a QANplatform's protocol for migrating Ethereum wallets to post-quantum security without breaking compatibility.
"Following the success of our QVM, we're forging the path to bring post-quantum security to the broader Web3 ecosystem. Hacken's thorough audit of QAN XLINK bolsters confidence in our ability to deliver forward-looking security, while also building the world's first Ethereum-compatible, quantum-safe hybrid blockchain."
— Johann Polecsak, Co-Founder and CTO, QANplatform[Full QANplatform Statement]
What is QANplatform?
QANplatform is the quantum-resistant Layer 1 hybrid blockchain platform that will allow developers and enterprises to build quantum-resistant: smart contract, DApp, DeFi, DAO, token, CBDC, NFT, Metaverse, and Web3 solutions on top of the QAN blockchain platform in any programming language.
The Quantum Threat Is Not Hypothetical
The quantum computing threat to blockchain is already here in the data. Every time a wallet broadcasts a transaction, its public key becomes visible on-chain. A sufficiently powerful quantum computer can derive the private key from a public key.
The exposure is large and growing: estimates range from 20–50% of circulating Bitcoin supply with exposed public keys, with Deloitte putting Ethereum's exposure higher still at over 65% of all Ether. Meanwhile, Web3 losses surpassed $4 billion in 2025, a 38% increase from the year before.
Quantum computing risk has been formally classified as a critical infrastructure threat too:
- NIST has published its post-quantum cryptography (PQC) standard (NIST).
- The Federal Reserve has formally flagged the risk (Federal Reserve).
- BlackRock updated its Bitcoin ETF prospectus to highlight quantum vulnerability (SEC filing).
"The quantum threat is no longer a distant concern — it demands proactive preparation for the whole Web3 ecosystem. Developing a quantum-safe protocol and performing rigorous audits of the code behind the protocol, QANplatform and Hacken are both pioneers and advocates for a quantum-safe Web3 ecosystem."
— Yevheniia Broshevan, Co-Founder and CEO, Hacken
QANplatform is building QAN XLINK to solve this.
XLINK is a cross-signer protocol that integrates Ethereum-compatible wallets like MetaMask, Trust Wallet, and others with quantum-safe signature-capable keypairs. Those keypairs are built on ML-DSA (FIPS 204), NIST's primary-recommended lattice-based Post-Quantum Cryptography algorithm.
XLINK creates a cryptographically provable association between an existing secp256k1 key and a post-quantum ML-DSA-65 key, providing a 100%-guaranteed safe migration path for the post-quantum era. This is important because it doesn’t require users to change wallets or abandon Ethereum compatibility.
Before any blockchain quantum-safe migration could proceed, QANplatform needed independent verification that the protocol's math, protocol logic, and implementation were all sound.
They engaged Hacken for a full cryptography audit.
What Hacken Audited
The audit covered the entire XLINK library codebase written in Golang, including:
- Key generation and derivation from 24-word BIP-39 mnemonics
- EC (secp256k1) and Post-Quantum (ML-DSA-65/FIPS 204) signature generation and verification
- Three payload types: Link, Renew, and Relink
- Cross-signature validation and payload construction
- Address derivation (Ethereum-compatible and XLINK-native)
- Memory safety and key lifecycle (zeroization, disposal)
- Timestamp and replay attack protection
- Serialization and deserialization logic
- All utility and helper functions
Methodology: Hacken Cryptography Audit Methodology (combination of formal methods, code review, and project-specific validation techniques).
What Hacken Found
The audit produced 31 total findings across four severity levels.
Summary:
- Critical: 0
- High: 0
- Medium: 5
- Low: 9
- Informational: 17
Resolution:
- 29 Fixed
- 2 Accepted (by client design decision)
- 0 Mitigated
No critical or high severity vulnerabilities were found — a strong signal for a protocol of this complexity. However, several medium and low severity issues were identified that, if left unaddressed, could have caused real-world failures.
Key Findings and What They Meant
Medium: BIP-39 Checksum Validation Flaw (F-2025-13244)
The entropy-to-mnemonic function used Go's big.Int.Bytes() to extract entropy before hashing. This method strips leading zero bytes. BIP-39 requires exactly 32 bytes of entropy for checksum computation. For mnemonics where entropy has leading zeros — a statistically non-negligible subset — this would cause valid mnemonics to be silently rejected.
Real-world impact: Users could be locked out of their wallets during import or backup, with no error explaining why. In a worst-case scenario, this means irreversible fund loss.
Status: Fixed — using big.Int.FillBytes() to left-pad entropy to exactly 32 bytes.
Medium: Domain Separation Tag Duplication Broke Interoperability (F-2025-13245)
The XLINK spec explicitly states that the domain separation tag (QAN_XLINK) is NOT part of the PQ message body — it should only be passed as the ML-DSA context parameter. The implementation was including it in both places, duplicating the domain separator.
Real-world impact: Any external implementation following the spec would fail to verify signatures generated by this library, breaking interoperability across validators and wallets for all XLINK payload types (Link, Renew, Relink).
Status: Fixed — the issue was addressed by updating the README to accurately align with the intended design. The SHA-256 checksum of the final README version is documented in the checksum list in Appendix 2.
Medium: Memory Safety and API Inconsistency (F-2025-13265)
The lookupPqPublicKey function returned a raw pointer from an external lookup function without performing a defensive copy. This allowed callers to hold a reference to memory they did not own, with potential for accidental mutation. It also deviated from the API contract established by every other PQ public key accessor in the codebase (which returned deep copies).
Status: Fixed — defensive nil check added; deep copy now returned consistently.
Medium: DoS Vulnerability via Malformed Input (F-2025-13267)
The validatePayloadBytes function was slicing into the payload before checking whether the input was long enough. An attacker sending a payload shorter than 2 bytes would cause a runtime panic — crashing any service accepting XLINK payloads from untrusted sources.
Real-world impact: A trivially simple denial-of-service attack requiring no cryptographic knowledge, just a truncated input.
Status: Fixed — length validation now happens before any slice operations.
Medium: Inconsistent Input Sanitization (F-2025-13268)
Address validation behaved differently depending on whether casing validation was enabled. With validateCasing=true, the function compared the raw input string — including any leading or trailing whitespace — against the canonical address string. The parsing step already trimmed whitespace internally, so valid addresses with whitespace were incorrectly rejected only in the stricter validation mode.
Status: Fixed — consistent whitespace trimming applied before casing comparison.
Low: Race Condition in Payload Generation (F-2025-13330)
The crossSign method accepted a pointer to a timestamp value and dereferenced that pointer three separate times during execution — once for the EC signature, once for the PQ signature, and once for the core payload construction. A concurrent modification between any two of these dereferences would result in a payload whose internal components referenced different timestamps, breaking cryptographic consistency.
Status: Fixed — timestamp pointer now dereferenced exactly once at function entry; the value copy is used throughout.
Low: Private Key Material Left in Memory (F-2025-13353)
During key initialization in New(), temporary byte slices holding EC private key material (32 bytes) and PQ private key material (4,032 bytes) were not zeroed after use. These slices remained in heap memory until garbage collection — typically 2–10 seconds — creating a window for memory dump attacks.
Status: Fixed — temporary slices explicitly zeroed after use, with runtime.KeepAlive() preventing compiler optimization from eliminating the clearing loop.
Low: Integer Overflow in Timestamp Serialization (F-2025-13266)
The timestamp serialization function cast a 64-bit Unix timestamp directly to uint32 without bounds checking. Timestamps outside the range [0, 2106-02-07 06:28:15 UTC] would silently wrap, encoding an incorrect on-wire value.
Status: Fixed — explicit range check added; function now returns an error for out-of-range values.
What Hacken Found to Be Strong
The audit served as independent validation of what QANplatform built well.
Architecture: Library-based, fully decentralized, no trusted third parties. Minimal external dependencies — only Cloudflare CIRCL and Go Ethereum. Payload sizes optimized: Link at 5.3KB, Renew at 3.4KB, Relink at 8.6KB — over 5,000% storage savings against pure post-quantum alternatives. Built-in versioning for backward compatibility.
Code quality: Strong separation of concerns, consistent error handling, proper use of Go generics, well-structured payload hierarchy with shared interfaces and common loader functions. Constants cleanly organized. Memory management sound.
Documentation: Comprehensive README with byte-level format specifications, message structures, and cryptographic protocol details. All public APIs carry detailed Go doc comments. Security-critical behaviors explicitly flagged — including a warning that ValidateVerbose() must not be used in public-facing contexts. Areas noted for improvement: concrete code examples for XLINK object creation, and expanded error condition guidance.
Test coverage: 19 test functions, 46 sub-tests. Strong positive and negative case coverage across all three payload types. Replay attack prevention, signature tampering detection, and key zeroization all tested. Mutation score: 77%. Gaps noted: no multi-user or concurrent access testing, no performance benchmarks.
Systemic Risks Documented (Not Vulnerabilities, But Important)
Hacken's audit also surfaced three architectural realities that blockchain implementers adopting XLINK must understand:
Genesis-only enforcement: The quantum-safety guarantee holds only if XLINK is enforced from block zero. Retroactive adoption faces the exact migration risks XLINK was built to prevent.
Timestamp manipulation: Timestamps are blockchain-provided and subject to consensus-level drift. Validation windows must be enforced at the application layer.
Storage growth: ML-DSA-65 signatures (3,309 bytes) and public keys (1,952 bytes) are large. Without pruning policies for Renew payloads, an attacker can bloat chain storage through valid but unnecessary submissions — a denial-of-service via storage exhaustion.
The Outcome
After remediation and retest, 29 of 31 findings were resolved. The 2 accepted findings were acknowledged by QANplatform by design decision.
QANplatform received:
- A prioritized findings report with exploitation paths and fix guidance for every issue.
- A standards matrix mapping relevant findings to NIST/FIPS/ISO/CFRG requirements.
- Evidence packs including code analysis and remediation verification.
- SHA-256 checksums for every audited and remediated file, providing a tamper-evident audit trail.
- A dated re-test certificate confirming remediation validation.
About Hacken's Cryptography Audit Service
Hacken’s Cryptography Audit follows a rigorous, layer-by-layer examination of math, protocol, code, and implementation. This is exactly what infrastructure-level cryptography demands. We cover the full stack: from mathematical soundness of constraint systems and hardness assumptions, through protocol correctness and domain separation, down to implementation-level issues including side channels, timing attacks, memory safety, and nonce handling.
Cryptography Audting cover:
- ZK Proof Systems (zkSNARKs, zkSTARKs, Groth16, Plonk, Halo2, Plonky, Binius, Jolt, zkVMs)
- Post-Quantum Cryptography (FIPS 203/204/205, Falcon, PQC-based multisig and MPC, PQC-based ZKPs)
- Privacy and Private Computation (FHE, TEEs including SGX/TrustZone/SEV, Garbled Circuits)
- Quantum Cryptography (QKD, QRNG)
- ECC, Symmetric Primitives, and Hash Functions (ECDSA, EdDSA, AES, ChaCha20, SHA-2/3, BLAKE2, Poseidon, HMAC, Poly1305)
- MPC Protocols and Multisignature Schemes
All findings are mapped to NIST/FIPS/ISO/CFRG standards, making deliverables immediately usable for compliance and diligence processes. Every audit includes a re-test and a dated certificate.
If you are building on post-quantum cryptography, zero-knowledge proofs, or any novel cryptographic protocol, make sure to get an independent security audit before deployment.
Request a cryptography audit: hacken.io/services/cryptography/
