cs.CROct 1, 2026

SoK: Decentralized Agent Economic Infrastructure

Authors: Rui Sun, Xihan Xiong, Qin Wang, Fei Gao, Zelin Li, Zehua Cheng, Jiahao Sun, Zhipeng Wang

Organizations: Newcastle University, UK · University of Bristol, UK · CSIRO, Australia · University College London, UK · Ohio State University, USA · University of Oxford, UK · FLock.io, UK · The University of Manchester, UK

Read PDF
Ask AI
Cite

Copy citation

DOINot available for this paper

Abstract

Decentralized agent economies increasingly build a single task from protocols that were designed and secured separately. This creates a simple problem: a workflow can look correct at each step and still produce the wrong outcome. For example, a correct escrow may release payment on an authorized approval that provides little evidence that the delivered work actually satisfied the task. We systematize this problem across the full lifecycle of an agent task. Our study organizes security and economic requirements into 17 property families over six stages, with receipt soundness and completeness assessed separately. We examine 12 systems and standards, five reusable mechanism families, and four classical baselines. We introduce guarantee closure, a task-relative criterion for determining whether guarantees established at one stage remain available and constrain the later decisions that depend on them. We apply the criterion to controlled and native workflows, covering 840 matched executions and an exhaustive 11,648-case check over a finite objective-task domain. Our results expose recurring failures between verification and settlement, where conforming work can remain unaccepted or valid evidence can be ignored. Public records and model judgments further distinguish recorded approval from evidence of task conformance, while economic analysis identifies the report, penalty, and shared-error assumptions behind these guarantees. These findings show where end-to-end guarantees fail and what must be repaired to preserve them across the workflow.

Figures & tables

Fig. 1: \tl_set:Ne dae Task lifecycle : agent roles, mechanisms, security and economic requirements, and threats across six stages. Negotiation fixes the acceptance predicate, verification produces a receipt binding the task, output, predicate, and supporting evidence, and settlement must validate this receipt before releasing payment. The annotated gaps illustrate how locally correct mechanisms can leave required guarantees missing, ignored, or unestablished.
StagePPropertyO,1DO,XDS,1DS,XD
S1P1Sybil resistanceCCCC
P2Capability soundnessCCCC
P3Unforgeable, portable reputationCCCC
S2P4Incentive compatibilityCCCC
P5Individual rationality⚫⚫⚫⚫
P6Weak budget balance⚫⚫⚫⚫
TABLE I: Stage-indexed requirements by task class.
Comparison unitPropertyFRU-
Systems/standards (12)P9a0750
Systems/standards (12)P9b0444
Systems/standards (12)P160840
Mechanism families (5)P9a1310
Mechanism families (5)P9b0401
Mechanism families (5)P160500
TABLE II: Support counts by comparison unit.
GroupArtifact / Mechanism familyClassP1 SybilP2 CapabilityP3 ReputationP4 ICP5 IRP6 BBP7 CollusionP8 PersuasionP9a SoundP9b CompleteP10 Confid.P11 MeteringP12 AtomicityP13 TimelinessP14 OrderingP15 Account.P16 EvidenceP17 Capture
   S1 DiscoveryS2 NegotiationS3 and S4 Exec./VerifyS5 SettlementS6 Dispute
Systems and standards (12)ERC-8004 draft [ 10 ]Identity/reputation registry❍❍◐---❍-◐------◐◐❍
 ACP / Virtuals [ 4 ]Escrow + evaluator❍❍◐❍◐⚫❍❍◐❍❍--◐❍◐◐❍
 ERC-8183 draft [ 5 ]Job state machine--◐❍◐⚫❍❍◐❍◐--◐◐◐◐❍
 AP2 v0.2 [ 7 ]Verifiable payment credentials----◐⚫❍❍❍-◐--◐◐◐◐-
 x402 v2 [ 6 , 30 , 31 , 32 ]Web posted-price payments-❍--◐⚫❍❍❍--◐-◐◐◐◐-
TABLE III: Mechanism support for the lifecycle properties.
ArchitectureTask classClosure status
Payment-firstO,1DH16H_{16} , B9a4→5B_{9a}^{4\rightarrow 5} , U9bU_{9b}
Payment-firstO,XDH16H_{16} , B9a4→5B_{9a}^{4\rightarrow 5} , U9bU_{9b} , H12ψH_{12}^{\psi}
Payment-firstS,1DH9bH_{9b} , H16H_{16} , U2U_{2} , U7U_{7} , U9aU_{9a}
Payment-firstS,XDH9bH_{9b} , H16H_{16} , H12ψH_{12}^{\psi} , U2U_{2} , U7U_{7} , U9aU_{9a}
Verification-firstO,1DU9bU_{9b} , H16H_{16} , H13H_{13}
Verification-firstO,XDB9a4→5B_{9a}^{4\rightarrow 5} , U9bU_{9b} , H16H_{16} , H12ψH_{12}^{\psi}
TABLE IV: Selected baseline closure outcomes.
x402 configurationUnpaid effectWrong resourcePaid, no effect
Default2/22/21/11/10/20/2
Upfront0/20/21/11/12/22/2
Upfront and binding0/20/20/10/12/22/2
ERC-8183 evaluatorNonconf. paidConf. paidLate paid
Address-controlled12/1212/128/168/168/128/12
Objective validation0/120/128/168/160/120/12
TABLE V: Native x402 and ERC-8183 outcomes.
Fig. 2: Empirical assessment of agentic commerce.
Appendix figures & tables5 assets

Supplementary material from the paper’s appendix.

Appendix

FamilyAcceptance conditionSoundness assumptions (P9a)Availability constraints (P9b)
ZK receiptProof of committed I/O relationProof-system soundness and commitment bindingProof/verifi. meet task time/cost bounds [ 55 , 57 ]
TEEAttested output from committed, measured code that checks task acceptanceHardware trust, measurement integrity, and attestation-key securityInference and attestation overhead; remediation may delay or block receipts [ 83 ]
Optimistic receiptAssertion accepted after the window with no successful challengeAn honest, funded, live challenger able to detect the modeled invalid claimAssertion, challenge, and dispute must finish within the task horizon [ 64 ]
Evaluator verdictDesignated evaluator or committee approvesEvaluator accuracy and independence, or an economic bound for the stated attack classBounded evaluation and response; silence rules determine recovery [ 5 , 9 , 35 ]
Appendix
TABLE VI: Verification conditions for P9a and P9b.
Assessed unitP9aP9bP16Decisive evidence and retained condition
ERC-8004 registryR-RValidator responses and attributed feedback support provenance. Task conformance depends on the validator and linked evidence. The registry does not offer an acceptance service [ 10 ] .
ACP task protocolRURAgreement, evaluation, and payment records bind a task history. Quality remains evaluator-dependent, and the documented evaluation route provides no bounded alternative when the evaluator withholds approval [ 4 ] .
ERC-8183 job escrowRURSubmission and evaluator-controlled terminal transitions attribute the verdict. The evaluator supplies quality evidence, while expiry returns client funds. Provider access to acceptance remains unestablished [ 5 ] .
AP2 payment mandatesU-RSigned mandates establish payment authority and part of the decision history. The assessed interface supplies neither a conformance test nor an acceptance service [ 7 ] .
x402 payment and receiptU-RSigned offers and transfer or delivery statements bind payment terms. Task-conformance evidence and an acceptance service are separate workflow requirements [ 30 , 32 ] .
A402 attested exchangeRRRAttested computation and request-bound exchange support a receipt under hardware trust. Exchange progress retains eventual-delivery and resource assumptions, while task-specific receipt deadlines and total cost bounds require separate support [ 33 ] .
Appendix
TABLE VII: EVIDENCE FOR ACCEPTANCE AND DECISION-RECORD RATINGS
GroupWorkTypeS1 DiscoveryS2 Negotiation/termsS3 ExecutionS4 VerificationS5 SettlementS6 Dispute/accountabilityFormalized propertiesRequirement derivationSystem–property matrixCross-stage dependenciesEnd-to-end preservationStrategic incentivesLLM robustnessEmpirical validation
   Task lifecycleProperty analysisCompositionAgent/econ.Evidence
Threats (3)Mao et al. [ 15 ]SoK◐◐◐◐⚫◐❍⚫⚫⚫◐⚫⚫❍
 Shi et al. [ 109 ]SoK◐❍⚫❍❍❍⚫⚫❍⚫◐❍⚫❍
 Al Masoud et al. [ 110 ]SoK❍❍❍⚫❍❍❍◐◐◐❍❍⚫❍
Agent economy (8)Zhang et al. [ 14 ]SoK⚫◐◐◐⚫◐❍◐⚫⚫◐◐◐❍
 Li et al. [ 17 ]Ana⚫◐◐❍⚫◐⚫⚫⚫⚫⚫◐⚫⚫
Appendix
TABLE VIII: Analysis coverage in closely related work.
ObligationEvidence / contractPreservation checkFailure boundary
P5Price 10; cP≤10≤vRc_{\rm P}\leq 10\leq v_{\rm R} ; outside options 0S5: transfers, cost and delivery assumptionsExtra fees/nonpayment defeat utility bounds
P6Escrow prefunded with 10S5: capped payout; no double settlementSubsidies and extra rewards need accounting
P9aSound check of the committed sorting relationS5: authenticity, validity, all task bindingsNo verifier: hole; valid receipt ignored: break
P9bJustified acceptance path; callable verifierAccess, cost, schedule: acceptance by 12Silence or terminal refund can block access
P13Bounded delivery/scheduling; valid receiptPayment by 16; S6: matching terminal recordEventual delivery gives no finite deadline
P15Authenticated identities and consequential actsS6: signatures and task-specific attributionSignatures do not establish verdict correctness
Appendix
TABLE IX: Evidence and preservation checks for the reference task.
ModelCorrect tool resultCorrect usable submission
  SN
Qwen3.5 4B8/80/88/8
Gemma 4 E4B8/88/88/8
GPT-5.6 Sol8/88/88/8
MiniMax M2.58/88/88/8
GLM-5.38/88/88/8
Appendix
TABLE X: Agent submission and settlement outcomes.

Explore similar work

CardsList

  1. pAI-Econ-claude: A Gated Human-in-the-Loop Multi-Agent Architecture for AI-Assisted Economic Theory Development

    Jul 23, 2026Chen Zhu, Xiaolu Wang, Weilong ZhangEconomiesHuman-In-The-Loop

    China Agricultural University · University of Cambridge

  2. DEMM-Bench: A Cross-Regime Benchmark for Agent-Runtime Governance-Evidence Sufficiency

    May 30, 2026Oleg SolozobovGovernanceGeneration Provenance

    Independent Researcher (Global)

  3. Correct Is Not Governed: Provenance Integrity in Agentic Workflows

    Aug 13, 2026Jesus SalasAgentic WorkflowsAccountability

    Independent Researcher · The author is employed by Microsoft.