作者：CoinW研究院
On June 25, the dispute over Anthropic's model security, access controls, and capability exfiltration escalated again. Anthropic publicly accused Alibaba of systematically extracting information related to Claude model capabilities through nearly 25,000 fraudulent accounts. The accusation further complicates the already stalled process of restoring access to Fable 5, and pushes a core question back to the forefront: when frontier models simultaneously possess stronger capabilities in cybersecurity, code analysis, and automation, model access, account risk control, cross-border use, and capability exfiltration will all be drawn into the regulatory and platform governance framework.
To understand this dispute, the timeline must be pulled back to June 12. On that day, Anthropic's Claude Fable 5 and Mythos 5 were abruptly suspended, quickly drawing attention from the AI industry and the crypto market. Fable 5 was originally a Mythos-tier model open to the public, with safety restrictions layered on top to suppress misuse in high-risk areas such as cybersecurity and biosecurity. However, after the safety protections were found to have bypassable paths, the U.S. government imposed export controls to restrict foreign nationals' access to the relevant models, and Anthropic subsequently extended the access restrictions to all users. Almost simultaneously, Microsoft also temporarily restricted internal employee use of Fable 5 due to its data retention requirements. This chain of reactions shows that enterprise customers' concerns have extended beyond model capabilities themselves to data retention, internal code, and trade secret protection.
Afterward, expectations for Fable 5's restoration kept swinging. On June 18, U.S. government officials required Anthropic to prove before re-release that its safety protections could not be bypassed. On June 22, the relevant API documentation page reappeared in search results, but the actual call endpoint was still not restored. Polymarket predictions showed the market was still betting on Fable 5 eventually being restored: the probability of it resuming operations in the U.S. by the end of July was about 90%, and by the end of August about 94%. This back-and-forth itself shows that access to frontier AI is no longer just a matter of whether a product is online or offline, but the combined result of safety proofs, policy judgments, and platform enforcement.
Source: https://polymarket.com/event/claude-fable-5-restored-for-us-customers-by-20260613193753196
From this, the key to the Fable 5 ban incident is not when a particular model regains access, but that the structural boundaries of centralized frontier AI have been laid bare all at once: the stronger a model's capabilities, the more easily it is simultaneously constrained by security reviews, export controls, enterprise data compliance, and platform permissions. For the crypto industry, this happens to provide an opening to re-understand DeAI. The significance of decentralized AI is an attempt to use open computing power, distributed inference, on-chain incentives, privacy computing, and verifiable execution to weaken a single platform's control over model access, data processing, and the execution process. Following this thread, the following article from CoinW Research Institute will first review the Fable incident, then sequentially break down three types of gaps in centralized AI, the problems DeAI can tackle, three technical pathways for verifiable AI computing, and the differentiation of representative projects at different infrastructure layers, before finally returning to DeAI's realistic boundaries and long-term opportunities.
1. Fable Incident Review: Not a Simple Model Shutdown
Main Thread: Amazon Researchers Discovered a Guardrail Bypass Path
The sensitivity of Fable 5 and Mythos 5 stems from their capabilities in cybersecurity tasks. Mythos 5 is mainly open to screened partner organizations for discovering and fixing software vulnerabilities; Fable 5 is a broader public release that retains some Mythos-level capabilities while using safety restrictions to block the output of offensive content.
The problem lay with this layer of safety restrictions. Public information indicates that Amazon researchers discovered a path through which Fable 5's guardrails could be bypassed during testing, after which Amazon CEO Andy Jassy raised concerns with the White House. Subsequently, senior White House officials held multiple rounds of communication with Anthropic CEO Dario Amodei within 24 hours, demanding that the company voluntarily take down the models and address the vulnerabilities. Anthropic viewed the relevant bypass method as more of a localized issue that did not constitute a widespread "jailbreak"; the White House believed the safety risk was already serious enough to trigger national security-level intervention.
The U.S. government then imposed export controls on Fable 5 and Mythos 5, prohibiting foreign nationals from using the models. Because Anthropic found it difficult to stably identify the nationality and identity of all users in a short time, the company ultimately suspended access for all customers. This step turned the Fable incident from a model safety dispute into a frontier AI access event.
Detail One: The Dual-Use Nature of Mythos-Level Capabilities
The core of the Fable turmoil lies not in ordinary Q&A, but in the increasingly blurred boundary between "defensive capabilities" and "offensive capabilities." Cybersecurity models can help enterprises discover vulnerabilities and patch systems, but they can also help attackers find entry points and automate exploitation.
This is also why the government intervened quickly. If a model could only write copy or generate code, regulatory pressure would be relatively limited; once it possesses strong vulnerability discovery and exploitation capabilities, it gets repriced within the national security framework. Fable 5, as a public version, was meant to reduce risk through guardrails; once the guardrails can be bypassed, regulators see it as "a potentially open access point to high-risk capabilities."
Detail Two: Microsoft's Usage Restrictions Reveal Enterprise-Side Risks
Another thread in the Fable incident comes from Microsoft. Microsoft temporarily restricted employee use of Claude Fable 5 due to Anthropic's new data retention requirements. Prompts and outputs from Fable 5 could be retained for 30 days, while content flagged by the safety system could be kept even longer. Microsoft was concerned that employees might input customer data, company materials, or internal code during use, and once such content is retained and enters an investigation process, it could bring compliance and competitive risks.
This detail is very critical. It shows that the risk of frontier AI has expanded from "whether the model is dangerous" to "whether enterprises can control their own data." When enterprises use AI, they care not only about whether the model's answers are good enough, but also whether prompts are saved, whether data can be deleted, whether model calls comply with internal compliance, and whether the vendor might access sensitive content during safety investigations.
Detail Three: Export Controls Trigger AI Sovereignty Issues
The Fable incident also triggered broader discussions on AI sovereignty. The core of the market's skepticism is: the U.S. government, on the one hand, hopes to promote U.S. AI going global, yet on the other hand can temporarily cut off overseas access to frontier models through export controls, which will cause global customers to reassess the reliability of U.S. AI supply.
This means the impact of the Fable incident will not only stay with Anthropic. Enterprises, nations, and developers all need to reconsider the AI supply chain: if core models come from a few U.S. companies, how stable is the right to access them? If enterprise workflows deeply depend on a particular model, could policy changes cause business disruption? If security and compliance rules are decided internally by the platform, can external users obtain sufficient evidence?
At this point, the Fable incident is no longer an isolated model shutdown. The real reason it triggered the DeAI discussion is that three long-standing structural gaps in centralized AI were simultaneously magnified: access rights are jointly determined by platforms and regulators, data flows remain inside the platform, and the execution process of models and agents lacks externally verifiable evidence.
2. Centralized AI Gaps: Uncontrollable Access, Data Opacity, and Unverifiable Execution
Uncontrollable Access: Model Services Can Be Cut Off by External Rules
The Fable incident proves that frontier models are no longer entirely ordinary internet services. They are affected by national security, export controls, identity recognition, partner feedback, and geopolitical relationships. Once an enterprise connects R&D, code auditing, risk control, customer service, or automation tasks to a single model, a sudden model suspension becomes a business continuity issue.
This type of risk was underestimated by the market in the past. Users usually only compared model capabilities, pricing, and response speed, but rarely factored "whether the model might suddenly become unavailable" into their evaluation. After Fable was withdrawn, this risk was realistically demonstrated. In the future, when enterprises choose AI vendors, they may consider redundancy plans, backup models, and cross-vendor switching capabilities, much like choosing cloud services.
Data Opacity: Hard for Enterprises to Confirm How Sensitive Information Is Handled
The core of Microsoft's restriction on Fable 5 was data retention. The stronger a model is, the more likely it is to be fed source code, customer data, financial documents, strategy documents, and internal knowledge bases. At that point, whether prompts and outputs are retained, for how long, who can access them, and whether they are used for safety investigations all become key factors in whether an enterprise connects to the model.
Centralized AI services typically keep these processes inside the platform. Users can only read policy terms and have great difficulty technically verifying whether data has really been deleted, whether it has entered some classifier, or whether it has been accessed by some investigation process. Enterprises need clearer privacy statements and execution evidence that can be externally verified.
Unverifiable Execution: Hard to Determine Whether Safety Layers Actually Take Effect
The Fable controversy also concerned the safety layer. The model was externally claimed to have restrictions, but whether those restrictions were correctly enforced every time is difficult for external users to verify. Model versions, system prompts, routing mechanisms, safety classifiers, and output filtering all happen inside the platform. Users see the answer, but cannot see the execution path behind the answer.
In low-risk scenarios, this opacity may be acceptable; in finance, cybersecurity, code auditing, on-chain transactions, and asset management, it becomes a liability issue. Users need to know whether the model has been swapped, whether the execution environment is trustworthy, whether inputs and outputs have been tampered with, and whether the AI agent has overstepped its authority. This is precisely the structural gap of centralized AI: capabilities are becoming ever stronger, but external verifiability mechanisms have not matured in tandem.
Therefore, the question DeAI needs to answer becomes more specific: Is there an alternative entry point when model access may be cut off? Can a provable processing environment be provided when sensitive data must enter the model workflow? When AI Agents begin executing transactions, calling contracts, and managing permissions, can an evidence chain be left behind for accountability? The importance of verifiable AI computing begins to emerge at this layer.
3. What Can DeAI Solve: From Open Access to Trusted Execution
The Fable incident resonated so strongly in the crypto industry because it touched a familiar question: Can critical infrastructure be shut down by a single entity? The core value of Bitcoin is not just the asset price, but offering a global, permissionless, censorship-resistant value transfer network. AI is becoming new critical infrastructure. When model capabilities begin to affect code, security, enterprise processes, and asset execution, the market naturally asks: Do we also need a more open, switchable, and verifiable AI access and execution layer?
This does not mean all AI must be trained through decentralized networks, nor does it mean technology can completely bypass regulation. A more realistic assessment is that users will need two types of capabilities simultaneously: the strong intelligence provided by centralized frontier models, and the access redundancy, privacy protection, and verifiable execution offered by open networks. When a model like Fable is suddenly suspended due to policy or platform rules, the market will re-appreciate the need for permissionless AI. At present, DeAI’s value is mainly reflected in the following three aspects:
Solving Access Single Points: Reducing Dependence on a Single Model Provider
DeAI can first ease the access single-point problem. The Fable incident shows that frontier models can be abruptly cut off by policy or platform rules. At the product level, DeAI can reduce risk in three ways: first, by introducing multi-model routing that lets users switch among centralized models, open-source models, and decentralized inference networks; second, through open model marketplaces that allow different models and inference services to connect freely, reducing the control of a single provider; third, through private inference entry points and local model combinations that let users keep backup paths for critical tasks.
In the short term, DeAI may not be able to train another Claude. Its more realistic value is ensuring key workflows no longer bet everything on a single model entrance. For ordinary users, this means access choice; for enterprises, it means business continuity; for countries and regions, it is part of AI sovereignty.
Solving Data Trust: Running Sensitive Computation in a Provable Environment
DeAI’s second value is giving sensitive computation stronger provability. When enterprises and on-chain applications call AI, they often involve private data, code, trading strategies, or user assets. Trusted execution environments, remote attestation, privacy computation, and on-chain auditing can let users verify whether sensitive data is processed in a protected environment.
The key focus of this path is to let users obtain evidence about the execution environment without exposing privacy. For example, enterprises can require AI inference to take place in a trusted execution environment and verify the running code and model version through remote attestation; on-chain applications can record task hashes, execution results, and attestations on-chain; users can confirm the computing environment has not been arbitrarily replaced without disclosing original data. For finance, healthcare, enterprise compliance, and on-chain asset management, this is more important than simply pursuing stronger models.
Solving Execution Accountability: Leaving an Evidence Trail for AI Agent Actions
DeAI’s third value is establishing an accountability chain for AI Agents. In the future, AI Agents will call wallets, exchanges, cloud services, enterprise systems, and on-chain contracts. They will move from answering questions to directly executing tasks. At that point, the market will need not only model outputs but also execution logs, permission records, call paths, fund flows, and error-accountability mechanisms.
On-chain systems are better suited to recording these behaviors. Through on-chain logs, deposits, challenge mechanisms, and economic penalties, DeAI can transform AI execution from “platform backstage operations” into trackable, verifiable, and attributable actions. For instance, each time an Agent calls a contract, reads data, initiates a transaction, or submits a result, an auditable record can be left; when a node submits an incorrect result, it can be reviewed and penalized through challenge mechanisms. What the Fable incident truly propelled is precisely this layer of demand.
4. How DeAI Builds Trusted Execution: Three Paths of Verifiable AI Computation
Judging from existing projects and research paths, verifiable AI computation is not a single technology but rather a combination of approaches built around “execution environment, computation result, and execution behavior.” Different paths solve different problems and have different timelines for real-world deployment.
Verifying the Execution Environment: First Confirm Where the Model Runs
The first path is trusted execution environments, whose core is proving that the model runs in a protected hardware environment. Users do not need to see the backend servers; they can use remote attestation to verify that the code, model, and execution environment have not been arbitrarily tampered with. Such solutions are closer to real-world applications and suit enterprise private models, AI Agent execution, financial risk control, and on-chain automated tasks.
Its advantage is relatively controllable cost and latency, initially solving the problem of “where the model runs and whether data is processed in a protected environment.” Its limitation is that it still depends on hardware vendors, trusted execution environments, and remote attestation mechanisms. If the underlying hardware or attestation mechanism fails, the verification foundation is affected as well.
Verifying the Computation Result: Attaching Proofs to AI Outputs
The second path is cryptographic proofs, with common directions including zero-knowledge proofs and zkML. Its goal is to generate a verifiable computation credential for AI computation, allowing a third party to confirm the result truly came from the specified computation process without re-running the full model.
This path is closer to a “mathematical proof.” Its advantage is stronger certainty, suitable for scenarios requiring extremely high result correctness; the limitation is high proof generation cost and latency, with limited support for large frontier models for now. Research on lightweight verifiable inference has begun trying to reduce cost through sampling and commitment mechanisms, but moving from research to large-scale commercial use still takes time.
Verifying Execution Behavior: Making Errors and Overreach Costly
The third path is economic incentives and auditable logs. It does not require every AI inference to immediately generate a full proof; the core lies in making erroneous results and malicious behavior costly through challenges, recomputation, sampling verification, deposit penalties, and on-chain recording. Nodes submitting false results may have their deposits slashed, and those who discover errors can receive rewards.
This path is especially important for AI Agents. In the future, users will not only look at the model’s answer but also at which interface the Agent called, what permissions it used, whether it overstepped its authority, and whether it executed according to authorization. Auditable logs turn AI behavior from a backend operation into a traceable record and may land earlier than fully verifying large models.
5. Representative Projects: DeAI Is Differentiating into Different Infrastructure Layers
Following the three verification paths above, DeAI projects are differentiating into different infrastructure layers: Bittensor and Gensyn lean more toward intelligence supply networks, Venice leans more toward user entry points, while OpenGradient and Ritual are closer to verifiable computation and on-chain execution layers. The differences among these projects also show that DeAI is a combined ecosystem built around access, privacy, proof, and execution.
5.1 Bittensor: Using the Subnet Mechanism to Curate Machine Intelligence Supply
As a network that started early and has a relatively large ecosystem in decentralized AI, Bittensor represents the open intelligence marketplace model. It consists of many subnets, each a relatively independent machine intelligence market: miners are responsible for producing digital commodities, covering computing power, storage, AI inference, training, financial predictions, etc.; validators are responsible for evaluating the quality of miner output; subnet creators design incentive mechanisms; and TAO holders can support validators through staking. The network eventually distributes TAO incentives to participants deemed to have contributed more.
In terms of capital structure, Bittensor is unlike typical equity financing projects. It did not conduct a private placement or ICO in the traditional sense; the core protocol is maintained by the Opentensor Foundation, and TAO had no reserved allocation for early investors. But this does not mean capital was absent: Polychain participated in incubating Bittensor as early as 2019 and accumulated a TAO position worth about 200 million USD through secondary markets, mining, and validation; Digital Currency Group continuously bought through its subsidiary Yuma, once becoming the largest holder with about 500,000 TAO, roughly 2.4% of the total supply.
From on-chain activity, the Taostats subnet page shows that Bittensor subnet markets had a 24-hour total trading volume of about 193,300 TAO, of which Alpha Token (the native subnet token of each subnet, used to reflect the specific subnet’s market pricing, staking, and capital flow) trading volume was about 139,000 TAO, accounting for 71.93%; Root TAO (the mainnet’s native TAO asset, serving as the base asset used to enter and exit each subnet’s Alpha Token) related trading volume was about 54,300 TAO, accounting for 28.07%. This indicates that current trading activity mainly comes from specific subnet assets rather than the mainnet TAO side.
Source: https://taostats.io/subnets
Among the current subnets, prominent representatives include SN3 τemplar and SN64 Chutes: SN3 τemplar focuses on decentralized large model training; its team previously completed training of the 72B-parameter model Covenant-72B on Bittensor Subnet 3, making it a representative subnet for Bittensor’s training capabilities. SN64 Chutes focuses on serverless AI inference, having cumulatively processed over 9.1 trillion tokens, with daily peaks exceeding 50 billion tokens, making it a notably high-usage inference subnet. At the same time, CoinW has launched a TAO ecosystem zone and has initially listed the three subnets: Chutes-SN64, Gradients-SN56, and Targon-SN4.
Bittensor has evolved from a single AI network into an open intelligence marketplace where multiple tasks, assets, and incentive curves coexist, splitting various digital commodities—AI inference, training, data, financial predictions, compute power, and storage—into separate markets, with miners supplying, validators evaluating, and token-based incentives being distributed.
What’s more noteworthy is that some inference-focused subnets have begun to strengthen the evaluation and verification layer. Here, “verification” is closer to an internal quality screening mechanism: miners submit model outputs or task results, and validators judge the quality of results through scoring, backtesting, sample rechecks, benchmark tasks, and incentive rules, ultimately affecting the TAO rewards miners receive. Bittensor’s value lies in turning “who can provide intelligent services” into an open competition problem; the challenge is that quality varies significantly across different subnets, and verification standards and anti-cheat mechanisms determine whether the network can truly filter out high-quality AI services.
5.2 V enice: A privacy AI gateway on the user side
Venice is more of an application entry point for DeAI. It integrates multiple AI capabilities—text, images, video, audio, code, and search—emphasizing private or anonymous access. At the model level, Venice supports multiple entry points such as Claude, Google, DeepSeek, OpenAI, Mistral, Meta, Qwen, Grok, Kimi, and also provides an API compatible with OpenAI, enabling access to agent tool stacks, function calls, web search, and multimodal generation.
Venice was launched in May 2024 by ShapeShift founder Erik Voorhees, bringing strong founder credentials; its funding and incentives rely more on tokens than traditional venture capital rounds. In January 2025, Venice issued its native token VVV on the Base network with a genesis supply of 100 million tokens, roughly half of which were airdropped to early users and the crypto AI community, with the remainder held by the project team, liquidity pools, and incentive funds. Subsequently, Venice introduced the DIEM token, forming a dual-token structure: each DIEM corresponds to a fixed daily API quota and can only be minted by VVV holders, thereby tying token demand to the platform’s actual compute consumption.
Returning to the product itself, Venice’s differentiation centers on its tiered privacy approach. It has four privacy architectures: anonymized access to third-party models, zero data retention on self-hosted open-source models, reduced platform-side visibility through TEEs, and end-to-end encryption. For regular users, this is easier to understand than the underlying proof networks: they care about whether they can access the service, whether data will be saved, and whether their calls will be used by the platform for training or censorship. After the Fable incident, this kind of demand becomes even more direct. Because a model being banned is not just a developer problem; it also impacts ordinary users’ trust in the continuity of AI tools.
Venice addresses the DeAI user-side gateway problem. The underlying proof networks solve the question “can computation be verified,” while a privacy AI entry point solves “can users use AI safely, continuously, and with low friction.” Venice cannot replace zkML or TEE execution layers, nor can it fully eliminate the restrictions of model providers, but it illustrates that the commercialization path for DeAI does not necessarily have to start from the bottom layer; what users perceive first is often accessibility, switchability, low friction, and privacy protection.
5.3 OpenG radient: Putting model hosting, verifiable inference, and on-chain agents on the same network
OpenGradient is more like a full-stack verifiable AI compute network. It aims to integrate model hosting, inference invocation, x402 payments, on-chain agents, and the proof layer into a single developer network, rather than just offering a model entry point, with the goal of placing model deployment, invocation, settlement, and verifiable proofs all within the same developer workflow.
On the funding side, OpenGradient closed an $8.5 million seed round in 2024, led by a16z, with participation from Coinbase Ventures, Symbolic Capital, Wintermute Ventures, GSR, and others. The investor group spans Silicon Valley AI capital, crypto trading infrastructure, and market-making institutions, a combination that helps the project simultaneously advance its developer ecosystem, on-chain settlement, and compute resource marketplace.
Looking at on-chain data, the latest figures from its Portal page show that the OpenGradient network already has 4,448 models, approximately 874.9K inference transactions, about 332.2K x402 transactions, a current block height of around 1,599,860, and roughly 2,510 daily transactions over the past 30 days.
Source：https://portal.opengradient.ai/dashboard
From a product data perspective, OpenGradient has already formed a complete pathway covering model hosting, inference invocation, x402 payments, on-chain agents, and a proof layer. Users can view it as an AI compute marketplace for developers: hosted models can be called directly, invocations generate transactions and payments, and critical results can then have their trustworthiness enhanced through zkML or TEEs.
OpenGradient’s advantage lies in its relatively complete product chain and the availability of verifiable on-chain usage data. The next stage needs to watch two questions: whether transaction volume can convert into sustained payment, and whether demand for proofs can cover the additional computational costs. The number of models and inference counts can be quickly boosted through incentives, but what truly determines the network’s value is whether developers are willing to pay long-term fees for reliable invocation, privacy-preserving execution, and verifiable results.
5.4 Gensyn: From a compute power network to a machine intelligence marketplace
Gensyn is a project with particularly prominent capital backing and technological ambition among DeAI infrastructure networks. It originally started as a compute power network aggregating idle GPUs, with the goal of gradually evolving into a more complete machine intelligence network where training, inference, model collaboration, and intelligent services can all be invoked and traded on an open network.
From a product structure perspective, the Gensyn network is no longer just a GPU scheduling layer. Its AXL component is used to exchange weights, gradients, and signals between machine learning nodes; on-chain identities and reputations record the historical performance of models, agents, and compute nodes; and a verification mechanism is used to confirm whether certain computations were executed as required. Gensyn’s Delphi information market further tests scenarios where humans and AI agents jointly participate in predictions, with settlements completed by AI oracles.
On the fundraising side, Gensyn's capital background stands out among comparable projects. In 2022, Gensyn completed a $6.5 million seed round led by Eden Block, with participation from Galaxy Digital, CoinFund, and others; in 2023, it raised a $43 million Series A led by a16z, bringing total publicly disclosed funding to at least $49.5 million. The long R&D cycle and sustained backing from top-tier capital allow it to simultaneously advance multiple technical tracks, including distributed training, a machine intelligence marketplace, on-chain identities, and verification mechanisms.
Gensyn addresses the supply fragility that comes from excessive concentration of cutting-edge AI capabilities. The Fable incident showed that model access can be quickly cut off amid shifting policies, regional restrictions, and corporate security strategies. Gensyn aims to turn machine intelligence into an accessible, competitive, and verifiable open market, so that model training, model collaboration, agent trading, and machine intelligence services do not rely entirely on a single platform. The challenge is that decentralized training demands extremely high requirements for bandwidth, data synchronization, gradient verification, and incentive design, so in the near term it is more likely to land first in vertical models, open-model optimization, agent collaboration, and prediction markets.
5.5 Ritual: Turning AI tasks into callable and trackable on-chain execution
Ritual focuses on the AI execution layer, centering its efforts on making model invocations, agent behaviors, and complex tasks directly orchestrated, executed, and settled on-chain, rather than remaining as off-chain black-box services. Ritual Chain adopts an EVM architecture with off-chain verifiable machine tasks. Deterministic tasks such as ordinary transfers and storage reads are still replicated and executed by the EVM, while high-cost tasks like LLM inference, agent calls, and image generation are executed within a TEE environment, with the results then bound to the original request and returned on-chain. System contracts such as AsyncJobTracker, TEEServiceRegistry, Scheduler, and AsyncDelivery respectively manage task status, executor registration, scheduling, and result callbacks. Ritual is also developing Infernet, which allows smart contracts to invoke models and external computation, positioning the product closer to an “on-chain AI execution operating system.”
In terms of funding, Ritual completed a $25 million financing round in 2023 led by Archetype, with participation from Accomplice, Robot Ventures, dao5, Avra, Hypersphere, and others; in 2024 it added Polychain as a strategic investor, further strengthening its resource reserves in the crypto infrastructure space.
Ritual's strength lies in its proximity to real on-chain demand, making it suitable for automated trading, AI oracles, on-chain agents, machine payments, and complex task orchestration. Its focus is not on training a stronger model, but on enabling model calls to enter the permission and settlement systems of smart contracts. The risk is that TEE still relies on a hardware root of trust; executor selection, asynchronous callback security, and developer barriers all require continuous validation. Whether Ritual can achieve scale ultimately depends on whether on-chain applications are willing to hand high-value AI tasks over to this execution layer.
6. Practical Boundaries: DeAI Cannot Solve Everything Yet
Decentralized Training Still Faces Physical Constraints
The long-term value of DeAI must be built upon practical boundaries. Pretraining large models requires extremely high bandwidth, stable GPU clusters, massive high-quality data, and mature engineering systems. While decentralized networks can lower certain compute thresholds, public internet communication, heterogeneous device coordination, and dataset quality all affect training efficiency. This does not diminish DeAI’s value. A more realistic pathway is: the training layer first serves niche model fine-tuning and open model optimization; the inference layer first serves privacy, cost, and multi-model routing; the verification layer first serves proofs and audits in high-value scenarios; the execution layer first serves on-chain Agents and automated tasks. The area where DeAI is most likely to mature first may be a complete trust infrastructure built around model invocation.
Verification Capability Still Has Applicable Boundaries
Verifiable AI computation also has clear applicable boundaries. TEE can prove the execution environment but requires trust in hardware and remote attestation mechanisms; zkML can prove computation results, but cost and latency remain constraints; economic incentives can make malicious acts costly, but require reasonable challenge mechanisms, bond design, and verifier incentives. Different solutions address different problems — a single “verifiable” label cannot encompass all capabilities. Therefore, future project screening needs to examine what specifically is being proved. Proving model identity, proving the execution environment, proving output results, etc., each corresponds to different product boundaries. The more clearly a project articulates its verification object, the more likely it is to truly meet the demands of enterprises and on-chain applications.
Market Hype Does Not Equal Real Usage
The Fable incident will bring sector sentiment to DeAI, but sentiment cannot be directly converted into long-term value. What really needs to be observed is whether projects have sustained task demand, whether users are willing to pay for verifiability, whether network revenue comes from real calls, and whether verification costs can fall below the security premium users are willing to pay. DeAI without real usage will ultimately return to concept trading.
7. Summary: DeAI’s Opportunity Lies in Rebuilding the AI Trust Layer
What truly deserves attention about the Fable incident is not that a particular Anthropic model was temporarily suspended, but that frontier AI has for the first time clearly exposed the structural contradiction between improving model capability and declining access stability. In the past, the market generally assumed that stronger model capability would lead to higher adoption rates; but the Fable incident shows that when models possess highly sensitive capabilities such as cybersecurity, biosecurity, and code execution, their operational boundaries are also more easily subsumed into export control, corporate compliance, and national security frameworks. The stronger the model’s capability, the more security layers the platform needs to stack; the more complex the security layers, the harder it is for external users to verify the execution process; the deeper regulatory intervention goes, the less model access is merely a product-level issue. This means that future AI competition will not revolve solely around model capability but will further extend to access stability, data controllability, and execution trustworthiness.
This is also where DeAI needs to be re-understood. In the short term, DeAI may not be able to replicate frontier models like Claude, but it can first target the weakest link of centralized AI — namely, whether models can be replaced, whether data can be protected, whether computation processes can be proven, and whether Agent behavior can be held accountable. Truly valuable DeAI projects do not simply migrate AI capabilities on-chain, but decompose the AI invocation process into several verifiable components, including who provides the model, who executes the reasoning, how the result is generated, who bears responsibility for errors, and whether users can switch between different services. In the past, these questions were mostly hidden inside centralized platforms; in the future, they may evolve into a new infrastructure market.
From this perspective, verifiable AI computing may be the most direction worthy of in-depth research in DeAI. AI is gradually shifting from a content generation tool to an intelligent entity with task execution capabilities. When AI is primarily used for text generation, users can tolerate a degree of opacity; but when AI begins to participate in code auditing, asset management, wallet invocation, transaction execution, and contract interaction, opacity will evolve into systemic risk. The future market will not only pay for stronger model capability but also for execution processes that are provable, auditable, and accountable.
Therefore, after the Fable incident, the investment logic for DeAI also needs to shift from emotional narratives to verification narratives. In the past, the market tended to chase AI concepts, model names, and short-term hotspots; the next stage should focus more on three types of indicators: whether there is real invocation demand, whether there are verifiable proof mechanisms, and whether users are willing to pay a premium for trusted execution. Only when these conditions are simultaneously met can verifiable AI computing potentially evolve from a periodic hotspot in the crypto market into a new trust layer for the AI era. The core of future AI competition will no longer be just model capability itself, but whether models can be invoked stably, trustworthily, and verifiably in an open environment — this is the long-term space that DeAI may truly open.
