Concept
Security model
What Tenrai guarantees, under which assumptions, and what wallets, miners, validators and services have to trust.
On this page
What you rely on
| For | You rely on |
|---|---|
| Finality of a cut | More than two thirds of the eligible stake not signing a conflicting cut |
| Ownership of coins | ML-DSA-65 and SHAKE256 holding, and your keys staying secret |
| Correct state | Your own node checking every cut, or the service you ask |
| Fair inclusion | Miners picking transactions by fee; any miner can include yours |
| Supply | Every node checking the value equation in every cut |
What consensus enforces
- One canonical encoding, and a chain ID in every transaction.
- Inputs that are sorted, unique and each authorized against the exact output it spends.
- Checked arithmetic: outputs plus fee equal inputs, with no overflow and no rounding.
- Work blocks anchored to a finalized cut, with valid proof of work.
- A fixed order of registration and execution, the same on every node.
- Emission by height, split by integers only.
- Byte and mass limits that bound parsing, signature checks and state changes per block.
Double spends and reorganizations
A finalized transaction cannot be reversed without more than two thirds of the eligible stake signing a second cut at the same height. Doing so is equivocation, it is provable, and the evidence burns each offender's self-bond plus 10 % of every delegation to it that can still be slashed. Downtime is never slashed.
There is no probabilistic finality to wait out and no deeper reorganization than zero. Hashrate, however large, cannot undo a certified cut: miners propose work, validators finalize.
What a majority of hashrate can do
A miner with most of the hashrate earns most of the mining rewards and chooses most of the transactions that get included. It can delay transactions by not including them. It cannot spend coins it does not own, reverse finalized payments or change the rules, and any other miner can still include what it leaves out.
What a third of the stake can do
Validators holding more than a third of the eligible stake can stop cuts from being certified by not signing. The chain then waits; nothing final is lost. At the committee's 80 % coverage floor, about 17 % of committee weight offline is already enough to stall, see Consensus.
Light clients and services
A wallet that asks a service, the Tenrai API or someone's node, trusts that service for what it reports.
- Signed answers prove which service answered and that the answer was not altered on the way.
- They do not prove that a reported balance, output or cut is true.
- Wallets pin the service's key on first contact. That protects every later contact, not the first one.
Whoever credits payments for a business should verify them through a node under their own control.
Post-quantum status
| Part | Status |
|---|---|
| Spending, staking, votes, node identity | ML-DSA-65 throughout; no classical alternative exists in the format |
| Identifiers | SHA-384 |
| Messenger texts | ML-KEM-512 key exchange, XChaCha20-Poly1305; the first message of a chat is public |
| Transport between native programs | TLS 1.3 with X25519MLKEM768 only |
| Transport in browsers | Chosen by the browser |
| Mining | TenQ proof of work; finality does not depend on it |
Operating safely
- Keep recovery phrases offline and validator keys on one machine only.
- Do not expose a node's API or a wallet daemon directly; put TLS and limits in front.
- Treat everything read from the chain, payloads and miner tags, as untrusted input.
- A reverse proxy and rate limits protect a service against misuse. They do not absorb a volumetric attack; that takes a CDN or a scrubbing service upstream.