Research

Applied research for a post-quantum world

We don't invent new cryptography. We take standardized, peer-reviewed algorithms and do the hard engineering of combining, testing and deploying them where real money and real data live.

Research areas

Six problems we're working on

Each area has a lead, a written problem statement and a public research note planned. Status is updated as work moves forward.

Post-quantum signatures

ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) replace elliptic-curve signatures, but they're 30 to 100 times larger. We study hybrid constructions with Ed25519 and how to fit them within on-chain size and compute limits.

ML-DSA-65SLH-DSAHybrid

Post-quantum key exchange

Every connection between our apps, devices and servers uses hybrid X25519 + ML-KEM-768 (FIPS 203). If either scheme holds, the session key stays secret, which shuts down harvest-now-decrypt-later attacks.

ML-KEM-768X25519TLS 1.3

Threshold & multi-party signing

Keys are generated and used in shares across several devices. Signing needs a quorum, like 2 of 3, and no single device ever reconstructs the full key, not even during setup.

t-of-nDKGProactive refresh

Formal verification

Machine-checked proofs that parsers, state machines and key-handling code do exactly what the spec says, and nothing else. We focus proofs where a bug would mean lost funds.

Memory safetyConstant timeSpec conformance

Side-channel & fault resistance

Post-quantum algorithms are newer and their implementations less battle-tested. We measure timing, power and electromagnetic leakage on real hardware and harden code with masking and redundancy checks.

MaskingTVLAFault detection

Quantum-safe migration for Solana

Solana accounts use Ed25519, and an account's public key is its address. A large quantum computer could derive the private key from it. We research hash-based vaults and rotation flows that let holders move to safety before that day.

Ed25519Hash-based vaultsKey rotation
Threat model

What a large quantum computer breaks

Shor's algorithm breaks the math behind elliptic-curve and RSA cryptography outright. Grover's algorithm only weakens symmetric ciphers and hashes, so doubling key length restores the margin. The real danger is timing: encrypted data and on-chain public keys can be collected now and attacked later.

PrimitiveUsed forQuantum attackImpactOur response
Ed25519 / ECDSAWallet and transaction signaturesShorBroken: private key recoverable from public keyHybrid with ML-DSA; hash-based vaults for long-term holdings
X25519 / ECDHSession key agreementShorBroken: recorded traffic can be decrypted laterHybrid X25519 + ML-KEM-768 on every connection
RSA-2048Legacy certificates, key wrappingShorBrokenNot used anywhere in our stack
AES-256Data at rest and in transitGroverWeakened to roughly 128-bit, still secureKeep AES-256-GCM; never use 128-bit keys
SHA-256 / SHA-3Hashing, commitments, Merkle treesGroverPreimage margin reduced, still secure at 256-bit outputKeep 256-bit outputs; basis for SLH-DSA vaults
Research notes

Published and upcoming notes

In progress Drafting Planned
QS-RN-001

Hybrid Ed25519 + ML-DSA signing

Construction, security argument and test vectors for a signature that is valid only if both components verify.

Signatures Drafting
QS-RN-002

Post-quantum signature cost on Solana

Transaction size, compute units and fees for ML-DSA and SLH-DSA verification, compared with Ed25519.

Signatures In progress
QS-RN-003

Threat model v1

Adversaries, assets and timelines, including harvest-now-decrypt-later and exposed public keys.

Threat model Drafting
QS-RN-004

2-of-3 threshold wallet design

Distributed key generation, share refresh and recovery without ever assembling a full key.

Threshold signing In progress
QS-RN-005

Hash-based vaults for Ed25519 accounts

Moving funds behind one-time hash signatures and the operational trade-offs that come with them.

Migration Planned
QS-RN-006

Leakage assessment of ML-DSA on embedded hardware

Power and EM measurements on our prototype signing device, before and after masking.

Side channels Planned
How we publish

Every result goes through the same six steps

Security claims are only worth something if others can check them. Nothing reaches users until it has been through each stage below.

Problem statement

What we're protecting, from whom, and what success looks like in measurable terms.

Specification

A written design precise enough for someone else to implement independently.

Reference code

Open-source implementation with test vectors that match the spec.

Adversarial testing

Fuzzing, fault injection and side-channel measurement by our own red team.

External review

Independent auditors and academic reviewers get full access and publish their findings.

Publication

Note, code, test results and audit report released together.

See how the research becomes a product

The five-layer software stack is where these results land first.