Credits pay only for a verified pair
Published
A device that contributes compute earns credits. Almost every interesting decision in this project is packed into that sentence: who decides a device earned something, what stops the cheapest possible lie from being the most profitable strategy, and why the thing earned cannot be sold.
Making it impossible, not merely forbidden
The specification defines a credit as an integer number of microcredits, with a million microcredits to the credit. Integers, never floating point, because this is money-shaped data and a rounding error must not decide whether a device was paid. The specification also names the balance field as the only authority for money; the display value beside it exists to be rendered and must never be used for arithmetic or settlement. That distinction is not pedantry: a dashboard once read the display value first, and a device that had earned forty microcredits was shown to the operator as a rounded-to-nothing fraction of a credit, in the wrong unit.
Credits live in a double-entry ledger. Every movement has postings that must sum to zero, the ledger total must be zero, and the invariant is checked rather than assumed. Accounts are device, operator and treasury, and each entry carries why it happened: a job earning, a job spend, an adjustment, or a ceiling refusal.
Non-transferability is structural rather than a policy note. The chain adapter exposes exactly three methods: record an earning, anchor the ledger prefix, report status. There is deliberately no transfer method. A credit that could move between accounts would be a tradeable reward token; with no transfer on the interface, it cannot be sold, withdrawn or traded even by a caller who wants to.
One place where money moves
The coordinator has exactly one place where money moves, and it routes through verification and then through the settlement function. Earning is paid for work that a second device reproduced, never for self-reported throughput, because otherwise the cheapest way to earn is to lie. The outcomes are enumerated rather than left to inference:
- A single, unreplicated result pays zero, with the reason awaiting_replica.
- A matching replica pair pays once, to the primary device, with the reason verified and the paid job id named in the settlement.
- A divergent replica is refused and pays nobody.
- A deterministic job with no replica at all is refused.
- A replica reported by the same device as the primary is refused. Replication is audit work and is not paid as a second earner.
- A sampled, non-deterministic operation with no replica is unverified and pays nobody.
- A pair that was already settled returns already_settled and credits zero, because the ledger carries a nullifier that stops a second payment.
The amount, and its honest limit
The spec sets the amount as the smaller of the two reported durations in seconds, multiplied by a rate and by an accelerator multiplier, and rounded. The spec rate is a hundred thousand microcredits per second, overridable, and its multiplier is three for WebGPU, two for WASM and one otherwise. Taking the smaller duration means inflating one number gains nothing.
Both durations are self-reported by the devices, and the project says so rather than dressing it up. The payment is still gated on a matching output digest, but a colluding pair that under-reports is bounded only by the daily ceiling. The recorded upgrade path is to measure elapsed time on the clock of the coordinator itself. Earning is also capped per device per day, and the cap is enforced in the ledger rather than in a scheduling interface; the policy can refuse a candidate with device_over_daily_ceiling, and the refusal itself is recorded as an entry.
Two planes, and why the chain is not in the content one
Re-running a forward pass needs no consensus. Paying strangers for one does. So prompts and completions travel on a content plane with no chain at all, and credits travel on a settlement plane with exactly one operator-controlled chain. The chain adapter has a local in-process kind and an optional HTTP kind, and local is the default.
The chain is append-only and nullifier-based: recording the same job id twice returns already_recorded, and anchoring commits a digest of the canonical ledger prefix, so a rewritten prefix is detectable. Every method carries an explicit success flag, so a failed write cannot be mistaken for a stored one and an unrecorded earning is reported as such. There is no retry queue and no offline reconciliation: an unavailable chain is an honest refusal and the job stays unsettled.
Why non-transferable, and what it is not
The project position is that a tradeable reward token is a regulated instrument while a non-transferable usage credit is a loyalty mechanism, and that this is a legal-risk position rather than legal advice. A qualified lawyer review precedes any change to it. So the boundary is stated in advance: no public chain deployment, no token sale and no cash-out. What a device earns buys inference here and nothing else. The specification is also explicit that the amounts are set so the mechanism is testable rather than so they are economically final.
Where this can be checked
The guide cited below is the source the registry rows name for model facts. The credit arithmetic, the daily ceiling and the non-transferability decision are not in it: they are documented in docs/07-swarm-v1-spec.md, docs/08-credits-and-chain.md and src/verify.ts in the llmeuchain repository, which has no public remote to link to.
Източници
Each link goes to the source the post cites. Where a source does not state a fact, the post shows it as unverified instead of filling it in.