Decentralized AI Agents and Blockchain: Architectures, Coordination Mechanisms, and Governance Frameworks

Abstract

Autonomous AI agents capable of holding digital assets, signing transactions, and executing smart contracts on public blockchain networks have moved from research prototypes to active deployment over the past two years. Despite this pace of adoption, no systematic treatment of their architecture, coordination protocols, and governance structures exists that spans the full design space. This survey addresses that gap through a systematic review of the literature from 2019 to 2026, covering 177 peer-reviewed publications and 14 system documentation sources, identified through a structured search of IEEE Xplore, the ACM Digital Library, Scopus, and arXiv. We classify deployed and proposed systems along four architectural dimensions: on-chain execution, off-chain agents with on-chain settlement, verifiable off-chain computation, and multi-agent on-chain interaction. Then, we examine the coordination mechanisms through which agents reach collective decisions, covering auction-based protocols, cooperative multi-agent reinforcement learning, token-incentive structures, and gossip-based peer-to-peer coordination. Governance is treated as a distinct dimension, analysed through a technical lens, covering on-chain parameter control, dispute resolution, and DAO structures, and an organizational one, covering accountability, incentive alignment, principal–agent dynamics, and regulatory compatibility. We survey applications across decentralized finance, supply chain, IoT, and agent marketplace domains, and identify six open research problems whose resolution is a prerequisite for broader deployment. The convergence of mechanism design and multi-agent reinforcement learning in asynchronous blockchain environments is identified as the direction of greatest near-term research value.

1. Introduction

In March 2024, an autonomous software agent deployed on a public blockchain network executed a series of decentralized exchange trades, paid gas fees from its own wallet, and distributed proceeds to token holders, with no per-step human approval at any stage. It was ordinary operation on the Autonolas protocol [1], one of several production systems in which AI agents currently act with genuine economic autonomy on-chain. The broader phenomenon is accelerating: agent frameworks with native wallet support, on-chain task markets where agents hire other agents, and DAO governance systems where AI agents hold voting power are all live as of 2025–2026 [2,3,4].

The literature has not kept pace with this shift. Multi-agent systems research has a long tradition of studying autonomous agent coordination [5], but it largely treats the execution environment as either a simulation or a centralized server. Blockchain research, in turn, has examined smart contracts, consensus protocols, and token economics in depth [6], but tends to treat AI as a capability to be added on top of an existing system, not treated as a structural design variable. The governance literature on Decentralized Autonomous Organisations (DAOs) and decentralised protocols [7] has developed its own vocabulary (voting mechanisms, treasury management, on-chain constitutions) without systematic connection to the multi-agent coordination problem. Researchers and practitioners working at the intersection of multi-agent systems, blockchain, and governance have no unified reference as a result.

This survey constructs that reference. We examine how AI agents are architecturally situated relative to blockchain infrastructure, how they coordinate with each other through on-chain and off-chain mechanisms, and how their autonomous behaviour is constrained and legitimated through governance structures. We treat these three dimensions, namely architecture, coordination, and governance, as mutually dependent: an agent’s coordination options depend on its execution architecture, and the governance mechanisms available depend on both.

The scope of this survey requires some clarification. We use the term decentralized AI agent to mean a software agent satisfying three conditions: operational autonomy (it acts across multiple steps without per-step human approval), economic autonomy (it controls digital assets and can transact independently), and some form of on-chain interaction, meaning its behaviour is mediated by or recorded on a blockchain network. This excludes simple smart contracts, which are deterministic and non-adaptive, and cloud-hosted AI systems that call blockchain APIs incidentally, which are not decentralized in any meaningful sense. The boundary cases are discussed in Section 2.

The maturation of Layer 2 infrastructure is one reason this survey is timely. By reducing transaction costs by two to three orders of magnitude compared to the Ethereum mainnet [8], these scaling solutions have made frequent on-chain agent operations economically viable. Large language model (LLM) agents with tool use, meaning agents that reason in natural language but act through blockchain transactions, have added a new architectural pattern with no clear precedent in the multi-agent systems literature [9]. And the EU AI Act [10] and the Markets in Crypto-Assets Regulation (MiCA) [11] came into force in 2024–2025, creating a concrete regulatory context for decentralized AI agents that did not previously exist. The governance dimension of this survey is motivated by the need to understand how these frameworks apply, and where they break down.

Cases from separate disciplines illustrate why this intersection demands unified treatment. In decentralised finance, autonomous liquidation agents on lending protocols such as Aave and Compound executed over $200 million in forced collateral sales during the market dislocations of March 2020 and May 2021 [12]. No human approved individual transactions; no single legal entity was identifiable as the responsible operator. The resulting losses affected retail users who had no visibility into the agent logic that triggered their liquidation. This is a problem that sits at the boundary of computer science, financial regulation, and tort law. In UAV coordination, DAO-governed drone swarms are being proposed for post-disaster response across national borders [13], raising questions about which jurisdiction’s aviation rules apply when the governing DAO has no registered domicile and the swarm’s collective decisions emerge from an on-chain vote among anonymous token holders. In supply chain management, autonomous AI agents that flag compliance violations and trigger smart contract penalties without human approval are entering production deployments [14], creating situations where a supplier’s payment is withheld by an algorithm whose decision logic is opaque to both parties. Each case involves computer science, a domain discipline, and a governance framework that were designed independently and do not compose cleanly. A survey that addresses only the technical dimensions cannot answer the questions these cases raise.

The main contributions of this survey are as follows:

• A three-dimensional analytical framework for decentralised AI agent systems, treating architecture, coordination, and governance as jointly determined design dimensions instead of independent concerns. The interaction structure across these three dimensions is made explicit throughout the paper: an agent’s execution architecture constrains its coordination options, which in turn determine what governance mechanisms are available.
• A four-pattern architectural taxonomy (Section 3) classifying systems by execution locus, verification mechanism, and learning paradigm, together with a 20-entry comparative table and three non-obvious cross-taxonomy observations about the current deployment state.
• A structured coordination mechanism comparison (Section 4) across auction-based, MARL-based, token-incentivised, and gossip-based protocols, covering communication overhead, trust assumptions, incentive alignment, and latency tolerance.
• A governance analysis (Section 5) spanning on-chain technical mechanisms (DAO structures, slashing, dispute resolution) and organisational dimensions (principal–agent alignment, regulatory compatibility under the EU AI Act and MiCA, inter-organisational adoption conditions). Two named analytical constructs (the governance vacuum and the dual agency problem) are introduced and grounded in the IS and mechanism design literatures.
• Six precisely stated open research problems (Section 7), each accompanied by a success criterion that defines what a resolution would look like.

Several surveys address adjacent territory without covering the intersection this paper targets. Nguyen et al. [15] survey blockchain-based task offloading and resource allocation in edge and UAV networks, but their scope is restricted to off-chain MARL with on-chain settlement and does not address architectural alternatives, coordination mechanisms beyond MARL, or governance. Zheng et al. [6] survey blockchain systems broadly, treating AI as one application area among many, not as a structural design variable. Busoniu et al. [16] provide the standard MARL reference but predate blockchain deployment and do not address on-chain execution environments, token incentives, or DAO governance. On the IS side, Lumineau et al. [17] examine blockchain governance as an inter-organisational coordination mechanism, but without an agent system layer. Fritsch et al. [7] analyse voting power concentration in DAOs empirically, but do not connect this to AI agent deployment or coordination. The present survey differs from all of these by treating the three dimensions (architecture, coordination, and governance) as jointly determined, by grounding the analysis in a systematic 177-paper corpus, and by targeting the design space for AI agents that satisfy all three conditions in the scope definition in Section 2.3.

The paper is structured as follows. Section 2 establishes scope, defines terms, and describes the survey methodology. Section 3 classifies deployed and proposed systems along four architectural patterns. Section 4 examines coordination mechanisms across four protocol families. Section 5 analyses governance from both a technical and an organisational perspective. Section 6 surveys empirical evidence across four application domains. Section 7 identifies six open research problems, and Section 8 draws the principal conclusions.

2. Background and Scope

2.1. Blockchain Primitives

An agent operating in a blockchain environment has fewer degrees of freedom than one operating in a conventional cloud environment. Understanding those constraints is necessary before the architectural taxonomy in Section 3 will make sense.

Smart contracts are programs deployed at a fixed network address, executed by a distributed virtual machine; most commonly the Ethereum Virtual Machine (EVM) or a compatible equivalent. Their execution is deterministic, publicly verifiable, and, absent an upgrade mechanism, immutable. In regards to agent design, this has direct consequences. Computation is metered by gas cost, which limits how much work an agent can do in a single transaction. Persistent mutable state is held in contract storage rather than memory. Native randomness is unavailable without an external feed. On-chain execution is therefore cheap only for simple logic; agents that require inference over high-dimensional inputs must execute off-chain and commit only results to the chain.

Account abstraction, standardised on Ethereum through ERC-4337 [18], decouples the signing key from the account logic. A smart contract account can be controlled by an agent’s key pair instead of a human-held private key, and the account’s validation logic can be customised, to allow multi-signature approval, rate limiting, or session keys with constrained spending. This is the primary mechanism through which agents acquire persistent on-chain identity and asset custody that is not tied to a human wallet.

Oracle networks bridge the gap between on-chain execution and off-chain data. An agent executing on-chain has no native access to external prices, sensor readings, or API responses; it can only read contract state and transaction inputs. Oracle networks such as Chainlink [19], Pyth [20], and UMA [21] push signed data onto the chain at configurable intervals. For agents that must react to real-world events, oracle latency and update frequency are binding constraints. Manipulation resistance matters equally: price oracle manipulation has caused substantial losses in DeFi systems that relied on agents acting on stale or distorted data [12].

Layer 2 rollup networks have changed the cost structure of agent operation. Ethereum mainnet gas fees make frequent on-chain agent actions uneconomical for most applications. Rollup networks, such as Arbitrum, Optimism, Base, zkSync, execute transactions off-chain and post compressed proofs or state differences to Layer 1, reducing per-transaction costs by one to two orders of magnitude. Block times on these networks are typically two seconds or less, compared to twelve seconds on Ethereum mainnet. These parameters directly constrain action frequency and agent responsiveness; as a result, most production deployments favour Layer 2 over Layer 1 environments.

Token incentive structures such as fungible tokens, staking mechanisms, and slashing conditions, are the primary tool for aligning agent behaviour with system-level objectives in the absence of a trusted authority. Staking requires an agent to lock tokens as collateral, creating a financial penalty for misbehaviour. Slashing destroys some or all of that collateral when a verifiable violation is detected. Reputation tokens, which accumulate from past behaviour and are difficult to transfer, serve a similar function where slashing would be too coarse an instrument. The design of these structures is inseparable from the coordination problem examined in Section 4.

2.2. AI and Agent Primitives

The systems surveyed draw on three families of AI methods, which differ in how an agent acquires its policy, what inputs it processes, and what behavioural guarantees, if any, it provides.

Reinforcement Learning (RL) agents learn a policy through repeated interaction with an environment by maximising cumulative reward [22]. The policy maps observed state to actions; the reward function encodes the designer’s objective. In blockchain environments, the state typically includes token prices, contract balances, and pending transaction data; actions include trade execution, liquidity provision, or protocol parameter updates. Deep RL algorithms such as DQN [23] and PPO [24] are the most common in this context. A known limitation is sample inefficiency: RL agents require large numbers of environment interactions to learn effective policies, which is costly when each interaction is a real blockchain transaction with gas overhead.

Multi-agent Reinforcement Learning (MARL) extends this to settings where multiple learning agents interact simultaneously [16]. As all agents learn concurrently, the environment each agent observes is non-stationary by construction. The Centralised Training, Decentralised Execution (CTDE) paradigm [25] addresses this by allowing agents to share information during training while restricting them to local observations at execution time. QMIX [26], MADDPG [27], and COMA [28] are the most widely used CTDE algorithms in the literature. The connection to blockchain-based systems follows directly from this property: CTDE maps naturally onto environments where agents act on local information but coordinate through shared contract state during a training phase. LLM-based agents use large language models as a planning and reasoning component, with external tools for action [9,29]. The ReAct pattern, which alternates between explicit reasoning steps and action calls, is the dominant design choice. These agents handle unstructured inputs and natural-language task specifications that pure RL agents cannot. Their weaknesses run in the opposite direction; inference is expensive, behaviour is non-deterministic, and the agent does not learn from interaction without fine-tuning. Hybrid architectures, in which an LLM handles high-level task decomposition and an RL or rule-based component handles execution, appear in several recent production agent frameworks and fall within the scope of this survey.

A note on terminology: this survey uses “AI agent” to mean a system in one of these three families (RL, MARL, or LLM-based) that acts with genuine policy-level autonomy. This is narrower than the common usage of “AI” to cover any machine learning system, and narrower than the use of “agent” in economic theory to mean any rational decision-maker. Systems that apply supervised or unsupervised ML to classify or predict without taking actions, and economic agents that are rational but not implemented as software, are outside the scope of this survey even where they interact with blockchain infrastructure.

2.3. What Makes an Agent Decentralised

Definitions in this space tend to be either too narrow or too broad. Some existing surveys treat any smart contract with conditional logic as an autonomous agent [30], while others restrict the scope to LLM-based agents and exclude reinforcement learning systems that constitute the majority of current deployments [31]. Industry usage, meanwhile, frequently extends the term to systems where a human approves every transaction. None of these captures what this survey is concerned with. We anchor on three conditions, each of which must hold.

The first is operational autonomy: the agent acts across multiple steps without per-step human approval. A system that executes a transaction only after a human clicks confirm is not operationally autonomous in the relevant sense, even if the underlying decision logic is sophisticated. The threshold matters because it determines where accountability sits and what governance mechanisms are required.

The second is economic autonomy: the agent controls digital assets and can transact with them independently. This separates agents that read blockchain state from agents that write to it with real consequences. An agent that monitors a liquidity pool without the ability to rebalance it unilaterally is an observer rather than an economic actor.

The third is on-chain interaction: the agent’s behaviour depends on blockchain state as input, commits its consequential outputs to a blockchain, or is governed by on-chain contracts, such that removing the blockchain component would fundamentally alter the agent’s operating mode or accountability structure. This condition excludes systems that use a blockchain purely as an incidental audit log while acting through centralised infrastructure, and admits off-chain reasoning with on-chain settlement, which is the dominant architectural pattern in current deployments.

Several system types fall close to but outside this boundary. Standard smart contracts fail the first condition: they execute deterministically on fixed inputs and cannot adapt their behaviour across interactions without an external call. Cloud-hosted AI systems that read blockchain data but act through centralised exchanges fail the third condition in the meaningful sense, since their consequential actions leave no on-chain record. Human-supervised systems that require approval above a spending threshold occupy a boundary position; we include them where the autonomous action space is otherwise non-trivial and the approval gate is the exception, not the rule.

These three conditions are not arbitrary. Each maps onto a design dimension addressed in subsequent sections. Operational autonomy shapes the governance problem (Section 5). Economic autonomy determines which coordination mechanisms are viable (Section 4). On-chain interaction defines the execution architecture options (Section 3).

2.4. Survey Methodology

This survey is guided by three research questions that reflect its three analytical dimensions:

• RQ1 (Architecture): What architectural patterns have emerged for deploying AI agents on or through blockchain infrastructure, and what are their respective trade-offs in verifiability, computational expressiveness, and latency?
• RQ2 (Coordination): Through what mechanisms do decentralised AI agents coordinate their actions, and how do these mechanisms perform across communication overhead, incentive alignment, and trust assumptions?
• RQ3 (Governance): How are decentralised AI agent systems governed, and where do existing technical and regulatory mechanisms fall short?

The current survey covers publications from January 2019 to April 2026. The lower bound reflects the period when smart contract platforms with sufficient expressiveness for non-trivial agent logic became widely available; the bulk of relevant work appears from 2022 onward, coinciding with the maturation of Layer 2 infrastructure and the first production deployments of autonomous on-chain agents.

We searched four databases: IEEE Xplore, the ACM Digital Library, Scopus, and arXiv. Search strings combined blockchain or distributed ledger with multi-agent system, autonomous agent, or AI agent, paired with at least one of coordination, governance, smart contract, or reinforcement learning. We additionally conducted targeted searches for deployed systems by name (e.g., Autonolas, Fetch.ai, SingularityNET, Giza, Bacalhau) and included technical documentation and whitepapers where peer-reviewed coverage was absent but the system was substantive enough to warrant inclusion.

Initial search resulted in 463 records across the four databases: 51 from IEEE Xplore (two query passes), 102 from the ACM Digital Library, 307 from Scopus, and 3 from arXiv. After removing 44 duplicates, 419 records remained for title and abstract screening. The relatively low cross-database overlap reflects the fact that the four queries used substantially different syntax to work around each database’s proprietary search grammar, producing partially non-overlapping result sets despite targeting the same conceptual intersection. Papers were excluded if they used agent purely in the economic rationality sense without any computational agent behaviour, if blockchain and AI appeared in unrelated sections of the same paper without integration, or if they were workshop papers under four pages without a corresponding full publication. Of the 187 records assessed at full text, 177 peer-reviewed publications met all three inclusion conditions. The final corpus comprises these 177 publications and 14 system documentation sources. The PRISMA flow diagram summarising the selection process is shown in Figure 1. Full search strings, inclusion and exclusion criteria, and coding rules are provided in Appendix A.

Figure 1. PRISMA 2020 [32] flow diagram. Of 463 identified records, 419 remained after removing 44 duplicates; 177 peer-reviewed publications met the inclusion criteria alongside 14 documentation sources (total: 191).

3. Architectures for Decentralized AI Agents

This section organises the architectural space along a single axis: where the agent’s computation runs and what guarantees that gives about its behaviour. Four patterns emerge from the literature. On-chain execution places all agent logic inside a smart contract, making behaviour verifiable by construction but severely constrained by gas metering and the absence of floating-point arithmetic. Off-chain agents with on-chain settlement remove the computation constraint at the cost of verifiability, relying instead on economic mechanisms and reputational accountability. Verifiable off-chain computation, attempts to recover some verification guarantees without returning to on-chain execution. Multi-agent systems introduce coordination structures on top of any single-agent architecture, with shared contract state and atomic transaction pipelines as the distinguishing properties.

Figure 2 shows how these components fit together in a complete system, from external data sources through oracle and bridge layers to the AI agent core, and from there through the blockchain layer to verification, coordination, and governance.

Figure 2. High Level architecture of a decentralised AI agent system across six layers: external data, oracle/bridge, AI agent core (RL/MARL, LLM, rule-based, ERC-4337), blockchain, verification, and coordination/governance. Dashed blue arrows = data reads; solid green = transaction settlement; dashed coral = governance control.

3.1. On-Chain Execution Architectures

The simplest architectural pattern places all agent logic inside a smart contract. The agent’s policy is encoded as contract code; it executes whenever triggered by a transaction or an on-chain event, reads state from the chain, and writes its output back as a state transition. No off-chain component is required.

The appeal is verifiability. Because the computation runs inside the EVM or an equivalent runtime, every step is reproducible by any node in the network. The agent’s behaviour is auditable in principle by anyone with access to the contract bytecode and transaction history. In decentralised systems where counterparties cannot be assumed to trust each other, this property has real practical value that more capable off-chain architectures cannot easily replicate.

The constraints are severe. EVM computation is metered by gas, capping the complexity of logic that can run in a single transaction. As of 2024, the Ethereum mainnet block gas limit permits approximately 30 million gas units per block, sufficient for arithmetic, storage reads, and simple conditional branches, but not for floating-point inference over a neural network of any practical size [33]. Contract storage is also expensive; reading a 32-byte word costs 2100 gas cold and writing costs 20,000 gas [34]. Agents that need to maintain large learned state across interactions will find this cost structure prohibitive. Native randomness is unavailable without an external oracle, which rules out stochastic policies unless the randomness source is brought on-chain through a verifiable random function such as Chainlink VRF [35].

The systems that operate within these constraints are not trivial, but they are rule-based, not adaptive. Automated market makers such as Uniswap v3 [36] implement concentrated liquidity algorithms entirely on-chain, adjusting price ranges and fee tiers through contract logic that responds to swap activity. Liquidation agents in lending protocols such as Aave [37] and Compound [38] monitor collateral ratios and execute liquidations when thresholds are crossed, with trigger logic encoded in the contract and execution incentivised by liquidation bonuses paid to the calling account. MakerDAO’s keeper system [39] follows the same pattern for collateral auctions. These agents are operationally and economically autonomous, but their policies are fixed at deployment. On-chain execution architectures are therefore best understood as the home of threshold-based and rule-based agents. Work on bringing ML inference on-chain through zero-knowledge proofs is at an early stage and is discussed in Section 3.3.

Beyond purely financial applications, on-chain logic has been applied to blockchain network management itself. Skowroński [40] demonstrates a DRL agent that adapts mining threat mitigation in proof-of-work chains, encoding detection logic in smart contract state transitions. Chitra et al. [41] use agent-based simulation to model the incentive dynamics of blockchain consensus protocols at the network level, showing that individually rational agents can produce system-level instabilities not predicted by static game-theoretic analysis. On the permissioned side, Li et al. [42] and Zhang and Chen [43] address parameter tuning for Hyperledger Fabric and similar systems through RL agents that observe throughput and latency metrics and adjust block size, endorsement policy, and batching parameters on-chain. Halasz et al. [44] formalise the trust requirements for Smart Agents executed on-chain to coordinate autonomous systems in Smart Cities, proposing a blockchain-enforced execution substrate as the mechanism for guaranteeing coordination safety properties.

3.2. Off-Chain Agents with On-Chain Settlement

The dominant architectural pattern in deployed systems separates reasoning from settlement. The agent runs off-chain, such as on a conventional server, a containerised cloud process, or edge hardware, and commits only its outputs to the chain; a signed transaction, a service delivery attestation, a state update, or a governance vote.

This pattern removes the computation constraint. Off-chain, an agent can run inference on arbitrarily large models, maintain rich learned state, and act at sub-second latency. The cost is verifiability. No network node can confirm that the off-chain computation was performed correctly, by the declared agent, or at all. Trust in agent behaviour is currently mediated by one of three mechanisms: the deployer’s reputation, a staking and slashing arrangement that makes misbehaviour financially costly, or monitoring by a third-party watchdog agent. None of these is a cryptographic guarantee.

The pattern subdivides by how the off-chain agent interfaces with the chain. In the event-driven variant, the agent subscribes to on-chain events, including a new block, a price crossing a threshold, or a task posted to a registry contract, and responds by submitting a transaction. Keeper networks, standardised by Chainlink Keepers [45] and Gelato [46], formalise this pattern: a set of registered off-chain agents compete to respond to trigger conditions, with rewards paid to the first valid responder. The competitive structure incentivises low-latency infrastructure, which suits reactive applications but tends to produce redundant computation when multiple agents race for the same trigger.

In the strategy vault variant, common in DeFi, the agent implements a long-running investment or rebalancing strategy. It reads on-chain prices and balances, computes an allocation off-chain (using optimisation, RL, or a rule set) and executes rebalancing through on-chain transactions. Yearn Finance vaults [47] are the most widely deployed example, though their strategy logic is rule-based; several subsequent systems have replaced the rule layer with trained RL policies [48]. The agent’s off-chain computation is opaque to the chain; its correctness is assessed retrospectively through the vault’s on-chain performance record.

LLM-based agents with wallet signers represent a newer instance of the same pattern. The agent uses a language model to plan and reason (interpreting task descriptions, decomposing goals, selecting tools) and executes on-chain actions through a connected wallet. Autonolas [1] and Fetch.ai [2] provide production frameworks for agents of this type, with identity registered on-chain and inter-agent communication handled through a combination of on-chain registries and off-chain messaging. The language model introduces non-determinism absent from rule-based or RL agents: two invocations with the same input may produce different outputs, which complicates any form of post-hoc audit.

A concern specific to this pattern is front-running. When an agent’s intended transaction is visible in the mempool before block inclusion, other agents can observe it and submit competing transactions with higher gas fees to execute first. This is the basis of the maximal extractable value (MEV) problem [49]. It affects any off-chain agent whose strategy depends on relative execution order. Mitigations include private transaction relays such as Flashbots Protect [50], commit-reveal schemes, and threshold encryption of transaction content, each with different latency and complexity trade-offs.

The off-chain agent with on-chain settlement pattern appears across a wide range of application domains in the corpus, and its prevalence is not uniform. Energy systems account for the largest single cluster. Shen et al. [51] established the foundational pattern for peer-to-peer microgrid trading: a DRL agent computes allocation decisions off-chain and commits settlement transactions to a permissioned blockchain, using the ledger for auditability and dispute resolution, not computation. Subsequent work has extended this to more complex market structures, including multi-party demand response [52] and cross-border prosumer coordination [53], but the architectural template has remained stable: off-chain policy, on-chain settlement, staking for compliance enforcement.

Resource allocation in mobile edge computing and UAV networks forms the second major cluster. The common structure is an off-chain MARL system whose joint policy is trained centrally on historical chain data, with individual agents executing at edge nodes and committing resource allocation decisions through smart contract escrow. Seid et al. [54] provide a representative example in 5G-RAN, and the same architecture recurs in multi-domain 6G networks [55] and multi-UAV task offloading [56]. The use of smart contract escrow for payment is the key difference from conventional MARL: it removes the need to trust the resource provider to execute and pay correctly, which matters when participants are from different organisations or administrative domains.

Blockchain network self-management is a smaller but analytically distinct sub-pattern. Here the agent’s environment is the chain: Li et al. [42] deploy an RL agent that observes Hyperledger Fabric telemetry and adjusts block size and endorsement policy through governance transactions, while Xing [57] applies the same approach to permissionless sharding reconfiguration. The feedback loop between agent and environment is tighter than in any other application cluster; the agent modifies the infrastructure it runs on, which introduces stability considerations not present in external control applications.

Vehicular and IoT deployments follow the same off-chain/on-chain split, primarily for path planning, caching, and task offloading [58,59,60], with blockchain providing cross-organisational settlement and tamper-evident logging. The Davarakis et al. system [61] is notable for making the coupling explicit: an RL agent’s state space, action space, and reward signal are all defined by on-chain contract state, so the blockchain is the environment in which the agent operates, not just a settlement layer.

3.3. Verifiable Off-Chain Computation

The architectural gap between on-chain and off-chain patterns is a trust gap. On-chain execution is verifiable by construction; off-chain execution is trusted by necessity. Closing this gap without requiring the agent’s computation to run inside the EVM has been attempted through zero-knowledge proofs, trusted hardware, and optimistic dispute mechanisms.

Zero-knowledge machine learning (ZKML) applies zero-knowledge proof systems to ML inference, producing a proof that a given model was evaluated correctly on a given input without revealing model weights or intermediate computation. The verifier, typically a smart contract, checks the proof rather than re-running the inference. Giza [4] and EZKL [62] are the main production-oriented implementations; both target the STARK proof system for its transparency and avoidance of a trusted setup. Modulus Labs [63] benchmarked proving cost across a range of model sizes and found that a 2.8-million-parameter model required approximately 2.5 min of proving time on a high-end GPU, with proof size on the order of a few hundred kilobytes. Proving time scales poorly with model size under current circuit compilation approaches, which limits ZKML to small models (e.g., classifiers, price predictors, lightweight policy networks). It is currently most plausible for verifying constrained RL policies, not LLM-based agents, where model size is orders of magnitude larger.

Trusted execution environments (TEEs) take a hardware-level approach. A TEE (e.g., Intel SGX, AMD SEV, or ARM TrustZone) is a hardware-isolated compute region where code runs in a protected enclave, shielded from the host operating system. Remote attestation allows an external verifier to confirm that a specific program is running inside a genuine TEE on unmodified hardware [64]. Applied to agent systems, an on-chain contract can receive a hardware-signed attestation that an off-chain agent ran a declared policy without interference. TEEs are computationally capable enough to run substantial ML inference, and the trust assumption shifts from the software deployer to the hardware manufacturer; a narrower surface, though not an unconditional one. Several oracle networks have adopted TEE-based computation for sensitive data feeds [19]. Known side-channel vulnerabilities in Intel SGX, including Spectre and Foreshadow, have been disclosed and partially mitigated, but the hardware trust assumption remains a point of concern for high-stakes agent deployments [65].

Optimistic verification does not attempt to prove correct computation upfront. It assumes the computation is correct and allows a challenge window during which any party can submit a fraud proof. If no valid challenge arrives before the window closes, the result is accepted. This mechanism underlies Arbitrum’s dispute resolution [8] and has been proposed for general off-chain computation by Truebit [66] and for agent-specific workloads by Cartesi [67]. The latency cost is the challenge window, typically several days on current deployments. Optimistic verification is unsuitable for time-sensitive agent actions but appropriate where finality can be deferred: batch settlement, periodic re-balancing, and governance proposal evaluation.

The security of smart contracts as execution environments for agent logic has received growing attention as an adjacent verification problem. Andrijasa et al. [68] survey the application of multi-agent Deep Reinforcement Learning (DRL) to smart contract fuzzing, in which agents act as adversarial testers probing contract logic for re-entrancy and integer overflow vulnerabilities. This is a case where the blockchain is the subject of verification rather than the verifier; agents act off-chain to find failures in on-chain code. Phiri [69] formalises eight auditability axioms for agentic AI systems, including integrity, temporal coherence, and attribution, and proposes blockchain as the natural substrate for satisfying them, since immutable transaction logs provide the permanent, tamper-evident record that auditability requires. Yoo et al. [70] address a related gap in federated learning pipelines, where off-chain agent contributions must be attributed and verified for incentive purposes, and propose a DLT-based credentialing architecture that provides verifiable agent identity without requiring full ZK proofs.

Table 1 summarises the three approaches across the dimensions most relevant to agent design.

Table 1. Comparison of verification approaches for off-chain agent computation (production deployment status as of April 2026). Proof latency: time to generate the verification artefact; Settlement latency: time until on-chain acceptance. For ZKML these two quantities can differ by orders of magnitude.

Approach	Comp. Overhead	Model Size	Proof Latency	Settlement Latency	Trust
ZKML	Very high	Small only	Seconds–minutes	Seconds	Cryptographic
TEE	Low	Moderate–large	Milliseconds	Seconds	Hardware mfr.
Optimistic	Low	Arbitrary	None (assumed)	Days	Economic

3.4. Multi-Agent Systems On-Chain

The preceding subsections treat agents in isolation. Many deployed and proposed systems involve multiple agents, interacting competitively, cooperatively, or both. The on-chain environment creates coordination properties that do not exist in conventional multi-agent systems; agents can read shared contract state atomically, commit to actions in a verifiable and binding way, and transfer value without a trusted intermediary.

Agent registries are the entry point for most multi-agent deployments. An on-chain registry records each agent’s identifier, declared capabilities, service endpoint, and staking position, giving other agents and clients a verifiable directory from which to discover counterparties. Fetch.ai’s Almanac contract [2] and the Autonolas service registry [1] are the most widely deployed examples. The registry pattern creates a first coordination layer: agents announce their capabilities, and other agents or contracts query this without relying on a centralised directory operator.

Task markets extend this by providing a protocol for agents to post work, receive bids from other agents, and settle payment on verified delivery. A requesting agent specifies a task and a payment ceiling; bidding agents submit offers; the contract awards the task and holds payment in escrow until the task output is submitted and verified. Bacalhau [71] implements this pattern for distributed computation tasks, with a network of worker agents bidding to execute jobs posted by client agents. The verification step varies by implementation: some systems use cryptographic output hashes, others use optimistic challenge periods, and some rely on reputation scores accumulated over prior interactions.

Multi-agent pipelines, where the output of one agent feeds the next, appear in DeFi sequential strategy execution and in agent service frameworks where an LLM planner delegates subtasks to specialised execution agents. On-chain, a pipeline can be encoded as a sequence of contract calls within a single transaction, giving it atomicity: either all steps complete or none do. This guarantee, unavailable in conventional multi-agent middleware without a trusted coordinator, is one of the more useful structural properties the blockchain environment provides. The cost is gas; each step adds to the transaction cost, and long pipelines require careful budgeting even on Layer 2 networks.

MARL in shared on-chain environments has properties that distinguish it from standard simulation-based MARL. The environment state, including contract balances, oracle prices, and pending transactions, is observable by all agents simultaneously and without additional cost, removing one common source of partial observability. At the same time, the block-by-block time structure means agents cannot act continuously: they submit transactions during a block and observe outcomes only after the block finalises. Chain reorganisations, where a confirmed block is replaced by a competing fork, introduce environment non-stationarity with no equivalent in simulation. The implications for MARL convergence are examined in Section 7.

The corpus contains several multi-agent architectures that extend the patterns above. Yang et al. [72] propose a general smart agent architecture on Ethereum in which agent logic is decomposed into modular on-chain components, establishing an early template for how classical MAS design patterns translate into the EVM environment. At the other end of the complexity spectrum, Chen et al. [73] build AgentChain, a blockchain-coordinated LLM multi-agent system for trustworthy question-answering, in which blockchain enforces attribution and tamper-evidence across agent contributions. The LearnChain system [74] is notable for its explicit treatment of cooperative RL on-chain: agents share learning updates via smart contracts, using blockchain both to coordinate training and to create an auditable record of each agent’s contribution to the joint policy. ManuChain II [75] and the blockchained smart contract system of Leng et al. [76] demonstrate Multi-Agent Systems (MAS) coordination for manufacturing pipelines, where smart contract pyramids encode hierarchical process control with verifiable state transitions. Smart contract security in MAS contexts is addressed by Praitheeshan et al. [77], whose SolGuard system detects external call vulnerabilities in multi-agent robotic systems that use smart contracts as coordination middleware. Pakana [78] takes a semantic approach, proposing that smart contracts can serve as semantic signalling mechanisms for AI agents, enabling interoperability across heterogeneous agent platforms without requiring shared representation formats.

3.5. Summary Taxonomy

Table 2 classifies the systems discussed in Section 3 along four dimensions: execution locus, verification mechanism, learning paradigm, and coordination protocol. These dimensions are not fully independent; execution locus constrains verification options, and the learning paradigm constrains viable coordination protocols. Treating them separately, however, still supports comparison across systems that differ along multiple axes simultaneously.

Table 2. Taxonomy of representative decentralised AI agent systems (selected). Rule-based systems are lower-boundary reference points. Coord. = coordination; n/a = not applicable.

System	Execution Locus	Verification	Learning	Coord.
Uniswap v3 [36]	On-chain	Chain consensus	Rule-based	n/a
Aave liquidator [37]	Off-chain + settle	Trusted deployer	Rule-based	Token incentive
Compound [38]	Off-chain + settle	Trusted deployer	Rule-based	Token incentive
Yearn vault [47]	Off-chain + settle	Trusted deployer	Rule-based/RL	Token incentive
Yang et al. [72]	On-chain	Chain consensus	Rule-based	n/a
SquirRL [79]	Off-chain + settle	Trusted deployer	RL	n/a
Nguyen et al. [15]	Off-chain + settle	Trusted deployer	MARL	Auction
Chainlink Keepers [45]	Off-chain + settle	Trusted + staking	Rule-based	Auction
Gelato [46]	Off-chain + settle	Trusted + staking	Rule-based	Auction
Fetch.ai [2]	Off-chain + settle	Staking	RL/LLM	Auction
Autonolas [1]	Off-chain + settle	Staking	LLM/hybrid	Auction + token
SingularityNET [3]	Off-chain + settle	Reputation + staking	Various	Token incentive
Bacalhau [71]	Off-chain + settle	Optimistic	Various	Auction
Giza [4]	Verifiable (ZK)	ZK proof	RL/supervised	n/a
TEE oracle [64]	Verifiable (TEE)	TEE attestation	Rule-based	Token incentive
Davarakis et al. [61]	Off-chain + settle	Trusted deployer	RL	Token incentive
Seid et al. [54]	Off-chain + settle	Staking	MARL	Auction
APOLLO [80]	Off-chain + settle	Staking + on-chain	RL	Token incentive
LearnChain [74]	Off-chain + settle	On-chain log	Cooperative RL	Token incentive
AgentChain [73]	Off-chain + settle	On-chain log	LLM multi-agent	Token incentive

The taxonomy supports a few observations. The verification column is dominated by trusted deployer and staking entries, reflecting the current gap between the verifiability ideal and the practical cost of cryptographic alternatives. Coordination protocols are also absent from most on-chain and verifiable off-chain systems; multi-agent coordination is predominantly an off-chain concern settled on-chain. Learning paradigm diversity, meanwhile, is concentrated in off-chain systems; on-chain agents are almost entirely rule-based, for the reasons given in Section 3.1.

A caveat on orthogonality: the four dimensions in Table 2 are analytically distinct but not fully independent in practice. The verification mechanism is constrained by the execution locus: on-chain execution implies chain consensus verification by construction, while off-chain execution admits the full range of verification options. The coordination protocol is constrained by both: token incentive mechanisms require on-chain settlement, while gossip-based coordination can operate independently of the chain. Several systems in the corpus occupy ambiguous positions. Fetch.ai’s architecture spans off-chain execution and on-chain settlement with both staking-based and auction-based coordination components, making single-column classification an oversimplification. Autonolas similarly combines staking, on-chain logging, and auction mechanisms in a layered stack. The entries in Table 2 reflect the dominant or most distinctive property of each system, not its full architectural description.

4. Coordination Mechanisms

Coordinating decentralised AI agents across a shared blockchain infrastructure requires resolving a set of problems that do not arise in conventional distributed systems. Agents must allocate tasks, enforce compliance, and adapt to changing conditions, all without a trusted central authority, and within the hard constraints that on-chain execution imposes; transaction costs limit interaction frequency, block-time discretisation breaks the synchrony assumptions underlying standard coordination theory, and smart contract logic must be self-enforcing by construction. This section examines four coordination mechanisms through which deployed systems have addressed these problems: auction-based task allocation, multi-agent reinforcement learning, token incentive design, and federated or gossip-based coordination. The four are not alternatives in the strict sense; production systems typically combine elements from more than one. The analysis in the current section proceeds mechanism by mechanism while Section 4.4 draws a comparative assessment across communication overhead, trust assumptions, incentive alignment, and latency tolerance.

4.1. Auction-Based Coordination

Auctions are a natural fit for on-chain task allocation. A requesting agent posts a task specification and a payment ceiling to a contract; candidate agents bid to fulfil it; the contract clears the auction and holds payment in escrow until verified delivery. The entire protocol executes without a trusted auctioneer, which is the primary reason auction mechanisms have become the most common coordination pattern in agent task markets.

The choice of auction format has consequences beyond price discovery. First-price sealed-bid auctions, where the winning bidder pays their bid, are simple to implement but incentivise bid shading: agents submit offers below their true valuations to preserve surplus, and the resulting equilibrium is allocatively inefficient. Second-price (Vickrey) auctions recover truthful bidding as a dominant strategy, since the winner pays only the second-highest bid [81]. The Vickrey–Clarke–Groves (VCG) mechanism generalises this to multiple simultaneous items and combinatorial bidding, achieving allocative efficiency and incentive compatibility under quasi-linear preferences [82,83]. On-chain VCG implementation is constrained by gas: clearing a combinatorial VCG auction is NP-hard in general, and even polynomial-time approximations become expensive at scale. Current implementations either restrict the combinatorial structure to single-minded bidders or process auction clearing off-chain and commit only the result to the chain, trading verifiability for tractability.

English auctions (ascending price with open bids) sidestep this complexity and map naturally to the block-time structure. Bids are submitted in successive blocks; the auction closes when no higher bid arrives within a timeout. MakerDAO’s collateral auctions [39] use this format. Dutch auctions (descending price) are used in contexts where settlement speed matters more than revenue maximisation, including several DeFi liquidation mechanisms.

A subtler problem in on-chain combinatorial auctions is the exposure problem [84]: an agent bidding on a bundle of complementary tasks may win only a subset, leaving it holding items of lower value than it paid. Two concrete smart-contract patterns address this, each with distinct gas and latency trade-offs.

The first is conditional batch settlement. All bids are collected in a commitment round spanning one or more blocks; the contract then clears all bids atomically in a single settlement transaction, either awarding the full bundle or rejecting it entirely. Because clearing logic runs on-chain, it is verifiable and tamper-evident. The cost is gas: clearing even a modestly sized combinatorial auction (e.g., 20 tasks, 10 agents) can consume 2–5 million gas units in a single transaction [85], approaching 10–20% of Ethereum’s mainnet block gas limit. This restricts the mechanism to small auctions or to Layer 2 networks where gas is cheaper by one to two orders of magnitude. The latency to settlement is bounded by the commitment round length plus one block for clearing, typically 15–60 s on current Layer 2 deployments.

The second pattern is escrow with conditional release. Each bid is submitted as a separate transaction locking the bid value in an escrow contract; a separate resolution contract aggregates outcomes and releases funds only when the full bundle condition is satisfied. This spreads gas cost across multiple transactions and avoids the block gas limit ceiling, but introduces a window between individual bid submission and bundle resolution during which an agent’s funds are locked and unavailable. The window can span multiple blocks, creating latency of 30 s to several minutes depending on network congestion. Front-running during this window is a real attack surface: an adversary who observes partial bids in the mempool can submit competing bids to disrupt bundle formation before the resolution contract executes [86].

4.2. Multi-Agent Reinforcement Learning

MARL in blockchain environments inherits the standard challenges of the field and adds several that are specific to the execution context. Standard MARL settings assume agents observe the environment and act at a fixed frequency, the environment transitions on all agents’ joint actions, and rewards are delivered at each step. None of these assumptions holds cleanly on-chain.

Block time introduces discrete, variable-length intervals: agents submit transactions during a block and observe outcomes only at finalisation, typically every 2–12 s depending on the network. Between blocks, no action is possible. This turns the MARL problem into an asynchronous repeated game with variable delays rather than a standard Markov game. Convergence proofs for CTDE algorithms such as QMIX [26] and MADDPG [27] assume synchronous step transitions; their validity under block-time discretisation is an open question addressed in Section 7.

Non-stationarity in blockchain MARL takes two distinct forms that should not be conflated. The first is agent-induced non-stationarity: the standard MARL problem where the environment each agent faces changes because other agents are learning concurrently. CTDE partially addresses this by conditioning on joint information during training while restricting agents to local observations at execution time. In blockchain environments, joint information is available directly from chain state, which is public and consistent across all participants, so CTDE training can use verified on-chain data rather than reconstructed joint state, a genuine advantage over partially observable simulation environments. The second form is environment-induced non-stationarity from chain reorganisations: recently finalised blocks are replaced by competing forks, retroactively changing the state that agents observed and acted on. This source of non-stationarity is qualitatively different from the first and is not addressed by CTDE or by any existing asynchronous MARL approach. Its implications for convergence are discussed in Section 7.

The severity of environment-induced non-stationarity depends critically on the consensus mechanism’s finality model. Nakamoto-style consensus (used by Bitcoin and pre-Merge Ethereum) achieves only probabilistic finality: a block is considered final after a sufficient number of successor blocks build on it, but this guarantee is statistical rather than absolute, and deep reorganisations remain possible in theory. Under Nakamoto consensus, an agent must treat any recently observed state as potentially reversible, which requires either deferring action until sufficient confirmations accumulate (adding latency of minutes to hours) or accepting that some fraction of committed actions may be retroactively undone. Tendermint-style Byzantine Fault Tolerant (BFT) consensus (used by Cosmos, Hyperledger Fabric, and similar systems) achieves deterministic finality within a single round: once a block is committed, it cannot be reorganised. For MARL agents, this eliminates environment-induced non-stationarity entirely. The state observed after block commitment is guaranteed to persist. The trade-off is throughput and decentralisation: BFT consensus requires $O\left(n^2\right)$ message complexity and a known, bounded validator set, which limits the number of participants and introduces a different trust surface. Ethereum post-Merge occupies a middle position: its PoS consensus achieves economic finality after approximately 12.8 min (two epochs), providing a much smaller reorganisation window than Nakamoto consensus but stopping short of the single-round finality guarantee of BFT protocols. System designers choosing a blockchain substrate for MARL agent deployment should treat the finality model as a primary design parameter: BFT chains are preferable where convergence guarantees are required; Nakamoto chains require agents to be designed with explicit state-reversal tolerance.

Token-denominated rewards introduce a property absent from simulation-based MARL: the reward function is on-chain and verifiable. An agent’s reward is a token transfer recorded on the ledger, so reward disputes can be adjudicated by the contract rather than by the system designer. Reward hacking takes the form of on-chain manipulation instead of simulation artefacts, which means it produces real transactions with real economic consequences—a deterrent that simulation environments cannot replicate.

Credit assignment in cooperative MARL maps directly onto an economic problem in token-incentivised systems. When a group of agents jointly produces an outcome, the contract must distribute payment in proportion to each agent’s marginal contribution. The Shapley value [87] provides a theoretically grounded attribution, but its exact computation is exponential in the number of agents. Practical systems use approximations or restrict contribution structures to admit simpler attribution rules, accepting some fairness loss in exchange for on-chain tractability.

The surveyed corpus contains a large and growing body of MARL deployments in blockchain-enabled distributed systems. Energy is the dominant application domain: studies address peer-to-peer microgrid trading [51,53,88,89], demand response [52,90,91,92,93], vehicle-to-grid coordination [94], and virtual power plant operation [95], with MADDPG and QMIX the most frequently used algorithms. Task offloading in mobile edge and UAV networks is the second largest cluster [15,56,96,97,98,99,100,101], sharing the architectural pattern of centralised training on historical chain data followed by decentralised execution at edge nodes. Consensus mechanism design using MARL is a smaller but distinct category: Islam et al. [102] propose MRL-PoS, a MARL-based proof-of-stake consensus algorithm in which validators learn bidding strategies, and Bappy et al. [103] apply MARL to detecting and mitigating malicious nodes in PoS chains. Cross-chain optimisation using MARL is addressed by Daliri and Jassbi [104], who propose a customised multi-agent architecture that handles heterogeneous blockchain networks with different consensus rules and latencies, providing one of the few empirical treatments of the cross-chain coordination problem identified in Section 7.

Token incentives are the primary coordination tool in decentralised agent systems where cryptographic guarantees are absent or too costly to compute. Rather than proving correct behaviour, token mechanisms impose a financial cost on misbehaviour and a financial reward on correct behaviour, relying on the assumption that agents are rational and will not deviate when the expected penalty exceeds the expected gain.

Staking and slashing form the core of this approach. An agent deposits tokens into a contract as collateral before participating in the system. If a verifiable protocol violation is subsequently detected, such as signing two conflicting messages, missing a required response window, or submitting an output that fails an on-chain check, the contract destroys some or all of the deposit. The deterrence effect depends on three parameters: the stake size relative to the gain from misbehaviour, the probability of detection, and the opportunity cost of capital locked as collateral. Systems where misbehaviour is hard to detect, or where the gain from a single deviation exceeds the stake, will experience equilibrium violation despite the mechanism.

Reputation tokens accumulate from past behaviour and provide a longer-horizon coordination substrate. Non-transferable reputation tokens (e.g., soulbound tokens [105]) cannot be purchased, meaning they track actual agent history, not financial position. Token-Curated Registries (TCRs) [106] extend this by allowing any participant to challenge a registry entry by staking tokens on the challenge, with disputes resolved through a vote weighted by stake. The result is a decentralised quality filter in which participants with accurate judgement about registry quality are financially rewarded.

A structural tension in token mechanism design is Goodhart’s Law [107]: when a measurable outcome becomes the reward target, agents optimise for the measure rather than the underlying objective. In agent systems this appears concretely. An agent rewarded for transaction volume will submit low-value transactions. One rewarded for uptime will remain online without performing useful work. Mechanism design responses, namely output-based bonding, mutual monitoring, and commit-reveal schemes that tie rewards to ex-post verified outcomes, are an active research area [108] with direct implications for how agent systems are designed in practice.

Tian [109] provides an empirical treatment of incentive-compatible mechanism design for MARL systems specifically, demonstrating that misalignment between token reward structures and agent learning objectives produces predictable exploitation patterns. Tang et al. [110] show that proof-of-stake incentive structures can be adapted to reward data collection agents in UAV-IoT systems, using staking as both a commitment device and a quality signal. Fernandez et al. [111] use agent-based simulation to analyse how initial token distribution policies in post-fair-launch blockchain networks affect long-term governance concentration; an important empirical input for the governance analysis in Section 5. Park et al. [112] extend this to show that blockchain token economics can inadvertently amplify economic inequality among network participants, with implications for the design of agent incentive structures in public protocols.

4.3. Federated and Gossip-Based Coordination

Not all coordination requires on-chain settlement. Where transaction costs or latency make frequent on-chain interaction impractical, agents coordinate through peer-to-peer messaging and commit only final outcomes to the chain.

Gossip protocols, the communication substrate of most peer-to-peer blockchain networks, propagate messages across a node network without centralised routing. Each node forwards received messages to a random subset of its peers; information reaches the full network in $\mathcal{O}(logn)$ steps with high probability [113]. Fetch.ai’s agent messaging layer [2] and the libp2p stack used by Autonolas [1] both rely on gossip for agent-to-agent communication, with on-chain contracts handling only task posting, payment escrow, and dispute resolution. This keeps the bulk of coordination traffic off-chain while preserving verifiable settlement.

State channels allow two or more agents to conduct an arbitrarily long sequence of interactions off-chain, with the blockchain serving as a court of last resort. Agents open a channel by depositing funds into a contract, exchange signed state updates off-chain at will, and close the channel by submitting the final agreed state. Any party can challenge the closing state by submitting a more recent signed update during a dispute window. The result is near-instant finality and zero gas cost for all intermediate interactions. The Lightning Network [114] established this pattern for payment channels; generalised state channels [115] extend it to arbitrary agent computation. For agent pairs that interact frequently (e.g., a planning agent and a designated execution agent) state channels reduce coordination cost by orders of magnitude relative to on-chain settlement of each step.

Federated learning with blockchain coordinates the specific case where agents need to train a shared model without sharing raw data [116]. Each agent trains locally and submits model updates to an aggregation contract; the contract records contributions and distributes token rewards proportional to update quality. The blockchain role is audit and incentive, not computation. Byzantine fault tolerance for federated learning under adversarial agents [117] applies here, with the additional property that the on-chain reward mechanism creates a financial incentive for honest gradient submission that pure federated learning frameworks lack.

The corpus contains several substantive implementations of blockchain-federated coordination. Chen et al. [118] develop BELIEFS, a blockchain-based federated intelligence system that combines attack-tolerant aggregation with on-chain reward distribution. Liu et al. [119] address the privacy and incentive dimensions jointly in a P2P energy trading system, using MADDPG with federated training and blockchain settlement to protect prosumer data while aligning contribution incentives. Wang et al. [120] extend this to asynchronous settings, where agents train on locally cached IoT data and commit updates at variable intervals, using blockchain to manage staleness and attribution without a central aggregator. Chai et al. [121] address the edge intelligence case, coordinating decentralised edge nodes through a blockchain-incentivised federated optimisation protocol with adaptive contribution weighting. Sankaran et al. [122] apply federated MARL to the blockchain consensus problem itself, demonstrating that the training and execution separation native to FL maps naturally onto permissioned blockchain governance where nodes cannot share raw state.

Decentralised AI agents use three distinct communication modes whose timing and cost profiles differ substantially. Table 3 summarises the key properties. State reads are the most frequent operation: an agent may query chain state hundreds of times per second at zero cost. Settlement transactions are comparatively rare but are the only mode that produces binding, cryptographically final outcomes. Gossip communication is used for high-frequency peer coordination where on-chain cost would be prohibitive, but any outcome that must be binding requires a subsequent settlement transaction.

Table 3. Comparison of the three communication modes available to decentralised AI agents.

Mode	Latency	Gas Cost	Finality	Typical Use
State read (eth_call)	10–50 ms (L2: <5 ms)	None	None (read-only)	Observe prices, balances, contract state before acting
Tx settlement	L1: ∼12 s/block; L2: 0.25–2 s	Yes (variable)	Cryptographic; block-time dependent	Commit bids, transfer assets, trigger contract logic
Gossip/P2P	1–200 ms	None	None; requires on-chain settlement for binding outcome	Coordinate off-chain, share observations, negotiate

4.4. Comparative Analysis

Table 4 compares the four coordination mechanisms described in the previous subsections, across five dimensions. Communication overhead refers to the volume of on-chain or off-chain messages required per coordination episode. Latency tolerance indicates how sensitive the mechanism is to block-time delays and network latency. Incentive alignment strength reflects how well the mechanism’s reward structure tracks the designer’s intended objective under rational agent behaviour. The ratings reflect the authors’ assessment of typical behaviour based on the surveyed literature. They are not derived from formal measurement; read them as a structured qualitative summary, not as empirical findings, drawn from the deployment classes described in Section 4.1, Section 4.2 and Section 4.3. Specific implementations may differ depending on mechanism design choices.

Table 4. Qualitative comparison of coordination mechanisms, synthesised from the surveyed literature. Ratings reflect typical behaviour and should not be interpreted as universal properties.

Mechanism	Comm. Overhead	Trust Assumption	Incentive Alignment	Latency Tolerance
Auction	Low (on-chain only)	Contract logic	High for allocation; weak for compliance	Low (block time bound)
MARL	High (training)	Shared policy	High; adaptive over time	Medium
Token incentive	Low	Economic	Medium; Goodhart risk	High
Gossip/channel	Very low	Off-chain peer	Low; no on-chain enforcement	Very high

The comparison supports a few observations. Auction-based and token-based mechanisms are complementary: auctions handle task allocation, while token mechanisms handle compliance enforcement, and most production systems combine both. Gossip and state channel coordination substantially reduce on-chain cost but shift the trust surface to off-chain infrastructure; network partitions, messaging failures, and counterparty availability are not addressed by the on-chain components. And Multi-Agent Reinforcement Learning (MARL) stands apart as the only mechanism that produces agents capable of adapting their coordination behaviour over time; the remaining three fix the coordination protocol at design time and rely on agents to optimise within it. This distinction becomes consequential in environments where task distributions, agent populations, and resource availability shift over the system’s lifetime.

What the coordination analysis does not address is the question of legitimacy: whether the outcomes produced by these mechanisms are acceptable to the participants who did not design them, and whether the agents executing them can be held accountable when they are not. Token incentives can align individual behaviour with a specified objective, but they cannot by themselves determine whether that objective is the right one, who authorised it, or how it should change when circumstances shift. Auction mechanisms allocate tasks efficiently under their stated assumptions, but those assumptions are embedded in smart contract code by developers whose interests may diverge from those of the agents or users that the contract governs. MARL agents adapt their policies over time, raising the additional question of who monitors whether the adapted policy remains within acceptable bounds. These are governance questions, and they require a different analytical frame from the one used in Section 4. Section 5 examines that frame.

Table 5 makes the interdependencies across all three dimensions explicit. Each cell states a concrete constraint: given an architectural pattern, what coordination options are available, and what governance mechanisms are implicated? The choice of execution architecture forecloses some coordination and governance options while enabling others; the table does not assert that all combinations in a row are deployed together.

Table 5. Interaction constraints across the three analytical dimensions: how execution architecture limits available coordination mechanisms and governance options.

Architecture	Available Coordination	Verification	Governance Implications
On-chain execution	Auction, token incentive; no MARL (gas prohibits repeated inference)	Chain consensus (automatic)	Deactivation by contract upgrade; accountability clear (deployer); DAO can modify parameters on-chain
Off-chain + on-chain settlement	All four mechanisms; MARL feasible off-chain with on-chain reward	Trusted deployer or staking; ZK/TEE optional add-on	Accountability gap: deployer identifiable but policy evolution unaudited; dual agency problem arises; DAO governs parameters but not agent pipeline
Verifiable off-chain (ZK/TEE)	Auction, token; MARL possible but proof generation per step is expensive	Cryptographic (ZK) or hardware (TEE); proof covers computation, not policy identity for LLMs	Narrows accountability gap for fixed-weight models; LLM policy commitment remains open (see Section 7); regulatory auditability improved but not complete
Multi-agent on-chain	Auction, token, shared contract state; no MARL training (gas)	Chain consensus for all agents jointly; atomic composition verifiable	DAO governs shared registry and payment rules; emergent collusion visible on-chain but detection logic must be pre-specified in contract

5. Governance of Decentralized AI Agent Systems

Section 3 and Section 4 established how decentralised AI agents are built and how they coordinate. This section addresses a harder question: how are they governed, and by whom. The answer is incomplete in every domain examined. Section 5.1 frames the structural problem: the accountability gap that decentralised architectures produce by design. Section 5.2, Section 5.3, Section 5.4 and Section 5.5 examine the mechanisms that attempt to fill it, namely DAO-based governance, regulatory frameworks, incentive alignment, and organisational adoption conditions. Section 5.6 states the limitations of the present survey. Section 6 traces how these governance mechanisms play out across four application domains (decentralised finance, supply chain, agent marketplaces, and IoT) where the tensions between operational autonomy and governance accountability are most visible, closing with cross-domain observations drawn from the full corpus. Governance investment lags technical deployment throughout: the architectural choices made in Section 3 determine what an agent can do, and separately, what governance mechanisms are even available to constrain it.

5.1. The Governance Problem for Autonomous Agents

Governance of AI agents in decentralised systems splits into three overlapping problems. Governance of agents concerns who determines an agent’s objectives, constraints, and operating parameters, and who can modify or terminate its operation. Governance by agents concerns autonomous agents participating in governance processes, such as voting, proposing protocol changes, or managing treasuries, on behalf of token holders. Governance accountability concerns who bears legal and ethical responsibility when an agent causes harm, and through what mechanism redress is obtained.

Traditional software governance allocates accountability through a relatively clear chain. A developer writes code, an operator deploys it, a user interacts with it, and liability for harm flows upward through that chain according to established software and product liability frameworks [123]. Autonomous AI agents disrupt this chain on two axes simultaneously. Their behaviour is not fully predictable at deployment because a learning agent’s policy evolves through interaction, and an LLM-based agent’s outputs depend on prompts and contexts the deployer could not have anticipated. The deployer in a decentralised system, moreover, may not be a legal entity at all. A DAO that governs an agent fleet may have no registered legal domicile, no identifiable human controller, and no conventional enforcement surface. The code is law, but only in the sense that the code executes; it does not follow that the code is answerable.

The space between an agent’s actions and any identifiable responsible party is what we term the accountability gap. It surfaces wherever AI systems operate with significant autonomy, so the gap is not confined to blockchain systems, but it is especially acute in decentralised environments because the architectural property that removes the trusted intermediary also removes the natural locus of accountability. Organisations that deploy AI agents through DAOs are, in effect, externalising governance risk to a mechanism that was designed to resist central control, not to provide it.

From an information systems perspective, this creates what we term a governance vacuum: a multi-stakeholder system in which no participant has both the authority and the information necessary to govern the whole. The concept has antecedents in adjacent literatures. Matthias [124] identified a “responsibility gap” in autonomous systems where no human agent can be held accountable for machine behaviour. Danaher [125] extended this to algorithmic governance, Zittrain [126] described governance deficits in generative systems where downstream consequences exceed the original designer’s control. The governance vacuum described here is a specific instantiation of these ideas in which the gap is structurally reproduced by the architecture, not produced by regulatory lag or technological surprise: decentralisation deliberately removes the central authority that would otherwise be the natural target of governance obligations. Each stakeholder, including developers, token holders, agents, users, and regulators, holds a partial view and partial authority.

5.2. DAO-Based Governance of Agent Systems

DAOs represent the most developed attempt to fill the governance vacuum described in Section 5.1. They do so by encoding governance rules in smart contracts and distributing governance authority across token holders, removing the need for a central operator while maintaining the capacity to update system parameters. Applied to agent systems, DAO governance controls the parameters under which agents operate, the conditions for agent deactivation, and the distribution of agent-generated revenue.

The dominant mechanism is token-weighted voting; holders of a protocol’s governance token submit and vote on proposals that update contract parameters, allocate treasury funds, or modify protocol rules. Token-weighted voting has three well-documented structural failure modes. Participation rates in major DAO governance votes rarely exceed 10–20% of eligible tokens [127], producing decisions made by a small active minority that may not represent the full stakeholder base. Governance token concentration among early investors and founding teams also produces outcomes that consistently favour capital holders over protocol users [128], the same plutocratic dynamics that decentralised governance was intended to escape. And flash loan governance attacks allow an adversary to borrow a large token position for the duration of a single block, vote on a proposal, and repay the loan before the block closes, bypassing the assumption that governance power correlates with long-term stake. This vector has been exploited in practice; the Beanstalk protocol [129] lost approximately $182 million in April 2022 to an attacker who used a flash loan to pass a malicious governance proposal and drain the treasury in the same transaction.

Several governance designs attempt to address these failure modes. Quadratic voting [130] weights votes as the square root of tokens held, reducing plutocratic concentration at the cost of introducing Sybil attack vulnerability, since an adversary who can create many identities can vote more cheaply. Conviction voting accumulates voting power over time, rewarding sustained engagement over reactive position-taking, which addresses low participation but not concentration. Optimistic governance defaults to no change and activates only when a proposal receives sufficient active opposition, reducing the gas cost of routine non-decisions. For agent-specific governance, time-locked parameter changes insert a delay between proposal approval and implementation, giving affected agents and users time to respond before a change takes effect.

From an organisational theory perspective [131], these mechanisms share a common limitation: they treat governance as a voting problem, not a legitimacy problem. Legitimacy in organisational governance requires two things: that decisions follow a specified procedure, and that the procedure itself is regarded as fair by those it affects [17]. Token-weighted voting satisfies the first requirement for token holders but has no mechanism for incorporating the preferences of users, counterparties, or third parties who bear consequences but hold no tokens.

Autonolas implements a service registry where agent service parameters are governed by holders of the OLAS token; services that fail quality checks can be removed by DAO vote [1]. SingularityNET’s AGI token holders vote on which AI services are listed on the platform and under what terms [3]. Neither system has faced a governance attack targeting its agent fleet specifically, but both inherit the general vulnerabilities of token-weighted governance, and neither provides a mechanism for incorporating feedback from the end users who interact with the agent services.

Dispute resolution for individual agent interactions operates below the DAO level through on-chain arbitration protocols. Kleros [132] and Aragon Court [133] use economic incentives to recruit jurors who stake tokens on correct verdicts; jurors who vote with the majority receive a share of the losing side’s stake. Applied to agent disputes, such as a client claiming a task was not completed or an agent claiming payment was withheld, these mechanisms provide decentralised adjudication without a trusted third party. Their limitation is the juror pool problem: effective arbitration of technical disputes between AI agents requires jurors with specialised knowledge, and staking mechanisms that recruit economically rational generalists may not produce the right adjudicators for complex agent-behaviour questions.

The corpus illustrates several concrete implementations of DAO-based agent governance. Cu et al. [134,135] develop a decentralised autonomous agent system for fractional asset ownership governed by a DAO, with on-chain governance managing agent parameters and dispute resolution for asset management decisions. Lee et al. [136] examine the interaction between AI policy governance and blockchain-based voting in federated learning systems, showing that DAO governance structures can extend meaningfully to FL coordination decisions where the agents are gradient-submitting nodes. Valiente and Pavón [137] provide a formal ontology for DAOs that covers the agent interaction patterns most relevant to multi-agent coordination, offering a shared conceptual vocabulary that the field currently lacks. Virovets et al. [138] survey interaction modes between autonomous economic agents in DAO environments, distinguishing competitive, cooperative, and hierarchical patterns and their governance implications. Ahmed et al. [80] develop APOLLO, an autonomous on-chain learning orchestrator in which the agent itself participates in blockchain governance (e.g., submitting proposals, casting votes, and updating its own policy parameters through the DAO) one of the few deployed systems where the governed and the governing entity are the same. Ikeda et al. [139] address the security dimension of DAO agent governance, proposing anomaly detection methods that distinguish malicious agent behaviour from legitimate protocol participation within DAO-managed crypto-asset transaction systems.

5.3. AI Governance Frameworks Applied to Decentralised Agents

The EU AI Act [10] establishes a risk-based framework for AI systems deployed in the European Union, with compliance requirements that scale with assessed risk. High-risk systems must register in an EU database, implement risk management processes, ensure human oversight, maintain technical documentation, and demonstrate accuracy and robustness. Prohibited systems include those that use subliminal techniques to manipulate behaviour.

The geographic scope of this analysis requires a caveat. The EU AI Act applies to systems placed on the EU market or whose outputs are used in the EU, regardless of where the developer is located. For decentralised agent systems deployed on global blockchains, this creates extraterritorial reach: a DeFi protocol accessible to EU users may fall within the Act’s scope even if no component of its infrastructure is physically located in the EU. Outside the EU, however, the regulatory picture differs substantially. The United States has not enacted unified AI legislation as of 2026; regulatory action has proceeded through sector-specific agencies (SEC, CFTC, FTC) and executive orders instead of a unified framework. The UK’s AI governance approach remains principles-based and non-statutory. China’s AI regulations focus on generative AI and algorithmic recommendation, not autonomous agent systems. The three governance gaps identified below therefore apply specifically to the EU context, though analogous gaps exist in other jurisdictions under different regulatory instruments.

Mapping these requirements onto decentralised AI agents reveals structural mismatches at several points. The Act defines a “provider” as a natural or legal person that develops or places an AI system on the market. A DAO is neither; it has no legal personality in most jurisdictions. An agent fleet governed by a DAO therefore lacks an identifiable provider, and the Act’s compliance obligations have no obvious bearer. The human oversight requirement is directly incompatible with operational autonomy as defined in Section 2.3: an agent requiring per-step human approval is not, by that definition, a decentralised AI agent. The Act does not currently distinguish between systems that are autonomous by design and those deployed without oversight incidentally; this gap will require regulatory clarification as autonomous on-chain agents become more prevalent.

The NIST AI Risk Management Framework (AI RMF 1.0) [140] takes a more flexible approach, organising risk management around four functions: (a) Map (identify context and risks), (b) Measure (analyse and assess), (c) Manage (prioritise and implement responses), and (d) Govern (establish accountability structures). This framework can be applied to decentralised agent systems without presupposing a single identifiable legal entity, since it addresses processes and practices instead of compliance obligations. Its limitation is that it carries no enforcement mechanism, which reduces its practical effect on systems operating outside US regulatory reach.

Beyond the US, regulatory approaches diverge sharply. MiCA [11], the EU’s markets in crypto-assets regulation, is the most immediately relevant instrument for agents operating in financial markets, though its scope is confined to the EU and firms serving EU customers. It establishes licensing requirements for crypto-asset service providers and issuers, and extends to algorithmic market-making and automated trading where an identifiable operator can be designated. However, MiCA explicitly defers fully decentralised protocols to future legislation: Article 4(3) and Recital 22 acknowledge that services provided in a fully decentralised manner without an intermediary fall outside the regulation’s current perimeter, and the European Banking Authority’s 2023 consultation on DeFi (Decentralised Finance) confirmed that this gap remains unresolved. An AI agent that provides liquidity to a decentralised exchange or executes algorithmic strategies on behalf of token holders therefore sits in a regulatory grey zone; it may fall within MiCA’s scope if an identifiable operator or issuer can be designated, but the majority of production decentralised agent deployments deliberately eliminate that designation. Jurisdictional attribution compounds the difficulty: an agent deployed by a pseudonymous address, governed by a DAO with no registered domicile, and executing on a globally distributed network does not map cleanly onto MiCA’s territorial scope regardless of how the perimeter question is resolved.

This mapping exposes three governance gaps that current frameworks do not address. Accountability without a legal entity is the first: existing frameworks presuppose an identifiable responsible party, which decentralised systems deliberately avoid. Auditability under zero-knowledge proofs is the second: a regulator can verify that an agent ran its declared policy but cannot inspect that policy for compliance, since the model weights remain private. Jurisdiction under a borderless protocol is the third: no single national regulator has clear authority over a globally distributed agent system, and regulatory arbitrage is achievable with minimal friction.

Empirical analysis of these gaps is beginning to emerge. Otalora and Themistocleous [141] analyse the regulatory challenges of LLM-integrated blockchain agents in the metaverse [142], documenting the specific points at which current frameworks, including MiCA and the AI Act, fail to map onto systems that are simultaneously AI agents, blockchain participants, and metaverse entities. Louck et al. [143] conduct a comparative security analysis of agentic AI communication protocols, identifying the trust boundaries and attack surfaces that any governance framework must address. Sekar [144] examines autonomous administrative intelligence in the context of DAO-governed organisations, arguing that existing administrative law provides partial but insufficient coverage for AI-mediated governance decisions. Vivekanand et al. [145] consider the sustainability governance dimension, proposing that agentic AI and blockchain together enable verifiable corporate sustainability reporting; a governance application where the auditability properties of the technology align naturally with regulatory intent.

5.4. Incentive Alignment and Principal–Agent Problems

The principal–agent problem describes the conflict of interest that arises when an agent acting on behalf of a principal has access to information the principal cannot observe, and objectives that may diverge from the principal’s [146]. In token-governed decentralised agent systems, this formulation undergoes a structural transformation: the principal is a distributed and heterogeneous set of token holders, each with different risk preferences, time horizons, and information access, rather than a single decision-maker. The autonomous software agent is simultaneously the agent in the economic sense and in the computational sense, but its objective function is encoded at deployment and may not reflect the preferences of the principal population that emerges after the token is distributed. Call this the dual agency problem: the software agent pursues its programmed objective, while the governance token holders pursue their investment and utility objectives, and neither mechanism ensures the two are aligned.

Divergence between the two shows up in several forms. Reward hacking occurs when an agent collects the reward signal without delivering the intended service [147]. In token-incentivised systems reward hacking takes the form of on-chain manipulation: submitting outputs that technically satisfy the contract’s verification condition without producing genuine value. Oracle manipulation attacks and governance exploits in DeFi confirm this is a live risk rather than a hypothetical one: economically rational agents will find and exploit the gap between the letter of a contract and its intent.

Emergent collusion arises when multiple independently deployed agents, each individually rational, converge on a cooperative equilibrium that extracts value from non-agent participants. MEV extraction by agent coalitions is the most documented instance: searcher bots that individually seek arbitrage opportunities can coordinate through private channels to divide MEV rents and exclude competitors, producing cartel-like outcomes without an explicit agreement [50]. The information systems and economics literature on algorithmic markets documents an analogous phenomenon: independent pricing agents, each optimising individually, can converge on supra-competitive equilibria through repeated interaction alone, without any communication or explicit coordination mechanism [148]. The mechanism is an emergent property of agents learning in shared environments with symmetric incentive structures, distinct from collusion in the legal sense. In shared on-chain environments the effect is amplified: agents observe the same public state, face the same incentive structure, and may independently arrive at strategies that are collectively anticompetitive.

The multi-principal problem arises when token holders have conflicting interests and the governance mechanism fails to aggregate them coherently. Platform theory [149,150] addresses multi-sided incentive conflicts in conventional platforms by having the operator set prices that internalise cross-side externalities. The DAO case lacks this operator: decisions that balance competing stakeholder interests must emerge from voting processes subject to the concentration and participation failures described in Section 5.2.

Mechanism design responses (e.g., output-based bonding, mutual monitoring, and retrospective evaluation) are partial at best. Output-based bonding requires a verifiable quality measure, reintroducing Goodhart’s Law. Mutual monitoring creates incentives for false reporting and may produce monitoring cartels. Retrospective evaluation reduces agent liquidity and may deter participation from smaller operators. The deeper difficulty is that all three responses assume a principal who can define correct behaviour and verify deviations. In distributed systems where the principal is itself fragmented, even this starting assumption fails. Token incentive design and MARL reward structure design are the same problem approached from different disciplines; the convergence of the two literatures has not yet occurred, and it represents one of the most productive directions for future work at the boundary of mechanism design and multi-agent reinforcement learning.

5.5. Organisational and Inter-Organisational Dimensions

Decentralised AI agent systems are not purely technical artefacts; they are organisational infrastructures that redistribute coordination functions across institutional boundaries, and their adoption and governance cannot be understood without attending to the organisational conditions that make them viable.

Digital platform theory characterises multi-sided platforms as intermediaries that reduce transaction costs between participant groups by maintaining the rules of interaction without directly controlling either side [149,151]. Blockchain-based agent systems fit this characterisation closely; the smart contract encodes interaction rules, the blockchain enforces them, and no single organisation controls the matching between agent service providers and consumers. This structural similarity makes platform theory a useful analytical lens, but it also exposes a significant gap. Platform governance in the conventional sense is exercised by a platform operator who can intervene, adjusting pricing, removing bad actors, or updating matching algorithms, in response to market failures. A DAO-governed agent platform can make analogous interventions only through its governance process, which is slower, more contentious, and subject to the failures described in Section 5.2. The governance capability that conventional platforms take for granted is precisely what decentralised governance sacrifices.

Cross-organisational agent pipelines represent the most direct application of decentralised agent systems to inter-organisational coordination. In supply chain management, a pipeline might span a manufacturer, a logistics provider, a customs authority, and a retailer, with each organisation operating its own agents and the blockchain providing a shared coordination layer that no single party controls. Inter-organisational information systems research has long identified trust, power asymmetries, and switching costs as the primary structural barriers to adoption in multi-party coordination settings [152,153]. Electronic data interchange deployments in the 1980s and 1990s demonstrated that technically sound coordination infrastructure fails when governance rights are perceived as asymmetrically distributed—a finding that anticipates the TradeLens outcome almost exactly [154]. Blockchain-based agent systems reduce the trust requirement by replacing institutional trust with cryptographic guarantees, but they do not eliminate it: confidence in the smart contract’s correctness, the oracle network’s integrity, and the governance process’s fairness is required instead. These are, if anything, harder for non-specialist organisations to assess than institutional reputation [17], because they demand technical due diligence capabilities that most supply chain participants do not possess.

The transaction cost economics perspective [155] adds a further constraint: decentralised agent systems impose significant fixed costs, including development, audit, deployment, and governance participation, that are only justified when transaction volumes are high enough or trust deficits between participants are severe enough to warrant them. Empirical research on blockchain adoption in inter-organisational settings [17,156] consistently finds that adoption concentrates in niches where these conditions hold: cross-border trade finance, where correspondent banking relationships are slow and costly; energy markets with many small distributed producers who cannot individually afford bilateral settlement infrastructure; and supply chains with documented fraud risk. Outside these niches, centralised alternatives remain dominant.

Digital innovation ecosystem theory [157] provides a third lens. In ecosystem frameworks, a platform layer attracts complementors who build services on top of shared infrastructure, with value creation distributed across the ecosystem instead of captured by a single firm. Decentralised AI agent platforms aspire to this model: a base layer of coordination infrastructure, governed by a DAO, on which independent operators deploy specialised agent services. The theory predicts that ecosystem health depends on the platform’s ability to set and enforce quality standards for complementors while maintaining openness to entry. DAOs can enforce quality through token-curated registries and staking, but their enforcement speed and precision are limited by governance throughput. Whether DAO governance can sustain the complementor attraction and quality control that successful platform ecosystems require remains unsettled, and the answer will depend on whether the governance legitimacy problem in Section 5.2 is resolved before the ecosystem reaches the scale at which governance failures become consequential.

The corpus provides several concrete instantiations. Wang et al. [158] develop a prototype for self-owning intelligent buildings in which blockchain enables the building itself to act as an economic agent (e.g., signing service contracts, managing energy, and paying maintenance fees) an extreme case of operational autonomy where the asset and the agent are the same entity, with implications for property law and organisational liability that existing frameworks do not address. Gürpinar [159] frames the broader trajectory as a move toward Web 4.0, in which autonomous AI agents operate within decentralised enterprise coordination structures governed by smart contracts, identifying the governance design requirements for this shift to be compatible with existing organisational structures. De Gasperis et al. [160] demonstrate MAS and DAO integration for public sector tax credit tracking, showing that governance properties of DAOs extend meaningfully beyond financial applications to contexts where public accountability requirements apply. Singh et al. [161] survey the architectural spectrum from fully decentralised to semi-autonomous Web3 agent systems, providing an organisational taxonomy that complements the technical taxonomy in Table 2. Qi et al. [162] address the multi-agent trust and incentive problem directly, proposing a blockchain-driven framework for transparent and incentive-compatible collaboration in decentralised LLM multi-agent systems, treating inter-agent governance as a mechanism design challenge rather than an engineering one.

The three governance dimensions examined above, the DAO mechanisms, the regulatory frameworks, and the organisational adoption conditions, are not independent of the architectural and coordination choices as those described in Section 3 and Section 4. They interact in a specific way. An agent’s execution architecture determines what governance mechanisms are even available: an on-chain agent can be deactivated by contract, but an off-chain agent can only be deactivated by its deployer. A verifiable off-chain agent narrows the accountability gap by providing a cryptographic record of its behaviour, but introduces the Zero Knowledge governance problem described in open problem one. Token incentive coordination creates the dual agency problem precisely because token rewards are specified at deployment and cannot adapt when the principal population shifts. MARL-based coordination makes the principal–agent problem worse: the agent’s policy evolves, which means the governance contract that was written against its initial policy may not constrain its adapted one. These dependencies mean governance cannot be treated as a layer added on top of a completed technical design. It is a design constraint that must be considered at the same time as execution architecture and coordination protocol, not after.

5.6. Survey Limitations

The findings of this survey should be interpreted with the following considerations in mind.

Publication bias. The corpus reflects what has been published in peer-reviewed venues and established preprint repositories, which over-represents successful deployments and positive experimental results. Systems that were designed but abandoned, architectures that failed to deploy, and coordination mechanisms that proved unworkable in practice are systematically underrepresented. The cross-domain observations in Section 6.5 should be read with this bias in mind: the apparent maturity of certain application domains may reflect the publish-or-perish incentive structure of academic research rather than the actual distribution of production deployments.

Negative-result underrepresentation. Related to the above, studies reporting that a proposed coordination mechanism failed to converge, that a governance design produced perverse incentives, or that a ZKML deployment was computationally infeasible at target scale are rare in the corpus. The open problems in Section 7 partially compensate by identifying gaps that the positive literature has not closed, but the absence of systematic negative evidence limits the ability to assess which research directions are likely to remain blocked.

Reliance on system documentation for production deployments. Fourteen of the 191 corpus sources are vendor or foundation documentation for production systems (Autonolas, Fetch.ai, SingularityNET, Giza, and similar). These sources are not peer-reviewed and may reflect the system’s intended rather than actual behaviour. Where peer-reviewed work on the same system is available, we have cross-referenced it; where it is not, claims about production deployment scale, performance, and governance structure carry the caveat that they rest on primary sources with an obvious interest in favourable presentation.

6. Applications and Empirical Evidence

6.1. Decentralised Finance

Decentralised Finance (DeFi) is the domain with the highest concentration of deployed autonomous agent systems and, by a wide margin, the largest real-money exposure. Total value locked in DeFi protocols peaked above $180 billion in late 2021 and remained in the tens of billions through 2024–2025 [163], with a substantial fraction managed or directly influenced by autonomous agents.

The dominant architectural pattern is off-chain agent with on-chain settlement (Section 3.2). Liquidation bots monitor lending protocol state continuously and submit liquidation transactions the moment a collateral ratio crosses a threshold; the Aave [37] and Compound [38] ecosystems each support hundreds of competing bots. AMM (Automated Market Maker), a decentralised exchange mechanism that uses algorithmic pricing formulas, arbitrage bots detect price discrepancies between DEXs (Decentralised Exchanges) and close them through a rapid sequence of on-chain transactions. This activity keeps prices aligned across venues but its MEV dimension extracts value from ordinary traders in the same block [49].

AI-driven portfolio management is an area of active development. Yearn Finance vaults [47] introduced the pattern of automated strategy switching; later vaults incorporated RL-trained strategies [48]. The Numerai tournament [164] provides an unusual governance model: data scientists submit ML-trained models whose on-chain performance is staked with NMR tokens, and the tournament aggregates predictions into a hedge fund portfolio. It is one of the few DeFi applications where model quality is directly coupled to financial stake, producing strong incentive alignment that the staking and slashing mechanisms in Section 4.2 only approximate.

Governance of DeFi agents is weak relative to the standards discussed in Section 5. Most liquidation and arbitrage bots are deployed unilaterally by their operators with no DAO oversight and no staking requirement. The deployer is effectively the sole principal; liquidity providers and ordinary traders bear the costs of MEV extraction without formal recourse.

The corpus adds several DeFi agent deployments not covered above. Hou et al. [79] present SquirRL, which uses DRL to automate attack analysis on blockchain incentive mechanisms, demonstrating that RL agents can systematically discover selfish mining and withholding strategies that are economically suboptimal in theory but viable in practice. Li et al. [165] survey strategic mining behaviour in proof-of-work systems from a reinforcement learning perspective, showing that the incentive design of Bitcoin creates an environment in which RL agents consistently converge on non-cooperative equilibria. Arcifa et al. [166] develop a bounded LLM orchestration system with deterministic safety gates for concentrated liquidity management in DeFi, combining LLM-based reasoning with smart contract guardrails that prevent the LLM from producing transactions that violate safety constraints. Luo et al. [167] address adversarial multi-agent dynamics in meme coin markets, using MARL with chain-of-thought reasoning to resist front-running manipulation by adversarial bots—a use case that highlights the competitive rather than cooperative face of multi-agent DeFi systems. Thomaidis et al. [168] study the coordination problem between AI workloads and Bitcoin mining, applying distributional MARL to jointly optimise computational resource allocation and mining revenue under operational constraints. The verification challenge differs substantially between fixed-weight RL agents (such as those in SquirRL and the strategic mining systems above) and LLM-based agents (such as Arcifa et al.’s bounded orchestration system); the two cases require separate technical paths, which are examined in detail in open problem 1 (Section 7).

6.2. Supply Chain and Logistics

Supply chain is the second most mature application domain, though production deployments with genuine multi-agent AI components remain rare [169]. The more common pattern is blockchain as a shared audit ledger, with rule-based agents handling trigger conditions rather than learning agents making complex decisions.

IBM Food Trust, built on Hyperledger Fabric [170], provides a provenance tracking system for food products in which participating organisations run local agents that submit supply chain events to a shared ledger. The system is federated: each organisation controls its own agents, and the shared ledger provides a consistent reference without a central operator. TradeLens [171], a similar system for shipping container tracking built jointly by Maersk and IBM, operated from 2018 until its discontinuation in November 2022. Its failure was attributed primarily to insufficient industry adoption rather than technical shortcomings, and it is a concrete example of the governance and adoption barriers discussed in Section 5.5: shipping carriers that competed with Maersk were reluctant to share data on infrastructure in which Maersk had a governance role.

More recent research has addressed smart-contract-based coordination in supply chains, where autonomous agents representing different organisations negotiate pricing, delivery terms, and quality guarantees, with agreed terms encoded in contracts that execute automatically on delivery confirmation [172]. The agent negotiation component remains largely at prototype stage; the settlement layer is production-ready.

The governance pattern in operational supply chain deployments is a consortium DAO or federated authority: a fixed set of known organisations share governance rights, with voting weighted by supply chain position or transaction volume. This is a more constrained structure than public DAO governance and reduces the flash loan attack surface described in Section 5.2, since governance token holdings are not tradeable on open markets.

The corpus extends coverage across several supply chain agent deployment types. Swain and Patra [173,174,175] present a series of distributed software agent frameworks for blockchain-enabled supply chain management and traceability, demonstrating progressively more capable agent coordination across supply chain actors. Kumar et al. [176] propose a blockchain-driven multi-agent framework for smart supply chain management that integrates transparency, efficiency, and resilience as co-equal design objectives, with smart contracts enforcing service-level agreements at each handoff. Giannopoulos et al. [177] address decentralised pricing in supply chains through a blockchain-enabled MARL approach in which competing agents discover equilibrium prices without a central auctioneer, showing that MARL convergence is achievable in supply chain negotiation environments with moderate state space complexity. Velastegui et al. [178] provide a conceptual model for scheduling and control of production and logistics operations using MAS and blockchain, covering the coordination protocol design space that precedes implementation. Paruchuru et al. [14] demonstrate fully autonomous AI agents for continuous fraud monitoring in supply networks, using anomaly detection agents that operate without human supervision and commit evidence to blockchain for auditability.

6.3. Decentralised AI Agent Marketplaces

Agent marketplaces are the most architecturally ambitious application category: Fetch.ai, SingularityNET, and Autonolas have achieved meaningful deployment scale among agent marketplaces.

Fetch.ai [2] combines an agent framework, a peer-to-peer messaging network, and an on-chain registry (the Almanac) into a general-purpose coordination infrastructure. Agents register their capabilities and service endpoints on the Almanac; clients query the registry and negotiate directly over the messaging layer, with FET token staking required for registration. As of 2025, the network supports several thousand registered agents across logistics, DeFi, and smart energy applications. SingularityNET [3] focuses on AI service composition: agents representing ML models offer inference services, and client agents chain multiple services into composite workflows, with AGIX token governance determining listing conditions. Autonolas [1] takes a service-oriented approach, registering multi-agent systems with defined interfaces on a DAO-governed registry; operators stake OLAS tokens and earn rewards for uptime and correct behaviour.

From a platform economics perspective [149,151], all three systems face the standard cold-start problem: agents are not useful without clients, and clients are not attracted without useful agents. Each has addressed this through different subsidy strategies: Fetch.ai through direct grants to agent developers, SingularityNET through an internal research division that supplies initial services, and Autonolas through a developer incentive programme funded by the protocol treasury. Whether any of these strategies produces self-sustaining network effects at commercial scale remains to be demonstrated.

Beyond the three major marketplace platforms, the corpus documents a growing set of agent marketplace architectures at various stages of maturity. Yang et al. [179] develop BlkMaC, a blockchain-based MAS with an LLM communication framework in which agents discover each other through on-chain registries and coordinate using natural language interfaces backed by smart contract enforcement. Ioannides et al. [180] propose Mod-X, a modular open decentralised exchange framework for heterogeneous interoperable AI agents, addressing the inter-platform compatibility problem that currently prevents agents on different blockchain networks from composing services. Rahmani et al. [181] describe a peer-to-peer autonomous agent communication network that operates without centralised discovery infrastructure, relying on cryptographic identity and reputation for counterparty selection. Ragupathy [182] presents DAIS, a decentralised autonomous identity system for AI agents that uses distributed ledgers and trust registries to manage agent credentials at scale. Sümer et al. [183] characterise a semi-autonomous digital commerce model in which AI agents act as customers in Industry 5.0 supply chains, extending the marketplace concept to procurement contexts where agents have spending authority on behalf of human principals.

Ocean Protocol [184] represents a structurally distinct variant of the agent marketplace model. Where Fetch.ai, SingularityNET, and Autonolas facilitate markets for AI agent services, Ocean Protocol facilitates markets for the data that AI agents consume. Data publishers tokenise datasets as data NFTs and publish them with access conditions encoded in smart contracts; AI agents acting as buyers acquire compute access without the data ever leaving the publisher’s infrastructure, through a Compute-to-Data architecture in which the computation runs adjacent to the data rather than transferring the data to the computation. Governance of the protocol’s curation, pricing, and access policies is managed by OCEAN token holders through a DAO. The analytical significance of this model for the present survey is the reversal of the standard marketplace structure: the agent sits on the demand side of a data market, not the supply side of a service market, which changes the incentive alignment problem. The publisher’s interests (data confidentiality, fair compensation) must be balanced against the agent’s interests (data quality, access continuity) without a centralised data broker, and the token governance mechanism must aggregate these competing preferences across a large and heterogeneous stakeholder base.

6.4. IoT and Edge-Based Agent Systems

IoT environments create a natural demand for decentralised agent coordination: large numbers of heterogeneous devices distributed across organisational boundaries, generating real-time data that must be acted upon locally while being recorded centrally for audit and billing. Placing agent logic at the network edge and committing only outcomes to the chain addresses both the latency and the bandwidth constraints of full on-chain execution.

IOTA [185] provides a directed acyclic graph ledger designed for high-throughput, feeless IoT transactions, with agent-like stream components that publish signed data sequences for downstream consumption. Fetch.ai has deployed IoT-specific agents for smart energy grid coordination, where local agents representing prosumers negotiate power allocation and commit settlement transactions on-chain [2]. The primary technical constraint in these deployments is resource asymmetry: edge devices often have limited compute and battery capacity, while blockchain interaction requires elliptic curve signature computation and sustained network connectivity. Lightweight agent designs that delegate heavy computation to nearby gateway nodes while retaining on-chain identity and settlement are the dominant architectural response [186].

SLA enforcement is a recurrent governance need in IoT agent systems. When an agent representing a sensor network commits to delivering data at a specified quality and frequency, a smart contract can hold payment in escrow and release it automatically on verified delivery, or redirect it to a backup agent if the primary fails. This is a direct application of the optimistic verification pattern described in Section 3.3, and it is one of the few IoT blockchain use cases where the on-chain settlement overhead is clearly justified by the governance benefit.

The corpus documents a large and diverse set of IoT and edge agent deployments. UAV networks represent the most active sub-area. Seid et al. study blockchain-empowered resource allocation for multi-UAV networks in 5G-RAN [54] and for multi-domain resource trading in 6G TN-NTN networks [55], consistently finding that blockchain settlement reduces the need for inter-operator trust while MARL handles the real-time allocation problem. Jia et al. [187] and He et al. [188] address trusted routing for blockchain-empowered UAV networks using MARL, demonstrating that routing decisions made by on-chain smart contracts with MARL-learned parameters can outperform centralised routing under adversarial conditions. Hafeez et al. [189] coordinate UAV fleets for post-disaster response using a consortium blockchain architecture, with smart contracts handling multi-agency access control and consensus enforcing coordination finality across competing responders. Vasalos et al. [13] develop a DAO-based swarm architecture for UAV analytics, in which governance of the swarm mission parameters is delegated to a DAO whose token holders include the operating organisations.

In vehicular networks and Internet of Vehicles (IoV), Chang et al. [59] apply distributed MARL to collaborative path planning and scheduling in blockchain-based cognitive IoV, while Kang et al. [190] address avatar migration for vehicular metaverse services using MARL with blockchain settlement. Security applications appear throughout the corpus: Raja et al. [58] use blockchain-integrated MARL to secure cooperative adaptive cruise control against adversarial manipulation, and Chelghoum et al. [191] apply blockchain-enabled collaborative intrusion detection with RL to securing vehicle-to-everything communications in 6G networks. Wang et al. [120] address the IoT-specific problem of asynchronous federated RL for trajectory prediction, using blockchain to manage staleness and contribution attribution in a system where device availability is intermittent. Xu et al. [192] address on-chain and off-chain data management for blockchain-IoT systems using MARL, directly examining the data placement and cost trade-off that underlies most IoT blockchain deployments. Antuley et al. [193] develop SORA-ATMAS, an adaptive trust management system with multi-LLM aligned governance for smart cities, representing one of the more complete treatments of how LLM-based agents can be governed in IoT environments through a combination of on-chain trust registries and human-aligned policy constraints. Zhan et al. [194] provide the first systematic security analysis of edge agent deployments on IoT hardware, identifying attack surfaces specific to the three-tier cloud-edge-device architecture that most production IoT agent systems use.

6.5. Cross-Domain Observations

The 177-paper corpus, spanning four application domains over seven years, supports five cross-cutting observations that are not visible within any single domain.

The first is an architectural concentration that predates and persists across all domains. The expanded taxonomy in Table 2 classifies 20 representative systems; all but two fall in the off-chain agent with on-chain settlement category. On-chain execution is limited to rule-based financial contracts. Verifiable computation appears only in isolated research deployments. The distribution reflects a genuine engineering constraint rather than a sampling artefact: off-chain reasoning with on-chain settlement is the only pattern that simultaneously supports complex agent behaviour and economically viable transaction costs. The architectural alternatives described in Section 3.1 and Section 3.3 will not challenge this dominance until ZKML proving costs fall by at least one order of magnitude or L2 execution environments support native ML inference.

MARL, meanwhile, dominates the research literature but is essentially absent from production deployments. The corpus contains over 50 systems that combine MARL with blockchain infrastructure in experimental or prototype settings, yet the production systems surveyed in Section 6.1, Section 6.2, Section 6.3 and Section 6.4 are almost entirely rule-based or use simple single-agent RL. The gap has two explanations. MARL convergence in asynchronous on-chain environments is not guaranteed, as discussed in Section 7, which deters risk-averse deployers. And MARL systems require sustained training infrastructure that most production deployments do not maintain. The research-to-deployment gap for MARL is therefore wider in this setting than in most other applied MARL domains.

Governance maturity, for its part, is inversely related to deployment scale. DeFi, the domain with the largest deployed capital, has the weakest agent governance: most DeFi agents are unilaterally deployed with no DAO oversight and no staking requirement. Supply chain consortium deployments have stronger governance structures, since the participating organisations are identifiable and subject to contract law, but smaller deployment scale. Agent marketplaces have the most developed token governance, but remain at early commercial scale. The pattern suggests that governance investment is driven by regulatory pressure and reputational risk among identifiable institutional participants rather than by technical necessity. MiCA’s current perimeter excludes fully decentralised protocols, but its progressive extension and the EU AI Act’s applicability to high-risk autonomous systems are likely to shift the DeFi governance posture substantially over the 2025–2027 period as regulatory guidance matures.

The fourth observation is that energy and UAV applications together account for roughly 40% of the corpus. Table 6 shows the distribution of the 177 peer-reviewed papers across application domains. Each paper was assigned to the domain of its primary application as stated in its abstract; papers that addressed multiple domains were assigned to the one accounting for the majority of the technical contribution. Papers where no single domain exceeded 50% of the contribution were placed in the residual “Other” category. Energy (including microgrids, P2P trading, demand response, and smart grids) and UAV/edge networks each account for approximately 20% of the corpus, and their combination exceeds DeFi, supply chain, and agent marketplaces combined.

Table 6. Distribution of the 177 peer-reviewed corpus papers by primary application domain.

Domain	Papers	Share (%)
Energy (P2P trading, microgrids, smart grids, demand response)	38	21.5
UAV, vehicular, and mobile edge computing	36	20.3
Decentralised finance and blockchain network management	27	15.3
IoT and general edge computing	26	14.7
Supply chain and manufacturing	18	10.2
Agent marketplaces and multi-agent platforms	16	9.0
Other (healthcare, governance, security, education)	16	9.0
Total	177	100

This concentration reflects the problem structure of the two leading domains rather than a bias in the literature. Energy and UAV systems share three features that map naturally onto blockchain-based MARL: many small heterogeneous actors with no prior trust relationship, short decision horizons that reward fast off-chain computation, and a genuine need for tamper-evident settlement because the underlying assets (energy, spectrum, compute) are rivalrous and contestable. Domains with fewer actors, longer horizons, or strong centralised governance alternatives (healthcare data markets, financial clearing, government services) are underrepresented for structural reasons, not bibliographic ones.

The fifth observation is that no production system in any domain currently uses ZKML or TEE verification at scale. Verifiable computation is consistently described as a necessary future capability, but the practical systems that would motivate its adoption (production agents whose behaviour must be audited by regulators or counterparties) are governed instead by staking and reputation mechanisms whose deterrence depends on economic assumptions that may not hold at high stakes. This is the dimension of the architecture-governance interaction that is most likely to be resolved by regulatory pressure rather than technical progress: when regulators require verifiable agent behaviour, the demand for ZKML or TEE verification will create the economic incentive to close the current cost gap.

7. Open Research Problems

The six problems identified below are stated precisely enough that each could form the basis of a targeted research contribution. They are not generic limitations restated as gaps; each identifies a specific missing result or mechanism whose absence currently constrains system design or deployment. A prioritized research roadmap summarising suggested first steps and estimated horizons is provided in Appendix C.

• Verifiable agent behaviour under zero-knowledge constraints.

Current ZKML implementations (Giza [4] and EZKL [62]) prove that a model was evaluated correctly on a given input, but do not by default prove that the model used at inference time is the model declared at deployment. An agent operator can swap underlying policy weights between deployments without any on-chain record of the change, provided the proof system commits only to the computation graph structure rather than the weights themselves.

For fixed-weight RL policies this gap has a tractable engineering response: committing a Merkle hash of the weight tensors at deployment and including that commitment in the ZK proof statement binds the declared policy to each inference proof. The additional circuit complexity is substantial but not prohibitive for the small models that current ZKML can handle. For constrained RL agents, then, this gap is an engineering step that production deployments have not yet taken rather than an open research problem, and its adoption will likely be driven by regulatory pressure rather than technical discovery.

The genuinely open problem lies one level up. LLM-based agents have no fixed weight set to commit: their “policy” is a prompt-plus-model combination that changes with each input, each session context, and potentially each fine-tuning cycle. No mechanism currently exists for proving that an LLM-based agent acted according to a declared prompt strategy without revealing the prompt, and without allowing the operator to substitute a different strategy between calls while presenting the same nominal identity. Weight hashing cannot address this. Progress requires either restricting the scope of verifiable LLM agents to those with immutable system prompts committed on-chain, or developing proof systems for program-level behavioural specifications that are independent of the model’s specific weights and prompt instantiation.

Success criterion: Can an on-chain verifier confirm, without ever seeing the prompt, that an LLM-based agent’s output was generated under a declared system prompt and that the prompt has not changed since a committed registration transaction? A proof system answering yes to both conditions would resolve this problem.

• MARL convergence under chain-reorganisation-induced non-stationarity.

As established in Section 4.2, blockchain MARL involves two distinct forms of non-stationarity. Agent-induced non-stationarity (the standard MARL problem) is partially addressed by CTDE, and practical implementations using experience replay and target networks already handle variable block-time intervals with reasonable empirical performance. The open theoretical problem is environment-induced non-stationarity from chain reorganisations.

When a recently confirmed block is replaced by a competing fork, the environment state that agents observed and acted upon is retroactively changed. An agent that submitted a transaction in block k expecting reward r may find, after a reorganisation, that its transaction never occurred, that the state it acted on no longer exists, or that a different agent’s transaction was executed instead. This violates the Markov property not because other agents are learning but because the execution environment itself is non-deterministic in a way that has no equivalent in simulation. Standard CTDE convergence proofs for QMIX [26] and MADDPG [27] do not account for this. Whether CTDE algorithms converge to stable joint policies under the reorganisation frequencies observed in production blockchains [195], and at what rate convergence degrades as reorganisation frequency increases, is an open theoretical question. A simulation environment that accurately models block-time variance and reorganisation statistics would be the necessary first step, and no such environment currently exists in the MARL literature.

Success criterion: Prove or disprove convergence for a standard CTDE algorithm (QMIX or MADDPG) in a Markov game environment subject to reorganisation events at empirically calibrated frequencies. A convergence proof or a counterexample would both count, provided each is accompanied by an open-source simulation environment that reproduces the relevant chain dynamics.

• Incentive-compatible agent deactivation.

Token-governed agent systems have well-designed mechanisms for activating agents (registration, staking, capability announcement) but poor mechanisms for deactivating them when their behaviour degrades. A DAO governance vote to deactivate an agent is slow, costly in governance attention, and vulnerable to blocking by the agent’s deployer if they hold sufficient governance tokens. Slashing addresses individual violations but not gradual performance degradation that remains above the slashing threshold. What is needed is a mechanism that makes it individually rational for an agent or its deployer to voluntarily decommission the agent when performance falls below a system-level threshold, rather than continuing to collect reduced rewards. This is a mechanism design problem with no obvious solution: deactivation must be incentive-compatible and not simply allowed by the rules. Potential directions include time-decaying staking rewards conditioned on performance metrics, and automatic stake forfeiture below a rolling performance floor, but neither has been deployed or formally analysed in the agent context.

Success criterion: A rational agent deployer, facing the mechanism, finds it individually optimal to decommission the agent once its performance metric falls below a specified threshold, that is, decommissioning is the Nash equilibrium strategy. This would need to be shown formally or through agent-based simulation under calibrated parameter ranges.

• Cross-chain agent coordination.

An agent that must act across multiple blockchain networks (for example, reading price data from one chain, executing a trade on a second, and settling payment on a third) faces fragmented state and asymmetric latency. Cross-chain messaging protocols such as the Inter-Blockchain Communication protocol (IBC) [196] and LayerZero [197] address the transport problem but not the coordination problem: an agent cannot atomically commit to actions on two chains simultaneously, because the chains finalise independently. This creates a window during which the agent has committed on one chain but not the other, exposing it to state inconsistency and front-running. The problem is analogous to the two-phase commit problem in distributed databases, but without a trusted coordinator, and with finality times that differ by orders of magnitude across chains. General solutions to this problem, whether based on ZK proofs of cross-chain state, trusted relayer networks, or optimistic challenge protocols, would substantially expand the design space for multi-chain agent systems.

Success criterion: A protocol under which an agent can atomically commit to actions on two or more chains with different finality models, with a formal proof of atomicity that holds under asynchronous networks and the failure of up to f of n relayers, deployed and tested on at least two production blockchain networks.

• Regulatory attribution in autonomous agent pipelines.

When a pipeline of autonomous agents causes a harmful outcome (a biased credit decision, a market manipulation, a privacy violation), existing regulatory frameworks provide no clear mechanism for attributing liability across the pipeline. The EU AI Act [10] assigns obligations to “providers” and “deployers”, but in a pipeline where agent A was developed by one party, deployed and operated by another, and its output consumed by agent B developed and operated by third and fourth parties respectively, there is no unambiguous mapping from the Act’s categories to the pipeline participants. MiCA [11] faces the same problem for financial agent pipelines. Legal scholarship on AI liability in multi-agent systems is in its early stages [123]; technical mechanisms that produce auditable records of each agent’s contribution to a pipeline outcome (including the provenance of each input and the basis for each decision) would be a prerequisite for any attribution framework, whether legal or contractual. The combination of on-chain execution logs and ZK proofs of model evaluation is a plausible technical direction, but no deployed system currently provides this at pipeline scale.

Success criterion: A pipeline-level attribution architecture would take the on-chain transaction log of a multi-agent pipeline and produce a machine-readable provenance record, mapping each component of the final output to the agent and input responsible for it. The record would need to satisfy the evidentiary standard required under at least one of the EU AI Act, MiCA, or GDPR’s automated decision-making provisions.

• Emergent collusion detection.

Multi-agent systems operating on shared contract state may converge on collusive equilibria that are individually rational for each agent but collectively harmful to the protocol and its users. MEV coalition formation [50] is the best documented instance, but the problem is more general: any MARL system trained in a shared environment may develop cooperative strategies that optimise joint value at the expense of non-agent participants. The difficulty is that collusive behaviour is often empirically indistinguishable from coordination that is genuinely beneficial. Two agents that consistently act in sequence on the same price discrepancy may be colluding to extract MEV, or they may independently be providing liquidity that happens to be complementary. On-chain detection of collusion therefore cannot rely on behavioural signatures alone; it requires a model of counterfactual outcomes under non-collusive behaviour. No on-chain detection mechanism currently exists that can distinguish the two cases at runtime. Game-theoretic approaches to collusion detection in mechanism design [84] and empirical methods from industrial organisation offer partial tools, but translating them to the on-chain agent setting is an open problem.

Success criterion: Demonstrated in a controlled simulation environment: an on-chain or off-chain detection mechanism that keeps the false-positive rate below 5% on known-legitimate coordination patterns (e.g., complementary liquidity provision) while correctly flagging at least 80% of synthetic MEV coalition scenarios, with the detection logic publicly auditable.

8. Conclusions

The deployment of autonomous AI agents on blockchain infrastructure has outpaced the research frameworks needed to design, evaluate, and govern them. Systems that hold digital assets, execute smart contracts, and coordinate with other agents without per-step human approval are now operating at scale across decentralised finance, supply chain, IoT networks, and agent marketplace platforms. They control substantial economic value and interact with regulatory frameworks that were not designed with them in mind. This survey has imposed structure on that space across three dimensions (architecture, coordination, and governance), and the picture that emerges is uneven in a specific way: the technical dimensions are maturing faster than the governance dimension, and the governance dimension is where the practical risks are highest.

On architecture, the design space is now mapped well enough to support principled choices. The taxonomy in Table 2 distinguishes four execution patterns that differ in verifiability, computational expressiveness, and latency. The comparison in Table 1 quantifies the cost of each verification approach. Off-chain reasoning with on-chain settlement is the dominant pattern and will remain so; the 177-paper corpus confirms this is a stable equilibrium under current cost structures rather than an interim state. Practitioners now have sufficient empirical evidence to choose between execution patterns on technical grounds rather than by analogy.

On coordination, production-ready mechanisms (auctions and token incentives) are well enough understood that their failure modes can be designed around. MARL coordination is more promising and more fragile. The corpus documents substantial experimental deployment across energy, UAV, and vehicular domains, consistently showing that blockchain’s public-state and atomic-commitment properties provide genuine advantages over conventional MARL environments. The open question is whether CTDE algorithms converge under block-time non-stationarity, and the stakes are real: systems deployed today on MARL policies rest on convergence assumptions that have not been validated for this execution context. The right response is to instrument production deployments carefully and treat convergence as an empirical property to be verified rather than assumed, not to avoid MARL.

On governance, the gap between what exists and what is needed is widest. The governance vacuum described in Section 5.1 is a multi-stakeholder system in which no participant has both the authority and the information to govern the whole. It describes the operational state of most deployed decentralised agent systems today, not just an abstract theoretical concern. DAOs govern token parameters but not agent pipelines, and the dual agency problem in Section 5.4 captures why: the software agent and the governance token holders pursue different objectives, and neither the staking mechanism nor the DAO voting process provides a reliable bridge between them. This matters for the architectural and coordination choices in Section 3 and Section 4 directly: an off-chain agent with no on-chain verification of its policy creates an accountability gap that no governance mechanism can close after the fact. The governance dimension constrains which architectural patterns are deployable in regulated contexts and which coordination mechanisms are viable at scale; it is not a concern that can be deferred to a later stage.

The EU AI Act and MiCA entered into force in 2024 and 2025. MiCA’s current perimeter explicitly defers fully decentralised protocols, but its progressive extension and enforcement guidance will narrow the regulatory gap for DeFi agent systems over the next two to three years. The EU AI Act’s risk-based framework applies to AI systems deployed in the EU regardless of the operator’s location, which creates real compliance exposure for high-risk autonomous agent deployments even where MiCA does not yet reach. Regulatory attribution in autonomous agent pipelines (open problem five in Section 7) is the question that enforcement actions will force into resolution within that window, and soon.

This survey offers researchers and system designers a shared vocabulary for a field that has developed largely in parallel silos across distributed systems, mechanism design, IS governance, and AI: the three-condition definition of a decentralised AI agent, the four-dimension architectural taxonomy, the coordination mechanism comparison in Table 4, the governance vacuum and dual agency problem formulations, and the mapping of EU AI Act and MiCA onto the agent setting in Section 5.3. The most consequential open problems are at the boundaries between those silos. Whether the next significant advance comes from ZKML efficiency, MARL convergence theory, regulatory design, or digital platform governance is an open question. The answer will determine which of the six problems in Section 7 resolves first, and which ones wait for the others.

Appendix A.1. Database Search Strings

The following platform-specific search strings were used. All searches were conducted between January and April 2026, covering publications from January 2019 onward.

IEEE Xplore (Command Search)—Primary pass:

("blockchain" OR "distributed ledger" OR "smart contract") AND ("autonomous agent" OR "multi-agent system" OR "AI agent" OR "software agent" OR "intelligent agent") AND ("coordination" OR "reinforcement learning" OR "multi-agent reinforcement learning" OR "governance" OR "incentive mechanism" OR "task allocation")

IEEE Xplore—MARL supplementary pass:

("QMIX" OR "MADDPG" OR "COMA" OR "cooperative MARL") AND ("blockchain" OR "smart contract" OR "distributed ledger")

ACM Digital Library:

("blockchain" OR "smart contract" OR "distributed ledger") AND ("autonomous agent" OR "multi-agent") AND ("coordination" OR "reinforcement learning" OR "governance" OR "incentive")

Scopus—Primary pass:

TITLE-ABS-KEY(("blockchain" OR "distributed ledger" OR "smart contract") AND ("autonomous agent" OR "multi-agent system" OR "AI agent" OR "software agent" OR "intelligent agent") AND ("coordination" OR "reinforcement learning" OR "governance" OR "incentive mechanism" OR "task allocation")) AND PUBYEAR > 2018 AND (LIMIT-TO(DOCTYPE,"ar") OR LIMIT-TO(DOCTYPE,"cp"))

Scopus—DAO supplementary pass:

TITLE-ABS-KEY(("decentralized autonomous organization" OR "DAO governance" OR "token voting" OR "on-chain governance") AND ("artificial intelligence" OR "machine learning" OR "autonomous agent" OR "automated")) AND PUBYEAR > 2018

arXiv (four targeted passes across cs.MA, cs.CR, cs.DC, cs.LG):

• blockchain autonomous agent coordination reinforcement learning
• multi-agent reinforcement learning blockchain smart contract
• decentralized autonomous organization governance token voting AI
• zero knowledge machine learning on-chain inference agent

Appendix A.2. Inclusion and Exclusion Criteria

Inclusion criteria (all three must hold):

• The paper describes a software agent satisfying at least one of: RL/MARL-based policy, LLM-based reasoning, or rule-based automation with non-trivial adaptive logic.
• Blockchain, a distributed ledger, or smart contracts are structural to the agent’s operation (not incidental), in the sense that removing the blockchain component would fundamentally alter the agent’s operating mode or accountability structure.
• The paper was published or publicly available between January 2019 and April 2026.

Exclusion criteria (any one is sufficient):

• The word “agent” is used only in the economic rationality sense, with no computational agent behaviour present.
• Blockchain and AI appear in separate, unrelated sections of the paper without structural integration.
• The paper is a workshop paper under four pages with no corresponding full journal or conference publication.
• The paper is an editorial, column, or job-market profile.

Appendix A.3. Screening and Coding Protocol

Screening process: Title and abstract screening was performed by one reviewer (M.T.) applying the criteria above. Papers that could not be resolved from the abstract alone were advanced to full-text assessment. Full-text eligibility was assessed by both authors independently, with disagreements resolved by consensus discussion. No papers required arbitration beyond the initial consensus round.

Coding rules: Each included paper was coded on four dimensions corresponding to the taxonomy in Table 2: (i) execution locus (on-chain/off-chain + settlement/verifiable/ multi-agent on-chain); (ii) verification mechanism; (iii) primary learning paradigm (RL/MARL/LLM/rule-based/hybrid); (iv) primary coordination mechanism (auction/ token incentive/MARL/gossip/none). Papers with mixed or ambiguous profiles were coded by dominant property. Papers that span multiple application domains were assigned to the domain accounting for the majority of the technical contribution; multi-domain papers where no single domain exceeded 50% of the contribution were assigned to the “Other” category in Table 6.