Overview

Qubits is a layer 1 for holding and moving value after large quantum computers break the signatures most chains use today. These pages describe the protocol as it is implemented in the reference client, version 0.2.3, for people who build on it, run it or audit it.

What it is

Qubits is deliberately narrow: an account chain with native vaults, a small validator set and a contract system that only governance can extend. Post-quantum signatures are large, so the design accepts fewer transactions of higher value and refuses anything that would bring a classical signature back in.

Property	Value
Default signature	ML-DSA-65 (FIPS 204)
Hash-based signature	SLH-DSA-SHA2-192s (FIPS 205)
Hash	BLAKE3, 256-bit, one derive-key context per use
Encoding	borsh for everything hashed or signed
Addresses	bech32m with the prefix `qb1`, the hash of the account's initial policy
Consensus	Pipelined Moonshot, n = 3f + 1, up to 50 validators
State	Jellyfish Merkle Tree on RocksDB
Validator links	TLS 1.3 restricted to the hybrid X25519MLKEM768 key exchange
Contracts	WebAssembly on the wasmi interpreter, deployed by governance only
Native token	18 decimals, amounts are `u128` base units
Licence	Apache-2.0

Threat model

A quantum computer running Shor's algorithm breaks elliptic curve signatures and key exchange. Grover's algorithm only gives a square-root speed-up against hashes.

Component	Quantum effect	In Qubits
Signatures such as ECDSA and Ed25519	Broken by Shor	ML-DSA-65 and SLH-DSA-SHA2-192s
Hashes such as SHA-2, SHA-3 and BLAKE3	Square-root speed-up from Grover	No change needed
Key exchange such as X25519	Broken, and traffic recorded today can be decrypted later	Hybrid X25519 and ML-KEM-768
Pairing-based proofs and BLS	Broken	Not used

ML-DSA and SLH-DSA rest on different assumptions, lattices and hashes alone, which is why the protocol keeps both. Accounts may mix them in one policy, so a vault can pair a daily ML-DSA key with a cold SLH-DSA recovery key. See Status and limits for what this model does not cover yet.

How a transaction moves

 wallet or CLI              any node                    validators
 -------------              --------                    ----------
 build draft
 compute minimum fee
 sign with the key(s)
        |
        |  POST /v1/transactions
        v
                     check signature and rules
                     without running contracts
                     keep it in the mempool
                             |
                             |  gossip
                             v
                                                 leader proposes a block
                                                 every validator executes it
                                                 on top of uncommitted parents
                                                 and votes by broadcast
                                                        |
                                                        |  2f+1 votes, twice
                                                        v
                                                 block is final, written with
                                                 its state root and receipts

A client builds a transaction bound to the chain's genesis hash, with a nonce, a fee and a last valid block time. See Transactions and fees.
A node accepts it after checking the signature and the rules, but runs no contract code, because submitting is free. See Node operation.
A leader orders it into a block. Every validator executes that block speculatively and votes. See Consensus.
Once a block is final, it is stored in one synced batch with the state tree and the transaction index. See State and blocks.

How the code is organised

The reference client is a Rust workspace. Each crate depends only on the ones above it.

Crate	Role	Docs
`qubits-crypto`	Signature schemes, domains, encrypted key files	Cryptography
`qubits-types`	Addresses, accounts, policies, transactions, blocks, limits	Accounts, Transactions
`qubits-state`	State trait, Jellyfish Merkle Tree on RocksDB	State and blocks
`qubits-vm`	WebAssembly sandbox and gas	Virtual machine
`qubits-execution`	Transaction rules, vaults, contracts	Vaults, Contract model
`qubits-consensus`	Sans-I/O consensus engine	Consensus
`qubits-node`	Validator, networking, sync, HTTP and WebSocket API	Node operation, HTTP API
`qubits-cli`	The `qubits` binary	CLI
`qubits-wasm`	Wallet core for browsers	Browser wallet

Where to start

To try it, run a local chain. It takes a few minutes and uses only the two binaries.
To audit it, start with Status and limits, then Cryptography and Consensus.
To write a contract, read the contract model, then Writing contracts.
To connect a website, read window.qubits.

Source

The project's GitHub organization is QubitsChain.