Verifying Decentralized Training: What Each Method Guarantees, and Where a Chain Fits

1. Where we left off

Consensus is inherently a chain-level function; settlement, incentives and verification of training are not. That sharpens the finding of the first post, The Blockchain Tax, which split decentralized training into five layers and found that only consensus is chain-specific. It defined the tax as B3 minus B2: the extra cost of a full-stack blockchain design over a distributed-trust design with no chain. That definition keeps the chain from being charged for the cost of distribution itself.

Consensus means the ordering and finality of transactions among validators, and it is a chain function by definition. The other three functions can sit on a chain or off it, as the table shows.

The consequence for the tax is direct. Verification costs are paid whether or not there is a chain, so they belong in B2, and only the extra work of putting part of verification on a chain, such as publishing hashes, resolving disputes or checking attestations, is a candidate for B3 minus B2. Measuring that requires three answers first: which guarantee does a system provide, where is it enforced, and what additional work does it require? The rest of this post answers those three questions for the verification methods we found.

2. What “verified” can mean: one yardstick

Two systems can both say they verify training and guarantee entirely different things, so we separate four guarantee classes and then describe every method with the same six terms. None of the four implies another.

In particular, execution validity does not say that the declared data or recipe was benign: a poisoned dataset that is part of the declared stream replays exactly. We deliberately do not rank the methods, because a ranking would need a common threat model and the papers do not share one.

Each method is then described with six terms:

This post keeps the four classes separate in every table. It leaves out data provenance and the privacy of training data, which raise separate questions.

3. Comparing the methods on the same terms

The methods fall into three families that establish different things: succinct proofs and replay audits give per-step exactness of execution, while in-swarm checks give contribution scores, probabilistic detection of named attacks, or admission. All entries are the authors’ own claims unless noted. Kaizen and the Prime Intellect verifier are read from abstracts, excerpts or secondary summaries, as flagged in Table 3.

One paper we read and set aside: a preprint on “verifiable fine-tuning” claims run-level proofs for LoRA, but it never states the model size, names no proof backend, has an inconsistency in its own epoch length, and misattributes three cited works. We did not use it as evidence.

4. Where each guarantee is enforced, and what the chain adds

In every billion-scale training system we read, the check itself runs off-chain, and the chain orders events, anchors records or pays rewards. Two designs could give a chain a larger role in billion-scale training verification, but we found no demonstrated system implementing them at that scale. Small-scale training prototypes do exist, as discussed below:

Small-scale on-chain prototypes. Verification has been put on a chain for inference and for very small training. Agatha has an Ethereum contract arbitrate fraud proofs for MobileNet, ResNet-50 and VGG-16 inference, and opML uses an on-chain fraud-proof virtual machine. A Layer-2 protocol for decentralized learning trains small CNNs with off-chain steps validated by fraud proof, and reports an accuracy drop from fixed-point arithmetic (arXiv 2510.16024). We saw only excerpts of these papers. The pattern matters for the tax: putting arbitration on a chain pushes the computation into the chain’s arithmetic, which is a cost of the chain and not of verification as such.

The chain-linked work that could count toward B3 minus B2 is therefore the anchoring of hashes, dispute resolution, attestation quorums and reward payment. None of these has been measured for training. What has been measured, the cost of exactness (proof time, replay slowdown, redundancy), is a cost of verification, and it would be paid with or without a chain.

5. A fair comparison of B2 and B3

A like-for-like comparison holds the guarantee and the threat model constant, then counts everything the chain adds, including costs it induces in parts of the design that are not on-chain. The procedure has five steps.

1. 1

   Fix the specification. Write down the guarantee classes required, the threat model with its exclusions, the trust assumption, the coverage, and the level required, such as exactness or a detection probability.

2. 2

   Build B2. Build a chain-free design that meets the specification and establish its cost across the dimensions being measured. If selecting a least-cost baseline, define the cost function in advance; otherwise, report the feasible trade-offs across energy, compute, latency, communication and economic cost.

3. 3

   Build B3. Take the chain design that meets the same specification.

4. 4

   Count B3 minus B2 in three groups. Direct chain work: consensus participation, published hashes or attestations, on-chain disputes and reward settlement, measured in operations, bytes and energy. Induced costs elsewhere: what the chain’s limits force on the off-chain parts, such as moving data off-chain because the chain cannot hold it (Covenant exchanges pseudo-gradients through Cloudflare R2 so that it need not write them to the chain), forcing arbitration into fixed-point or deterministic arithmetic because the chain lacks native floating point, waiting out challenge or finality windows, and locked capital. Guarantee deltas: anything B3 gives that the specification did not require, such as public auditability or censorship resistance, reported as benefits and not netted against cost, because the guarantee is no longer held constant. It is important that we must point out there is a difficult measurement question that is not immediately obvious here¹.

5. 5

   Report what is measured, modeled or unknown for every line.

A design fails the fairness test if B2 and B3 meet different guarantees, if they assume different trust, or if the verification cost is counted in B3 only. The table shows the structure for a replay-audit design; it is an illustration, and the status column says how much of it has been measured.

6. Two gaps, provisional until the search is documented

Both gaps below are provisional, because our search was not systematic and “not found” does not mean “does not exist”.

The threat is real in this setting. A Gensyn-authored preprint (arXiv 2604.02372) shows that an adversary controlling one intermediate pipeline stage can inject a backdoor into a 1B model during post-training with negligible effect on validation loss, reaching a 94% attack success rate that stayed above 60% after safety alignment; the paper tests no defense. That attack edits the attacker’s own stage outside the declared update rule, so replaying that stage’s steps could expose it, whereas Sentinel lists backdoors as out of scope and was not tested against it. Attacks that arrive through admitted data or correctly computed gradients would pass a replay audit.

What the search has covered. The queries below were run on 27 Oct 2026 through a web search tool, by one searcher (an AI research assistant, with the author reviewing), alongside full reads of eleven papers and one specification. The tool does not query Google Scholar, DBLP, the ACM or IEEE libraries or Semantic Scholar directly, and some sites refuse automated access (the IACR ePrint server did), so this is a web-wide search and not a database search. About eight earlier queries, five on Gap A and three on audits and swarm checks, were run before this protocol was written and are not logged verbatim.

7. Energy: an open question

None of the verification papers we read reports energy per verified step, and only OPEN-1B reports power at all. So the energy cost of each guarantee in the tables above is unknown.

One rough estimate. OPEN-1B reports about 50% power usage on average with spikes to 70%, roughly 485 W per GPU, over 27.8 active days on 48 GPUs. That is about 32,000 GPU-hours. If 485 W is the average, the GPUs alone used about 16 MWh; if it is the spike level and the average was half of an assumed 700 W rated power, about 11 MWh. That is roughly 28 to 39 Wh per million tokens. The paper does not say which reading of 485 W is right, does not state a rated power, and the figure leaves out hosts, networking and cooling.

Inputs as OPEN-1B reports them, plus an assumed 700 W rated power. The arithmetic is ours.

What we do not know. Whether a verification method’s throughput overhead translates into an energy overhead, and in which direction it differs, is unknown. Power draw depends on utilization, memory traffic and the kernel mix, and these differ between a reproducible stack and a stock one, so we make no prediction.

What would settle it. A matched measurement of joules per token for a reproducible stack and a stock baseline on the same hardware, model, precision and data order, with hash or commitment overhead included and repeated runs to estimate variance. OPEN-1B’s data stream is designed to give the same batch ordering on any topology, which makes such a comparison practical. We cannot run it without GPU access.

8. What this means for measuring the tax

Before the tax can be measured, each design needs an accounting sheet built with the procedure above: the specification fixed first, B2 and B3 built against it, and the three groups of cost counted. The sheet then splits the costs: verification costs go into B2, and only the chain-linked work goes into B3 minus B2. The table lists what each design family would put on that sheet.

On CPU-only hardware we cannot measure the verification costs, because they depend on GPU training. What we can do without a GPU is count the chain-linked work of a design, for example how many hashes per step must be published or how many signatures an attestation quorum needs. That would give the B3 minus B2 side of the sheet a first, partial entry.

What comes next. A separate third post covers what this one leaves out: agent payments on x402, how much settlement batching saves and what it leaves unsolved, what the demand evidence shows, and why “privacy on-chain” is several problems. Those findings concern the payment layer and do not change anything discovered on the verification layer.

Appendix: the search log

Notes

1. 1

   A blockchain is a shared infrastructure. Its validators process transactions from many applications, not just the training system being studied. How much of the chain’s energy consumption should be attributed to your particular workload? Transaction count alone cannot answer that. You will eventually need an attribution method, perhaps based on marginal workload-induced resource consumption, while distinguishing it from the chain’s shared baseline energy. Back to text

Sources

As of 27 Oct 2026. Pages we opened in full or substantially:

1. 1VerdearXiv:2502.19405
2. 2Optimistic Verifiable Training by Controlling Hardware Nondeterminism (NeurIPS 2024)arXiv:2403.09603
3. 3Covenant-72BarXiv:2603.08163
4. 4OPEN-1BarXiv:2609.17380
5. 5SentinelarXiv:2603.03592
6. 6zkLoRA / VeriLoRAarXiv:2508.21393
7. 7zkLLMPoTarXiv:2610.08258
8. 8Feasibility proposal for ZK verification of frontier trainingarXiv:2606.05433
9. 9Backdoor Attacks on Decentralised Post-TrainingarXiv:2604.02372
10. 10AgoraarXiv:2607.13332
11. 11FLOP yellow paper v0.5.0 (the fetch ended before its later sections)flop.finance/intro/yellowpaper
12. 12Verifiable Fine-Tuning (read, then set aside)arXiv:2510.16830

Seen only as excerpts, abstracts or secondary summaries, and to be opened and checked before anything rests on them: Kaizen, CCS 2024 and its ePrint version; FALAFEL, ePrint 2026/1335 (abstract only); TOPLOC, arXiv 2501.16007 (ICML 2025) and Prime Intellect’s INTELLECT-2 post; the on-chain prototypes Agatha, opML and arXiv 2510.16024; the x402 batch-settlement docs and announcement; Gensyn’s testnet docs (undated, apparently stale) with dated news reports of its mainnet launch; and a Psyche repository pull request for the Solana program layout.