QSSNQSSN Admin

Quantum Cash

ETH-backed quantum money, simulated: back a note on-chain once, hand it person-to-person entirely off-chain via a chain of one-shot signatures*, and settle on-chain once at the end.

* POC mock, not real quantum money. Notes are browser-held ML-DSA keypairs, so nothing enforces one-shot signing (a real quantum state is destroyed when spent, making double-spends physically impossible). Redemption trusts a demo attestor key that lives in this page. The on-chain flow and the cash-like off-chain transfers are the real story here; the quantum layer is simulated.
Network:signed and paid by your connected wallet (MetaMask). Switching network resets the demo.
Mode:Story simulates all parties here; Real transfer exchanges copy-paste blobs between two independent parties (self-test with both panels, or one panel per person).
on-chain txs: 0off-chain transfers: 0gas spent on transfers: 0

Redeem payout: leave the address blank for a fresh demo address (local) or your connected wallet (Sepolia). The final holder's signature binds whatever address is used.

Note holders

No note yet, mint one to begin.

    Chain of custody (off-chain)

    Chain starts once the note is backed by a deposit.

    On-chain activity

    Quiet. Transfers never touch the chain, only the deposit and the final redeem do.

    How the demo data works (and how it differs from real OSS)

    What's real vs simulated. The ML-DSA key generation, signing, and verification are genuine (FIPS-204 via qssn-sdk); the deposit and redeem are real on-chain transactions; and the off-chain verifier actually replays and checks every signature from the funded root. What is simulated: one-shot-ness is not enforced, the redemption verifier is a trusted in-page attestor, and notes are browser-held keys rather than quantum states.

    Where every value comes from

    • One session seed per browser tab. A fresh 32-byte random seed is generated when you mint (and on reset). Every party in the chain is derived from that single seed, so all the "users" you see are really one browser instance. It is deliberately independent of any wallet/ECDSA key (QSSN never derives ML-DSA and ECDSA from the same seed).
    • Each note is HD-derived from the seed at m/44'/9000'/87'/<index>'/0/0 (index 0 is the first party, +1 per transfer). A note is an ML-DSA-87 keypair.
    • Serial = keccak256(note public key). The 32-byte serial is the note's public identifier; the full public key is much larger and travels only off-chain.
    • On-chain the vault stores only the deposit id ν, the root serial s0, the value, and a spent flag, plus the two transactions (deposit, redeem). Full public keys and signatures never go on-chain; they live in the off-chain chain blob (open "Show raw data" to see it).
    • The funder is not the owner. The wallet (EOA) that pays the deposit is separate from the note's owner. Ownership is whoever holds the ML-DSA key for the funded serial s0, not whoever paid; nothing on-chain records an owner address. You could fund a note whose key someone else holds (a gift).

    Demo vs a real one-shot-signature deployment

    • Note: here an ML-DSA keypair that can physically sign more than once. In the real scheme it is a quantum state that is consumed on first use (no-cloning), which is what actually prevents double-spend.
    • Trust at redeem, and why this vault is drainable: the vault only checks a trusted attestor's ECDSA signature (plus that the deposit's root serial matches and it isn't spent). It does not verify the ML-DSA chain on-chain at all, and the demo attestor's private key ships in this page's bundle, so on this throwaway testnet vault anyone can forge an attestation and redeem any deposit. It holds trivial amounts by design. A real deployment runs the verifier off-chain (key never shipped) or replaces it with a succinct proof (SNARK) so no party is trusted.
    • On-chain settlement is ECDSA, not post-quantum. Redemption rests on an ECDSA attestation, mirroring QSSN's current posture (ML-DSA verified off-chain; on-chain is ECDSA + keccak commitments). End-to-end quantum safety on-chain would need a post-quantum proof system (e.g. a STARK), not a classical SNARK.
    • The note blob: here it grows by one signature per transfer (naive), and reveals the full ownership history to each recipient. A real system can keep it constant-size with a recursive proof and hide the history (zero-knowledge).
    • Double-redeem vs double-spend (important): the contract's spent flag truly prevents a double-redeem, a given deposit can only ever be paid out once, on-chain, first-come-first-served. What nothing here prevents is a malicious holder signing transfers to two (or more) recipients, creating branching chains. Every branch looks valid, but only the first to redeem gets paid; the others are victims who accepted a note that turns out already spent. Only true one-shot signatures (the quantum state is consumed on first use, no-cloning) make that fork impossible to create in the first place. A SNARK would make redemption trustless and succinct but would not fix this, both branches can still produce a valid proof.

    Network: Sepolia · vault: 0x35Ecd8…F165 · attestor: 0x660F78…9aBA · gas payer: your injected wallet (MetaMask)