Documentation
How QuantumLock works
QuantumLock is a fixed-term token lock on Solana. You deposit an SPL token or SOL, choose an unlock date, and the protocol returns the full amount to your wallet when the term ends. Every lock carries a post-quantum attestation that anyone can verify.
Custody
QuantumLock is custodial. Deposits are held by the protocol vault 9Z1gsv…mTmDQs and paid back to the owner address recorded at deposit time — never anywhere else. That address is part of the signed seal, so the payout destination cannot be edited after the fact.
This is the trade-off to understand before you use it: the protocol can be watched on chain, and the terms are cryptographically fixed, but the keys are held by QuantumLock rather than by a program. A non-custodial vault program is the next step on the roadmap.
The seal
At deposit, nine fields — version tag, lock id, owner, mint, amount in base units, decimals, creation time, unlock time and the deposit signature — are joined into a canonical pipe-delimited string. That exact string is signed with ML-DSA-65, the module-lattice signature scheme standardised by NIST as FIPS 204, and hashed with SHA3-256 as a commitment.
The signature (3,309 bytes), the public key (1,952 bytes) and the signed message are all published on the lock’s proof page, where the verification runs client-side. If a single character of the record changed, the signature would stop verifying and the page would say so.
Threat model
Solana account ownership rests on ed25519. Published resource estimates put a break of 256-bit elliptic-curve keys at roughly 2,330 error-corrected logical qubits (Roetteler et al., 2017) — far beyond any machine that exists today, but a long lock is a long bet.
Lattice problems are not vulnerable to Shor’s algorithm, and Grover’s only halves preimage security, leaving a 128-bit margin on a 256-bit hash. QuantumLock’s attestation and commitment layers are built on those primitives today; binding the release path itself to the lattice key is the layer currently in development.
Fees
A flat 0.05 SOL per lock, paid in the same transaction as the deposit. No percentage of the locked amount, and nothing charged on claim.
Claiming
When the countdown reaches zero, the claim button activates on your locks page. The unlock time is re-checked server-side against the signed record — a client that lies about the clock gets refused — and the payout transaction is then sent from the vault to the owner address. Claims are guarded by a single-writer state transition, so hammering the endpoint cannot produce a double payout.