QSDM technical whitepaper.

Abstract

QSDM (Quantum-Secure Dynamic Mesh Ledger) is an open-source ledger for the coin Cell (CELL). Wallet transfers, task actions and consensus messages are signed with ML-DSA-87, the post-quantum signature scheme standardised by NIST as FIPS 204. Every transfer names earlier committed transfers as its parents, a rule called Proof-of-Entanglement. New CELL is created only by mining on NVIDIA GPUs, through the QSDM Hive desktop app, under a mining supply cap of 90,000,000 CELL.

The design separates two jobs: validators agree on blocks and, in the target design, earn transaction fees; miners create new supply. Today QSDM runs as a public pilot network with a single block producer operated by the project. Independent validators are the next step, and mainnet depends on a published list of gates, including an independent external audit. This paper states plainly which parts are live and which are not.

1. Motivation: a post-quantum ledger

Most blockchains sign transactions with elliptic-curve signatures. A large enough quantum computer could break those signatures and let an attacker sign on someone else's behalf. A ledger whose records are meant to last for many years should not depend on that assumption.

QSDM therefore uses ML-DSA-87 from the start. ML-DSA is a lattice-based scheme designed to resist known quantum attacks on signatures. QSDM uses it for the things that move value or decide the chain: wallet transfers, task actions and consensus votes. A wallet address is derived from the ML-DSA-87 public key, so ownership is tied to the post-quantum key itself.

Signatures are not the whole system. Section 3 lists what ML-DSA covers and what it does not, and section 9 lists the open limitations.

2. System overview

QSDM has two node roles by design, and they never run in the same process:

• Validators keep the ledger, order transactions, agree on blocks and serve the public API. They run on CPU-only, server-class machines; in the target design they earn transaction fees. They receive no block subsidy.
• Miners run on NVIDIA GPUs and produce mining proofs. Accepted proofs earn newly created CELL.

Keeping the roles apart keeps the validator's attack surface small (a validator-only build removes the GPU mining code), keeps the split between fee income and new supply clear, and means validators do not need GPUs.

What runs today

• Block producer. One node, run by the project with the role validator, produces every block at a 10 second target. A backup node follows the chain. The status API reports peers: 0.
• Validators (planned). There are no independent validators yet. Onboarding them is the next step and has not started publicly. The production design calls for at least four validators, the minimum for BFT safety with one faulty node (3f+1 with f=1).
• Miners. Enrolled NVIDIA GPU nodes running QSDM Hive submit proofs to the producer over HTTPS.
• QSDM Hive. The desktop app for Windows and Linux (1.4.22 is current). It holds the wallet, mines, and submits task actions. In the Edge Pool it can also act as a Mother Hive that coordinates a Relay.
• Relay. Part of the Edge Pool (section 8). A Relay authenticates walletless Agent computers, verifies their work and signs aggregate proofs with ML-DSA-87 for settlement.

Other first-party clients are the web wallet, the qsdmcli command-line tool, the explorer and the public HTTP API at https://api.qsdm.tech/api/v1, which needs no account or key for reads.

3. Cryptography

Signatures

QSDM signs with ML-DSA-87 (NIST FIPS 204), the highest of its three security levels (NIST security category 5). The implementation is Cloudflare CIRCL. ML-DSA-87 is used for:

• wallet transfers (qsdm/wallet-transfer/v1);
• task actions (required in blocks from height 625,000);
• mining enrollment (qsdm/enroll/v2) and owner signatures on mining proofs from Hive 1.4.22;
• consensus: every BFT vote and consensus message, from block 827,000. Each validator uses a separate consensus-only key that is never a CELL wallet;
• Relay settlement batches in the Edge Pool;
• the QSDM Hive release manifest (v2 release key; the previous key was rotated in 2026).

Addresses

An address is 64 hex characters: the SHA-256 hash of the wallet's ML-DSA-87 public key, hex(sha256(public_key)). A node accepts a signed transfer only if the signature verifies under the sender's public key and the sender address equals the hash of that key.

Keys on the user's device

Hive, qsdmcli and the web wallet create key pairs on the user's device. The web wallet stores the private key encrypted with AES-256-GCM under a key derived from the passphrase (PBKDF2-SHA-256, 600,000 iterations). Backups are a recovery phrase and an encrypted JSON keystore. Nobody, including the project, can reset a lost wallet.

Out of scope

ML-DSA protects signatures. It does not make the rest of the system quantum-resistant. Transport encryption (TLS) and some peer-to-peer traffic still use classical cryptography, and are outside the scope of this paper's post-quantum claims.

One legacy path remains: the generic peer-to-peer transaction-gossip verifier code still accepts Ed25519 signatures. The producer runs without transaction gossip intake, so no Ed25519 transaction can reach the live chain today. Retiring that code path is planned and not done.

4. Ledger and Proof-of-Entanglement

Checks on every transfer

Every signed transfer must pass three checks, at every height:

• the ML-DSA-87 signature verifies under the sender's public key, and the sender address equals the hash of that key;
• the nonce is the sender's next nonce, with no replays and no gaps;
• the balance covers the amount plus the fee. The sender chooses the fee.

The producer checks these before a transfer is queued, and every follower checks them again when it replays a block.

Transaction content root

From height 625,000 a block's transaction root commits the full contents of its transactions, not only their IDs. Amount, recipient, payload and signature cannot change without changing the block hash.

Proof-of-Entanglement

Proof-of-Entanglement (PoE) ties each transfer to history the network has already committed. A transfer names parent cells: the IDs of earlier transactions, carried inside the bytes the sender signs, so nobody can change them after signing. From the activation height, a transfer at block height h is valid only if:

1. it names 2 to 10 parents;
2. no parent repeats, and no parent is the transfer's own ID;
3. its own ID is not already used in the reference window or earlier in the same block;
4. every parent was committed at a height from h−8,640 to h−1, or earlier in the same block.

The window is 8,640 blocks, about 24 hours at the 10 second target. Because every parent points strictly backwards, the parent graph cannot contain a cycle. Each node decides parent validity from its own copy of the chain, never from the mempool, so every node reaches the same verdict.

Activation

PoE is a consensus rule from block 816,600 (11 October 2026, 13:18 UTC). The public API began refusing transfers without valid parents (HTTP 422) slightly earlier, at block 816,240, so that no such transfer could still be waiting when enforcement began. Blocks below the activation height keep replaying under the rules they were produced with.

Wallets get parents from GET /api/v1/chain/parents, which returns the tip, the window size, the minimum and maximum parent counts and a ready-to-use list of parents. Hive 1.4.22, the web wallet and qsdmcli --auto-parents fill them in automatically. A signed transfer stays valid for about a day after its parents were committed.

PoE is a block-validity rule. It does not replace BFT voting, which is how validators agree on the next block.

5. Consensus

Signed consensus

From block 827,000 (12 October 2026, 18:11 UTC) every BFT vote and consensus message must carry a valid ML-DSA signature. Unsigned consensus traffic is refused, and a signature that is present but invalid is refused at every height. This stops forged consensus messages. The status API reports it as signed_consensus_active: true and unsigned_consensus_traffic_accepted: false.

One producer today

Signed consensus does not add validators. Today the single producer signs every consensus message. That producer can, in principle, delay or leave out transactions. It cannot forge a user's ML-DSA-87 signature, so it cannot spend from a wallet. If the producer stops, the chain stops until it is back.

Mining is not part of consensus. Consensus does not depend on proof-of-work; in the design, if all miners went offline, validators would keep producing blocks and only new supply would stop.

Rules in force

Live status for each rule is in consensus_auth of /api/v1/status and on How QSDM works.

Path to independent validators

The next steps are independent validators that vote with signed consensus messages, and a standby producer: a second, independently run producer that can take over block production. Production validators must pin the list of authorised block producers. Neither step has started publicly, and no dates are promised.

6. Mining

Mining creates all new CELL. It runs on NVIDIA GPUs through QSDM Hive, using mining protocol v2; only v2 proofs are accepted.

NVIDIA attestation

Every proof must carry an NVIDIA attestation of one of two types:

• nvidia-cc-v1: data-center GPUs with confidential computing, verified through an NVIDIA-signed attestation quote against a pinned root.
• nvidia-hmac-v1: consumer NVIDIA GPUs, verified through an HMAC over the proof bundle with a key bound to an enrolled operator and its bond. This is an economic control tied to the enrollment, not cryptographic proof of the hardware.

To stop replays, a miner fetches a fresh signed challenge from the node and embeds it in the proof. A proof older than the 60 second freshness window is rejected, and a reused challenge nonce is rejected. Since October 2026 the node stores accepted proofs and nonces durably, so a proof cannot be paid twice after a restart, and pending rewards survive restarts.

Signed enrollment and bond

A mining node is registered with a signed qsdm/enroll/v2 transaction from the owner's wallet. Each node needs a 10 CELL bond (1,000,000,000 dust). The bond can be paid up front or built up from rewards: with a deferred bond, rewards are withheld into the enrollment record until it reaches 10 CELL, and only the rest goes to the spendable balance. A zero-balance enrollment requires a one-time computational postage to limit spam. Unenrolling holds the bond for 201,600 blocks (about 23 days).

The slashing transaction path exists in the code, but production consensus accepts no slash today; slash attempts produce rejection receipts. New mining enrollments are paused during the current recovery, and reopening them is the first item on the roadmap.

Canary windows and caps

Mining is open to enrolled QSDM Hive miners in 7-day canary windows (168 hours each), each with a fixed CELL budget. Caps apply per owner per 24-hour epoch (8,640 blocks), and per-IP rate limits apply. Hive 1.4.22 signs each proof with the miner's wallet (owner signature) automatically.

Reward

The block reward is 3.56490987 CELL per block in the first emission epoch, at a 10 second target block time. A reward is newly minted when the block is confirmed, through a single mining-reward transaction that credits the winning miner. That transaction is the only way new supply is created on the current chain.

7. The CELL coin

Identity

Name Cell, symbol CELL, 8 decimals. The smallest unit is dust: 1 CELL = 100,000,000 dust.

Supply

• Mining supply: 90,000,000 CELL, the cap reported by /status. The code's absolute ceiling is 100,000,000 CELL, which would leave room for a proposed 10,000,000 CELL genesis treasury; that treasury is an open decision and none has been issued. The tokenomics document plans this emission over about 20 years, with the cap approached asymptotically.
• Founder and insider allocation: 0%. There is no sale of any kind; the project does not sell CELL.
• A 10,000,000 CELL genesis protocol treasury, vested over 48 months, is a proposal for mainnet only. It is not built and is not part of the current chain.
• Validators never mint new supply. In the target design they earn transaction fees; today, with no independent validators, the fee is deducted from the sender and credited to no one, so fees leave circulation.

Emission schedule

The reward halves every 12,623,040 blocks (four Julian years at 10 seconds per block). The next halving is at height 12,623,041. Rewards are computed with integer arithmetic only, so every node agrees to the dust. The schedule in the CELL tokenomics document:

The "% of mining cap" column is cumulative. Integer truncation leaves a small, bounded shortfall (about 0.12 CELL per epoch) against the round percentages. If the target block time were changed, the per-block reward would change but the 90,000,000 CELL cap would not. The amount emitted so far is read live from tokenomics in /api/v1/status (about 3.0 million CELL in mid-October 2026).

Uses and fees

CELL pays transaction fees (in dust), WASM contract gas and the 10 CELL miner enrollment bond. Validator bonds, bridge collateral and governance weight are future uses in the design. Whether part of each fee is burned (an EIP-1559-style base-fee burn) is an open decision that must be made before genesis.

The tokenomics document is ratified in the repository but awaits counsel review before mainnet genesis. It is a technical specification, not a legal offering document.

8. Edge Pool and tasks

Signed task actions

Tasks are units of work published in the on-chain task registry. Task actions use the same self-custody rule as transfers: each action is signed with ML-DSA by its sender, whose address is the hash of the public key. Signatures are required in blocks from height 625,000. Since the node release of 15 October 2026 the built-in system task IDs are reserved: only the project's owner key can register them, so nobody else can publish a task under a built-in ID. After that release the public route POST /api/v1/tasks/actions/submit-signed was opened.

The Edge Pool

The Edge Pool pays for fixed CPU, NVIDIA GPU and RAM jobs along an explicit path: Agent computers, then a Relay, then one or more QSDM Hives acting as Mother Hives, then QSDM Core.

• Agents are walletless, outbound-only workers. They run only approved, bounded QSDM jobs. There is no remote shell, arbitrary command, script or file transfer.
• The Relay authenticates Agents, enforces resource ceilings, verifies results, stores receipts and signs aggregate settlement batches with ML-DSA-87.
• For each accepted batch, Core allocates 70% to the contributor-owner wallet, 15% to the Mother Hive operator and 15% to the CELL ecosystem reserve. Payouts come only from an already-funded task reward pool; they never mint CELL.

Relay-only settlement

From block 833,800 (13 October 2026, 13:21 UTC) paid edge tasks (qsdm-edge-worker and its GPU and RAM variants) settle only through an authorised settlement relay: a Relay whose key-derived ID is listed in the task's authorized_relay_ids, with a valid ML-DSA-87 Relay signature. Any other settlement is rejected. Settlement is fail-closed.

Status: paid resource work is in an operator-only test and is not yet open to other miners.

9. Security model and limitations

What protects users today:

• Keys are created and kept on the user's device; transfers need the owner's ML-DSA-87 signature.
• Nonces stop replays; Proof-of-Entanglement ties transfers to committed history; the content root fixes transaction contents in the block hash.
• Consensus messages must be ML-DSA signed; unsigned consensus traffic is refused.
• Mining proofs need NVIDIA attestation, a signed enrollment and a bond; duplicate proofs and nonces are rejected durably, and the node stops producing rather than continue after a block-storage failure.
• Hive checks a signed release manifest before installing an update. Every download has a published SHA-256 checksum.
• Administrative routes are not reachable from the internet, and the operator dashboard is private.

What is not done, and what users must trust meanwhile:

• Pilot network. QSDM is pre-mainnet. Treat balances and history as pilot data. Do not keep value on it that you cannot afford to lose.
• One producer. A single block producer, run by the project, makes every block. Users trust it to include valid transactions and not to censor or reorder them.
• No independent validators. There is no multi-validator BFT today.
• No external audit. No independent external security audit has been completed. The public audit page is a self-assessment. There is no bug bounty programme.
• Ed25519 retirement pending. The generic gossip verifier still accepts Ed25519; it cannot reach the live chain today, and retirement is planned.
• Consumer attestation is economic. nvidia-hmac-v1 binds a GPU to an enrolled operator and bond; it does not prove the hardware cryptographically. Slashing is not yet accepted by consensus.
• Classical transport. TLS and some peer-to-peer traffic use classical cryptography.
• Release key. Users trust the holder of the v2 release key.
• Infrastructure. Rate limits and edge rules run on infrastructure operated by the project.

Report security issues privately as described in security.txt. Do not open a public issue.

10. Roadmap and mainnet gates

The project lists its next steps in order. Dates are not promised; each step ships when it is ready and is announced on Network status and Network upgrades.

Done in October 2026

• Proof-of-Entanglement, from block 816,600.
• Signed consensus, from block 827,000.
• Relay-only paid edge tasks, from block 833,800.
• Reserved built-in task IDs and the public signed task-action route (node release of 15 October 2026).

Next

1. Reopen mining enrollment so new NVIDIA GPUs can enroll through Hive.
2. Retire Ed25519 from the generic gossip verifier.
3. Independent validators, voting with signed consensus messages.
4. Standby producer, independently run, able to take over block production.

Mainnet gates

Mainnet is declared only after all of these are done:

1. Multiple independent validators in production.
2. Signed consensus enforced (done, from block 827,000).
3. The treasury multisig (if the genesis treasury proposal is adopted) and an official, published genesis manifest.
4. An independent external security audit, with its findings fixed and the report published.

The treasury policy adds that the pilot's solo-producer bookkeeping must be replaced or redesigned, and that mainnet must start from an audited clean state or a deterministic network-wide migration that removes historic development credits. Until these gates close, QSDM is a pilot network, not a trust-minimised mainnet.

References

Project documents (fetched live from the QSDM repository on GitHub):

• What is QSDM
• Network status
• Node roles
• Security model
• Proof-of-Entanglement
• Consensus rules in force
• Signed consensus rollout
• Network upgrades
• Mining protocol v2
• Mining today
• CELL tokenomics
• Treasury policy
• Pooled edge compute (Edge Pool)
• Task registry
• Roadmap
• Glossary

On this site: How QSDM works · FAQ · API reference · Public audit. Standard: NIST FIPS 204, Module-Lattice-Based Digital Signature Standard (ML-DSA). Source code: github.com/blackbeardONE/QSDM (external site), MIT License.