The Blockchain Tax: A First Framework for Energy-Efficient Decentralized Training

1. The question

Decentralized training promises resilience and democratized access to compute. It also promises, less examined, that this can happen efficiently, and that tokenized coordination can make it economically viable without adding a second layer of overhead on top of the first.

Our research question: how can large-scale ML be trained across decentralized, heterogeneous, energy-constrained compute while preserving efficiency, privacy, verifiability, and economic incentives — and how does the architecture need to evolve for blockchain to work better as an economic coordination layer rather than a compute layer?

That last clause is a bet the industry increasingly makes implicitly. We wanted a name for what it actually costs before designing experiments around it.

What “blockchain tax” usually means, and what we mean by it

In crypto-economics, the phrase is used loosely to cover at least four distinct things: transaction fees paid to use a network; MEV extracted by whoever controls transaction ordering; inflation or seigniorage that dilutes token holders to fund security; and state-rent-style penalties meant to discourage bloating shared storage. These are all real costs of using a chain. None of them are specifically about using a chain to coordinate ML training, and folding them together is part of why “does blockchain add overhead” is such a slippery question to answer.

For this research, we define it more narrowly.

This is deliberately multidimensional rather than a single number. For this purpose, energy is the primary measurement axis, since it’s the one most directly tied to the efficiency question we’re actually asking and the one our current instrumentation can measure directly; compute, latency, and economic cost are tracked as secondary axes rather than collapsed into one composite score.

More simply: it’s the additional energy, compute, or time a decentralized training system spends specifically because it is coordinated through a tokenized, verifiable, trust-minimized layer, relative to an equivalent system without that layer. Not “the cost of blockchain” in the abstract — the marginal cost of the coordination mechanism, isolated from the training itself.

That definition only means something once you can say which part of the system a given cost belongs to, and what it’s marginal relative to. Both are the next problem.

2. A decomposition of the system

We’re splitting any decentralized training system into five layers, because collapsing them into one “blockchain tax” number turned out to hide more than it revealed once we started reading primary sources.

Only the consensus layer is unique to blockchain-coordinated systems. Everything else exists, in some form, in ordinary distributed ML.

Training is the actual forward pass, backward pass, and optimizer update — the useful compute we’ll measure in FLOPs later. There is no blockchain-specific cost here; this is the floor everything else is overhead relative to. Communication is gradient, activation, or parameter exchange between nodes, and exists in any distributed system. Verification is proving or checking that claimed work was actually done correctly — the layer that reduces the amount of trust participants need to place in one another.

Consensus is how the chain itself agrees on state and ordering. This is the layer most people mean when they say “blockchain is energy-expensive,” usually with Bitcoin or pre-Merge Ethereum in mind. Incentives is the reward and settlement mechanism — how work gets converted into payment, and how that payment gets distributed fairly, or does not.

The rest of this post is organized around determining which of these five actually bears the cost, rather than assuming consensus by default.

3. What the literature currently tells us

Bittensor · the consensus layer

The natural assumption is that tokenized ML networks inherit blockchain’s classic energy problem. Bittensor, the largest live example, does not map onto that story by default. Its chain, Subtensor, uses Aura for block authoring and GRANDPA for finality — not proof-of-work¹.

We haven’t measured Subtensor’s actual consensus energy ourselves, and we’re treating its magnitude as an open empirical question rather than something the mechanism’s name alone settles. What its architecture does suggest is that the more interesting cost, if there is one, may lie elsewhere — for instance in the compute validators spend evaluating miners’ work, though whether that activity should count as our verification layer or something adjacent to it is something we want to test rather than assume.

Verde · the verification layer

Gensyn’s Verde protocol is the first place where we found the verification cost actually quantified². Their approach is to send a task to two or more untrusted parties and, if they disagree, binary-search down to the single operation on which they diverged rather than re-running everything.

Refereed delegation against zero-knowledge proofs for the same work. Both figures are the Verde paper’s own, for single-device tasks, and self-reported.

That number is for single-device tasks. Since then, progress has come in stages worth naming separately rather than treating as one advance.

The third stage is the one that actually matters for decentralized training, and it looks open — including for the team that first flagged it as future work ².

Bittensor · the incentives layer

An independent, data-driven audit of all 64 active Bittensor subnets found reward distribution tracking stake concentration more than output quality — a documented misalignment between the incentive mechanism’s intent and its measured outcome — a third-party audit, not a self-report⁴.

Not proof the design is unfixable — the same paper proposes protocol-level interventions — but real, on-chain, third-party evidence of a gap at the incentives layer specifically.

4. What remains unresolved

Distributed verification

Verification has been experimentally demonstrated, with real numbers, for single-device tasks. Whether it holds for genuinely distributed training — the case that actually matters for large-scale decentralized ML — remains open. This is the single biggest open item to come out of this literature pass.

Energy attribution

No source we found integrates training, communication, verification, consensus, and incentive-layer energy into one accounting framework. Each measurement we found isolates a single layer. There’s also a live methodological trap underlying any such accounting: average (flow-traced) and marginal carbon-intensity signals can disagree enough to flip which architecture looks “greener”, depending only on which commercial data provider you query.

Incentive correctness

Whether Bittensor’s stake-versus-quality gap is a fixable parameter problem or a structural property of stake-weighted peer ranking is untested. Alternative trust anchors exist in the literature — data-anchored trust, seed-peer-anchored trust — but haven’t been compared against it on shared, controlled ground.

5. Our hypotheses

Five, each tied to one layer of the decomposition above.

H3 and H4 both fall under the same accounting as everything else here: robustness is not free under any trust anchor, so the choice between stake-weighted and data-anchored trust is also a choice about where, and how much, energy is spent defending against dishonest participants.

H5 would be falsified by any system where that ordering reverses — for instance a chain whose settlement or on-chain computation, or the behavioral effects of its incentive structure, are expensive enough to outweigh a verification scheme that mostly reuses work the system would perform anyway.

6. Measurement plan

Before any of the items below can speak to “blockchain tax” specifically, we need a ladder of baselines that isolates it from the broader costs of decentralization, communication, and verification — since collapsing all of those into one number was exactly the mistake Section 2 was trying to avoid.

Each rung adds exactly one mechanism, so each delta isolates exactly one cost.

That delta can include induced secondary effects — for instance changes in how often or how thoroughly validators evaluate work once doing so is tied to token rewards — on top of whatever the consensus mechanism costs directly. A different consensus or settlement design would produce a different Baseline 3 number, so any measured blockchain tax describes the specific implementation tested, not a universal property of blockchains in general.

Not all FLOPs are equal

This is exactly the incentive-design problem. If a tokenized network rewards raw FLOPs contributed, it implicitly treats a FLOP on a tensor core and a FLOP on a laptop CPU as interchangeable, when their energy cost and dollar cost can differ by orders of magnitude. That’s a direct extension of H3 and H4: a naive FLOP-based reward function would systematically favor whoever can pad FLOP count cheaply, not whoever is actually energy-efficient.

Whether incentive layers should reward FLOPs per joule instead of raw FLOPs — and how a node’s claimed energy consumption would itself need verifying, which starts to look like Verde’s redundant-execution problem but for telemetry instead of computation — is a genuinely open design question we will revisit.

Right now Baselines 0 through 3 are framed in joules. But there’s a FLOP-level way to describe the same ladder: Baseline 2 minus Baseline 1 is, in one sense, exactly the extra FLOPs spent on redundant execution (Verde-style k ≥ 2 trainers) that does not directly reduce loss. If useful FLOP fraction — FLOPs that reduce loss, over total FLOPs spent — turned out to be a cleaner accounting unit than energy for comparing across very different hardware, we will consider it as a complementary second axis alongside the energy one.

RAPL

Energy reads come from the kernel’s powercap sysfs interface, where supported. We’re checking which domains — package, DRAM, integrated GPU — are actually exposed on each machine rather than assuming identical support across the AMD and Intel systems.

The initial pilot measures only the RAPL-visible host terms. Network and storage energy are treated as explicitly unmeasured, not folded into the host number.

On-chain activity

Public chain data for Bittensor, via Subtensor’s own API and explorer, and Gensyn’s testnet, via its public Blockscout explorer — aimed at separating consensus-layer, verification-layer, and incentive-layer costs per our five-way decomposition, rather than treating “on-chain cost” as one undifferentiated number. As with Baseline 3 above, any resulting figure describes these two specific implementations, not blockchain-coordinated training in general.

CPU, network and storage

Baseline 0 and Baseline 1, concretely: our machines, real network conditions, training a small model both as a single-machine baseline and split across both machines with real synchronization overhead. This will not tell us anything about GPU-datacenter energy profiles, but it’s a genuine — if tiny — instance of heterogeneous decentralized coordination, not a simulation of one.

Future GPU measurements

Baseline 2 and Baseline 3, at any meaningful scale, along with H1, are explicitly deferred pending access to cloud or rented GPUs, and are not simulated or approximated at toy scale in the meantime.

7. What’s next

No experiment has run. The numbers in this post trace to someone else’s measurement, not ours, and are labelled that way deliberately: self-reported figures — Verde’s benchmarks, Gensyn’s changelog claims — are flagged as such, not treated as independently confirmed.

Next experiments

Immediate: on-chain instrumentation (H5) and RAPL verification, running in parallel; neither blocks the other. Following that: the two-node CPU energy pilot (Baselines 0 and 1, feeding H2) once RAPL access is confirmed on both machines, and a federated-learning simulation harness (H3 and H4) that needs no new hardware and can start as soon as the design is finalized. Shelved: H1, and Baselines 2 and 3 at real scale, until GPU compute is available.

We’ll report results as they exist, not before.

References

1. 1Opentensor Foundation. subtensor (GitHub repository), Bittensor Blockchain Layer.github.com/opentensor/subtensor
2. 2Arun, A., St. Arnaud, K., Titov, A., Wilcox, T., Kolobarić, K., Brinkmann, N., Ersoy, O., Fielding, B., & Bonneau, J. (2025). Verde: Verification via Refereed Delegation for Machine Learning Programs.arXiv:2502.19405
3. 3Gensyn AI. ree (GitHub repository), Reproducible Execution Environment.github.com/gensyn-ai/ree
4. 4Lui, E., & Sun, J. (2025). Bittensor Protocol: The Bitcoin in Decentralized Artificial Intelligence? A Critical and Empirical Analysis. Also published in Mathematical Research for Blockchain Economy (MARBLE 2025), Springer, 2026.arXiv:2507.02951