Litepaper
Useful-work AI on a sovereign Layer-1.
Community machines, called miners, answer AI prompts on a GPU or on a CPU and are paid in $DNDR. A random sample of answers is re-checked by a jury of other miners, and a miner that jury convicts loses part of the deposit it locked on chain (its stake).
- Encrypted from the gateway to the miner
- Sampled re-check
- Stake at risk
On this page
The idea
Proof-of-work
Pays for hashes. Their only value is difficulty; the compute does nothing else.
Cloud AI
Useful answers, but you trust the operator's honesty, with no way to check an answer.
Dendra
Pays for AI answers people ask for (inference), on GPUs people already own, and on CPUs too. A sampled re-check, with stake at risk, makes that work checkable.
The difference is verifiability.
Validators and miners
dendra-testnet is a public testnet. It started from a fresh genesis, the file that sets a chain's first state.
Validators are the computers that order and finalise the chain's blocks, with Byzantine-fault-tolerant consensus. Miners answer and judge requests; they never validate. Random draws decide which miner serves a job, whether its answer is audited, and who sits on its jury. While committee_seed_source is 1, the work and audit draws use a block's seed only when at least committee_min_vrf_contributors validators (the seed floor) contributed to it, together carrying two thirds of the voting power that committed the block.
Check it with two commands. The first lists the validators; the second shows committee_min_vrf_contributors. dendrad is the chain's command-line program (glossary). The Explorer shows both.
$ curl -s http://testnet-api.dendranetwork.com:26657/validators $ dendrad query jobs params -o json
Join with a GPU or with a CPU
- A GPU (NVIDIA) mines. The hardware probe picks the open model the card can serve.
- A CPU judges, for now. The network's judge model, a mixture-of-experts, runs on the CPU and needs at least
MOE_CPU_MIN_RAM_MBof system RAM, with or without a GPU (bash deploy/hw_probe.sh --judge-floor-mbprints that floor; under Windows, the RAM of WSL 2). - A juror is a registered miner, so the machine also serves requests, on its GPU if it has one.
- Kit v0.2.2 keeps the rule that kit v0.2.1 set for machines without a GPU: they join only as judges, from
MOE_CPU_MIN_RAM_MBof system RAM, and answer the requests drawn for them with the judge's model; with less RAM, the kit refuses to join. - A full node or a validator needs no GPU. More roles and technologies for CPU-only machines are planned.
The path of a request
A client sends a prompt to a gateway that serves the chat-completions API (/v1/chat/completions), so existing clients work unchanged. Endpoints and the keyless demo tier are in the API docs.
The path, as a list
- You send a prompt over HTTPS to the Dendra gateway.
- The gateway reads the prompt and runs the content filter.
- It opens a job: the chain holds the fee and draws a present miner.
- The gateway encrypts the prompt to that miner, and the relay carries it.
- The miner decrypts it in memory and answers with an open model.
- The answer comes back the same way.
- The chain keeps the fee, a hash of the prompt and an embedding of the answer, never the prompt itself.
To be drawn, a miner locks DNDR on chain as its stake, at least min_stake: stake weights the draw, up to a ceiling of assignment_stake_cap_multiple × min_stake, so at a multiple of 1 a larger stake buys no more work; and a conviction takes part of it (a slash).
Before the prompt leaves the gateway, the chain holds the client's fee (escrow) and draws one present miner, one that proved it was online, or registered, in the current or the previous availability window, a fixed span of blocks. The gateway then encrypts the prompt to that miner.
The miner answers on its own hardware and anchors a commitment on chain: a fingerprint of the prompt (its hash) and an embedding of the answer, a list of numbers that summarises its meaning and that anyone can read. The job is then settled: the chain records it as answered, and the fee stays held until the audit draw below. The launch genesis holds all of it: hold_bps = 10000, since a _bps parameter counts in basis points and 10000 is 100 %.
The commitment travels in a transaction, and every block header carries the Merkle root of its transactions.
On chain, the x/jobs module handles escrow, assignment, anchoring, settlement and slashing; off chain run the miners and an encrypted relay.
How an answer gets checked
A language model rarely answers twice in the same words, so answers cannot be compared byte for byte. Dendra pays optimistically and re-checks a random sample: settle fast, audit some, punish what a jury convicts.
The life of a fee, as a list
- Held at settlement (
hold_bps). - A later block draws whether the job is audited (
audit_sample_bps). - Not drawn: released at finality, the miner is paid.
- Drawn: a jury of other miners, if the floor is met:
audit_min_quorum+ 1 present, eligible miners, since the audited one is excluded. - Upheld: the miner is paid. Convicted: the miner is slashed (
slash_leak_bps) and the client refunded. - No verdict within
audit_unwind_blocks, because no jury could be seated or it reached no verdict: the client is refunded and the miner is neither paid nor slashed.
The draw
After the job is settled, the next block's random seed (from the validators' verifiable random function, VRF) decides whether the job is audited. If that seed does not count (see Validators and miners), the draw waits for a later block. A job not drawn becomes final: its held fee is released and the miner is paid with no verdict, which is what “optimistic” means. The seed comes after the miner's commitment, so the miner cannot know in advance whether it will be checked. The rate, audit_sample_bps, is governable; read it with dendrad query jobs params -o json.
The jury
A drawn job goes to a jury of other miners, drawn on chain by stake from the pool frozen when the job opened. A juror must be present and eligible: it anchored work, or registered, within a recent window of blocks. The jury excludes the miner under audit. Each juror receives the prompt and the answer, runs a language model as judge (LLM-as-judge) and commits a valid or invalid verdict; only a node started with --judge posts one.
Every judge of the kit runs the same model, so their errors are correlated: from kit v0.2.1 the kit's judge abstains, rather than voting invalid, when all it finds is a divergence from its own reference answers, until the project lifts that guard after a dated measurement. An answer that is not a coherent attempt is still voted invalid.
To convict: “invalid” verdicts at the jury bar, which is the larger of audit_min_quorum jurors and two thirds of the anchored seats (the jury seats recorded on chain for that audit), and from a strict majority of the voting stake. The convicted miner loses slash_leak_bps of its stake (80 % in the launch genesis), and the client is refunded. To uphold, the same bar applies with “valid” verdicts, and the miner is paid. A jury that reaches neither concludes nothing.
A drawn job with no verdict is refunded. With fewer than audit_min_quorum + 1 present, eligible miners (the jury floor), no jury is seated; a jury that concludes nothing leaves the job waiting. Either way, once audit_unwind_blocks have passed, the whole fee goes back to the client, the protocol's cut included (see where a fee goes). Nobody is slashed, and a drawn job is never paid unverified.
Why sampling is enough
Auditing only a fraction of jobs makes a costly LLM judge affordable. Deterrence does not need every job checked: it needs cheating to lose money on average.
Deterrence, as a list
- s is the share of jobs drawn for audit (
audit_sample_bps), P the stake lost on conviction (slash_leak_bpsof the stake), g what a cheat saves by skipping the model. - Where a jury can conclude, cheating loses money when s × P is larger than (1 − s) × g. Opening a job caps its fee so this holds even at
min_stake.
That balance needs a jury: audit_min_quorum + 1 present, eligible miners. The Explorer shows the jury counters.
Who can read your prompt
Who reads it, as a list
- You: plain text on your device, sent over HTTPS.
- Dendra gateway: reads it, runs the filter, then encrypts it to the miner.
- Relay: ciphertext only; it passes the prompt on and cannot read it.
- Miner memory: reads it to answer it, guarded by the miner software.
- Jurors, if the job is drawn for audit: read the prompt and the answer to judge it. From kit v0.2.1 only they receive them; a miner on an earlier kit seals them for every other registered miner.
- Chain: a hash of the prompt, never the prompt itself, and an embedding of the answer, which anyone can read.
The gateway encrypts the prompt to the serving miner's key, which is anchored on chain (X25519 + AES-256-GCM), and it reads the answer on its way back to you. Besides your device, the prompt is read in plain text by the Dendra gateway, the serving miner and, if the job is audited, its jurors; the relay between them carries ciphertext only. Outside the project, a prompt reaches the public network only through the Dendra gateway: handing it to a miner is a write on the relay's request route, which takes a token the project does not distribute (relay_server.py, Handler._policy). A gateway you run yourself serves your own stack, a separate chain served only by the miners you attach to it, until the relay opens that route to other gateways. The gateway's code is in the open-source repository. Do not put secrets in a prompt.
On the miner, the miner software applies outgoing-network (egress), disk and crash-dump guards while the model answers: it keeps the prompt out of crash dumps and blocks writing it to disk or sending it anywhere but the model, where the host allows it. If the job is drawn for audit, the miner re-seals the prompt and answer to its jurors: from kit v0.2.1, to the jurors the chain anchored for that audit and to no other miner; a miner on an earlier kit seals them for every other registered miner. Each copy is sealed to the encryption key the juror registered on chain; for a juror that registered none, to the key the relay serves for it, which a relay that replaces that key can open. The gateway's content filter matches fixed text patterns.
$DNDR: a fixed supply, no mint
$DNDR is a utility token: it pays for inference and rewards miners. The supply is fixed at 10,000,000 DNDR (1 DNDR = 1,000,000 udndr). No code path can create a coin: the mint module is absent from the binary, and a test pins the 10,000,000 total.
10,000,000 DNDR at genesis: a fixed supply, no mint
The bar is the whole supply, in true proportions. The last part, 13.18 %, is split below into five balances.
The three large balances, each bar drawn against the whole supply
-
Community33.82 %3,382,000 DNDR
What remains of a 34 % community pocket after the two carve-outs below.
-
Reserve33 %3,300,000 DNDR
Released over time as protocol rewards.
-
Validator delegation pocket20 %2,000,000 DNDR
Held for future validators.
The other 13.18 %, drawn six times larger
-
Validator7 %700,000 DNDR
The launch validator's own bond and a margin.
-
Team5 %500,000 DNDR
-
Faucet float1 %100,000 DNDR
What the testnet faucet hands out.
-
Final Testnet Season payout0.15 %15,000 DNDR
Carved out of the community pocket; it pays the season's rewards, which the season cap bounds at 3,000 DNDR.
-
Request generator0.03 %3,000 DNDR
Carved out of the community pocket; it pays the fees of the season's programme requests.
Together: 10,000,000 DNDR, readable in the published genesis.
Protocol rewards come from the pre-allocated Reserve, released by a governable share of what remains each epoch (reserve_release_bps; the launch genesis sets 2 basis points, 0.02 %, per 86,400-block epoch). That is the drain rate of a pool, not a yield, and it is never annualised: an epoch's length in time depends on the interval between blocks, which the consensus does not fix. The release funds a work subsidy for miners (capped against client demand), a security share for validators, and an availability share that the launch genesis does not pay out (avail_payout_bps = 0).
Where a fee goes: of every 100 DNDR of a final job fee
- Miner 80
- Validators 7.5
- Treasury 4.5
- Team 3
- Burned 5
Validators, treasury and team together are the protocol cut: 15 (protocol_fee_bps). The 5 burned (fee_burn_bps) go at finality.
Genesis values, governable by on-chain parameters. A refunded job burns nothing.
The protocol pays for work from block 1, from client fees and the Reserve, never from inflation.
The protocol states no amount, rate or yield. What anyone receives depends on real traffic and on what remains in the Reserve. Read the live parameters with dendrad query emission params -o json.
The Final Testnet Season
A separate reward programme, not a protocol flow. It ends on 7 November 2026 at 23:59 UTC: it counts every block timestamped before 8 November 2026, 00:00 UTC, and the chain's own block times decide. Programme days are 17,280 blocks each; the last one is cut at the end. Anyone running a miner takes part, with no sign-up. Rewards are computed off chain by a published formula and paid in testnet DNDR per miner identity every seven programme days, from a payout account funded at genesis. An identity is one miner registered on chain, and one machine can run several. Anyone can recompute the ranking with final_season_rank.py.
Rewards count as points: each testnet DNDR the season paid becomes one mainnet DNDR, credited in the mainnet genesis to the address that received it, at most 3,000 mainnet DNDR in all; mainnet launches after the Final Testnet Season.
A wallet balance is not a reward: faucet grants, the stake, transfers, on-chain job pay and the work subsidy are not points. Rates, caps and limits are on the Final Testnet Season page.
Security model
| Property | Mechanism |
|---|---|
| Block order and finality | Byzantine-fault-tolerant consensus among the validators (see Validators and miners). |
| Randomness of draws | Validators' VRF outputs, attached to their block votes (vote extensions), combined and bound to the block hash. A seed must meet the seed floor, checked per block; a block whose seed does not count picks no serving miner and draws no audit; both wait for a later block, and a settled job still waiting after audit_unwind_blocks is refunded to its client. |
| Answer checking | A sampled audit, concluded by a jury at the bar set out in How an answer gets checked, with the miner's stake at risk. |
| Jury pool | Frozen at the job's opening height: an identity registered later cannot be drawn for that job. |
| Prompt confidentiality | Encryption from the gateway to the miner; egress, disk and crash-dump guards in the miner software while the model answers, where the host allows them. The miner writes a hash of the prompt and an embedding of the answer on chain, not their text. |
| Parameter changes | A governance vote, weighted by bonded stake. |
| Supply | x/mint absent from the binary; app/fixed_supply_test.go. |
| Code | Open source; the chain's test suite covers the slash, refund and unwind paths. |
Status and roadmap
Built done
The protocol
Escrow, draws from a verifiable random function checked on chain, optimistic verification with a language-model judge, settlement that pays a job at most once, Reserve release, stakes, burn and slashing, all covered by the chain's test suite. A bench also ran real inference from request to answer with actual balances.
Public testnet
dendra-testnetand the Final Testnet SeasonBlocks from a published genesis, the API at
testnet-api.dendranetwork.com, the proof feed attestnet-proof.dendranetwork.com, and install paths for Linux and Windows (Run a miner). The season's dates and current day are on its page.Mainnet next
Launches after the Final Testnet Season
Roadmap
The roadmap, by status
- Integrated
- Held fees and random audits, AI juries and slashing, encryption to the miner, availability proofs, validator joining, a chat-completions API and chat, a model sized to the miner's GPU, judging on the CPU, the miner app and installers, one miner per GPU card, rented GPU pods and HiveOS, protected keys and stake, the judge on by default, bounded automatic updates, signed releases, a fixed supply.
- Ready to switch on
- Availability rewards, the attestation gate, the model registry, randomness from several validators, the probation of new identities.
- In development
- A confidential MPC mode.
- Coming
- Judge diversity on chain, verification by recomputation, image verification (verified effort), pooled multi-GPU serving, attestation on chain, per-request model routing, a data-center enclave tier, and more roles and technologies for CPU-only machines.
Go further
Open the chat
Ask an open model and see who served each answer and its audit status.
Run a miner
Check your machine, fund a wallet, install, serve: a GPU mines, and a CPU judges, for now, and serves its share too.
Use the API
Chat-completions endpoints and the keyless demo tier.
Read the live chain
Validators, draws, verdicts and parameters, as the chain reports them.
Glossary
Escrow, settlement, finality, basis points, draws, the jury floor and slashing, one line each.