Install one Safe Guard. Your owners, threshold and history stay exactly as they are — but every transfer also needs a post-quantum approval, verified on-chain.
An owner signs the transfer in the real Safe{Wallet}. It will not execute. The Quantum Administrator reads the payment on the device — token, amount, recipient, validity window, Safe and chain — and approves it with a one-time post-quantum signature. Only then does the money move.
Recorded end to end against the local demo stack — a real Safe, the real Safe{Wallet} and the Guard enforcing on-chain. The device is the simulated Ledger, not hardware — see Status for where the Ledger app stands.
Open it full size · Run it yourself →
Every Safe owner signs with ECDSA. A large enough quantum computer breaks ECDSA — for all your signers at once. Assets you hold for ten years need a signature that survives that day.
It decides who may sign. It can't help when the signature scheme itself falls.
They don't stop a forged signature over the same curve — the key never has to leave the device.
A policy engine the chain doesn't consult can be bypassed. The last word has to be on-chain.
FermionGuard is a Safe Guard — Safe's official pre-execution hook. Owners keep signing as they do today. The Guard lets the transaction run only if it also carries a matching post-quantum approval.
Same owners, same threshold, same hardware wallets. Protects against rogue operators, lost devices and internal failures.
A designated Quantum Administrator approves each transfer on a Ledger with an XMSS key. Protects against compromised signers, replayed approvals, allowance drains — and future quantum attacks.
An operator queues a transfer in Safe{Wallet}. Owners sign as usual.
The FermionGuard Safe App marks it 🟡 quantum authorization required.
The Administrator reviews the payload, decoded from two independent sources.
The Ledger shows every enforced field. Hold to approve.
The row turns 🟢. Anyone executes; the Guard checks and consumes the approval.
The Administrator sees exactly what they're approving
An approval names the Safe, chain, token, recipient, amount and a validity window. If anyone edits the queued transaction afterwards, the approval stops matching and the Guard refuses it.
No blind signing — the device shows every field the Guard enforces
FermionGuard ships as a Safe App inside Safe{Wallet} and a Ledger app for the Administrator. Risk flags highlight first-time recipients, unusual amounts and transactions the Guard would reject anyway — before anyone signs.
Payroll runs? A whole batch of up to 100 transfers needs one approval.
No new wallet, no new chain, no asset migration. Four steps, run by your existing owners through ordinary Safe transactions.
Add FermionGuard in Safe{Wallet}. It checks your Safe version and modules before anything changes.
The Administrator's key is generated inside the Ledger. Owners confirm it and co-sign its registration.
Owners sign one setGuard transaction, like any other Safe transaction.
A dust-sized transfer runs the full flow. When it lands, your dashboard shows Protected ✓.
Add an independent, standards-based cryptographic control to client-asset custody.
Keep your approval workflow, and make a compromised signer insufficient to move funds.
Put a public, time-locked check on the moves that matter most: governance changes.
The Guard is the last on-chain veto — and it's designed so a lost key or a bug can never freeze your funds.
Lost the Ledger? Owners alone can remove the Guard after a 14-day public countdown. A dead device never locks the Safe.
Removing the Guard or changing owners needs an approval and a 48-hour public countdown every owner is notified about.
A non-upgradeable Guard with a fast deny-all pause for incidents. No admin backdoor.
Safe modules skip guards, so enrollment requires no enabled modules — or a paired module guard on Safe 1.5+.
approve, permit and transferFrom are rejected outright, and batches are checked leg by leg on-chain.
Owners co-sign the key's full public root on their own devices, so a compromised website can't substitute a different key.
Governance changes are slow and loud; cancelling is quick
An attacker with the Administrator's Ledger still can't move funds without your owners' signatures, and can't remove the Guard without a public 48-hour countdown that your owners can cancel.
XMSS is pure hashing, so the chain checks it directly — no oracle, no trusted server. The verifier is a clean-room implementation of RFC 8391, and we say exactly how far its proof reaches: every RFC primitive, and the checks that reject malformed input, are machine-checked for all inputs against a line-by-line transcription of the RFC. Composing them into the root comparison that finally accepts or refuses a well-formed signature is argued by hand, checked symbolically at tree height 2, and pinned by RFC vectors at h = 4, 10 and 20.
XMSS is stateful: reusing a one-time leaf would let an attacker forge. The Ledger commits its counter before releasing a signature, and the contract keeps a used-leaf bitmap that reverts on any reuse.
function _verifyAndConsumeXmss( bytes32 keyId, bytes32 digest, bytes calldata xmssSignature ) internal { XMSS.Signature memory sig = abi.decode(xmssSignature, (XMSS.Signature)); BitMaps.BitMap storage used = _usedLeaves[xmssRoot(keyId)]; // per KEY, not per registration if (used.get(sig.leafIdx)) revert LeafAlreadyUsed(keyId, sig.leafIdx); if (!XMSS.verify(digest, sig, publicKey(keyId), treeHeight(keyId))) revert InvalidXmssSignature(); // whole tx rolls back used.set(sig.leafIdx); // burn the one-time leaf emit LeafConsumed(keyId, sig.leafIdx, digest); }
The design and the post-quantum verifier are public today. Early-access teams help shape the rest.
Stan (Konstantin) Kladko — from the physics that creates the quantum threat to the cryptography that has to survive it.
Ph.D., Max Planck Institute. Worked with Nobel laureate Robert B. Laughlin on quantum systems at Stanford. Director's Fellow at Los Alamos National Laboratory.
Directed a NIST-accredited cryptographic-module testing lab (CMVP), delivering FIPS 140-2 and side-channel security certifications.
Co-founder and CTO of SKALE, taking BLS threshold cryptography from paper to an Ethereum-aligned mainnet.
No. You install a Guard on the Safe you already have. Owners, threshold, history and addresses stay exactly the same.
Your owners can remove the Guard on their own, with no quantum key, after a 14-day public countdown. If the request isn't legitimate, your owners can cancel it at any point during that time with an ordinary Safe transaction. A lost device can never permanently lock your Safe.
Each transfer needs one extra approval from the Administrator on a Ledger. Batches — like a payroll run of up to 100 transfers — need just one approval for the whole batch.
Verifying the post-quantum signature costs about 745,000 gas, paid once when an approval is created (745,003 gas measured at h = 20). The check when the transaction executes is a lookup.
Safe v1.3.0 and later. The Safe must have no enabled modules, because modules skip guards — or be on Safe 1.5+ with FermionGuard's module guard installed too. It must also have no fallback handler: ERC-20 tokens and ETH work normally, but signed-message features (Permit, CowSwap orders, sign-in) and receiving NFTs via safeTransferFrom aren't supported yet.
XMSS is a NIST-approved (SP 800-208) hash-based signature, so the EVM can verify it for about 1M gas. Lattice schemes like ML-DSA and Falcon would cost tens of millions of gas to verify on-chain today.
Not yet. The post-quantum verifier is machine-checked against RFC 8391 as far as described above, and the Guard contracts are implemented and tested, but nothing is audited yet; the Ledger app and Safe App are in development, and an external audit is required before any mainnet deployment. Request early access to be among the first teams onboarded.
We're onboarding a first group of teams holding assets on Safe. Tell us about your setup and we'll be in touch as pilots open.
Opens a short, public GitHub form — please don't include anything confidential.