Two capabilities are now live on the QBC base layer, and they are the kind that are easy to claim and hard to actually wire all the way through: wallets whose spends are authorized by post-quantum signatures, and transfers whose amounts are never written to the chain. This post walks through both in detail, including the cryptography, the path a transaction takes from a browser to a finalized block, and where to watch the live counters on the frontend.
Why these two, together
Most privacy designs assume a classical signature scheme underneath. Most post-quantum work assumes amounts are public. QBC is built to need both at once. The signatures that authorize a spend are quantum resistant, and a sender can choose to keep the value of a transfer confidential. Neither feature borrows security from the other, and you can use the post-quantum wallet whether or not you ever touch the confidential path.
Part one: quantum-secure spending
The signature scheme
Every native QBC spend is authorized with a CRYSTALS-Dilithium signature at NIST Level 5, the parameter set standardized as ML-DSA-87 in FIPS-204. Public keys are 2592 bytes and signatures are 4627 bytes. These are large compared to an elliptic-curve signature, and that is the point: the security rests on the hardness of lattice problems that a quantum computer does not break the way it breaks elliptic-curve discrete logs.
Keys are generated entirely client side. In the browser wallet, key generation runs inside a WebAssembly module built from a pure-Rust FIPS-204 implementation, seeded by the browser's cryptographic random source. The secret key never leaves the device. The address is simply the SHA-256 hash of the public key, so an address is a commitment to a specific quantum-resistant key from the moment it exists.
How a spend is verified
QBC uses an unspent-output model. To spend, the wallet references specific outputs as inputs, names the new outputs, and signs a message that is the exact byte serialization of those inputs and outputs. On chain, the runtime recomputes that same message and checks the signature against the public key registered for the input's address.
The verification itself runs in a native host function rather than inside the WebAssembly runtime. This keeps the heavy lattice math fast and keeps the runtime small, while still being fully deterministic across every validator. The verifier is dual-accept: it recognizes both the earlier ML-DSA-87 encoding and the final FIPS-204 standard form. That matters for tooling. It means the browser can use a standard, well-reviewed FIPS-204 library and still produce signatures that the chain accepts, rather than being forced onto a single bespoke build.
The wallet, end to end
The flow from a click to a finalized block looks like this:
- The wallet selects an unspent output that covers the amount plus the fee.
- It builds the signing message from the chosen inputs and the intended outputs, including the change back to the sender.
- It signs that message in WebAssembly. The secret key stays in the sandbox.
- If the sender's public key has not been registered yet, the wallet proves control of the key by signing a fixed challenge, and a relay endpoint records the public key on chain. This step is idempotent and gated: a key that cannot produce a valid signature is never registered, which removes any path to an address that can receive but never spend.
- The signed spend is sent to a relay endpoint that re-verifies the signature against the exact runtime verifier before it broadcasts anything. The relay only signs the outer envelope of the extrinsic. It never sees and never needs the spending key.
The verify-before-broadcast rule is deliberate. The endpoint is a convenience, not a trust anchor. Authorization is the post-quantum signature, and that is checked again on chain by every validator. There is also a command-line tool that performs the same key generation, signing, and submission directly against a node for anyone who prefers not to use a browser at all.
Part two: confidential transactions
The confidential path hides the amount of a transfer. A confidential output does not record a number. It records a commitment, and the chain verifies that the whole transaction is consistent without ever learning the values involved. The construction is Mimblewimble style, and it rests on three checks.
Pedersen commitments hide the amount
A confidential output is a Pedersen commitment of the form C = v times H plus r times G, where v is the value, r is a secret blinding factor, and H and G are two fixed, independent generators on a Ristretto group. Because r is random and secret, C reveals nothing about v. Two different amounts with two different blindings are indistinguishable on chain. The amount lives only in the wallets that know v and r.
Commitments are additive, which is the property that makes the rest work. The commitment to a plus b equals the commitment to a plus the commitment to b. That lets the chain reason about sums of hidden values without seeing any of them.
Bulletproof range proofs prevent inflation
Hiding the amount creates an obvious risk: a malicious sender could try to commit to a negative value and conjure money from nothing. Every confidential output therefore carries a Bulletproof, a zero-knowledge range proof that the committed value lies in the interval from zero to two to the sixty-fourth, without revealing the value. A single range proof is compact, on the order of seven hundred bytes for a sixty-four bit range, and it requires no trusted setup. If a proof does not check out, the transaction is rejected. This is what makes a chain of hidden amounts sound rather than an open door.
The kernel proves balance and authorizes the spend
The third check ties everything together. For a valid transfer, the sum of the output commitments plus the fee must equal the sum of the input commitments. When you subtract those, the value terms cancel exactly if and only if inputs equal outputs plus fee, and what remains is a commitment to zero value with a blinding the sender knows. That remainder is called the kernel excess.
The sender proves they balanced the transaction by producing a Schnorr signature over the blinding generator, using that leftover blinding as the secret key. Verifying the kernel signature does two jobs at once. It confirms the transaction balances, since only a balanced transaction yields a commitment to zero, and it authorizes the spend, since only someone who knows the blindings could have produced it. The fee is bound into the signature challenge, so it cannot be altered after the fact.
Where the work happens
As with the post-quantum signatures, the elliptic-curve and Bulletproof verification run in a native host function. The generators are fixed constants, so the wallet that builds a proof and the chain that verifies it agree byte for byte. The result is that the runtime stays lean while every validator independently and deterministically checks the range proofs, the commitment balance, and the kernel signature.
In this first version, value enters the confidential pool through a governance-gated step, and confidential transfers within the pool are permissionless. Crucially, the amounts in those transfers never appear on chain. An observer sees commitments, range proofs, and a kernel signature. They do not see who paid whom how much.
The QVM, and where confidentiality meets contracts
Alongside the base layer, QBC runs the QVM, an EVM-compatible virtual machine on chain 3303 extended with quantum opcodes. The QVM is where smart contracts live, and it is the natural place for application logic that wants the same post-quantum and confidentiality properties available to plain transfers. A contract can verify a Dilithium signature inside its own logic, and the broader design lets the confidential and post-quantum primitives compose with the contract layer rather than sitting off to the side.
The QVM is busy. It is running real contracts today, and that activity is now something you can watch rather than take on faith.
Watch it on the frontend
The landing page at qbc.network carries live counters. There is an on-chain transaction counter that reflects activity across the layers, and a dedicated QVM contract counter that reads the live deployed-contract count straight from the virtual machine. The contract counter in particular is a good, honest signal of the L2 being alive: it is the number of accounts that actually hold deployed bytecode, read directly from the chain, not a hardcoded figure. The block explorer labels the new transaction types as well, so a confidential transfer shows up for what it is.
What this adds up to
A spend on QBC is authorized by a signature designed to outlast quantum computers. A transfer can keep its amount private while the chain still proves, in zero knowledge, that nothing was inflated and everything balanced. Both are verified by every validator, both are exposed through a browser wallet and a command-line tool, and both compose with the QVM contract layer. The cryptography is the interesting part, but the quieter achievement is that it is wired the whole way through, from a key generated in a browser sandbox to a proof checked inside the runtime, and you can watch the counters move.