What can a blockchain do for AI? On October 2nd, the Solana Foundation released a lengthy article that outlines a roadmap from computing power, models, coordination to applications: to turn GPU capabilities into tradable resources, to establish verifiable settlement rules for reasoning and training, and to provide agents with portable identities, memories, and payment capabilities. The nature of this article is a proposal for industrial judgment and design direction put forward by the foundation, not a press release stating that all the aforementioned products have already been launched. Confusing the vision with existing applications might lead investors to mistakenly believe that technical challenges have been resolved.
The foundation's starting point is that currently, the computing resources of AI are often allocated to a few large contracts, making it difficult for users and developers to see changes in price, quality, and supply. If a unit of computing power or reasoning service could be made into a programmable transaction object, it would theoretically be possible to purchase, guarantee, settle, and hedge on a per-use basis. However, writing "GPU hours" into a token does not automatically ensure that the machine actually exists, that its performance meets the standards, or that data will not be leaked. While orders and payments can be recorded on the blockchain, off-chain, it is necessary to prove that the service has been delivered as agreed; the verification bridge between the two is precisely the most challenging part of such markets.
AI The agent has to pay for themselves. Who can prove that they have actually completed the work?
Solana The article proposes that low costs and fast settlement can support machine-to-machine payments between AI agents. For example, one agent calls upon data API, pays for the model inference fees, and then passes the results to another agent; the entire process can operate without manual confirmation of each transaction. The real challenges are not just whether each fee is low enough, but also include issues such as permission limits, error reversals, fraud detection, and attribution of responsibility. If an agent retrieves incorrect data, makes duplicate calls, or transfers funds to malicious services, the faster the payment system is, the faster the potential losses can grow. Therefore, even after integrating agent wallets onto the blockchain, it is still necessary to have budget control, verification of transaction purposes, and a stop mechanism that allows human intervention.
The foundation also discussed the Trusted Execution Environment TEE: Service providers run inference programs within isolated hardware, provide hardware proofs regarding code or model versions, and then record these proofs or keys on the blockchain. Users can verify the environment before sending sensitive keywords. This approach can reduce the reliance on the cloud service provider's claims to being entirely trustworthy, but it is not foolproof. Hardware trusted roots, code configurations, side channels, the behavior of the models themselves, and whether the proofs cover the entire service chain all affect the level of trust. Registration on the blockchain merely makes the records easier to publicly verify; it does not guarantee the security of every step outside of the chain.
On the side of model training, the article outlines the concept of a distributed training network: GPU from different locations contribute computing power, with tasks coordinated on-chain, rewards allocated, and it is verified whether participants have performed effective calculations. The core contradiction here is that large model training requires frequent communication, and an internet connection does not equate to high-speed interconnection within the same data center. Compressing gradients, splitting tasks, and economic incentives can alleviate these issues, but it does not mean that all cutting-edge training can be moved to arbitrarily dispersed machines. The foundation views this as a direction for an open computing power market, rather than providing verified results that can 'completely replace centralized supercomputing'.
What requires the most vigilance is mistaking "settleable" for "trustworthy".
The article also discusses identity, memory, and the application layer: Agents can hold cross-platform assets and histories, rather than relying on a single service provider account. For developers, this means more convenient payments and collaboration; for users, it raises new questions: who will keep the agents' private keys, whether old memories can be deleted, how to recover in case of identity theft, and how to reclaim cross-service permissions. A permanently verifiable ledger is not naturally compatible with the principle of minimal retention of personal information. During design, it is essential to separate publicly verifiable data from private data protection; one cannot assume that privacy issues are resolved just because the phrase “users own the data” is used.
This foundation article covers both real-world projects and a number of forward-looking scenarios, but it does not provide a unified launch date for the entire four-layer architecture, nor does it mention the total transaction volume or independent performance audits. The best way to understand it is to break down each layer into issues that need verification: whether there is credible proof of delivery for computing power products, whether the proofs of model inference can be reproduced, whether the limits on proxy payments and error correction can be controlled, and whether long-term identities can truly be carried over. Only when these questions are answered through specific products and publicly available operational data will the roadmap transform from a narrative of industry development into actual infrastructure.
For the Web3 industry, AI represents an attractive new entry point, as proxies indeed may require machine-native pricing and payment mechanisms. However, what blockchain does best is recording states, executing rules, and settling values; it cannot replace medical models, scientific validation, or the security of hardware itself. The discussions around Solana have proposed a set of designs worth testing item by item, which are not a universal solution to all AI issues. The next step is to see whether developers can deliver usable tools, whether real customers will pay repeatedly, and whether the costs and risks are lower than those of existing cloud services. Speed can facilitate transactions, but credibility relies on slower and more meticulous verification processes.
What is particularly worth distinguishing are "on-chain verifiable" and "result verifiable." The former can prove that a certain payment, a certain certificate, or a certain address has indeed been written into the ledger; the latter, however, also requires proof that computing power performance, reasoning quality, data permission, and user authorization all meet the agreed-upon criteria. If these two concepts are confused, a system that was intended to reduce intermediary risks may simply shift that trust to hardware manufacturers, data providers, or some closed-source scoring programs. Publicly auditable contracts and continuous operation records are the evidence that ultimately needs to be presented along this path.
Source: Solana Foundation, October 2, 2026, " Solana x AI : The Democratization Layer ". https :// solana.com / news / solana-ai-the-democratization-layer
