io.net has a more substantial product than many crypto projects carrying an artificial-intelligence label. It operates a marketplace where developers can rent GPUs for training, inference and other compute-heavy work, while independent suppliers earn for making compatible hardware available. That is a real service. It still does not answer the harder question for an IO holder: does growing compute use create enough durable token demand to offset rewards, unlocks and supplier selling?
This review separates the cloud business from the token. It examines how jobs are delivered, what the token actually does, the supply schedule, the new demand-linked burn model and the evidence a reader should monitor. The result is neither a dismissal nor an endorsement. The network can attract paying users while the token remains exposed to dilution, execution and transparency risks.
The short answer
The strongest part of the case is the product stack. IO Cloud offers virtual machines, containers, bare-metal servers and multi-GPU clusters. Customers can pay with a card, USDC or IO, which removes a common crypto onboarding barrier. Supplier hardware is tested before it becomes eligible for work, and the public explorer exposes available devices and bookings.
The weaker part is value capture. A customer does not need to acquire and hold IO before renting a GPU. Payments made in other currencies are converted through the system, and suppliers can convert earnings to USDC. That creates transactional demand, but it can also create immediate selling. Staking and fee discounts add utility, while rewards and scheduled unlocks add supply. The central test is therefore not the number of registered GPUs. It is whether paid usage and token burns grow faster than net issuance and unlocked supply.
| Evidence | What it supports | What it does not prove |
|---|---|---|
| Cloud products accept real deployments | There is a usable compute service | High utilisation or profitable demand |
| IO is used for supplier rewards and settlement | The token has operational utility | Users must hold it for long periods |
| Staking is tied to eligible devices | Tokens can support supplier accountability | Broad protocol governance |
| Demand-linked burns are live | Usage can reduce supply | Burns will exceed emissions and unlocks |
What io.net is building
Traditional cloud providers own or lease large data centres. This network instead aggregates GPUs and CPUs supplied by data centres, miners and other operators. A renter chooses hardware, region and deployment type through IO Cloud. The control layer then provisions the requested resources, while the workload runs off-chain on the selected machines. Solana handles token settlement and staking rather than the machine-learning computation itself.
This distinction matters. Calling the service “on-chain compute” would be misleading. Blockchain records can make payments and reward flows easier to inspect, but they do not prove that a remote GPU is genuine, available or performing correctly. The platform needs its own checks for hardware identity, uptime, bandwidth and completed work.
Why distributed GPU supply is difficult
A marketplace can list thousands of devices and still struggle to serve demanding customers. Multi-GPU training needs consistent drivers, fast interconnects, adequate memory, stable uptime and predictable networking. A disconnected consumer GPU is not interchangeable with an H100 in a professionally operated cluster. Location and data-transfer costs also affect whether the advertised hourly rate is the customer’s true cost.
io.net uses recurring proof challenges and device scoring to test suppliers. Its documentation describes checks for GPU model, memory, bandwidth and reliability, with staking used as collateral for some reward eligibility. This is more meaningful than counting every machine ever registered. Readers should still prefer active, cluster-ready hardware, paid device hours and repeat bookings over a headline inventory number. On 24 August 2026, the public explorer displayed about 1,200 cluster-ready, fully collateralised GPUs and CPUs, far below the 30,000-plus GPU claim on the main marketing page. The figures measure different populations, so they should not be treated as a contradiction; they show why definitions matter.
For comparison, our Nosana compute-network analysis covers a narrower job market built around containerised AI workloads. The relevant comparison is not which project reports the larger fleet, but which can turn suitable hardware into completed, paid jobs with reliable service.
How the IO token captures activity
IO has three defensible uses. It settles compute payments, rewards suppliers and supports device staking. Customers paying entirely in IO avoid the 2% payment fee applied to USDC, according to the documentation. Suppliers may receive IO or convert their proceeds, while a 0.25% reservation fee applies on both sides of a compute booking. These mechanics create a reason to transact in the token, although a fee discount is not the same as forced long-term ownership.
Staking is more closely tied to network operation. A device owner can stake the required amount to qualify for block rewards, and third parties can co-stake on eligible devices in return for an agreed reward share. This locks tokens and places capital behind supplier reliability. It also means staking yield partly comes from emissions, so an attractive nominal reward does not automatically represent economic profit after dilution.
The project’s public material often uses the language of securing a network, but the control model is not equivalent to a permissionless proof-of-stake blockchain. Compute scheduling, device verification, customer accounts and product operations depend heavily on the company-run platform. I found no clear evidence that token holders control protocol upgrades or treasury policy through binding on-chain votes. It is safer to describe IO as a payment, reward and collateral asset than as a mature governance token.
This is the same analytical separation readers should apply to other AI infrastructure assets. Our Vana data-network review asks whether product activity must flow through the token, while the Sahara AI review distinguishes useful products from weak or delayed token capture.
Tokenomics: the dilution is visible
The original design set a 500 million IO genesis supply and an 800 million maximum. The remaining 300 million was intended for supplier and staker rewards over 20 years, starting at 8% annual inflation and declining each month. The project later introduced its Incentive Dynamic Engine, or IDE, to connect supplier payouts and burns more directly to demand. Its official IO tokenomics documentation remains the clearest primary reference for the cap, reward pool, fees and revenue-funded burn design.
Market data aggregators reported roughly 381.5 million IO circulating on 24 August 2026, against a total supply near 800 million and a maximum of 800 million. Circulating supply is not the same as minted supply: restricted investor and contributor tokens can exist on-chain without being freely tradable, while future reward tokens may not yet have been distributed. Because aggregator labels and project definitions can differ, the circulating figure should be treated as a dated estimate rather than an immutable protocol fact.
| Supply area | Published design | Holder implication |
|---|---|---|
| Genesis supply | 500 million IO | Includes investor, contributor, R&D and ecosystem allocations |
| Maximum supply | 800 million IO | About 300 million above genesis before accounting for burns |
| Community at full distribution | About 50% of maximum supply | Includes long-term supplier and staker incentives |
| Seed investors | 12.5%, or 100 million IO | Monthly unlocks run from month 13 through month 36 |
| Series A investors | 10.2%, or 81.6 million IO | Uses the same investor restriction schedule |
| Core contributors | 11.3%, or 90.4 million IO | Monthly unlocks run from month 13 through month 48 |
| R&D and ecosystem | 16%, or 128 million IO | Public docs do not give an equally precise transfer schedule |
The June 2024 distribution date means investor and core-contributor unlocks began in mid-2025 and are active during 2026. That creates recurring potential supply rather than a single cliff. An unlocked token is not necessarily sold, but the buyer must account for the new ability to transfer it. The largest transparency gap is the R&D and ecosystem bucket: the official allocation page names it, yet does not provide the same clear monthly restriction timetable used for investors and employees.
Can the IDE burn offset emissions?
The IDE went live in June 2026. The company says supplier rewards target a stable dollar value and that at least half of revenue remaining after payouts is used to burn IO. One month after launch, io.net reported more than 1.1 million IO burned, 2.5 million IO paid to GPU providers and over 122,000 device hours associated with demand. These are useful operating figures, but they are company-reported and cover a short period.
A burn is verifiable once tokens reach an irrecoverable address, but attribution still matters. Readers need a reconciliation showing customer receipts, supplier payouts, new emissions and burns over the same period. Without that bridge, a rising cumulative burn can look deflationary while total circulating supply continues to increase. The project’s target to burn at least 12 million IO in the first IDE year is a forecast, not a completed reduction.
Security and operational risk
The previous version of this article claimed a 0/100 audit score, a developer backdoor and arbitrary minting authority. I could not verify those accusations from a named audit or reproducible contract analysis, so they should not guide a reader. The IO token is an SPL asset on Solana, but most practical risk sits beyond the token contract: account security, worker software, orchestration, remote access, billing and the custody path used for payments and staking.
Hardware verification reduces fake-device risk but cannot eliminate downtime, poor connectivity or a malicious supplier. Sensitive workloads require stronger controls than a public marketplace listing. The platform now offers confidential-compute options using trusted execution environments and hardware attestation for selected hardware. That can protect data in use, but it does not make every deployment confidential. Customers must confirm the exact machine type, attestation path, networking and data-retention terms for their own job.
Centralisation is another trade-off. The company operates the customer interface and coordinates much of the service. A business using the cloud should assess support, service-level commitments and jurisdiction in the same way it would assess a conventional provider. A token holder should ask who can change reward parameters, approve hardware and implement IDE rules. Public dashboards improve observability, but they are not a substitute for independent audits and clearly documented administrative controls.
How to judge progress without relying on hype
Four measurements would make the investment case more testable. First, report paid compute hours separately from proof challenges and idle availability. Second, publish repeat-customer retention and revenue without mixing cloud rentals with token rewards. Third, reconcile every IDE period from customer revenue to supplier payouts, emissions and burns. Fourth, disclose the circulating-supply methodology and treasury movements on a dated schedule.
- Demand quality: paid jobs, repeat customers and utilisation by hardware class.
- Supplier economics: job income compared with emission-funded block rewards.
- Net token change: emissions and unlocks minus verified burns.
- Service reliability: successful deployments, failure rates and support outcomes.
- Control transparency: documented upgrade keys, reward authority and treasury policy.
AIOZ takes a broader infrastructure approach spanning storage, streaming and AI tasks. The comparison in our AIOZ Network review is useful because it shows the same underlying problem: a technically active network only supports its token when service demand, settlement and incentives connect in a measurable loop.
Verdict: useful cloud, demanding token test
io.net should not be reduced to “DePIN hype.” It offers deployable compute products, multiple payment routes, supplier tooling and a public explorer. The addition of demand-linked burns is a better economic direction than paying fixed rewards regardless of use. Those features give the project a credible operating base.
The token case remains conditional. Customers can avoid holding IO, suppliers may convert earnings, investor and contributor unlocks are active, and the circulating supply is still well below the 800 million cap. IDE can improve that equation only if paid demand produces burns large enough to offset both new rewards and transferable locked allocations. A month of burn data is encouraging evidence of implementation, not proof of a durable deflationary system.
The sensible research position is to track the business and token ledgers separately. Product adoption should be judged through paid usage and customer retention. Token value capture should be judged through net supply change, staking demand and transparent settlement. When those two records strengthen together, the thesis becomes more convincing. Until then, the technology is ahead of the evidence needed to treat the token as a clean claim on network growth.
Frequently asked questions
Is io.net a blockchain?
It is a GPU marketplace and cloud platform that uses Solana for token settlement, staking and rewards. The compute runs on supplier hardware off-chain.
Do customers have to pay with IO?
No. The platform supports IO, USDC and card payments. Paying in IO avoids the stated 2% payment fee, while other payments can be converted through the platform’s settlement process.
What is IO staking for?
Device owners stake IO to qualify eligible machines for rewards, and co-stakers can support a device for a share of its block rewards. This is collateral and incentive alignment, not evidence of broad token-holder governance.
Is the 800 million supply already circulating?
No. About 381.5 million was reported circulating on 24 August 2026. The maximum is 800 million, while restrictions, reward distribution and burns affect how supply changes over time.
What would most improve the IO token case?
A consistent public reconciliation of customer revenue, supplier payouts, new emissions, unlocks and burns would show whether real demand is reducing net dilution rather than merely increasing gross activity.
Founder & Managing Editor of CryptosMedia. Zahid Hussain leads evidence-based crypto research covering tokenomics, security, governance, adoption, and risk.
CryptosMedia separates verified facts from interpretation, avoids buy/sell recommendations, and updates reviews when major evidence changes.
8 thoughts on “io.net Review: Real GPU Demand, Unclear Token Capture”