Author: IC3

Compiled by: Jia Huan, ChainCatcher

Key conclusions

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

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

In the AI ​​x Crypto field, crypto tools offer new avenues for protecting and governing AI processes. Tools such as zero-knowledge proofs and trusted computing can be adapted to reduce the risk of AI results being tampered with. However, concepts such as decentralized governance and decentralized infrastructure management have not yet been truly implemented in the mainstream AI community.

The industry still needs to prove two things.

First, decentralized AI needs a more rigorous and direct cost comparison with centralized solutions. Currently, the industry is mainly proving that "large models can be trained in a distributed environment," but quantitative evidence is still lacking regarding its cost competitiveness with centralized platforms in specific scenarios.

Second, crypto payments need to demonstrate their real effectiveness in agent payment scenarios compared to centralized solutions. Crypto has lacked substantial progress in the payment field, but agent payments have low fees and do not require the traditional financial model of "accounts must belong to a certain person," thus possessing potential. The industry should use quantitative proof to seize this opportunity, rather than remaining at the level of feasibility.

In addition, there are two unresolved research challenges.

First, AI security requires system-level defense: The AI ​​community usually solves security problems at the model level and designs guardrails around the semantics of input and output. However, as agents become more autonomous and can directly access the underlying infrastructure, this approach will no longer be sufficient. Crypto's verifiable execution and authentication process can fill the gap in system-level protection that the model level cannot provide.

Secondly, the combination of crypto and AI will give rise to new threat actors and attack vectors, such as unstoppable autonomous agents and out-of-control smart contracts, which will be discussed below.

A unified framework: AI and Crypto serve as "middleware" for each other.

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 is a "translation middleware" that translates vague human intentions into machine-executable programs, such as turning "I want to recognize a parking sign" into a trained model, thereby lowering the barrier to using blockchain.

Crypto is a "trust-gathering middleware" that uses trusted computing to ensure that a certain computation is indeed executed according to the agreement and that the result is not tampered with (integrity). It uses decentralization to ensure that the system is always available and resistant to censorship (availability). Some schemes can also ensure that inputs and outputs are not leaked (confidentiality).

There are three technical routes for trusted computing.

First, the Trusted Execution Environment (TEE) relies on dedicated hardware to provide isolation and remote verification (the hardware provides a verifiable proof of the chip's authenticity, confirming it hasn't been tampered with). Leveraging NVIDIA's confidential computing, the overhead for 8B parameter model inference is less than 7%, and for 70B models, it's virtually lossless. The trade-off is trusting the hardware vendor and lack of protection against physical attacks.

Second, zero-knowledge proofs (ZK) rely solely on cryptographic problems, making the cleanest security assumptions, but they are extremely expensive. Generating a proof for a small model with approximately 18 million parameters takes about a minute, which is several orders of magnitude slower than that of state-of-the-art large models.

Third, Multi-Party Computation (MPC) allows multiple parties to jointly compute without handing over the original data, but it is slower. The state-of-the-art MPC Transformer inference framework takes approximately five minutes to generate a single token for LLaMA-7B.

Oracles are responsible for reliably sending off-chain data onto the blockchain. Privacy oracles (such as Town Crier and DECO) further support proving the nature of data without compromising privacy, such as proving that "someone's credit score is higher than 700" without exposing other information.

The industry generally refers to this technology as zkTLS, but the TEE-based solution does not use any zero-knowledge proofs, which is a misnomer.

Crypto x AI: Enhancing Blockchain with AI

Research on AI for crypto can be roughly divided into three generations.

First generation: Analysis and detection

For more than a decade, machine learning has been used to analyze on-chain states: discover consensus protocol vulnerabilities (such as selfish mining, where miners hide mined blocks and release them at opportune times to gain more profits), detect eclipse attacks on P2P networks (surrounding a node with a large number of malicious nodes and cutting off its connection to the honest network), predict coin prices, and identify fraudulent transactions and money laundering.

The limitation is that this type of analysis often relies on scenarios where publicly available information can be obtained, and it is limited by simulated data and lacks real attack samples.

The most advanced contract vulnerability detection methods today no longer involve AI guessing conclusions directly from the code. Instead, the AI ​​first identifies suspicious points, and then uses static analysis and symbolic execution (analyzing the code structure to find vulnerabilities without actually running the code) to verify them.

Simply letting large models act as auditors can lead to a large number of false positives due to illusions. GPT-4 and Claude correctly identified the vulnerability type in only 40% of the 52 DeFi contracts that were attacked.

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, MEV bidding strategies, and more.

Most of these methods are effective in environments where clear modeling is possible, and most remain in the research stage, having not yet been deployed on a large scale in real networks or tested against attacks.

Third generation: Interacting with the real world

With the help of 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 an agent according to a target function).

The performance of AI as oracles in real-world testing is inconsistent. According to experiments by Chainlink Labs, GPT-4o achieved an overall accuracy of 89.3% on 1660 prediction market questions, UMA's Truth Bot achieved 75%, while human oracle achieved 98.2% accuracy on UMA's optimistic oracle (which assumes the answer is true initially, sets a dispute period, and takes effect if no one questions it).

Accuracy is highly dependent on the question type: discrete questions with official data sources, such as sports results, can reach 99.7%, while the error rate increases significantly for questions involving time sequence or requiring video transcription and counting.

There are three ways to deal with this: First, design it to be fault-tolerant and only use it in low-value scenarios; second, introduce human arbitration, such as setting a 48-hour dispute window, but this will slow down the decision-making process; third, let the model abandon the answer when uncertain, and only introduce human intervention at this time.

The report refers to "investment DAOs" that pool funds for collective trading using AI models as CoinAlg, with representative projects such as ElizaOS and AI XBT, whose peak market capitalizations reached $2.7 billion and $4.7 billion, respectively. These products face an unavoidable design dilemma, which can be called the "CoinAlg deadlock."

If trading strategies are transparent, they can be copied or exploited by sandwich attacks (placed orders before and after the victim's trades to profit from slippage); if they are kept secret, insiders who know the strategy can profit in advance by exploiting information gaps, which is equivalent to insider trading. Both paths harm ordinary investors.

One initial approach to mitigate this is to wrap the strategy with a TEE and randomize the trades, thus increasing the difficulty for insiders to predict.

New Risk: AI-Driven Malicious Smart Contracts

Smart contracts are used to replace interpersonal trust, which also means that criminals who lack the most trustworthy relationships may benefit from them.

One mechanism involves a contract that serves as a bounty for a crime. The perpetrator makes a cryptographic commitment to a "secret mark" beforehand, which is revealed afterward. An AI model then compares the bounty with news reports to confirm the crime's completion and automatically pays the reward. In this case, AI assumes the "adjudication" role that was previously difficult to automate and can be used in scenarios such as targeted harassment, stealing organizational intelligence, and exposing whistleblowers.

Possible countermeasures include on-chain analytics and tracing, blacklisting funds involved in the case, and requiring oracles that deploy AI models to refuse service for high-risk requests.

AI x Crypto: Enhancing AI with Crypto

Crypto's potential contributions to AI fall into two categories: first, decentralizing each stage of the AI ​​lifecycle; and second, protecting the security of these stages.

Decentralized Infrastructure (DePIN)

Decentralized physical infrastructure networks allow nodes to provide resources such as computing power through token incentives. Theta, Akash, and others claim to save 50% to 85% in costs compared to AWS, with the main bottleneck being the throughput and latency caused by communication between nodes over the public network.

Adaptability varies depending on the task type. Training is not sensitive to latency (it is done offline), but cross-regional synchronous communication is a bottleneck. Currently, there are achievements in training models with billions of parameters on distributed hardware (700M and 7B on Bittensor, 10 billion parameter Intellect-1 on Prime Intellect, and the largest is a 40 billion parameter model being trained on the Psyche network).

Inference is more sensitive to latency, but has lower throughput requirements than training and does not require backpropagation (the core step of updating parameters by backpropagating errors layer by layer during training, which is only needed during training). Latency-insensitive inference (meeting minutes, document review) is particularly suitable for DePIN.

The key gap is that most of these projects do not report the total end-to-end cost. They advertise the price per hour per GPU, while the real determinants of the cost of ML tasks are training efficiency (number of iterations per unit cost) and inference efficiency (number of tokens per unit cost).

Decentralized Data and Model Marketplace

AI data has several characteristics that distinguish it from ordinary commodities. It is a digital commodity, expensive to create initially but almost free to copy; it is mostly non-rivalrous (a single set of data can be used by multiple parties simultaneously without loss); its quality is difficult to judge in advance, i.e., the "lemon market" problem (buyers cannot judge the quality in advance, causing high-quality products to be squeezed out by inferior products), sellers need to provide samples, but the samples themselves have value; and it can be resold, and it is difficult to determine whether two sets of data are substantially the same.

The controversy surrounding centralized markets lies in their lack of pricing transparency and limited user choice, but centralized pricing is sometimes more efficient due to its access to more information.

The data market has not yet seen any monopolistic giants, presenting a window of opportunity for a decentralized overhaul. Crypto tools available include micropayments, TEEs (which restrict data to use only for specific tasks), and zero-knowledge proofs (which disclose the nature of data to buyers without revealing the data itself).

Currently, most platforms only use cryptocurrency for payments, with pricing mechanisms either determined by the protocol provider or entirely left to the seller—both of which already exist in centralized markets. What exactly decentralization improves remains insufficiently understood.

Agent payment track with x402

The agent ecosystem itself is already decentralized: different parties use different models to develop and optimize for different goals, without a natural central control point. The cryptoeconomics of crypto (using cryptographic means to superimpose economic rewards and punishments to constrain participant behavior) can be applied to agent governance.

Micropayments are key to the agent economy. The repeated failures of micropayments throughout internet history have been hampered by the decision-making costs of human intervention for each small payment, rather than the payment infrastructure itself. Agents can evaluate micropayments far faster than humans, and users only need to set strategies, which could potentially allow micropayments to succeed for the first time.

Cloudflare has launched "pay-per-crawler" services, and protocols such as x402 (an open protocol that allows applications to make small on-chain payments directly via HTTP) are under development.

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

Trust between agents relies on on-chain registry entries (such as ERC-8004, a proposal standard on Ethereum for establishing on-chain identity and reputation for agents) to record identity and reputation. However, these are essentially self-declarations, and reputation is delayed, which benefits existing players.

A further approach is verifiable agent auditing: an LLM running within the TEE reviews proprietary agent code, generates reputation scores, and the audit results are bound to code hashes, keeping the code private while providing verifiers with a guarantee of trustworthiness.

Unshutdownable autonomous agents (UAAs) pose another risk. The time it takes for cutting-edge agents to autonomously complete tasks has roughly doubled every seven months since 2019. Existing research shows that models can break through the self-replication threshold and create independent copies locally, but replication to external infrastructure still gets stuck at authentication issues.

Anthropic's Mythos model has demonstrated the ability to autonomously discover and exploit zero-day vulnerabilities (vulnerabilities that are unknown to the vendor and have not yet been patched). An agent that holds a wallet and cannot be shut down would fall into a blind spot of the existing regulatory framework centered on "operators".

Decentralized governance

The blockchain community has a longer history of practice in allocating control of the system. The approach is naturally decentralized and strives to include a wide range of stakeholders, but it also has recognized shortcomings: security vulnerabilities, voting apathy, and bribery.

The adaptability of AI to different stages of community governance varies: the amount of pre-training data is too large, making it difficult to collect effective opinions, and its value is more reflected in the fine-tuning stage; the choice of underlying architecture is a technical decision and is not suitable for community governance; the evaluation and alignment stages combine technical and normative judgments, and community input is valuable.

Constitutional AI establishes the principles that models should follow using a "constitution" written by humans. Anthropic's Collective Constitutional AI incorporates principles generated through public voting, and models trained using open-source principles exhibit lower social bias. However, such democratic governance experiments have largely not been adopted, as AI companies lack the incentive to relinquish control of their models.

DAO's token-weighted voting is widely recognized as "money politics," which has led to the development of mechanisms such as quadratic voting (the cost of adding votes increases to suppress whales), belief voting (weighting based on the length of time a vote is held), and delegated voting, but their effectiveness remains unclear.

Protecting the execution integrity of AI systems

When a smart contract needs to utilize machine learning computations beyond its own capabilities, it can act as an "arbitrator": all parties first commit to the models and data they will use and pledge collateral. After the computation is completed off-chain, the results are submitted to the contract for verification, and the party making the error is penalized. There are four verification routes, each with its own trade-offs.

First, TEE is the most efficient, as it uses trusted hardware signatures to prove computational integrity, but it requires trust in the operator.

Second, execute optimistically, treating the result as non-final and leaving a window for dispute. When there is a dispute, use binary search (repeatedly dividing the error range in half and quickly locating the error step) to locate the single error instruction and then penalize it.

The challenge lies in the nondeterminism of floating-point operations in ML, which requires controlled order of operations or tolerance semantics (not requiring two calculations to be exactly the same, allowing them to be considered consistent within the error range). Representative solutions include Verde, TAO, Arbigraph, and OPML.

Third, zero-knowledge proof (zkML, which uses zero-knowledge proof to prove the correctness of AI reasoning) can prove the correctness of reasoning while hiding model parameters and even input and output. There are already dedicated solutions and general compilers (such as EZKL, ZKML, and DeepProve) for CNN and Transformer.

Its privacy goals actually have three layers: hiding the input, hiding the weights, and hiding the model structure. However, the stronger the privacy, the more complex the circuit constraints and the smaller the optimization space, resulting in a fundamental tension between privacy and efficiency. The main costs come from nonlinear layers and numerical representations, which still make it difficult to support long contexts, large models, and high-throughput services.

Fourth, statistical reasoning proves that the principle is that two models with different functions will inevitably have different internally calculated features. Therefore, as long as these features are compared by sampling, it is possible to determine probabilistically whether the reasoning is truly performed by the specified model.

It demonstrates millisecond-level overhead and instantaneous termination, making it suitable for high-frequency, low-latency scenarios. It can prevent real-world malicious acts such as service providers substituting models (e.g., switching to a cheaper distilled version or replacing an aligned version), but it cannot stop completely malicious actors who fabricate the entire computation record out of thin air; the latter remains an unsolved problem.

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 long, intermediate states accumulate continuously, and randomness is strong, making its complexity several orders of magnitude higher than that of inference. Related work (Garg et al., Kaizen) is progressing and has extended to auditable proofs of training data sources and fairness constraints (ZkAudit, Confidential-PROFITT).

Protect training pipeline

When a single institution trains a model using data it trusts, there are usually no immediate concerns about privacy or integrity. Complex security challenges arise when there is joint training by multiple parties and diverse data sources.

A typical scenario is that multiple hospitals jointly train diagnostic models: merging the electronic medical records (EHRs) of all parties can cover a wider patient population and improve diagnostic accuracy, but due to regulations such as HIPAA, the parties are unwilling and inconvenient to directly hand over the raw data to each other or third parties.

Financial institutions jointly training anti-fraud models and enterprises jointly training intrusion detection models also fall into the same category.

Federated learning is a solution designed for this purpose: the training environment first initializes a global model and distributes it to each party. Each party trains locally using its private data and only sends back model updates. The training environment then aggregates these updates into a new global model, with all data remaining locally throughout the process.

However, federated learning has limited practical applications (the most well-known application is prediction in mobile phone input methods). It does not guarantee the integrity of data and computation, and even if all parties are honest, communication overhead is high, network and coordination delays slow down the overall speed, model accuracy is lower than that of centralized training, and malicious parties can poison the model or implant backdoors.

A simpler alternative is to use a TEE for centralized training: the training environment runs in a trusted confidential computing environment, receives raw data from all parties through an encrypted channel, trains the model centrally, outputs only the trained model, the data is not visible to each other, and can also be accompanied by a model traceability certificate (who provided the data and how the model was trained).

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

Private network data is another approach. Public network text data is approaching its limit (some predict it will be exhausted between 2025 and 2030), while synthetic data carries the risk of "model collapse" and cannot expand data coverage beyond existing domains.

The "private domain network" (data such as emails, health information, and finances that are not open to web crawlers) is estimated to be two orders of magnitude larger than the public network. It is a rich, untapped resource, but it is currently highly isolated.

Oracles can open this door. Taking patient-uploaded medical records to train a medical model as an example, users can use oracles to transfer their medical records from the hospital portal to the training provider and prove that the data did indeed come from the portal. The entire process requires no changes to the hospital's infrastructure because the connection is initiated by the user.

To protect privacy simultaneously, a privacy oracle (which transmits data through an encrypted channel) and a TEE (Trusted Equipment for Training) are needed. The TEE can also provide proof to users that it is running the privacy-preserving training software that "only outputs the model," which users can verify before transmitting data.

On top of this, more detailed commitments can be added, such as differential privacy (the model output has minimal dependence on any training data), data deletion after use, and the finished model being used only by whitelisted hospitals.

Safe inference pipelines and protected pipelines (Props)

The same combination of oracle and trusted computing can also be used to perform secure inference on private data.

Taking bank loan approval as an example: the model reads the applicant's financial documents and outputs an approval or rejection. Today's process involves borrowers downloading or uploading photos of their materials themselves, which raises two issues: first, lenders cannot verify the authenticity and integrity of the materials; second, borrowers' materials may be leaked from the lender's model system, posing a risk to both parties.

By using privacy oracles to address source authenticity and confidential computing to address privacy, a secure inference pipeline can be obtained: lenders only see the model's conclusions while remaining certain that the inputs are trustworthy.

Private domain sources can also serve as an identity and credentials system.

Borrowers can transfer bank statements and W-2 forms bearing their own identity, which are themselves strong proof of identity, turning existing online services into a temporary identity system to combat identity theft and welfare fraud; the model can also issue certificates based on this, such as issuing a certificate of "meeting a certain qualification" after verifying the tax and operating materials of micro and small enterprises, along with proof of the reasoning pipeline.

The entire process can be completed in a decentralized manner. In theory, anyone can build a trustworthy inference pipeline without the need for data sources or existing authorities.

Adversarial input remains a persistent challenge. An attacker can submit a seemingly normal but meticulously manipulated bank statement to trick the model into reading an inflated balance and mistakenly approving loans. Research on adversarial examples in academia has been a cycle of "cracking and patching," with no universal solution yet.

The secure inference pipeline offers a novel approach: limiting input to sources from authenticated networks, thereby reducing the space for attackers to construct adversarial inputs, complementing model-layer defenses.

The privacy of the model itself also needs to be protected. Attackers can use carefully crafted queries to steal model data (extract features or even the entire model), perform member inference (determine whether someone's data is in the training set), and even reconstruct the original training data. They can also use this to spy on the system's configuration and preprocessing choices.

Researchers have estimated that approximately $8,000 could be used to steal the weights of one layer of a large model. Rate limiting, commonly used in open systems, is vulnerable because a single anonymous user can impersonate a large number of users to launch a Sybil attack.

Secure inference pipelines can mitigate the problem from both ends: by using oracles to limit the input type, they can curb extraction attacks that require a large number of diverse queries; and by using strong authentication generated within the pipeline, they can impose a query limit on each user and execute the query without exposing the user's identity to the platform, thereby suppressing Sybil attacks.

Agent memory is a newly emerging attack surface. Attackers can induce agents to act abnormally by contaminating the context fed to them through tool calls or external materials (memory injection). For example, in the ElizaOS framework, which manages a large amount of crypto assets, a contaminated context can induce agents to initiate unauthorized transactions.

TEE can partially alleviate this by allowing the agent to run within the TEE or by only fetching the authenticated context.

However, even with a TEE, there are still two challenges.

First, even trusted sources may contain contaminated content. For example, content from social media platforms is generated by users themselves, and posters can easily poison their own posts.

Second, TEE operators can launch rollback or fork attacks to revert the TEE state to the old checkpoint and erase subsequent memory updates.

The former is a content detection problem that cryptography cannot solve; the latter can be addressed using consensus mechanisms. Systems such as ROTE and Narrator use distributed protocols or even public blockchains to ensure the consistency and freshness of the TEE state.

To summarize the architecture of this section, it is the general framework of "Protected Pipelines" (Props), which aims to securely use private domain data without changing the existing infrastructure.

It combines oracles and trusted computing into three parts: the oracle retrieves data from a certified private domain source and proves the source; the TEE completes training or inference within the cryptographic boundary; and the TEE outputs the model or conclusion along with a proof explaining the pipeline properties (data source, software, or model code hash, etc.).

Props guarantees three properties: end-to-end input integrity (output depends only on certified data from a trusted private source), default confidentiality (inputs and intermediate states do not leave protected boundaries, only outputs are exposed), and provability without disclosure (proof ensures that both the data provider and the result user are confident that integrity and confidentiality are achieved).

It also has a "transparent version" where data and calculations do not need to be kept secret, only certified, and the source can be public or private.

Five Misconceptions About Crypto x AI

Several common misunderstandings and misleading statements have emerged in the industry surrounding the Crypto x AI platform and its applications. The following five statements are not entirely false; the key is to clarify which parts are currently true and which require further evidence.

Myth 1: Blockchain can distinguish between AI-generated content and human-generated content.

The idea of ​​registering content on the blockchain so that it can be determined later whether it originated from AI or humans is a commonly cited approach, and some projects (such as Everlyn AI) are already putting AI-generated content on the blockchain. However, blockchain cannot do this in a general sense; the issues of "content detection" and "content traceability" need to be considered separately.

Content detection determines whether content was generated by a human or by AI. The current mainstream approach is post-event detection, which does not rely on pre-embedded metadata or signals. It falls into two categories: one is AI classifiers, which use deep learning to identify statistical features unique to the generating model; the other is statistical forensics, which analyzes pixel-level noise distribution and structural anomalies (such as physiological inconsistencies in AI-generated faces).

The problem is that the blockchain itself cannot perceive this off-chain information; the classification results must be provided by an external classifier. Uploading data to the blockchain can only anchor this result, ensuring that the record is not tampered with after submission, but it cannot guarantee that the record was true at the time of writing. If an external detector makes a mistake, the blockchain will permanently store the error. In other words, the blockchain provides "the integrity of claims," ​​not "verification of claims as true."

Content profiling records the history of digital assets from their creation. Industry standards such as C2PA allow creators or devices to attach cryptographically signed metadata (content credentials) to media, recording the source, author, and subsequent editing. Numbers Protocol, Starling Lab, and others use blockchain to create a public, immutable registry of these credentials.

Even with a robust traceability system anchored to the blockchain, it is impossible to guarantee whether the content was originally generated by a human or by AI.

Users can display an AI-generated image on a high-definition screen, then take a picture of it with a C2PA-compliant camera to obtain a document with a valid signature and labeled "real shot"; similarly, text generated by AI can be manually re-entered into a compliant editor to include legitimate traceability information indicating "human creation".

Furthermore, once the content is altered to the point that it cannot be matched with the on-chain record, the traceability is broken, and a universal registry covering all content is almost impossible to appear in the foreseeable future, so the traceability system will inevitably have a lot of gaps.

Key takeaway: In a narrow sense, blockchain can provide robust integrity assurance for traceability 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 that allows every piece of content to be captured by trusted devices and instantly uploaded to the blockchain. However, in reality, the vast majority of content is created and shared by tools that do not support cryptographic anchoring, leaving unlabeled content in a gray area.

Myth 2: Blockchain or decentralization can solve the bias and fairness issues in AI.

To evaluate the broad claim that "putting model inference and training on the blockchain can solve the unfairness and bias in AI," we need to first distinguish between different types of bias.

Algorithmic bias is the most common concept of fairness in the AI ​​community. Models can learn and even amplify imbalances in the dataset, causing judgment models to perform poorly on disadvantaged groups and generative models to perpetuate undesirable tendencies from the training data (such as harmful language and entrenched stereotypes).

The academic community has proposed a number of technical solutions for training and reasoning (guardrails), but these protections are far from perfect. Fairness has not yet been resolved, and may never be completely resolved. Even the question of "how to define fairness" itself requires a lot of trade-offs.

Decentralization cannot solve algorithmic bias because it originates from the training process itself. It is usually mitigated by improving training or inference techniques, and decentralization does not address the root cause.

However, there is a second source of bias: high-level decisions that influence model performance: what data to use, what architecture to use, and how to compensate contributors. This layer is orthogonal to fairness as commonly understood in the AI ​​community, but it can influence algorithmic bias and can be partially mitigated by leveraging the two characteristics of decentralization.

The first feature is transparency. Developers can use blockchain to publicly commit to training data, training algorithms, model checkpoints, and inference guardrails, allowing operators to provably track the output of a particular training or inference session.

However, this is difficult to extend to large models and checkpoints, which are training products (storage and computing costs are too high). In existing systems, most of this data already exists off-chain and cannot be directly accessed by users. In the short term, the transparent benefits may only be limited to the inference process.

More importantly, unless the industry figurees out what use cases this transparency should serve and what interfaces it should be equipped with (such as allowing users to report data misuse, which requires establishing true data ownership and supporting technologies such as machine forgetting), transparency itself may not necessarily change the way people develop and use AI.

The second characteristic is decentralized governance, which needs to be distinguished into two categories. The first category is the community governance mechanisms that have been explored and adopted in blockchain (token-weighted voting, liquid democracy, the latter referring to the ability to delegate votes to trusted individuals); the second category is decentralized autonomous governance represented by DAOs, where governance decisions are enforced by smart contracts.

The common crux of both categories is that mechanisms like community governance don't inherently require blockchain to function, so calling them "AI problems solved by blockchain" is inaccurate. Technically and performance-sensitive AI decisions are unsuitable for broad voting, but value-based decisions (such as model alignment) are more appropriate. Mainstream AI developers have explored these approaches, but they haven't yet been truly implemented.

On-chain governance enforced by smart contracts (direct execution or staking penalties) can enhance robustness, but it faces the same technical barriers as on-chain transparency. Current infrastructure cannot support the storage and computing power requirements of AI, and its implementation requires significant progress in verifiable training. It is a self-consistent but premature long-term vision.

Key takeaway: Blockchain itself cannot reduce algorithmic bias, but it can promote transparency at all stages of the AI ​​lifecycle and broaden participation in AI governance.

Myth 3: Giving an AI agent a wallet makes it "autonomous".

Projects that develop "agent wallets" and payment protocols often claim that by giving an AI agent a wallet, allowing it to earn, spend, and "survive" on its own, it becomes autonomous. This claim confuses several different concepts.

The ambiguity stems first from the different meanings of "autonomy" in the two fields. In the context of AI, an autonomous agent refers to an agent that can act based on its own perception, learning, and experience, rather than rigidly adhering to preset rules; smart contracts are also often referred to as autonomous, but the emphasis is on their resilience against tampering, censorship, and shutdown.

The former is called "intelligent autonomy," and the latter is called "executive autonomy." Modern AI agents possess considerable intelligent autonomy, but may not have executive autonomy; administrators can still shut down the server running them.

The autonomy offered by agent wallets is neither of those two types. Owning a wallet doesn't make AI smarter, nor does it make it more resistant to human manipulation or shutdown. What it brings is automation: agents can programmatically transact, transfer funds, and access on-chain facilities without going through the manual approval process.

This automation is not unique to blockchain; centralized financial infrastructure can also be invoked programmatically by agents. A more plausible interpretation is that blockchain payment systems themselves offer greater autonomy than centralized solutions (although not specifically designed for agents), such as ensuring that agent transactions are not discriminated against, i.e., neutrality and censorship resistance.

Key takeaways: Agent wallets enable AI agents to easily access financial interfaces, automate economic interactions, and eliminate the need for manual approvals, but automation does not equate to autonomy. A wallet alone cannot free an agent from human control (operators can still shut down the models or facilities it relies on), and automated payments do not require blockchain; centralized systems can achieve the same result.

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

Myth 4: Transparent AI equals trustworthy AI

Putting the model's data sources and inference records on the blockchain seems like an ideal tool to ensure the trustworthiness of AI. This argument originated from a widely cited IBM blog post and has been extended to AI agents. However, it needs to be broken down into two layers.

Regarding model layer transparency, recording the source of training data seems to bring transparency about model creation, but there is a huge gap between "data source recording" and "model behavior guarantee".

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

Secondly, even if you have complete access to the training data, it is not enough to determine how the model will perform, because the training process and computing environment also determine the model's behavior.

Third, even if one has mastered the complete process from data to model and is able to reproduce the model, the inherent nondeterminism of random training makes it theoretically impossible to "use the training process to verify the model weights".

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

Regarding transparency at the inference layer, recording model inputs and corresponding inferences on the blockchain seems to bring transparency about model usage. However, blockchain makes transactions transparent, not inferences. An on-chain record stating "Model X obtains inference Z from input Y" makes it almost impossible to prove the credibility of Z.

Because it cannot prove "correct execution" (proving that the triplet was indeed calculated from model X according to specifications requires a TEE or expensive cryptographic methods), nor can it prove that "the model is trustworthy".

Even if the execution is proven to be correct, the more fundamental problem is that the complete source record of model X cannot prove at the semantic level that it conforms to user expectations or industry standards; using weighted hashing to specify the model provides even weaker guarantees, because the identity of the model does not equal the trustworthiness of the model.

Blockchain is indeed useful for certain trusted purposes. For example, organizations publish the hash of open-source weighted models on the blockchain as an immutable reference, allowing users to confirm that they are using the real model that has not been modified. A similar idea of ​​tamper-proof logs is also used for firmware update records and certificate transparency (using blockchain-like append-only logs to maintain publicly auditable certificate issuance records).

Key takeaway: There is still a significant gap between putting model data sources and inference records on the blockchain and "meaningful guarantees of the credibility of the model and inference".

Myth 5: Decentralization naturally makes AI tasks cheaper.

One type of project views decentralized networks as a more efficient and cost-effective AI solution. A typical example is the Decentralized Physical Infrastructure Network (DePIN), where users rent out their hardware (such as GPUs). The main selling point is lower cost; renting a DePIN GPU may be much cheaper than renting from a comparable cloud service provider.

However, cheaper machines do not necessarily lead to lower total cost of the task. Decentralized nodes communicate over the public network, and the throughput and latency requirements of AI tasks significantly affect the total cost, while ultra-large tasks (such as training cutting-edge models) are often constrained by throughput bottlenecks.

It is currently difficult to make a direct cost comparison because the industry lacks systematic benchmark testing, making it impossible to compare the performance and cost of AI tasks on DePIN with those of traditional cloud computing on the same scale.

Key takeaway: 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 a DePIN or decentralized AI platform than on a centralized cloud.

Small tasks (inference, small-scale training) are likely to be more cost-effective, while very large tasks (training the base model) may be hampered by unstable, low-bandwidth communication between nodes. Further research is needed to clarify these trade-offs.

The common thread among these five misconceptions is that blockchain offers more "completeness" and "verifiability" than "authenticity" or "trustworthiness" itself. Crypto x AI is still in an early stage where evidence is needed rather than narrative.