Introduction
Three years after launching on Solana, io.net posted its strongest commercial numbers to date on June 11, 2026. The network closed an $8 million enterprise contract, reported over 4 billion AI inference tokens processed daily, and on the same day, launched a new tokenomics system designed to link token burns directly to real revenue. It was the most substantive update the project has had since its TGE.
The IO token still sits 96% below its all-time high of $6.43 from June 2024. That gap between operational progress and market performance is the story most coverage skips over.
This article covers what io.net actually is and how it works technically, what the IDE tokenomics overhaul changes and what it does not, where real workloads are running, and the risks that almost none of the recent announcement coverage has addressed. The network has genuine traction. Whether the IO token captures any of it is a more complicated question.
What io.net Actually Is
io.net is a decentralized physical infrastructure network (DePIN) built on Solana that aggregates idle GPU capacity from independent operators and rents it to AI and machine learning teams as on-demand compute. The core function is simple: take underutilized hardware scattered across data centers, crypto miners, and partner networks, and package it into clusters that AI developers can spin up without buying their own servers or waiting in line at AWS.
The project began in 2022 under the name ANTBIT, with a focus on quantitative trading infrastructure. As the team’s own compute demand outgrew what centralized providers could cheaply supply, they pivoted toward solving the GPU access problem directly. IO Research raised $30 million in a Series A round in March 2024, led by Hack VC with participation from Multicoin Capital, Solana Labs, Delphi Digital, Animoca Brands, and Aptos Labs. The token generation event followed in June 2024 via Binance Launchpool.
How io.net Differs from Competitors
io.net operates in a crowded field. Akash Network is the most established alternative, primarily focused on CPU compute and container deployment rather than GPU inference. Render Network specializes in GPU rendering workloads with a creator-economy base. Aethir centers on gaming and AI applications. Gensyn, which launched its own mainnet in 2026, focuses on verifiable training rather than inference serving.
io.net’s differentiating position is aggregation at scale: it pulls GPU supply from partner networks, including Render and Filecoin, rather than only onboarding its own hardware. The network’s current footprint spans 138 countries and, by its own figures, 100,000 or more GPUs. Those GPU counts need scrutiny, addressed in the risks section. But the geographic distribution is architecturally meaningful for latency-sensitive inference workloads.
Why Decentralized GPU, and Why It Matters Now
The GPU shortage that began in 2023 has not been resolved. It has matured into a structural feature of the AI economy. Hyperscalers, specifically AWS, Google Cloud, and Azure, have absorbed the bulk of available NVIDIA H100 and A100 inventory. Their on-demand pricing for an H100 instance ranges from $4.50 to $5.50 per GPU-hour. For startups running continuous inference workloads, that cost is not a rounding error. It is a strategic constraint.
Goldman Sachs estimated that major AI hyperscalers will collectively spend more than $500 billion on data center and chip infrastructure in 2026. Almost none of that capital benefits the smaller teams competing for access on the margin. Waiting lists for H100 clusters at AWS stretch into quarters for organizations outside preferred tiers. Building your own data center is not an option for a ten-person research team.
The structural argument for decentralized compute is that fragmented supply, idle GPUs sitting in data centers, miner rigs, and partner networks, represents a meaningful reservoir of capacity that goes unused because no coordination layer exists to price and allocate it efficiently. io.net’s pitch is that it builds that coordination layer.
Whether the network actually unlocks that supply at enterprise-grade reliability is the real question. The announcement-layer argument has been solid since 2023. The execution layer is where things get more complicated.
The AI Inference Shift Changes the Math
Training a large language model requires massive burst compute that favors centralized clusters. Inference, running a model to answer queries, has very different characteristics. Inference workloads are latency-sensitive and continuous; they benefit from geographic distribution and do not require the same level of hardware homogeneity as training. A well-clustered set of A100s spread across three data centers can serve inference as effectively as a single centralized rack.
This matters for io.net specifically because inference is now the dominant growth vector in AI infrastructure spending. Model training has consolidated among a small number of frontier labs. Inference serving is the workload that millions of developers and enterprises need at scale, right now, continuously. io.net’s position as the leading DePIN-native inference provider on OpenRouter is a direct bet on that shift.
How io.net Works
The Supply Layer: IO Worker
GPU providers join the network by installing the IO Worker software on NVIDIA GPUs with a minimum of 4GB VRAM and meeting bandwidth requirements of at least 100 Mbps download and 75 Mbps upload. Each GPU must pass a 12-hour initial stress test and maintain a minimum 5-hour daily uptime to remain eligible for rewards. Providers stake a minimum of 200 IO per chip, adjusted by a GPU model multiplier, with premium hardware like H100s and RTX 4090s receiving significantly higher reward weights.
One detail the documentation understates: the IO Worker binary is closed-source. Providers are installing and running software they cannot inspect. The implications of this for the network’s claimed openness are covered under risks.
The Demand Layer: IO Cloud and IO Intelligence
On the demand side, developers interact with io.net through two primary interfaces. IO Cloud is the cluster management platform, where users spin up on-demand GPU clusters for parallel training, hyperparameter tuning, reinforcement learning, and batch inference. Clusters are built using Ray, the open-source distributed computing framework that OpenAI used to train GPT-3 and GPT-4. Ray handles task orchestration, workload distribution, and parallel execution across nodes.
IO Intelligence is the more recent product, a managed inference API that abstracts away the cluster management layer entirely. Developers call the API, pay per inference token, and get back model outputs without managing hardware. This is the product feeding io.net’s OpenRouter integration, and it is where the 4 billion daily token figure comes from.
Payments use USDC or IO tokens, with a 2% fee on USDC transactions and no fee when paying in IO.
Verification: Proof-of-Work and Proof of Time-Lock
To prevent fake GPU registration and reward farming, io.net runs two verification mechanisms. Proof-of-Work runs hourly and requires each registered GPU to solve a computational puzzle, verifying that the hardware is real and performing at advertised capacity. A Binary Checker API validates solutions. A Challenges API generates the puzzles. Results are submitted to a validation API.
Proof of Time-Lock verifies uptime, ensuring that hardware is not simply turned on for verification and then switched off. Providers must demonstrate sustained availability across rolling time windows to qualify for hourly rewards.
Both of these systems were introduced or hardened after the April 2024 Sybil attack. They represent genuine improvements to verification integrity. Their limitations are detailed in the risks section.
What Is Live Today vs. What Is Still Early
| Capability | Status |
| IO Cloud cluster management | Live |
| IO Intelligence inference API | Live |
| OpenRouter inference integration | Live |
| IDE tokenomics (token burn) | Launched June 11, 2026 |
| Revenue-linked supplier payouts | Live under IDE |
| On-chain governance / DAO | Not live |
| Open-source orchestration layer | Not live |
| GPU training at scale (H100 clusters) | Emerging, not reliable at enterprise scale |
| Governance token voting | Not planned |
The inference story is real and operational. The enterprise training story, the larger compute market where io.net would compete directly with AWS and Lambda Labs for sustained GPU-hours at scale, is still early. The $8M enterprise contract is described by io.net as an inference workload. No public details confirm it involves large-scale model training.
IO Cloud accepts both crypto and credit card payments, removing the on-ramp friction that keeps traditional developers away from DePIN compute. That is a meaningful product decision.
Tokenomics: The IDE in Depth
What the Old Model Got Wrong
Like most DePIN projects, io.net launched with a fixed emissions schedule. Hourly rewards flowed to GPU providers regardless of whether the network was actually generating revenue from paid jobs. Supply-side income was entirely dependent on IO’s token price. When the price fell, provider income fell with it. Providers had an incentive to turn off hardware during downturns, which reduced available capacity and further damaged the network’s reliability reputation. Fixed emissions without demand coupling create a structural fragility that multiple DePIN networks have already experienced.
io.net’s original tokenomics have a maximum supply of 800 million IO. 500 million were released at the TGE in June 2024. The remaining 300 million are scheduled to be emitted as hourly rewards over 20 years on a disinflationary schedule, starting at 8% annual inflation and decreasing monthly. A programmatic burn mechanism using a portion of network revenue was always planned. The IDE is the formal, demand-driven implementation of that mechanic.
How the IDE Works
The Incentive Dynamic Engine replaces the fixed emissions model with a system that adjusts token flows based on actual network usage. Two vaults handle the mechanics. The reward vault distributes provider payouts. The fee vault accumulates customer payment revenue. The engine calculates target payout levels based on real demand signals rather than a static schedule.
Provider income under the IDE is denominated in a stable USD target. When IO’s price drops, the engine distributes more tokens from the existing supply to maintain the same USD-equivalent payout. When IO’s price rises, fewer tokens are needed. This protects suppliers from the income volatility that destabilized the original model.
The burn mechanism, the part most coverage focused on after the June 11 announcement, commits at least 50% of post-payout network revenue received in IO tokens to permanent destruction. io.net projects a minimum of 12 million IO tokens burned over the next 12 months, backed by the $8 million enterprise contract, contributing roughly $650,000 in monthly on-chain earnings. The first burn occurred on June 11, 2026.
12 million IO against a circulating supply of approximately 346 million is a 3.5% reduction. Meaningful, but not a dramatic supply shock on its own. The bull case requires that additional enterprise contracts scale revenue significantly before the remaining 300 million emissions reach the market.
Token Distribution and Unlock Pressure
The genesis 500 million supply is split across five allocations: seed investors, Series A investors, core contributors, research and development, and community/ecosystem. Seed and Series A investor unlocks began in July 2025, 13 months after TGE, vesting over two to three years. The core team unlocks began on the same schedule.
The token distribution is insider-heavy relative to its DePIN peers. Investors who participated in the $1 billion FDV Series A valuation are sitting on substantial losses at today’s prices. Linear vesting schedules create ongoing sell pressure even as burns increase. The net supply trajectory depends entirely on whether revenue growth outpaces scheduled emissions and investor exit behavior. Those are not guaranteed.
Real Use Cases on io.net Today
Large Language Model Inference
This is the largest workload category by volume in 2026. Open-weight models, including various Llama and Mistral variants, are being served through io.net’s IO Intelligence API and surfaced through OpenRouter. Developers call the API to run inference on these models without managing GPU clusters directly. The 4 billion daily token figure comes from this workload category. For the broader context of where AI inference fits into the decentralized AI stack, see the analysis on how AI agents consume compute infrastructure.
Image and Video Synthesis
Diffusion model inference, generating images and short video clips, is the second-largest category. These workloads are GPU-intensive but embarrassingly parallel, meaning they distribute well across geographically dispersed nodes. io.net’s architecture handles this workload more cleanly than training, which requires tighter node coordination.
Hyperparameter Tuning and Reinforcement Learning
ML teams use io.net’s cluster-based IO Cloud for hyperparameter search runs and smaller RL training jobs. These workloads require bursts of parallel compute across many GPUs simultaneously, rather than sustained GPU-hours on a homogeneous cluster. Distributed heterogeneous hardware suits this pattern.
Fine-Tuning Runs
Fine-tuning a pre-trained model on a proprietary dataset requires far less compute than training from scratch. It is a realistic workload for smaller teams that cannot afford reserved cloud capacity. io.net’s on-demand pricing, reportedly 50 to 70% below AWS rates, makes this economically viable at a scale that centralized pricing prevents.
Batch Processing
Non-time-sensitive jobs, large-scale data processing, embedding generation for vector databases, model evaluation runs, suit io.net’s current reliability profile better than real-time production inference. Latency tolerance is higher, and occasional provider variability matters less.
The Risks: What Most Coverage Is Not Saying
1. The Sybil Attack Revealed a Metric Integrity Problem That Has Not Been Fully Resolved
On April 25, 2024, io.net’s network was targeted in a coordinated attack. Malicious actors exploited a leaked authentication token that was historically identical across all registered GPUs to access the worker API and alter device metadata en masse. The attack allowed fake GPUs to masquerade as legitimate hardware and farm airdrop rewards. The authentication vulnerability was a universal token, meaning any single compromised device could have been used to impersonate any other device on the network.
io.net’s response was prompt: they shut down the metadata update capability within 10 minutes of identifying the attack, deployed Proof-of-Work verification, and began flushing spoofed GPUs from the network. What the response did not address is the residual credibility damage to io.net’s GPU count figures.
Before the attack, io.net claimed 600,000 or more registered GPUs. After flushing, independent analysis found roughly 327,000 registered devices, but only approximately 6,720 verified active GPUs on any given day, and only around 5,350 cluster-ready GPUs at any moment. The gap between the headline figure and the actionable supply is significant. io.net now describes itself as having 100,000 or more GPUs, a number that sits between the registered and verified-active figures, without a clear explanation of how verification defines that count.
The Proof-of-Work and Proof of Time-Lock systems meaningfully improved Sybil resistance after the attack. They did not eliminate the fundamental challenge of verifying physical hardware remotely through software running on that same hardware.
2. The Core Is Centralized, and the “Open Source” Framing Misrepresents That
io.net uses open-source branding prominently in its communications. The IO Worker binary, the software running on every GPU supplier’s hardware, is closed source. The orchestration layer, matching engine, billing system, API, and verification stack are all operated centrally by io.net. There is no public code repository for these components. The platform can censor or deny service to any provider or consumer, with no community governance mechanism to challenge those decisions.
This is not incidental. An independent review rated io.net’s infrastructure decentralization at 10/20, noting that while the supply side is geographically distributed, the control plane is entirely centralized. Governance scored 2/20. There is no DAO, no on-chain governance forum, and no token voting for any protocol parameter, including the tokenomics changes introduced by the IDE.
The IDE itself, a significant redesign of how the network operates, was announced and implemented by the io.net team without any community governance process. That is a meaningful fact for anyone evaluating the token’s decentralization properties.
3. Three CEOs in Under Two Years Is Not a Footnote
Founder Ahmad Shadid departed on June 11, 2024, the day of the token generation event, under circumstances that were not fully disclosed. Co-founder Tory Green assumed the CEO role. At least one additional leadership change has occurred since then. Three CEO-level changes in under two years at a young infrastructure protocol create execution risk that is difficult to quantify but real.
Major customer contracts, the enterprise deal category io.net is now targeting, require technical roadmap credibility and leadership continuity. The departure of a founder at the precise moment of the most visible event in the network’s history is a yellow flag that received almost no coverage in mainstream crypto media.
4. The IDE’s Reserve Depletion Risk Is Real and Has Not Been Battle-Tested
Messari’s analysis of the IDE included stress test simulations that are worth reading carefully. The IDE effectively stabilizes provider income under scenarios like a 50% token price crash or a 55% demand drop. Under those conditions, the dual-vault system distributes tokens from reserve to maintain USD-equivalent payouts.
The flagged failure mode is reserve depletion. If the token price drops severely and demand falls simultaneously for a sustained period, the fee vault runs out before the reward vault can be replenished by incoming revenue. The IDE becomes temporarily unable to maintain supplier payouts at target levels. That scenario would trigger the same supply-side exit that the IDE was designed to prevent.
The stress tests demonstrated this risk exists. They did not demonstrate that io.net has adequate reserves to survive a bear market of the type that has repeatedly hit DePIN tokens, including IO itself, which fell from $6.43 to below $0.15 at its low. The IDE launched on June 11, 2026, during a period of favorable network traction. It has not yet been tested under genuine market stress.
5. Investor and Team Token Unlocks Create Persistent Sell Pressure
The 300 million emission pool is the most visible supply overhang, but it is not the only one. Seed investors, Series A investors, and core contributors began unlocking in July 2025. These allocations represent roughly 34% of the genesis 500 million supply and vest linearly over two to three years. Investors who purchased at the $1 billion FDV are sitting on significant paper losses. The incentive to exit on any meaningful price recovery is structural, not speculative. The IDE’s burn mechanism needs to absorb both ongoing emissions and periodic unlock-driven sell pressure simultaneously to produce a sustained supply reduction.
What This Means for Different Types of Investors
For investors: The IDE represents a genuine structural improvement over fixed emissions, and the $8M enterprise contract is the first real evidence that io.net’s compute is worth paying for at commercial scale. But the token price at ~$0.16 reflects the substantial overhang: insider unlocks running through 2027, 300 million in remaining emissions, and a market cap that peaked at over $2 billion during the TGE excitement. The burn math works if enterprise revenue scales significantly. It does not work if the current contract is a one-time event. Watch the second enterprise deal announcement as the near-term signal.
For developers: IO Intelligence, as an OpenRouter-integrated inference provider, is a real product that works today. The cost advantage, reported at 50 to 70% below major cloud providers, is meaningful for inference-heavy applications that do not require guaranteed SLAs. For latency-critical production workloads, io.net’s distributed heterogeneous hardware introduces variability that centralized providers do not. Test in a staging environment before committing production traffic.
For GPU suppliers: The IDE changes the income calculus materially. Under the old model, your IO-denominated rewards swung with the token price. Under the IDE, payouts target a stable USD value, which means your hardware ROI is more predictable. The 200 IO minimum stake requirement means suppliers have skin in the game, and the staking mechanics matter more under the new model than the old one. Run the numbers against the updated reward structure, not the 2024 documentation.
What to Watch Over the Next 12–18 Months
Second enterprise deal close (expected: Q3 2026). io.net has described a second enterprise contract as being in advanced stages as of June 2026. If closed, it would validate that the $8M deal is repeatable, not a proof-of-concept outlier. The revenue contribution and how it feeds the burn mechanism will be the real signal.
IDE reserves performance through a market downturn. The system was designed for stress tolerance. The next meaningful IO price correction will be the first real test of whether the dual-vault mechanism holds at the burn commitment rate without reserve depletion. No simulation substitutes for this data.
OpenRouter volume scaling. io.net is currently the leading DePIN-native inference provider on OpenRouter. OpenRouter itself recently raised $113 million and processes 25 trillion tokens per week across all providers. io.net’s share of that volume, currently tied to the 4 billion daily token figure, is a trackable metric on OpenRouter’s public provider dashboard. Sustained or growing share indicates product-market fit.
Governance announcement (or continued absence). The IDE was implemented without community input. If io.net moves toward on-chain governance in any form, it would change the token’s risk profile meaningfully. If the silence continues, the centralization risk remains unaddressed. Either outcome is informative.
Conclusion
io.net has done something rare in the DePIN space: it has generated verifiable enterprise revenue tied to an actual workload. The $8M contract, the 4 billion daily inference tokens on OpenRouter, and the IDE launch are not vaporware. They represent a network that is genuinely useful for AI inference at commercial scale, three years after launch.
The IO token’s 96% drawdown from its all-time high does not mean the network failed. It means the market priced in a $2 billion future in June 2024 that has not materialized on that timeline. The gap between network utility and token performance is real, and it will persist until revenue scales faster than the unlock and emissions schedules.
What remains unresolved are matters. The governance question is not cosmetic. A tokenomics system redesigned without holder input, operated by a centralized platform, with closed-source infrastructure, and three CEO changes in two years, carries a structural risk that enterprise traction does not automatically offset. The IDE’s reserve depletion scenario has not been stress-tested in a live market downturn. The GPU count methodology needs more transparency.
io.net’s compute traction is real. Whether the IO token captures it at a multiple that justifies the risk is a different question entirely, and the answer depends on what happens in the next two quarters.
FAQs.
What is io.net (IO) in simple terms?
io.net is a decentralized network that pools idle GPU hardware from data centers, crypto miners, and partner networks across 138 countries, then rents that compute capacity to AI and machine learning teams as on-demand cloud infrastructure. Developers spin up GPU clusters for inference, training, and fine-tuning workloads without needing to purchase or manage hardware. The IO token is used to pay for compute services, reward GPU suppliers, and is now burned using a portion of network revenue under the Incentive Dynamic Engine.
Is io.net’s 100,000 GPU figure accurate?
The answer requires context. io.net reports 100,000 or more GPUs on the network, but independent analysis found roughly 327,000 registered devices with only approximately 6,720 verified active on any given day, and around 5,350 cluster-ready at any single moment. The gap stems from the April 2024 Sybil attack, which exposed spoofed hardware at scale. io.net improved its Proof-of-Work verification after the incident, but the methodology behind the current headline figure lacks detailed public disclosure.
How does the IDE token burn mechanism work in practice?
The Incentive Dynamic Engine collects revenue from customer payments into a fee vault. After distributing supplier payouts from the reward vault, at least 50% of the remaining post-payout revenue received in IO tokens is permanently destroyed. The burn is funded by actual customer spending, not token issuance. io.net projects a minimum of 12 million IO burned over the next 12 months, backed by an $8M enterprise contract generating roughly $650,000 in monthly on-chain earnings. The first burn was executed on June 11, 2026.
What is the main technical risk of using io.net for production AI workloads?
The core technical risk is hardware heterogeneity and provider variability. io.net’s nodes span different GPU models, data center configurations, and network conditions across 138 countries. For latency-tolerant workloads like batch inference or fine-tuning, this variability is manageable. For real-time production inference requiring consistent sub-100ms response times, the distributed heterogeneous model introduces unpredictability that centralized providers do not. Developers should test under production-equivalent load before committing critical workloads.
Can io.net Compete With Traditional Cloud Providers?
io.net is not trying to replace AWS or Google Cloud entirely. Its goal is to provide decentralized GPU capacity for AI workloads at competitive costs. Success depends on whether it can maintain reliability, performance, and enterprise adoption at scale.
io.net is generating real revenue from real AI workloads, and most coverage stopped there. Subscribe below for no-hype AI crypto analysis before the market catches up.
Editorial & Disclaimer Note: Content on CryptoAIAnalysis is independently researched and written using publicly available documentation, technical resources, and observable network data. The aim is to explain AI-powered crypto and blockchain systems clearly, highlight real-world use cases, and discuss limitations alongside potential. This content is provided for informational and educational purposes only and does not constitute financial, investment, or legal advice. Cryptocurrency and AI-related investments involve risk, and readers should always conduct their own research before making decisions.



