Status and limits
What exists today, what does not, and what is still undecided. Read this first if you are assessing Qubits for real value. Everything else in these docs describes the reference client at version 0.2.3.
Mainnet is not live, and there is no public node to connect to yet. The code has had no independent security audit.
Implemented
| Area | State |
|---|---|
| Accounts, M-of-N policies with mixed schemes, key rotation | Implemented |
| Native vaults with delay, cancel and recovery | Implemented, managed from the CLI |
| Pipelined Moonshot, validator changes by governance, epochs | Implemented |
| Fees paid to validators, claimed for a fixed payout address | Implemented |
| TLS 1.3 validator links with hybrid key exchange and ML-DSA authentication | Implemented |
| State snapshots verified from the genesis validators, history expiry, era files | Implemented |
| WebAssembly contracts, deployed by governance only | Implemented |
| Token, AMM and escrow contracts | Implemented, not deployed on any public chain |
Chrome extension wallet and window.qubits | Built, not yet published in the Chrome Web Store |
How it has been tested
| Check | Scope |
|---|---|
| Unit and integration tests | The Rust workspace, including an in-process node for the CLI |
| NIST ACVP and Wycheproof vectors | Key generation and signature verification, pinned with the exact fips204 and fips205 versions |
| SMT model of the voting rules | All schedules within a bound on validators and rounds, and each rule switched off must produce a fork |
| Simulated networks | Delays, loss, partitions, crashes and an equivocating leader, in simulated time |
| Chaos runs | Random crashes, power cuts, partitions, loss, equivocation and signed nonsense |
| End-to-end runs | Real processes over TCP and TLS, partitions through proxies, a Byzantine validator, a soak |
| Wallet in real Chrome | Websites, approvals and real transactions against a local chain |
These checks find bugs. They do not replace a review by people who did not write the code.
Not implemented
| Feature | State |
|---|---|
| Independent security audit | Not done. It is a precondition for mainnet, and should include the fips204 and fips205 crates |
| Solana bridge | Not implemented. The only trace in the code is a reserved signature domain, qubits/bridge/v1 |
| Staking and slashing | Not implemented. There is no code for either |
| Changing fee parameters | Not implemented. min_fee_per_byte is set in genesis |
| Open contract deployment | Not implemented on purpose. Opening it would need an index of token holders and a defence against spam tokens |
window.qubits on every site | Coming soon. For now it works only on qubits.sh and its subdomains |
| Block explorer | Not built. The wallet already links to explorer.qubits.sh |
| Wallet screens for vaults | Not implemented on purpose. The protocol and the CLI keep vaults |
Open questions
These are undecided, and the answers may change the protocol.
- Token economics. The native token's supply and the fee model are not settled.
- Validator selection. Whether the chain starts permissioned or moves to proof of stake. Today the set changes only through a quorum of the current validators. See Validators and epochs.
- Certificate-free consensus. Approaches that use signatures for accountability alone could cut vote traffic sharply, but are not yet peer reviewed.
- Protecting consensus from a break of ML-DSA. Validators sign with ML-DSA-65 only. A periodic checkpoint signed with per-validator SLH-DSA keys is under consideration.
- Signature aggregation. Post-quantum signatures do not aggregate, so a certificate holds 2f+1 full signatures. STARK-based aggregation is a possibility, with no timeline.
Known limits
- Validators have equal weight.
- A validator set holds at most 50 keys, so that a quorum of ML-DSA signatures fits in one governance transaction.
- The HTTP API has no connection limit or header timeout. Public API nodes must run behind a reverse proxy. See Node operation.
- BLAKE3 at 256 bits gives high second-preimage resistance for addresses. Its collision resistance is at NIST category 2.
- An SLH-DSA signature is 16,224 bytes against 3,309 for ML-DSA-65, and fees are charged by size, so an SLH-DSA account pays about 3 times the fee on its first transaction, which carries the public key, and about 4.7 times after that.
Known issues
Not fixed yet. Each is described in full on the page linked.
| Issue | Effect | Page |
|---|---|---|
A recovery SetAuth leaves the pending queue alone | A thief's queued SetAuth that nobody cancelled still executes after the rotation, so recovery must cancel it too | Vaults |
| A vault with no native balance cannot pay for recovery | Recovery waits until someone sends the vault coins for the fee | Vaults |
A second SetValidators in one block is not refused | The epoch rises by two, and epoch_views then rejects the chain of epochs that joining nodes walk | Validators and epochs |
table_elements is not limited | A contract's table size is neither limited nor charged. Only governance deploys today | Virtual machine |
| Retrying a failed snapshot restore | A retry can bring back contract storage deleted between the two pivots | Sync and history |
| A snapshot chunk can end exactly on the last live leaf | That attempt and its retries at the same pivot fail until the next pivot | Sync and history |
The height reported by a --follow source is unverified | A source that lies can keep a validator out of consensus for up to 300 s at a time | Sync and history |
Launch plan
The project has decided to launch directly on mainnet, with no public testnet. The default node of the published wallet will be https://mainnet.qubits.sh, which does not answer yet.