What Is io.net? The Decentralized GPU Network Powering AI on Solana in 2026

What Is io.net? The Decentralized GPU Network Powering AI on Solana in 2026

The NVIDIA H100 shortage that began in 2023 was not a temporary hiccup. By 2026 it has become the defining bottleneck of the artificial intelligence economy. Hyperscalers set the rules, waiting lists for top tier accelerators stretch into quarters, and on demand prices for an H100 hour at AWS, Google Cloud, and Azure float in the 4.50 to 5.50 dollar range. For founders building generative models or autonomous agents, that ceiling is a strategic problem.

io.net answers that problem by treating GPUs the way Airbnb treated spare bedrooms. Instead of owning hardware, the protocol orchestrates a global pool of idle accelerators sitting in data centers, mining farms, and studios, then bundles them into ready to use clusters that machine learning teams can rent by the hour. The settlement layer is Solana, the orchestration runs on the Ray distributed computing framework, the user facing product is IO Cloud, and the supplier app is IO Worker. Headline pricing lands 50 to 70 percent below AWS on demand for comparable hardware, with cluster sizes reaching 10,000 GPUs aggregated across geographies for the largest jobs.

This guide explains what io.net is, how its DePIN model works, what the IO token does after the 2025 dynamic tokenomics overhaul, how it stacks up against Aethir, Render, Akash and the hyperscalers, and what the honest tradeoffs look like for both compute buyers and GPU suppliers.

What Is io.net in Plain English

If you have ever rented a server on AWS, the mental model is simple. You pick a machine type, the vendor reserves it in a data center it owns, and you pay an hourly rate the vendor sets. io.net flips two of those three steps. The protocol does not own data centers and it does not own hardware. Anyone with a GPU and a stable internet connection can install IO Worker, register their machine, and become a supplier. On the demand side, machine learning teams open IO Cloud, specify the GPU type, count, region preferences, and duration they need, and the protocol assembles a cluster from across the supplier base. Payment flows in IO tokens through smart contracts on Solana, with the chain handling escrow and settlement.

The technical category is DePIN, short for decentralized physical infrastructure network. We covered the broader thesis in our explainer on what is DePIN, but the short version is that these projects coordinate real world hardware with crypto economic incentives instead of corporate ownership. The network pays suppliers in tokens to plug machines into a coordination layer, and the protocol earns fees by matching supply with demand.

What makes io.net distinct inside DePIN is the focus on AI workloads and the engineering decision to build the orchestration layer on top of Ray. Ray is the open source distributed computing framework created at the RISELab at UC Berkeley and used at OpenAI, Uber, Shopify, and ByteDance for large model training and inference. By integrating Ray natively, io.net lets data scientists submit a Ray job that executes across thousands of GPUs the same way it would on a private cluster, abstracting away the fact that those GPUs sit in dozens of different locations under dozens of different owners.

Why Decentralized GPU Compute Matters in 2026

The case for decentralized compute is no longer ideological, it is arithmetic. Frontier AI labs spend more than half of their total operating cost on GPU rentals. Mid tier startups burn through seed rounds because inference costs scale linearly with usage and there is nowhere to escape the hyperscaler pricing band. Academic groups have effectively been priced out of training at meaningful scale. Meanwhile, the global supply of GPUs is not as scarce as the price signals suggest. NVIDIA has shipped millions of accelerators that sit idle outside corporate data centers, including hardware in former proof of work mining facilities, professional studios with off peak capacity, and individual workstations powered down for most of the day.

io.net is the most aggressive attempt to turn that idle global supply into a usable cluster product. The headline pricing of 50 to 70 percent below AWS is not a temporary subsidy. It reflects the structural cost difference between hyperscaler overhead, which includes corporate real estate, sales teams, and shareholder returns, and a marketplace where suppliers compete on their marginal cost of electricity, hardware amortization, and the small margin needed to stay rational. The protocol takes a fee from each compute transaction, and the rest flows to the supplier.

There is a second reason decentralized compute matters that has nothing to do with price. Geographic diversification. A workload that runs across 47 suppliers in 14 countries has fundamentally different exposure to single points of failure than a workload running in one AWS region. For teams worried about sanctions, jurisdictional risk, or regional outages, that distribution is a feature. The catch, which we explore honestly below, is that distribution also makes latency harder to predict and service level agreements harder to write.

Founding Team and Backers

io.net was founded by Ahmad Shadid, a former quantitative finance engineer who built high frequency trading infrastructure before pivoting to AI compute. The original problem Shadid set out to solve was a specific scarcity issue inside a quantitative trading firm called BC8.ai that needed to backtest machine learning models at scale and could not get the GPUs through traditional channels at any acceptable price. The first version of what became io.net was an internal aggregation layer that stitched together GPUs from multiple sources to feed BC8's research pipeline. The team realized the coordination layer was more valuable as a public network than as a private tool, and io.net was spun out as an independent project in 2023.

By the end of 2024 io.net had closed a thirty million dollar Series A round led by Hack VC, with participation from Multicoin Capital, Solana Ventures, Aptos Labs, Delphi Digital, and Foresight Ventures. The Solana Foundation became an early partner. The choice of Solana as the settlement layer was deliberate. The team needed a chain that could handle high frequency state changes from cluster scheduling and per second metering at a transaction cost that would not eat into the margin advantage over hyperscalers. Solana delivered the throughput, sub second finality, and unified state required, plus immediate composability with stablecoins and emerging AI agent platforms.

Shadid stepped down as chief executive in 2024 and was succeeded by Tory Green, who came in from Hum Capital and Lockheed Martin and has focused the team on operational maturity, enterprise customer acquisition, and the dynamic tokenomics overhaul that shipped in 2025. If you want a refresher on the chain hosting the settlement layer, our explainer on what is Solana gives the necessary context.

Timeline From BC8 Origins to 2026 Ecosystem

io.net's history is short but dense with milestones. The timeline below captures the inflection points that turned a private trading firm tool into a public DePIN with more than a hundred thousand registered GPUs in 2026.

How io.net Aggregates Global GPUs on Solana

The hardest engineering problem io.net had to solve was not finding GPUs. There are millions of underutilized accelerators in the world. The hard problem was turning a population of independent, heterogeneous, geographically scattered machines into something that behaves like a single coherent cluster. A modern AI training job assumes the GPUs talking to each other share high bandwidth interconnect, synchronized clocks, and predictable network latency. That is what NVLink and InfiniBand give you inside a corporate data center. It is not what you get when you stitch together a hundred consumer rigs across four continents.

io.net's answer treats clustering as a scheduling and topology problem solved by software. When a user requests a cluster of, say, 256 A100 GPUs, the IO Cloud control plane queries the global supplier pool, filters by hardware type and availability, then runs a topology aware allocation algorithm. The algorithm groups GPUs that are physically close, on similar uplinks, with low latency to one another. For workloads that tolerate higher inter node latency, such as embarrassingly parallel inference or hyperparameter sweeps, allocation can stretch across continents. For workloads that require tight synchronization, the scheduler prioritizes co located GPUs even at higher per hour cost.

Underneath the scheduling layer sits Solana. Every supplier registration, every cluster lease, every per second meter reading, and every payment settlement is recorded as a Solana transaction or program account state change. The chain is the source of truth for who owns what, who owes what, and which supplier is currently serving which job. Solana's high throughput is essential because cluster bookings can spawn hundreds of state changes per minute when a job acquires capacity, scales up, releases nodes, and finalizes payment.

Ray Framework and Cluster Scheduling

Most decentralized compute networks stop at the marketplace layer. They give you a GPU and let you figure out how to use it. io.net goes one step further by integrating Ray directly into the cluster runtime. Ray provides a Python first programming model where you decorate a function or class as a remote actor, and the framework handles scheduling, communication, fault tolerance, and resource allocation across a cluster.

From a developer's point of view that integration is a quietly enormous deal. A data scientist already comfortable writing Ray jobs for an internal cluster can submit the same job to io.net without rewriting the application. The protocol injects Ray on the supplier side, the user connects to the head node, and the workload spreads across leased GPUs as if they sat in one machine room. Ray also gives io.net free fault tolerance. If a supplier disconnects mid job, Ray reschedules the missing actor to another node and the application continues. That graceful failure handling is mandatory in a network of independent operators.

The Ray choice explains why io.net is positioned heavily toward AI and machine learning rather than general purpose web hosting. Ray is engineered around training, inference, hyperparameter search, and reinforcement learning patterns. It is not the right tool for hosting a stateless web service or a database, which is the regime where alternatives like Akash Network shine. The two networks are complementary rather than directly competitive on the workload level.

The Two Sides: Suppliers and Compute Consumers

Like every two sided marketplace, io.net runs on the relationship between two distinct groups. On the supply side are GPU operators ranging from large data center partners and former cryptocurrency mining facilities, through professional studios with off peak capacity, down to individual enthusiasts running gaming GPUs at home. The supplier app, IO Worker, is the entry point. After installing the software, an operator runs a benchmark that classifies the GPU by model, available memory, bandwidth, and reliability, registers the machine with the network, and starts earning hourly rewards as soon as the scheduler can route work to it.

The economic detail suppliers care about most is that io.net pays them hourly regardless of whether their GPU is actively serving a workload. The protocol distinguishes between active job rewards from compute buyers paying for cluster time, and a base hourly stipend tied to availability, reliability, and reputation. The combination gives suppliers a predictable income floor while rewarding the most active and reliable machines with the lion's share of paid work. The exact formula shifted under the 2025 dynamic tokenomics overhaul covered below.

On the demand side are the compute consumers, primarily AI research teams, machine learning startups, inference providers, academic groups, and a growing roster of on chain AI agent projects that need autonomous compute access. The entry point is IO Cloud, a web dashboard where buyers describe the cluster they need and the system provisions it. Buyers can pay in IO tokens or stablecoins, with the protocol handling conversion under the hood. IO Cloud looks deliberately familiar to anyone who has used a hyperscaler dashboard, with the differences hidden in the back end.

IO Cloud Product Walkthrough

For most buyers, the first contact with io.net is through the IO Cloud dashboard. The interface walks users through a three step booking flow that mirrors what an AWS customer would expect, with the difference that the cluster lives across a permissionless supplier network rather than inside a single cloud region.

The buyer never thinks about which specific suppliers serve the cluster, just as an AWS user never thinks about which physical rack hosts their EC2 instance. The difference is that on io.net the buyer can audit the chain to see exactly which suppliers were assigned and how payment was distributed. That transparency is an underrated advantage of public blockchain settlement.

IO Cloud also exposes a command line interface and an API for teams that want to automate cluster booking. A typical machine learning operations workflow might script the API to spin up a hyperparameter search cluster, run experiments overnight, capture results, and tear the cluster down before morning. That programmable access is what unlocks io.net for on chain AI agent projects, where the agent itself is the buyer making compute decisions algorithmically. We dive deeper into that overlap in our piece on AI agents in crypto.

IO Token Economics and Dynamic Model

The IO token is the economic spine of the network and performs four primary functions. It is the payment unit for compute buyers, even when those buyers initially deposit stablecoins, since the protocol converts to IO under the hood. It is the reward unit for suppliers, paid both hourly for availability and per second for active usage. It carries governance rights, allowing holders to vote on protocol parameters, fees, and upgrades. And it acts as the staking and slashing asset for suppliers seeking higher reputation tiers.

The original 2024 tokenomics design used a fixed emission schedule that paid suppliers in IO at a programmatic rate independent of actual network usage. That worked during bootstrap, but by mid 2025 the disconnect between emissions and real demand had become a problem. Suppliers received steady IO regardless of utilization, the token faced constant sell pressure, and compute buyers got less direct value from holding IO. The dynamic model that launched in 2025 rebalanced the equation in three ways.

First, the emission schedule became responsive to network utilization. When clusters are busy and buyers pay high volumes of fees, emissions to suppliers expand. When utilization is low, emissions contract automatically. Second, a fee burn mechanism was introduced where a portion of every cluster payment is permanently removed from supply. High real usage now compresses circulating supply, creating a direct link between network demand and token scarcity. Third, supplier rewards were split into a base hourly stipend, which remains predictable for income planning, and a usage based bonus, which scales with actual job time served and reputation. The combination aligns long term token holders, suppliers, and compute buyers in a way the fixed schedule never did.

For investors, IO is now a closer proxy to network usage than under the fixed model. Growing cluster booking volume, growing fee burn, and contracting supply form a coherent thesis if the protocol continues to expand. For suppliers, modern hardware with high reliability matters more than before, since the usage based bonus rewards actual productive work rather than raw machine count. Anyone considering becoming a supplier should run the calculation against the updated model, not the 2024 schedule.

Real Workloads Running on io.net

A network with 100,000 GPUs sounds impressive on a slide. What matters is what those GPUs are actually doing. By 2026 the workload mix has settled into four dominant categories. Large language model inference is the largest by volume, with open weight serving and fine tuning runs spread across A100 and H100 clusters. Image and video synthesis sits second, primarily through diffusion models that require high throughput inference. Computer vision and reinforcement learning sit third, supported by mid tier accelerators such as RTX 4090 and L40S. The fastest growing category is autonomous AI agent compute, where on chain agents schedule and pay for their own inference cycles without human intermediation.

A specific example illustrates the model. A mid sized inference startup serving a popular open weight large language model can rent a 256 GPU H100 cluster on io.net for a multi day deployment at roughly forty percent of the AWS cost for equivalent capacity. The cluster is geographically constrained to one region for latency, the supplier mix is filtered to high reputation operators, and the deployment runs Ray Serve on the leased nodes. From the application's point of view it behaves like a managed inference service. From the cost line of the business it is the difference between burning seed capital and surviving the next eighteen months.

Another emerging pattern is hyperparameter search and experimentation tranches. Academic groups and small labs that could not afford continuous hyperscaler access now run weekend long campaigns on io.net, spinning up a few thousand GPU hours, capturing results, and tearing the cluster down. No annual contracts, no minimum spend, no procurement meetings.

io.net vs Aethir vs Render vs Akash vs AWS

The DePIN compute landscape in 2026 has four serious decentralized players and a wall of hyperscaler incumbents. The table below summarizes the position of each network on the variables that matter most for a workload decision. Numbers move week to week, so always validate against current network pages before signing a contract.

The simplest way to position the four DePIN competitors is by workload fit. io.net is the strongest fit for AI teams that already use Ray and value cluster scale and supplier diversity over enterprise service level agreements. Aethir is the strongest fit for enterprise customers needing explicit contract terms and gaming operators needing predictable latency. Render Network is the strongest fit for three dimensional rendering and media production. Akash is the strongest fit for general containerized applications, web hosting, and blockchain node operators needing a permissionless container marketplace rather than an AI specific stack.

In practice the four networks are not mutually exclusive. A sophisticated machine learning operation in 2026 might run training on io.net for the Ray integration, host its API gateway on Akash, use Render for visualization assets, and reserve a small Aethir contract for inference workloads needing guaranteed service levels. The era of one cloud per company is ending, and DePIN is one of the forces driving that change.

Risks and Honest Tradeoffs

A guide that only sells you the upside is not a guide. io.net carries real risks. The first is service level. The protocol does not offer a hyperscaler style agreement with credit refunds when a cluster degrades. Reliability is built through reputation filtering, multi supplier redundancy, and Ray's graceful failure handling. For most AI workloads that is acceptable. For workloads with hard contractual uptime obligations it is not, and those teams should keep a hyperscaler fallback or use an enterprise grade DePIN like Aethir for the regulated tier.

The second risk is latency variance. A globally distributed cluster has tail latency characteristics that a single region cluster does not. For latency sensitive inference, io.net is appropriate only with geographic constraints and high reputation supplier filters. For training, where iteration time matters more than tail latency, the variance is acceptable. The third risk is regulatory. Decentralized GPU networks are still novel to many jurisdictions, and the permissionless property is a feature for many use cases and a problem for others. Enterprises in regulated industries should consult compliance before routing sensitive workloads through any DePIN network.

The fourth risk is the IO token itself. Tokens funded by emission, even under a dynamic model with burn, face structural sell pressure from suppliers covering fiat denominated expenses. The new design improves the alignment but does not eliminate the dynamic. Anyone holding IO long term should size against the possibility of extended drawdowns in DePIN beta even if fundamentals continue to improve. The fifth risk is concentration. While io.net is decentralized in supplier count, the protocol team, the foundation, and a handful of large data center partners hold disproportionate operational influence. The trajectory toward broader decentralization is positive but the destination is not yet reached.

Pros and Cons Side by Side

Best Practices for Developers and Suppliers

For developers approaching io.net for the first time, the most useful preparation is to package your workload in a Ray compatible form before requesting a cluster. Many teams discover too late that their training loop assumes a single machine, and porting to Ray takes a week or two. Start by writing a small Ray actor based prototype on a local two GPU machine, and you will know exactly how your job behaves before committing budget to a 256 GPU booking. Pair that with geographic region filtering when latency matters, and supplier reputation filtering when reliability matters.

Another good practice is treating cluster booking as part of the experiment cycle rather than a fixed infrastructure decision. Because io.net charges per second with no minimum spend, the rational pattern is to provision exactly the cluster you need for the experiment, capture results, and release. The savings versus a permanently provisioned environment compound quickly. Automating cluster booking through the IO Cloud API is the highest leverage move for machine learning operations teams, since it lets the platform layer build cost optimization on top of the protocol primitives. We cover a parallel optimization pattern in our piece on what is DeFi, which shares conceptual DNA with composable compute.

For suppliers considering the network, the calculation starts with two numbers. The first is your fully loaded electricity cost per GPU hour including cooling and operational overhead. The second is the current expected reward per GPU hour under the dynamic tokenomics model for your hardware class. If the second meaningfully exceeds the first, supply is profitable. If it does not, no amount of token upside speculation will fix the unit economics. Modern accelerators in cheap electricity regions clear that bar comfortably. Older consumer hardware in expensive power regions often does not. IO Worker gives a useful estimator to run that calculation before committing capital.

A final reminder for both sides of the marketplace. Practice basic on chain hygiene. Never approve unbounded token spending on contracts you do not understand, double check addresses before transferring IO or stablecoins, and beware phishing flows that mimic the IO Cloud login. Our reference on how to avoid crypto address poisoning scams applies directly. If you are exploring staking IO, the primer at what is crypto staking covers the concepts. For traders monitoring IO action, the standard workflow on DEXTools remains the most direct route.

Frequently Asked Questions

The Bottom Line

io.net in 2026 is the most credible answer the DePIN ecosystem has produced to the central economic question of the AI era. How do you get GPUs cheaply, at scale, without surrendering your roadmap to a hyperscaler's procurement timeline. The protocol does not pretend to solve every workload. It does not chase the regulated enterprise tier that Aethir serves. It does not compete on rendering with Render. It does not host general containers the way Akash does. What it does is take the specific shape of AI and machine learning workloads, build a coordination layer optimized for that shape, settle the economics on Solana, and pass the cost savings to the buyer.

The dynamic tokenomics overhaul of 2025 was the inflection that turned io.net from an attractive bootstrap into a sustainable market. By linking emissions to utilization, introducing fee burn, and splitting rewards between availability and usage, every party now has aligned interests. Suppliers earn more when buyers buy more. Token holders capture network throughput through supply contraction rather than vague promise.

Whether you are a machine learning engineer trying to free your training budget, a hardware operator looking for a new revenue stream, or an investor evaluating DePIN as a long term thesis, the answer is the same. Start small, measure honestly, and let actual workload performance and unit economics guide the decision. The shift toward decentralized AI compute is no longer a slogan. It is a structural reordering of the most important infrastructure market in technology. For live IO token analytics, market depth, and on chain activity, the standard workflow on DEXTools remains the most direct lens onto the protocol's pulse.