Research, transformed

The Case for Decentralised AI

Rebuilding intelligence from the ground up — how decentralised infrastructure changes what AI can be.

Hellas AINov 26, 20258 min read

This article examines how artificial intelligence can be built on decentralised infrastructure, rather than relying on a few large companies. It focuses on three key layers that make this possible: how compute and training can be distributed across independent networks, how models can be represented and executed in transparent ways, and how coordination and verification can keep these systems reliable.

Together, these layers show what a decentralised AI stack could look like and how it might make AI development more open, verifiable, and accessible.

The Centralisation of AI Infrastructure

The economics of artificial intelligence remain defined by concentration. The capital and infrastructure required to train state-of-the-art models have grown so large that only a few firms can participate directly.

Recent data from the Centre on Regulation in Europe shows that this concentration is increasing. The three largest cloud providers now account for around 75% of the global public cloud market and are responsible for most new large-scale AI deployments.

In that sense, compute capacity has become a form of market power. The organisations that control this part of the AI stack effectively determine who can conduct frontier research, while others rely on access leased from the same cloud providers. The result is a growing structural divide between those who design intelligence and those who merely deploy it.

While centralisation at the compute and infrastructure level is already significant, this dependency also extends further into the software layer. Most modern AI systems are built and trained using a few platforms such as PyTorch and TensorFlow. These frameworks simplify the development of large models but also concentrate control over how those models are created and optimised.

Recent industry analyses indicate that PyTorch now accounts for approximately 55% of production usage, while TensorFlow maintains a strong position in large-scale deployment environments. Together, they support nearly all state-of-the-art model development, showing that the software layer of AI has become almost as consolidated as the hardware that supports it.

Centralisation across both hardware and software limits competition and slows innovation. Relying on a small group of providers also creates a single point of failure. Changes in pricing, policies, or technical availability at one level of the stack can quickly affect the entire field. Smaller organisations and researchers face additional barriers, as most development tools follow predefined workflows that are difficult to modify or reproduce outside the dominant ecosystems.

The Case for Decentralising the AI Stack

The concentration of compute and software control within a few firms has created structural dependencies that are increasingly difficult to unwind. Addressing these dependencies requires more than incremental openness; it demands decentralisation across the entire AI stack.

Partial decentralisation is not sufficient. Open-weight models, for example, still depend on proprietary frameworks and cloud infrastructure, meaning that access and verification remain limited. The result is a system that appears open in principle but functions as closed in practice. Unless decentralisation extends through both hardware and software layers, control over the direction of AI development will remain concentrated in the same institutional hands.

Full-stack decentralisation would separate the development and governance of intelligence from the ownership of infrastructure. Distributed compute, transparent model design, and interoperable software environments would allow research and deployment to occur independently of single providers. This structure would not only reduce concentration risk but also enable broader participation in model evaluation, replication, and improvement.

As the diagram suggests, AI's centralised nature contrasts sharply with blockchain's decentralised and transparent design. Bridging these systems could unlock the shared benefits of both, such as data ownership, accountability, and inclusion. Blockchain provides the mechanisms to make such integration real by embedding transparency and collective governance directly into the AI stack, turning decentralisation from principle into practice.

From Black Boxes to Transparent Systems

If decentralisation is the necessary direction for artificial intelligence, the question becomes how to achieve it across a system built on centralised foundations. The current AI stack is vertically integrated: a small group of firms controls compute infrastructure, the frameworks that define model design, and the coordination mechanisms that govern deployment.

Breaking this concentration requires more than policy incentives or open licences. It requires rebuilding the technical architecture of AI so that its key layers of hardware, software, and governance can operate independently while remaining interconnected.

Three layers define whether such decentralisation can succeed in practice.

Compute and Training Infrastructure (Hardware Layer)

At the foundation of decentralised AI is the compute layer, where projects are exploring new methods to source and coordinate the hardware required for large-scale model training. The aim is to make use of idle or underutilised GPU resources and organise them into open, market-based networks accessible on demand.

Akash Network is building a decentralised marketplace for cloud compute, enabling independent providers to rent out unused GPU and CPU capacity. Users submit deployment requests through a reverse auction process, where providers compete to offer the lowest price for compute. The protocol earns network fees from these transactions, while validators secure and verify the marketplace's integrity.

For users, Akash offers lower-cost and censorship-resistant access to scalable compute infrastructure; for providers, it creates a new monetisation channel for idle hardware. The model effectively transforms compute into a fluid, permissionless resource rather than a fixed cost locked behind corporate contracts.

Prime Intellect builds on this foundation by extending decentralisation from compute provisioning to full-scale training orchestration. Rather than merely allocating hardware, it coordinates distributed model training across many nodes, ensuring that each contributor's work is auditable and properly attributed. The system records provenance data such as model checkpoints, gradients, and training metadata on-chain, allowing researchers and developers to verify how a model was trained and by whom. Participants earn rewards for contributing compute or model updates, while users gain access to verifiable, collaboratively trained models.

Together, these initiatives illustrate how decentralised approaches are being applied to compute provisioning and model training. Rather than accessing fixed resources from central cloud providers, developers interact with networks where protocol rules govern pricing, verification, and coordination. This represents an early stage in the development of infrastructure intended to support decentralised AI systems.

Model Representation and Execution (Software Layer)

The software layer defines how intelligence is represented and executed. Most frameworks, such as PyTorch and TensorFlow rely on dynamic computation graphs that prioritise usability but obscure the underlying model structure, making verification and portability difficult. Catgrad (developed by Hellas) takes a different approach. It is a deep learning compiler that converts models into mathematical graphs before execution, producing static code that runs directly on hardware without depending on a framework. This design makes models faster, portable, and self-contained.

Because Catgrad represents models symbolically, every operation and data flow can be inspected and verified. Training and inference are compiled in advance rather than recorded during execution, ensuring deterministic behaviour and eliminating runtime dependencies. This enables transparent and reproducible AI pipelines that can be deployed across different environments without sacrificing trust or performance.

By redefining how models are expressed and executed, this layer introduces a new level of reliability and autonomy in AI development. It allows users to own, audit, and distribute models independently of proprietary ecosystems, creating a foundation for verifiable, composable intelligence that can operate across decentralised infrastructure.

Coordination, Verification, and Governance

The coordination layer connects the hardware and software pieces into a working system. It manages how compute tasks are assigned, verified, and paid for across independent participants. Without this layer, decentralised compute would remain fragmented and unreliable.

The Hellas Network provides this coordination function as a general-purpose compute marketplace. It can source compute from networks like Akash, and it can support distributed training and orchestration with systems such as Prime Intellect, but it does not rely on either. Participants can also bring their own hardware directly to Hellas or run workloads entirely within the network.

Hellas distributes models, including those compiled through systems like Catgrad, to whichever compute providers a user chooses, whether that is Prime Intellect, Akash, self-hosted clusters, or nodes connected directly to Hellas. Each model is deterministic, so given the same input, it always produces the same output. This makes verification simple: nodes submit output hashes or partial proofs that others can check without re-running the full computation. Once results match, the computation is confirmed, and rewards are released automatically.

Hellas functions as an interoperable coordination and settlement layer that can connect to external networks when useful or operate independently when needed. This gives users flexibility in how they source or provide compute.

The result is an open decentralised AI pipeline where models can be compiled, distributed, executed, and verified across different networks or solely within Hellas. Computation becomes portable, verifiable, and accessible to anyone who wants to contribute resources or run AI workloads.

The Decentralised Future of AI

Decentralisation is not about rejecting scale but about achieving it more openly and reliably. Centralised systems are efficient in the short term but place too much control and risk in a few operators. Distributed systems spread that risk and allow infrastructure to grow more stably and transparently. Artificial intelligence has reached a point where this kind of structure is both possible and increasingly necessary.

The model described here outlines how this can work in practice. At the hardware level, distributed compute networks reduce dependence on a few cloud providers. At the software level, verifiable model compilers make training and execution portable across different environments. At the coordination level, shared protocols and onchain verification ensure that work is executed correctly and rewarded automatically. Together, these layers create a functioning system for decentralised AI.

The main benefits are practical. Decentralisation makes AI infrastructure more transparent, reduces single points of failure, and lowers entry barriers for smaller developers and research institutions. It provides a technical foundation for building AI systems that can be trusted, verified, and maintained by a wider range of participants.

Rebuilt as a Lemur Labs reading experience from the original Hellas research.

State of the Network

March 2026

Security, liquidity, volume, fees, user activity and supply across THORChain, in one read.

THORChainApr 8, 20265 min read

March delivered more of the same restraint. Volume came in at $801M, down again from February's $882M, as crypto markets spent the month attempting to find a base after a brutal February selloff. Retail sentiment stayed subdued, macro uncertainty persisted, and the kind of momentum that drives sustained trading volume simply wasn't there.

Volume & Fees

Large swaps

The standout swap of the month came on March 10th: 51.0 BTC ($3.6M) converted to ~1,700 ETH ($3.6M) in a single transaction, routed through THORSwap's frontend and powered by SwapKit. It executed across 671 subswaps with a 0.2% LP fee, plus a 0.3% affiliate fee. Clean execution at scale, exactly what the protocol is built for.

General volume

March daily volume clustered in the $15–50M range for most of the month, with one standout day: March 5th reaching $87.17M. Total volume in March came to $801M.

Swap paths

BTC and ETH continue to dominate, with BTC→ETH and ETH→BTC the two largest flows by volume. BCH holds a more visible presence this month, sitting above stablecoins, with USDT, WBTC and USDC rounding out the top routes. SOL is not yet in the top 10, though with native SOL swaps resuming around March 9th that should shift as liquidity deepens.

Fees collected

System income came in at $848K for March, down from February's $1.19M, tracking the lower-volume month. The March 5th spike is clearly visible in the income chart, producing the highest single day of the month.

TCY & RUNE yield

Yields trended downward through March, reflecting the quieter volume environment.

• RUNE APR rolled off its February peak near 25%, closing the month around 17% on the 7-day average.
• TCY followed the same trajectory, compressing from roughly 10% toward the 1–2% range by month end.

Retention & user acquisition

User acquisition held steady and was slightly higher in March despite the quieter trading environment.

Security & Supply

Bonds

Node count edged up to 105 in March, adding two operators from February's 103. Total bonded capital sits at 97.45M RUNE ($39.22M); the average bond per node holds at 928,110 RUNE ($373.56K). The minimum bond requirement stands at 433,437 RUNE ($174.46K), with the maximum effective cap at 1,004,102 RUNE ($404.15K).

Supply

RUNE supply distribution remained essentially unchanged through March. Bonded, pooled, reserve and CEX holdings all held flat, with no meaningful shift between categories.

Burn

March burned $39K in RUNE over the 30-day period, down from February's $56K. Cumulative burns now sit at $641K lifetime. The mechanism keeps running automatically, removing supply regardless of conditions.

Frontends

Leaderboard by fees

THORChain Swap's native frontend dominated the two highest-volume days, March 5th and 10th, with SwapKit taking a strong share on both spikes and forming the backbone of baseline affiliate volume. THORSwap appeared regularly, with TrustWallet, Vultisig and Asgardex contributing smaller but steady flows.

Swap count by affiliate

Daily swap counts have grown substantially since 2021 and have stabilised around 2k, with activity spikes following market trends. Affiliate diversification has also increased, showing that integrations across frontends such as Trust Wallet and Ledger are effective.

RapidSwaps

RapidSwaps picked up meaningfully toward the end of March. Cumulative volume reached $1.7M by March 30th, climbing from nearly $400k on March 22nd.

In volume share, RapidSwap went from under 1% of total THORChain volume on March 22nd to 11.64% by March 30th, all in just 9 days.

Data sources: RUNETools, THORCharts, THORChain Explorer, Raynalytics, Dune, BooneTools.

Rebuilt as a Lemur Labs reading experience.

Research, decoded

ADR023, Changing RUNE FDV

A dev spec on GitLab, turned into a story investors can actually read.

THORChainApr 9, 20265 min read

Source: adr-023-rune-supply-restructure.md on GitLab

THORChain's ADR023 proposes a restructuring of the RUNE supply framework with a clear objective: simplify tokenomics and improve how the asset is perceived and evaluated.

As the protocol has evolved, multiple legacy mechanisms have remained embedded in the supply structure. These no longer reflect how THORChain operates today, and they introduce unnecessary complexity, particularly for new market participants attempting to assess RUNE. ADR023 doesn't aim to modify core protocol mechanics, but to simplify the tokenomics, getting rid of minted RUNE that have never circulated.

The role of the Reserve

To understand ADR023, the first step is to understand the Reserve. Historically it played multiple roles within the protocol:

• Block rewards: incentives to nodes and liquidity providers (inflation).
• Inbound and outbound buffers: ensuring smooth settlement of swaps and covering gas costs.
• Exploit buffer: a backstop to compensate users in case of protocol failures.

With the removal of block rewards more than a year ago, the Reserve is no longer actively used at the same scale. Today, the majority of it is simply non-circulating RUNE sitting within the protocol: not traded, not actively used, not part of market liquidity. As a result it carries no real economic value in the market, instead representing potential dilution if ever introduced into circulation. This creates confusion around RUNE's actual supply.

💰 Current tokenomics

The initial maximum supply was 500M RUNE. Since then several adjustments have taken place:

• 13.9M RUNE removed from tokens never migrated from BEP2 to native.
• 60M RUNE burned during ADR012 to support the old lending mechanism.
• 0.9M RUNE burned through the protocol's 5% fee burn mechanism.

This brings the current maximum supply to approximately 425.3M RUNE. But not all of it is actively circulating: 71.2M RUNE remain in the Reserve, largely unused since the end of block rewards, and 2.9M RUNE are allocated to Protocol-Owned Liquidity from the THORFi era. That leaves roughly 351.2M RUNE circulating and actively used (as of October 2025).

🔁 What ADR-023 changes

ADR023 proposes to remove the majority of this non-circulating supply: around 64.9M RUNE from the Reserve will be burned, with a small balance remaining for operational and safety purposes. Following this change, total supply will be reduced to approximately 360M RUNE, aligning much more closely with the actual circulating supply.

💡 Why this matters for investors

This change is not just cosmetic, it directly impacts how RUNE is valued. Investors typically use two key metrics: Market Cap (based on circulating supply) and Fully Diluted Valuation (based on total or maximum supply). Under the current structure, THORChain shows a gap between circulating supply (~351M) and total supply (~425M), creating an artificial overhang in FDV even though a large portion of that supply will never be usable.

THORChain has recently been identified as one of the few profitable DeFi protocols. At the moment the MC/FDV ratio is around 70%, suggesting potential dilution. With ADR023 this ratio could move closer to 100%, and the price-per-share becomes more accurate and more attractive to investors.

Less artificial supply → clearer valuation → better comparability with other protocols.

Conclusion

ADR023 is a structural simplification of RUNE tokenomics. It recognises that a large portion of the current supply is no longer relevant to how the protocol operates. The proposal has already passed; following implementation in an upcoming protocol upgrade, total supply will decrease to approximately 360M RUNE. This does not change how THORChain functions, but it does change how investors and traders approach RUNE.

Rebuilt as a Lemur Labs reading experience from the ADR-023 spec ↗.

Technical deep dive

Anatomy of the May 15 halt

How automated guards, the community and node operators took THORChain offline, block by block, on May 15, 2026.

THORChainMay 20, 2026Exploit Report #1

Decentralised defence is messy, fast and very public. This is the on-chain and off-chain timeline of how THORChain responded to the May 15, 2026 exploit, reconstructed from mimir changes, node votes and the developer Discord.

1 · Automated solvency guards fire first

Before anyone typed a message, the protocol's own guards began tripping. From 07:26, solvency checks auto-halted affected chains one by one, ETH, AVAX, BSC, BASE, DOGE and GAIA, each writing a mimir key on-chain at the block the anomaly was detected. These are automatic, no human in the loop.

2 · The community spots it

Almost in parallel, contributors in the developer Discord noticed the same thing the guards did: large, memo-less transfers leaving THORChain's ETH router to a single address. Within roughly half an hour the conversation moved from "what's up with the solvency halt" to an explicit call: nodes, please do a global emergency halt.

3 · Nodes vote to halt trading

Halting THORChain is not a switch one person flips. Each protective action is a vote: once three of the 93 active nodes (≈3.2%) submit the same mimir, it activates. Trading was first, HALTTRADING activated at 09:00 on the third vote.

4 · Signing follows

With trading frozen, operators moved to stop the network from signing any outbound transactions. HALTSIGNING activated at the third vote and kept climbing as more nodes piled on, 10/93 within minutes, closing the door on outflows.

5 · A global chain halt

At 09:17, nodes escalated to HALTCHAINGLOBAL, taking every connected chain offline at once rather than chain by chain.

6 · Pausing churn, block by block

To stop the validator set from rotating mid-incident, operators repeatedly extended a churn pause. Each PAUSE pushed the halt further out, cumulatively past 7,600 blocks by 09:08, buying time to investigate safely.

Finally, HALTCHURNING was voted in at 09:43, fully freezing the node set.

From first auto-halt to a fully frozen network: a couple of hours, dozens of independent operators, all on the public record.

Rebuilt as a Lemur Labs reading experience.