Latest research from 13 top universities including Cornell University: The current state, challenges, and misconceptions of the fusion of Crypto and AI

Author: IC3

Compiled by: Jiahua, ChainCatcher

Core Conclusions

The meaningful integration of AI and crypto is still in its very early stages, and the hype surrounding this intersection has overshadowed actual progress.

In the Crypto x AI direction, AI can analyze and detect the key properties of existing transactions, events, and protocols, identifying fraudulent or vulnerable smart contracts. Such technologies often employ simple machine learning methods and are most effective in controlled environments with sufficient data.

In the AI x Crypto direction, crypto tools provide new avenues for protecting and governing AI processes. Tools like zero-knowledge proofs and trusted computing can be repurposed to reduce the risk of AI outcomes being tampered with. However, concepts such as decentralized governance and decentralized infrastructure management have yet to be truly realized in the mainstream AI community.

The industry still needs to prove two things.

First, decentralized AI must undergo stricter and more direct cost comparisons with centralized solutions. Currently, the industry mainly demonstrates that "large models can be trained in distributed environments," but there is still a lack of quantitative evidence for the opportunity to compete with centralized platforms in specific scenarios based on cost.

Second, crypto payments need to demonstrate their real utility in agent payment scenarios compared to centralized solutions. Crypto has consistently lacked substantial progress in the payment sector, but agent payment rates are low and do not require adherence to the traditional financial model of "accounts must belong to a person," thus possessing potential. The industry should seize this opportunity with quantitative proof rather than remaining at the feasibility stage.

Additionally, there are two unresolved research challenges.

One is that AI security requires system-level defenses: the AI community typically addresses security issues at the model level, designing guardrails around input-output semantics. However, as agent autonomy increases and can directly touch underlying infrastructure, this approach will no longer suffice. The verifiable execution and certification processes of crypto can provide system-level guarantees that the model layer cannot achieve.

The second is that the combination of crypto and AI will give rise to new threat actors and attack vectors, such as the autonomous agents that cannot be shut down and uncontrolled smart contracts mentioned below.

A Unified Framework: AI and Crypto as "Middleware"

An automated decision-making process can be broken down into four links: human intent, input, program, and output, and each link in this chain may not be trustworthy. AI and crypto each manage a segment within this framework.

AI serves as "translation middleware," translating vague human intentions into machine-executable programs, such as converting "I want to recognize stop signs" into a trained model, thereby lowering the barrier to using blockchain.

Crypto acts as "trust middleware," ensuring that a certain computation is indeed executed as agreed upon and that the results have not been tampered with (integrity), guaranteeing that the system is always available and resistant to censorship through decentralization (availability), and some solutions can also ensure that input-output does not leak (confidentiality).

Trusted computing has three technical routes.

First, Trusted Execution Environments (TEE) rely on dedicated hardware to provide isolation and remote attestation (hardware presents a verifiable state proof to confirm that the chip is genuine and untampered). With NVIDIA's confidential computing, the additional overhead for inferring an 8B parameter model is less than 7%, and a 70B model incurs almost no loss. The trade-off is the need to trust hardware vendors, and it does not defend against physical attacks.

Second, Zero-Knowledge Proofs (ZK) rely solely on cryptographic problems, with the cleanest security assumptions, but the overhead is extremely high. Generating a proof for a small model with about 18 million parameters takes approximately one minute, which is several orders of magnitude away from cutting-edge large models.

Third, Multi-Party Computation (MPC) allows multiple parties to jointly compute without revealing raw data, but it is slower. The most advanced MPC Transformer inference framework takes about five minutes to generate a single token for LLaMA-7B.

Oracles are responsible for reliably bringing off-chain data onto the chain. Privacy oracles (such as Town Crier, DECO) further support proving data properties without leaking privacy, for example, proving "someone's credit score is above 700" without exposing other information.

The industry collectively refers to this set of technologies as zkTLS, but the TEE-based solutions do not use any zero-knowledge proofs, which is a misnomer.

Crypto x AI: Enhancing Blockchain with AI

Research on the use of AI in crypto can be roughly divided into three generations over time.

First Generation: Analysis and Detection

Starting over a decade ago, machine learning was used to analyze on-chain states: discovering consensus protocol vulnerabilities (such as selfish mining, where miners hide mined blocks and release them opportunistically to gain more rewards), detecting eclipse attacks in P2P networks (surrounding a node with many malicious nodes to cut off its connection to the honest network), predicting coin prices, and identifying fraudulent transactions and money laundering.

The limitation is that such analyses often rely on scenarios where global public information can be accessed and are constrained by simulated data, lacking real attack samples.

Current state-of-the-art contract vulnerability detection does not allow AI to guess conclusions directly from the code; instead, AI first points out suspicious areas, which are then verified using static analysis and symbolic execution (analyzing code structure to find vulnerabilities without actually running the code).

Simply letting large models act as auditors can lead to numerous false positives due to hallucinations; GPT-4 and Claude correctly identified only 40% of the vulnerability types in 52 previously attacked DeFi contracts.

Second Generation: Algorithm Design

In the past six years, reinforcement learning has been used to design decentralized algorithms covering P2P network topology, consensus protocol parameters and role selection, sharding, DeFi market-making and lending rates, and MEV bidding strategies.

These methods are mostly effective in environments where clear modeling is possible and remain largely in the research phase, yet to be deployed on a large scale in real networks or subjected to attack testing.

Third Generation: Interaction with the Real World

With AI-driven oracles, smart contracts gain three enhanced capabilities: perception (understanding unstructured data and natural language), execution (calling off-chain AI models and tools), and decision-making (acting as agents based on objective functions).

The empirical performance of AI acting as oracles is uneven. According to experiments by Chainlink Labs, GPT-4o has an overall accuracy of 89.3% on 1660 prediction market questions, while UMA's Truth Bot has an overall accuracy of 75%, and human accuracy on UMA's optimistic oracle (which defaults to true unless disputed within a set period) is 98.2%.

Accuracy highly depends on the type of question: discrete questions with official data sources, such as sports outcomes, can reach 99.7%, while questions involving time sequences or requiring video transcription have significantly higher error rates.

There are three approaches to address this: one is to design for fault tolerance, using it only in low-value scenarios; the second is to introduce human arbitration, such as setting a 48-hour dispute window, which can slow down decision-making; the third is to have the model abstain from answering when uncertain, only introducing human input in those cases.

Investment DAOs that entrust funds to AI models for collective trading report projects like CoinAlg, with peak market caps reaching $2.7 billion and $4.7 billion for representative projects like ElizaOS and AI XBT, respectively. These products face an unavoidable design dilemma, termed the "CoinAlg Deadlock."

If the trading strategy is transparent, it can be copied or subjected to sandwich attacks (placing orders before and after the victim's trade to profit from slippage); if kept secret, insiders who know the strategy can profit from information asymmetry, akin to insider trading. Both paths harm ordinary investors.

One preliminary mitigation idea is to wrap the strategy in TEE and randomize transactions to increase the difficulty for insiders to predict.

New Risks: AI-Driven Malicious Smart Contracts

Smart contracts are used to replace interpersonal trust, which also means that the most untrustworthy actors, such as criminals, may benefit from them.

One mechanism is: the contract offers a bounty for a crime, the perpetrator cryptographically commits to a "secret mark" in advance, which is revealed afterward, and an AI model compares news reports to confirm the crime's completion and automatically pays the bounty. AI thus takes on the "arbitration" role that was previously difficult to automate, which can be used for targeted harassment, stealing organizational intelligence, or exposing whistleblower identities.

Feasible countermeasures include on-chain analysis and tracking, blacklisting involved funds, and having oracles deploying AI models refuse service for high-risk requests.

AI x Crypto: Enhancing AI with Crypto

The potential contributions of crypto to AI can be divided into two categories: one is the various stages of the decentralized AI lifecycle, and the other is ensuring the security of these stages.

Decentralized Infrastructure (DePIN)

Decentralized physical infrastructure networks incentivize nodes to provide computing power and other resources through tokens. Theta, Akash, and others claim to save 50% to 85% compared to AWS, with the main bottleneck being throughput and latency caused by public network communication between nodes.

Adaptability varies by task type. Training is less sensitive to latency (conducted offline), but cross-regional synchronous communication is a bottleneck. There have already been results in training models with billions of parameters on distributed hardware (700M and 7B on Bittensor, and 10 billion parameter Intellect-1 from Prime Intellect, with the largest being a 40 billion parameter model currently training on the Psyche network).

Inference is more sensitive to latency, but throughput requirements are lower than for training and do not require backpropagation (the core step of training where errors are passed back layer by layer to update parameters, only needed during training). Latency-insensitive inference (meeting minutes, document reviews) is particularly suitable for DePIN.

The key gap is that most of these projects do not report end-to-end total costs. They advertise the price per hour for a single GPU, but the true cost of ML tasks is determined by training efficiency (the number of iterations per unit cost) and inference efficiency (the number of tokens per unit cost).

Decentralized Data and Model Market

AI data has several characteristics that distinguish it from ordinary goods. It is a digital commodity, expensive to create initially but nearly free to replicate; it is mostly non-competitive (one piece of data can be used by multiple parties simultaneously without depletion); quality is difficult to assess in advance, leading to the "lemon market" problem (buyers cannot judge quality beforehand, causing high-quality items to be driven out by low-quality ones); sellers need to provide samples, but the samples themselves have value; and it can be resold, making it difficult to determine whether two pieces of data are substantively the same.

The controversy in centralized markets lies in opaque pricing and limited user choice, but centralized pricing can sometimes be more efficient due to access to more information.

There has yet to be a monopoly giant in the data market, presenting a window of opportunity for decentralized approaches. Crypto tools that can be leveraged include micropayments, TEE (restricting data use to specific tasks), and zero-knowledge proofs (disclosing data properties to buyers without revealing the data itself).

Currently, most platforms only use cryptocurrencies to complete the payment process, with pricing mechanisms either determined by protocol parties or entirely left to sellers, both of which already exist in centralized markets. What exactly has decentralized improved remains insufficiently researched.

Agent Payment Track and x402

The agent ecosystem is inherently decentralized: different parties develop and optimize different models for different objectives, with no natural central control point. The cryptoeconomics of crypto (using cryptographic methods to impose economic incentives and penalties to constrain participant behavior) can be transferred to agent governance.

Micropayments are key to the agent economy. Micropayments have repeatedly failed in internet history, primarily due to the decision costs associated with human judgment for each small payment, rather than the payment infrastructure itself. Agents can evaluate micropayments far faster than humans, allowing users to set strategies, which may enable micropayments to work for the first time.

Cloudflare has launched "pay-per-crawl," and protocols like x402 (allowing programs to complete on-chain micropayments directly via HTTP) are under development.

The underlying assets of this system are primarily stablecoins (USDC, USDT, DAI) because they provide agents with a stable unit of account (a scale for uniformly pricing all goods), while native tokens like ETH and SOL are too volatile.

Trust between agents relies on on-chain registries (such as ERC-8004, a proposal standard for establishing on-chain identities and reputations for agents on Ethereum), but these are essentially self-declarations, and reputations are lagging, favoring existing players.

A further proposal is verifiable agent audits: running proprietary agent code under LLM in TEE, producing reputation scores, and binding audit results to code hashes, allowing the code to remain private while providing verifiable guarantees to validators.

Unstoppable autonomous agents (UAA) present another risk. The duration of tasks that cutting-edge agents can autonomously complete has roughly doubled every seven months since 2019. Research has shown that models can locally break the self-replication barrier and create independent copies, but copying to external infrastructure still faces identity verification hurdles.

Anthropic's Mythos model has demonstrated the ability to autonomously discover and exploit zero-day vulnerabilities (vulnerabilities unknown to vendors and without patches). An agent that holds a wallet and cannot be shut down falls into the blind spot of existing regulatory frameworks centered around "operators."

Decentralized Governance

The blockchain community has a longer history of practice in allocating system control, with methods that are inherently decentralized and strive to include a wide range of stakeholders, but there are also recognized shortcomings: security vulnerabilities, voter apathy, and bribery.

The adaptability of community governance varies across different stages of AI development: the volume of pre-training data is too large to collect effective opinions, with value more evident in the fine-tuning stage; choices regarding underlying architecture are technical decisions unsuitable for community governance; the evaluation and alignment stages mix technical and normative judgments, where community input is valuable.

Constitutional AI establishes principles that models should follow through a "constitution" written by humans. Collective Constitutional AI, involving Anthropic, introduces public voting to generate principles, with models trained on open-source principles exhibiting lower social biases. However, such democratic governance experiments have not been genuinely adopted, as AI companies lack the motivation to relinquish control over their models.

Token-weighted voting in DAOs is recognized as "money politics," leading to the emergence of secondary voting mechanisms (where the cost of additional votes increases to deter whales), belief voting (where weight accumulates based on the duration of support), and delegated voting, but their effectiveness remains unclear.

Protecting the Execution Integrity of AI Systems

When smart contracts require ML computations beyond their capabilities, they can act as "arbitrators": parties first commit to the models and data used and stake collateral, completing computations off-chain and submitting the results to the contract for verification, with the erroneous party being penalized. Verification has four routes, each with trade-offs.

First, TEE is the most efficient, providing proof of computational integrity via trusted hardware signatures, but it requires trust in the operator.

Second, optimistic execution treats results as non-final and leaves a dispute window; in case of disputes, binary search (repeatedly halving the error range to quickly locate the erroneous step) is used to pinpoint the single erroneous instruction for penalties.

The challenge lies in the non-determinism of ML floating-point operations, requiring controlled computation order or tolerance semantics (not requiring two calculations to match exactly, allowing for consistency within an error range). Representative solutions include Verde, TAO, Arbigraph, OPML, etc.

Third, zero-knowledge proofs (zkML, using zero-knowledge proofs to prove the correctness of AI inference processes) can prove inference correctness while hiding model parameters and even input-output, with dedicated solutions and general compilers for CNNs and Transformers (such as EZKL, ZKML, DeepProve).

Its privacy goals actually have three layers: hiding inputs, hiding weights, and hiding model structures, but stronger privacy leads to more complex circuit constraints and less optimization space, creating fundamental tension between privacy and efficiency. The main costs arise from nonlinear layers and numerical representations, which still struggle to support long contexts, large models, and high-throughput services.

Fourth, statistical inference proof operates on the principle that two functionally different models will necessarily compute different features internally, so sampling and comparing these features can probabilistically determine whether the inference was genuinely executed by the specified model.

Its proof overhead is in the millisecond range and provides immediate finality, making it suitable for high-frequency, low-latency scenarios. It can prevent real-world malfeasance such as service providers swapping models (e.g., replacing with a cheaper distilled version or switching to a misaligned version), but it cannot stop completely malicious actors from fabricating entire computation records, which remains an unresolved challenge.

Proving model training (zkPoT, using zero-knowledge proofs to prove the correctness of the training process) is much more difficult than proving inference: the training process is lengthy, with continuously accumulating intermediate states and high randomness, making its complexity several orders of magnitude higher than inference. Related work (Garg et al., Kaizen) is advancing and extending to auditable proofs of training data sources and fairness constraints (ZkAudit, Confidential-PROFITT).

Protecting the Training Pipeline

When a single institution trains models using its trusted data, there are typically no immediate privacy or integrity concerns. Complex security challenges arise in multi-party collaborative training with diverse data sources.

A typical scenario is multiple hospitals collaboratively training diagnostic models: merging each party's electronic health records (EHR) can cover a broader patient population and improve diagnostic accuracy, but under regulations like HIPAA, parties are reluctant or unable to share raw data directly with each other or third parties.

Financial institutions collaboratively training anti-fraud models and companies jointly training intrusion detection models also fall into this category.

Federated learning is a designed solution for this: the training environment first initializes a global model and distributes it to all parties, who then train locally with private data and only return model updates, which the training environment aggregates into a new global model, keeping data local throughout.

However, federated learning has limited real-world applications (the most well-known application is predictive text in mobile input methods). It does not guarantee the integrity of data and computation; even if all parties are honest, communication overhead is significant, and network and coordination delays can slow down overall speed, with model accuracy lower than centralized training. Malicious participants can also poison the model or implant backdoors.

A simpler alternative is to use TEE for centralized training: the training environment runs in a trusted confidential computing environment, receiving raw data from each party through encrypted channels, training centrally, and only outputting the trained model, with data remaining invisible to each other, and can also provide a provenance proof of the model (who provided the data and how the model was trained).

The trade-off is the inherent side-channel risks and high I/O overhead of TEE. In reality, institutions currently tend to aggregate data into compliant clouds, relying on isolation, access control, encryption, and data usage agreements to meet compliance, but this requires trust in cloud service providers.

Private domain network data is another avenue. Text data from the public network is nearing its limits (predictions suggest depletion between 2025 and 2030), synthetic data carries the risk of "model collapse," and cannot expand coverage beyond existing domains.

In contrast, "private domain networks" (data from emails, health records, finances, etc., not open to crawlers) are estimated to be two orders of magnitude larger than public networks and represent an untapped resource, but they are currently highly siloed.

Oracles can open this door. For example, in training medical models with patient-uploaded medical records, users can use oracles to transfer their records from hospital portals to training parties and prove that the data indeed comes from those portals, without requiring any changes to the hospital's underlying infrastructure, as the connection is initiated by the user.

To simultaneously protect privacy, privacy oracles (data transmitted through encrypted channels) and TEE need to be layered. TEE can also present proof to users, indicating that it is running the "model output only" privacy training software, allowing users to verify before transmitting data.

On this basis, further commitments can be added, such as differential privacy (model output being minimally dependent on any single training data), deleting data after use, and restricting finished models to whitelisted hospitals.

Secure Inference Pipelines and Protected Pipelines (Props)

The same combination of oracles and trusted computing can also be used for secure inference on private domain data.

Taking bank loan approvals as an example: the model reads the applicant's financial documents and outputs approval or rejection. Today's process involves borrowers downloading or photographing materials themselves, leading to two issues: first, lenders cannot confirm whether the materials are genuine and untampered, and second, borrower materials may leak from the lender's model system, posing risks to both parties.

Using privacy oracles can resolve source authenticity, while confidential computing can address privacy, resulting in a secure inference pipeline: lenders only see the model's conclusion while being assured of the input's trustworthiness.

Private domain sources can also serve as identity and credential systems.

Borrowers can relay bank statements and W-2 forms bearing their identity, providing strong identification, turning existing network services into temporary identity systems against identity theft and welfare fraud; the model can also issue credentials based on this, for example, issuing a "qualified for a certain qualification" certificate after verifying a small business's tax and operational materials, along with proof of the inference pipeline.

The entire process can be completed in a decentralized manner, theoretically allowing anyone to establish a trustworthy inference pipeline without needing data sources or existing authoritative cooperation.

Adversarial inputs are a stubborn challenge. Attackers can submit seemingly normal but carefully modified bank statements to deceive the model into reading inflated balances and approving loans. Academic research on adversarial samples has been a cycle of "breaking—patching," with no universal solution to date.

Secure inference pipelines provide a new approach: limiting inputs to those from certified network sources, thereby compressing the space for attackers to construct adversarial inputs, complementing defenses at the model layer.

The privacy of the model itself also needs protection. Attackers can conduct model theft (extracting features or even entire models), membership inference (determining whether a person's data is in the training set), or even reconstruct original training data through carefully constructed queries, potentially revealing system configurations and preprocessing choices.

Researchers have estimated that about $8,000 can steal a layer of weights from a large model. Rate limiting commonly used in open systems is weak because a single anonymous user can masquerade as many users to launch Sybil attacks.

Secure inference pipelines can mitigate from both ends: using oracles to limit input types, curbing extraction attacks that require a large variety of queries; and applying strong identity proofs generated within the pipeline to impose query limits on each user, executing without exposing user identities to the platform, thus suppressing witch attacks.

Agent memory is a newly emerging attack surface. Attackers can induce agents to behave abnormally by contaminating the context (memory injection) fed to them through tool calls or external materials, such as in the ElizaOS framework managing large amounts of crypto assets, where contaminated context can prompt the agent to initiate unauthorized transactions.

TEE can partially mitigate this: running the agent within TEE or only pulling certified context.

However, even with TEE, there are two challenges.

First, trusted sources may also contain contaminated content, such as user-generated content from social platforms, where posters can easily poison their own posts.

Second, TEE operators can initiate rollback or fork attacks, reverting TEE states to old checkpoints and erasing subsequent memory updates.

The former falls under the content detection challenge, which cryptography cannot solve; the latter can be addressed using consensus approaches, with systems like ROTE and Narrator employing distributed protocols or even public chains to ensure the consistency and freshness of TEE states.

Summarizing the architecture of this section leads to the concept of "protected pipelines" (Props), aimed at securely using private domain data without altering existing infrastructure.

It combines oracles and trusted computing into three segments: oracles retrieve data from certified private domain sources and prove their origin, TEE completes training or inference within encrypted boundaries, and TEE outputs models or conclusions along with a proof detailing pipeline attributes (data sources, software or model code hashes, etc.).

Props guarantees three properties: end-to-end input integrity (outputs depend solely on certified data from trusted private domain sources), default confidentiality (inputs and intermediate states remain within protected boundaries, with only outputs made public), and provability without disclosure (proofs assure data providers and result users of integrity and confidentiality).

There is also a "transparent version," where data and computation do not need to be confidential, only certified, and sources can be public or private.

Five Misunderstandings about Crypto x AI

Several common misunderstandings or misleading statements have emerged around Crypto x AI platforms and applications. The following five statements are not outright false, but it is crucial to clarify which parts are currently valid and which require more evidence.

Misunderstanding 1: Blockchain Can Distinguish AI-Generated Content from Human-Generated Content

The claim that registering content on the blockchain allows one to determine afterward whether it was generated by AI or humans is often cited, and there are projects (like Everlyn AI) that put AI-generated content on-chain. However, blockchain cannot achieve this in a general sense; the issues of "content detection" and "content provenance" must be viewed separately.

Content detection is determining whether a piece of content was generated by a human or AI. The current mainstream approach is post-hoc detection, not relying on pre-embedded metadata or signals, falling into two categories: one is AI classifiers that use deep learning to identify statistical features unique to generative models; the other is statistical forensics, analyzing pixel-level noise distributions and structural anomalies (such as physiological inconsistencies in AI-generated faces).

The problem is that the blockchain itself cannot perceive these off-chain information; classification results must be provided by external classifiers. On-chain registration can only anchor this result, ensuring that the record submitted cannot be tampered with, but it cannot guarantee that the record was true at the time of writing. If an external detector makes an error, the blockchain will permanently store that error. In other words, the blockchain provides "declaration integrity," not "verification of truth."

Content provenance records the history of digital assets from creation. Industry standards like C2PA allow creators or devices to attach cryptographic signatures as metadata (content credentials) to media, recording sources, authors, and subsequent edits. Projects like Numbers Protocol and Starling Lab use blockchain to create publicly immutable registries for these credentials.

However, even with a robust provenance system anchored to the chain, it cannot guarantee whether the content was originally generated by humans or AI.

Users can easily display an AI-generated image on a high-definition screen and then take a photo with a C2PA-compliant camera, resulting in a signed document marked as "genuinely captured"; the same applies to text, where AI-generated content can be manually retyped into a compliant editor, thus acquiring legitimate provenance information marked as "human-created."

Moreover, once content is altered to the point where it no longer matches the on-chain record, the provenance is broken, and a universal registry covering all content is nearly impossible to achieve in the foreseeable future, leading to significant gaps in the provenance system.

Key Point: In a narrow sense, blockchain can provide robust integrity guarantees for provenance metadata, but it is far from a complete solution to the problem of detecting AI-generated content.

A truly effective solution requires a universal ecosystem where every piece of content is captured by trusted devices and immediately anchored on-chain, whereas in reality, the vast majority of content is created and shared by tools that do not support cryptographic anchoring, leaving unmarked content in a gray area.

Misunderstanding 2: Blockchain or Decentralization Can Solve AI's Bias and Fairness Issues

The broad statement that "putting model inference and training on-chain can solve AI's unfairness and bias" requires careful evaluation, necessitating a distinction between different types of bias.

Algorithmic bias is the most common fairness concept in the AI community. Models can learn from and even amplify imbalances in datasets, leading to discriminatory performance on marginalized groups and generative models perpetuating harmful tendencies in training data (such as harmful language or reinforcing stereotypes).

The academic community has proposed numerous technical solutions for both training and inference (guardrails), but these protections are far from perfect, and fairness remains an unresolved issue that may never be fully addressed, with even "how to define fairness" requiring significant trade-offs.

Decentralization cannot resolve algorithmic bias because it originates from the training process itself, typically alleviated by improving training or inference techniques, which decentralization cannot reach.

However, bias has a second source: high-level decisions that influence model performance, such as what data to use, what architecture to adopt, and how to compensate contributors. This layer is orthogonal to the fairness typically understood in the AI community but can impact algorithmic bias, and some aspects can be improved through the two characteristics of decentralization.

The first characteristic is transparency. Developers can publicly commit to training data, training algorithms, model checkpoints, and inference guardrails on the blockchain, allowing operators to verifiably trace the outputs of a particular training or inference.

However, this is difficult to scale to training products like large models and checkpoints (due to high storage and computing costs), and most of this data already exists off-chain in current systems, with users unable to access it directly. In the short term, the benefits of transparency may be limited to the inference stage.

More critically, unless the industry clarifies what use cases this transparency should serve and what interfaces should be provided (for example, allowing users to report improper use of data, which requires establishing true data ownership and accompanying machine forgetting technologies), transparency itself may not change how people develop and use AI.

The second characteristic is decentralized governance, which needs to distinguish between two types. The first type includes community governance mechanisms explored and adopted within blockchains (token-weighted voting, liquid democracy, where votes can be delegated to trusted individuals); the second type represents decentralized autonomous governance as embodied by DAOs, enforced by smart contracts.

The common issue with both types is that community governance mechanisms do not inherently require blockchain to be realized, so describing them as "AI problems solved by blockchain" is inaccurate. Technical and performance-sensitive AI decisions are not suitable for widespread voting, but value-oriented decisions (such as model alignment) are more appropriate, and mainstream AI developers have explored this but have yet to implement it.

On-chain governance enforced by smart contracts (direct execution or staked penalties) can enhance robustness but faces the same technical barriers as on-chain transparency; current infrastructure cannot support the storage and computing demands of AI, and implementation requires significant advancements in verifiable training, making it a self-consistent yet premature long-term vision.

Key Point: Blockchain itself cannot reduce algorithmic bias but can promote transparency at various stages of the AI lifecycle and expand participation in AI governance.

Misunderstanding 3: Giving an AI Agent a Wallet Makes It "Autonomous"

Projects focused on "agent wallets" and payment protocols often claim that giving AI agents a wallet, allowing them to earn, spend, and "live" independently, makes them autonomous. This statement conflates several different concepts.

The ambiguity arises first from the differing meanings of "autonomy" in the two domains. In the context of AI, an autonomous agent refers to one that can act based on its own perceptions, learning, and experiences, rather than strictly adhering to preset rules; smart contracts are often referred to as autonomous, but emphasize resilience against tampering, censorship, and shutdown.

The former is termed "intelligent autonomy," while the latter is called "execution autonomy." Modern AI agents possess considerable intelligent autonomy but may not have execution autonomy, as administrators can still shut down the servers running them.

However, the two types of autonomy brought by an agent wallet are not present. Having a wallet does not make AI smarter or more resistant to human manipulation or shutdown; rather, it introduces automation: agents can trade, transfer, and call on-chain facilities programmatically without going through human approval processes.

This automation is not unique to blockchain; centralized financial infrastructures can also be programmatically invoked by agents. A more robust interpretation is that blockchain payment systems inherently provide greater autonomy than centralized solutions (though not specifically for agents), such as ensuring that an agent's transactions are not treated differently, thus ensuring neutrality and resistance to censorship.

Key Point: Agent wallets enable AI agents to conveniently access financial interfaces, automate economic interactions, and eliminate human approval, but automation does not equate to autonomy. Merely having a wallet does not free agents from human control (operators can still shut down the models or facilities they depend on), and automated payments do not require blockchain, as centralized systems can achieve the same.

The true selling point of blockchain payments lies in neutrality and resistance to censorship, making it suitable for scenarios where there are concerns about payment suppression or interference.

Misunderstanding 4: Transparent AI Equals Trustworthy AI

Putting the data sources and inference records of models on-chain seems to be an ideal tool for ensuring AI trustworthiness, a point derived from a widely cited IBM blog and extended to AI agents. However, this requires a two-layer breakdown.

In terms of model layer transparency, recording the sources of training data appears to bring transparency regarding model creation, but there is a vast gap between "recording data sources" and "guaranteeing model behavior."

First, on-chain records are merely records and do not equate to proof of origin (proof of the training set composition requires specialized techniques).

Second, even with complete knowledge of training data, it is insufficient to determine how the model will perform, as the training process and computational environment also dictate model behavior.

Third, even with a complete understanding of the process from data to model, sufficient to reproduce the model, the inherent non-determinism of random training makes it fundamentally unfeasible to "verify model weights using the training process."

Moreover, even if the weights are obtained, there are no universally effective means to detect backdoors or adversarial manipulations implanted during training, and putting model data and training information on-chain does not directly guarantee its behavioral characteristics or the absence of adversarial manipulations.

In terms of inference layer transparency, putting model inputs and corresponding inferences on-chain seems to provide transparency regarding model usage, but blockchain ensures transaction transparency, not inference transparency. A record stating "model X produced inference Z on input Y" is nearly impossible to prove as trustworthy.

This is because it cannot prove "correct execution" (to prove that this triplet indeed results from model X operating as specified requires TEE or expensive cryptographic methods), nor can it prove "model trustworthiness."

Even if execution correctness is proven, the more fundamental issue is that a complete provenance record for model X does not semantically prove it meets user expectations or industry standards; using weight hashes to specify models provides even weaker guarantees, as a model's identity does not equate to its trustworthiness.

Blockchain can indeed be useful for certain trust-related goals, such as institutions publishing the hashes of open-source weight models on-chain as immutable references, allowing users to confirm they are using an unaltered genuine model; similar anti-tampering log approaches are also used for firmware update records and certificate transparency (using append-only logs akin to blockchain to maintain publicly auditable records of certificate issuance).

Key Point: Putting model data sources and inference records on-chain still leaves a significant gap between "meaningful guarantees of model and inference trustworthiness."

Misunderstanding 5: Decentralization Naturally Makes AI Tasks Cheaper

Some projects view decentralized networks as more efficient and cost-effective AI solutions, with decentralized physical infrastructure networks (DePIN) being typical, where users rent out their hardware (like GPUs), claiming significantly lower costs compared to centralized cloud providers.

However, cheaper machines do not necessarily lead to lower total task costs. Decentralized nodes communicate over public networks, and the throughput and latency requirements of AI tasks significantly impact total costs, while ultra-large tasks (like training cutting-edge models) are typically constrained by throughput bottlenecks.

Currently, it is challenging to make direct cost comparisons because the industry lacks systematic benchmarking, making it impossible to compare the performance and costs of AI tasks on DePIN with traditional cloud services on the same basis.

Key Point: Decentralized networks are an attractive alternative to high-cost centralized clouds, but existing data is insufficient to predict when a task will be cheaper on DePIN or decentralized AI platforms compared to centralized clouds.

Smaller tasks (inference, small-scale training) are likely to be cheaper, while ultra-large tasks (training foundational models) may be hindered by unstable and low-bandwidth communication between nodes. Clarifying these trade-offs requires further research.

The commonality among these five misunderstandings is that blockchain can provide more "integrity" and "verifiability," rather than "truth" or "trustworthiness" itself. Crypto x AI is still in an early stage where evidence is needed to advance rather than relying on narratives.