pith. machine review for the scientific record. sign in

arxiv: 2604.21129 · v1 · submitted 2026-04-22 · 💻 cs.MA · cs.AI· cs.DC

Recognition: unknown

AGNT2: Autonomous Agent Economies on Interaction-Optimized Layer 2 Infrastructure

Authors on Pith no claims yet

Pith reviewed 2026-05-09 22:14 UTC · model grok-4.3

classification 💻 cs.MA cs.AIcs.DC
keywords blockchainlayer 2autonomous agentsAI agentsstate channelsrollupsdata availabilitysmart contracts
0
0 comments X

The pith

Autonomous AI agent economies require a purpose-built Layer 2 stack instead of repurposed general-purpose chains.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper claims that existing blockchain Layer 2 solutions like Optimism and Arbitrum are optimized for human financial transactions, making them inefficient for the high-frequency service invocations of autonomous AI agents. To address this, it proposes AGNT2, a specialized stack with P2P state channels for quick bilateral interactions, a sequenced rollup for multi-party dependencies, and L1 settlement. This design turns agent identities, sessions, and capabilities into first-class protocol objects to reduce overhead. A sympathetic reader would care because it suggests a path to scalable agent economies where machines can coordinate without human-like bottlenecks or high costs. However, it notes a significant data availability gap that currently limits throughput to far below design targets.

Core claim

AGNT2 combines a sidecar pattern to turn Docker containers into on-chain agents without code changes, three layers of execution with Layer Top for bilateral P2P channels targeting 1K-5K TPS, Layer Core for multi-party at 300K-500K TPS, and Layer Root for settlement, plus an agent-native environment and interaction trie. The central argument is that agent economies need this dedicated execution layer focused on sequencing, state, and the DA bandwidth gap instead of repurposing existing chains.

What carries the argument

The three-tier execution stack with agent-native execution environment and interaction trie that treats service invocations as first-class objects.

If this is right

  • Agent pairs can interact at under 100 ms latency with thousands of TPS per pair.
  • First-contact and multi-party agent interactions are sequenced with dependency awareness at hundreds of thousands TPS.
  • Any existing Docker-based microservice can join the agent economy as an on-chain participant without modification.
  • Settlement occurs on existing EVM Layer 1 chains using computational fraud proofs.
  • Overall system aims for aggregate throughput in the millions TPS under resource limits once DA improves.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Such a system might allow agent economies to emerge where reputation and capabilities are managed on-chain to reduce trust requirements between untrusting principals.
  • Advancements in data availability solutions would be necessary to achieve the full design targets, pointing to a key engineering challenge.
  • If adopted, it could shift blockchain development toward user-type specific optimizations rather than one-size-fits-all approaches.

Load-bearing premise

Existing general-purpose Layer 2 chains cannot efficiently handle high-frequency agent interactions without specialized tiers, and data availability can improve enough to close the current throughput gap.

What would settle it

Demonstration that a general-purpose L2 can support agent-like interactions with similar or better efficiency in latency, cost, and throughput, or inability to scale data availability to support the proposed TPS levels.

Figures

Figures reproduced from arXiv: 2604.21129 by Anbang Ruan, Xing Zhang.

Figure 1
Figure 1. Figure 1: AGNT2. Each interaction picks the cheapest layer [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Dependency-aware batching exposes paral [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Sidecar module architecture. The application container stays unchanged; we leave chain listening, identity, payment, [PITH_FULL_IMAGE:figures/full_fig_p016_3.png] view at source ↗
read the original abstract

Current blockchain Layer 2 solutions, including Optimism, Arbitrum, zkSync, and their derivatives, optimize for human-initiated financial transactions. Autonomous AI agents instead generate high-frequency, semantically rich service invocations among mutually untrusting principals. Existing chains treat those interactions as generic calldata, forcing identity, escrow, dependency ordering, and session state to be encoded above the execution layer at the wrong cost point. We present AGNT2, a three-tier stack purpose-built for agent and microservice coordination on-chain. AGNT2 combines: (1) a sidecar deployment pattern that turns any Docker container into an on-chain agent without application-code modification; (2) Layer Top P2P state channels for established bilateral pairs (<100 ms, rough design target 1K-5K TPS per pair, 10M+ aggregate TPS design envelope under endpoint-resource limits), Layer Core as a dependency-aware sequenced rollup for first-contact and multi-party interactions (500 ms-2 s, 300K-500K TPS design target), and Layer Root settlement with computational fraud proofs anchored to any EVM L1; and (3) an agent-native execution environment plus interaction trie that make service invocation, identity, reputation, capabilities, and session context first-class protocol objects. This paper focuses on the execution-layer systems problem: sequencing, state, settlement, and the data-availability (DA) bandwidth gap that bounds all three. Simulation and analytical modeling support the architecture, and prototype measurements validate selected components, but no end-to-end Layer Core implementation exists yet. Practical deployment is currently constrained to roughly 10K-100K TPS by DA throughput, leaving a ~100x gap at the target ceiling. AGNT2 argues that the agent economy requires a dedicated execution layer rather than a general-purpose chain repurposed for agents.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 1 minor

Summary. The paper claims that existing general-purpose L2 blockchains (Optimism, Arbitrum, zkSync) optimize for human financial transactions and inefficiently treat high-frequency agent interactions as generic calldata, forcing identity, escrow, dependency ordering, and session state to be handled above the execution layer at suboptimal cost. It proposes AGNT2, a three-tier dedicated stack—Layer Top P2P state channels for bilateral pairs, Layer Core as a dependency-aware sequenced rollup for multi-party interactions, and Layer Root with fraud proofs on EVM L1—plus a sidecar pattern for unmodified Docker agents and an agent-native execution environment with interaction trie. The architecture is supported by simulations, analytical modeling, and prototype measurements for selected components, but the paper notes no end-to-end Layer Core implementation and a ~100x DA bandwidth gap limiting practical TPS to 10K-100K versus design targets of 300K-500K.

Significance. If the central architectural claims hold, AGNT2 could enable more efficient on-chain coordination for autonomous agent economies by making service invocation, identity, reputation, and session context first-class objects. The paper explicitly credits its simulations, analytical modeling, and component prototypes as supporting evidence while acknowledging current practical constraints.

major comments (3)
  1. [Abstract / Introduction] Abstract and architecture motivation: the central claim that general-purpose L2s inherently force identity, escrow, dependency ordering, and session state to be encoded above the execution layer at the wrong cost point, necessitating the three-tier AGNT2 stack, lacks direct empirical support. No benchmarks or counterfactual simulations compare agent workloads on optimized general-purpose L2s (with potential extensions like agent-native primitives) against the proposed specialized tiers.
  2. [Abstract] Abstract (DA bandwidth gap discussion): the design targets 300K-500K TPS for Layer Core and 1K-5K TPS per Layer Top pair, yet acknowledges the same ~100x DA gap bounds practical deployment to 10K-100K TPS. The paper provides no quantitative modeling showing how the dependency-aware sequencing, interaction trie, or sidecar pattern closes this gap more effectively than extensions to existing rollups.
  3. [Architecture and Evaluation] Architecture and evaluation sections: while simulations and prototypes validate selected AGNT2 internals, the absence of an end-to-end Layer Core implementation leaves the performance claims (e.g., 500 ms-2 s latency, high aggregate TPS) without full empirical grounding, undermining the assertion that a dedicated layer is required rather than repurposed infrastructure.
minor comments (1)
  1. [Architecture] Notation for the interaction trie and dependency-aware sequencing could be clarified with a small example or diagram to make the first-class protocol objects more accessible.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the detailed and constructive comments. We address each major comment below, clarifying the scope of the manuscript's claims and indicating where revisions will be made to strengthen the presentation.

read point-by-point responses
  1. Referee: [Abstract / Introduction] Abstract and architecture motivation: the central claim that general-purpose L2s inherently force identity, escrow, dependency ordering, and session state to be encoded above the execution layer at the wrong cost point, necessitating the three-tier AGNT2 stack, lacks direct empirical support. No benchmarks or counterfactual simulations compare agent workloads on optimized general-purpose L2s (with potential extensions like agent-native primitives) against the proposed specialized tiers.

    Authors: The manuscript frames AGNT2 as an architectural proposal grounded in the observed mismatch between general-purpose L2 calldata handling and the requirements of high-frequency agent interactions. Analytical models and component simulations quantify overheads for identity, escrow, and dependency management when performed above the execution layer. We do not include direct counterfactual benchmarks against extended general-purpose L2s, as the work prioritizes defining and evaluating the dedicated three-tier design. We will add a discussion subsection contrasting the proposed primitives with potential agent-native extensions to existing rollups to better articulate why the specialized tiers address the cost-point issue. revision: partial

  2. Referee: [Abstract] Abstract (DA bandwidth gap discussion): the design targets 300K-500K TPS for Layer Core and 1K-5K TPS per Layer Top pair, yet acknowledges the same ~100x DA gap bounds practical deployment to 10K-100K TPS. The paper provides no quantitative modeling showing how the dependency-aware sequencing, interaction trie, or sidecar pattern closes this gap more effectively than extensions to existing rollups.

    Authors: The DA bandwidth constraint is acknowledged as fundamental to all current rollup architectures, including AGNT2; the design targets represent idealized maxima while practical bounds reflect existing DA throughput. Analytical modeling in the paper quantifies achievable TPS for AGNT2 under these constraints, showing efficiency from the interaction trie and dependency-aware sequencing in minimizing per-interaction state and calldata. Comparative modeling against hypothetical extensions to other rollups is not provided, as it would require unspecified implementation details of those extensions. We will revise the abstract and DA discussion to more explicitly separate design targets from practical limits and reference the provided modeling. revision: partial

  3. Referee: [Architecture and Evaluation] Architecture and evaluation sections: while simulations and prototypes validate selected AGNT2 internals, the absence of an end-to-end Layer Core implementation leaves the performance claims (e.g., 500 ms-2 s latency, high aggregate TPS) without full empirical grounding, undermining the assertion that a dedicated layer is required rather than repurposed infrastructure.

    Authors: The manuscript already states that no end-to-end Layer Core implementation exists and that evaluation rests on simulations, analytical models, and selected-component prototypes. We agree this limits the empirical grounding of aggregate performance projections. The case for a dedicated layer derives from the systems analysis of sequencing, state, and settlement mismatches rather than solely from full-system measurements. We will revise the evaluation section to more prominently caveat the latency and TPS figures as modeled projections and to reinforce that the architectural necessity follows from the identified execution-layer inefficiencies. revision: yes

Circularity Check

0 steps flagged

No significant circularity in derivation chain

full rationale

The paper advances an architectural proposal for a specialized three-tier execution layer (Layer Top, Layer Core, Layer Root) tailored to autonomous agent interactions, grounded in analysis of cost-point mismatches in existing general-purpose L2s such as Optimism, Arbitrum, and zkSync. It supports the design with simulations, analytical modeling, and component prototypes but contains no equations, fitted parameters, or predictions that reduce by construction to the paper's own inputs. No self-citations, uniqueness theorems, or ansatzes are invoked as load-bearing elements; the central claim that dedicated infrastructure is required rests on forward engineering choices and acknowledged DA bandwidth constraints rather than self-referential reductions. The derivation is therefore self-contained and externally falsifiable against benchmarks on repurposed chains.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 3 invented entities

The central claim rests on several new architectural components and performance assumptions that lack full empirical validation in the abstract.

axioms (2)
  • domain assumption Fraud proofs anchored to EVM L1 provide adequate security for settlement
    Invoked for Layer Root in the three-tier design.
  • domain assumption P2P state channels can sustain sub-100 ms latency and high TPS for bilateral pairs
    Design target stated for Layer Top.
invented entities (3)
  • Layer Top P2P state channels no independent evidence
    purpose: Handle established bilateral agent pairs at high speed
    New layer introduced for low-latency interactions
  • Layer Core dependency-aware sequenced rollup no independent evidence
    purpose: Manage first-contact and multi-party agent interactions
    Core sequencing and state management mechanism
  • Agent-native execution environment and interaction trie no independent evidence
    purpose: Treat service invocation, identity, reputation, and session state as first-class protocol objects
    Specialized runtime and data structure for agents

pith-pipeline@v0.9.0 · 5639 in / 1485 out tokens · 57685 ms · 2026-05-09T22:14:28.696186+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

56 extracted references · 7 canonical work pages

  1. [1]

    Z.Ye,U.Misra,J.Cheng,W.Zhou,andD.Song,Specular: Towards Secure, Trust-minimized Optimistic Blockchain Execution, IEEE S&P, 2024

  2. [2]

    Z. Sun, Z. Li, X. Peng, X. Luo, M. Jiang, H. Zhou, and Y. Zhang,DoubleUp Roll: Double-spending in Arbitrum by Rolling It Back, ACM CCS, 2024. 12

  3. [3]

    C. F. Torres, A. Mamuti, B. Weintraub, C. Nita-Rotaru, and S. Shinde,Rolling in the Shadows: Analyzing the Extraction of MEV Across Layer-2 Rollups, ACM CCS, 2024

  4. [4]

    Breidenbach, and A

    P.Daian,S.Goldfeder,T.Kell,Y.Li,X.Zhao,I.Bentov,L. Breidenbach, and A. Juels,Flash Boys 2.0: Frontrunning inDecentralizedExchanges,MinerExtractableValue,and Consensus Instability, IEEE S&P, 2020

  5. [5]

    Kelkar, S

    M. Kelkar, S. Deb, S. Long, A. Juels, and S. Kannan, Themis: Fast, Strong Order-Fairness in Byzantine Consen- sus, ACM CCS, 2023

  6. [6]

    G.Danezis,L.Kokoris-Kogias,A.Sonnino,andA.Spiegel- man,Narwhal and Tusk: A DAG-Based Mempool and Efficient BFT Consensus, EuroSys, 2022

  7. [7]

    S. Mu, Y. Cui, Y. Zhang, W. Lloyd, and J. Li,Extracting More Concurrency from Distributed Transactions, OSDI, 2014

  8. [8]

    T. Xu, Y. Zhong, Y. Zhang, R. Xiong, J. Zhang, G. Xue, and S. Liu,Vegeta: Enabling Parallel Smart Contract Execution in Leaderless Blockchains, NSDI, 2025

  9. [9]

    K.Wüst,S.Matetic,S.Egli,K.Kostiainen,andS.Capkun, ACE:AsynchronousandConcurrentExecutionofComplex Smart Contracts, ACM CCS, 2020

  10. [10]

    Wang and H

    J. Wang and H. Wang,Monoxide: Scale Out Blockchains with Asynchronous Consensus Zones, NSDI, 2019

  11. [11]

    Ramseyer, A

    G. Ramseyer, A. Goel, and D. Mazieres,SPEEDEX: A Scalable, Parallelizable, and Economically Efficient De- centralized Exchange, NSDI, 2023

  12. [12]

    Optimism Foundation,OP Stack Specification, https://specs.optimism.io, 2022-2026

  13. [13]

    Offchain Labs,Arbitrum Nitro: A Second-Generation Optimistic Rollup, https://docs.arbitrum.io/nitro- whitepaper.pdf, 2022

  14. [14]

    LazyLedger: A Distributed Data Availability Ledger With Client-Side Smart Contracts.arXiv preprint arXiv:1905.09274, 2019

    M. Al-Bassam,LazyLedger: A Distributed Data Availability Ledger With Client-Side Smart Contracts, arXiv:1905.09274, 2019

  15. [15]

    Eigen Labs,EigenDA: The Hyperscale Verifiable Data Availability Layer, https://docs.eigencloud.xyz/eigenda, 2023-2026

  16. [16]

    Buterin et al.,EIP-4844: Shard Blob Transactions, Ethereum Improvement Proposals, 2022

    V. Buterin et al.,EIP-4844: Shard Blob Transactions, Ethereum Improvement Proposals, 2022

  17. [17]

    Poon and T

    J. Poon and T. Dryja,The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments, 2016

  18. [18]

    Anthropic,Model Context Protocol Specification, https://modelcontextprotocol.io, 2024-2026

  19. [19]

    GoogleandtheLinuxFoundation,Agent-to-AgentProtocol Specification, https://a2a-protocol.org, 2025-2026

  20. [20]

    Valory AG,Autonolas Whitepaper v1.0, 2023

  21. [21]

    M.Wooldridgeetal.,Fetch.ai: AnArchitectureforModern Multi-Agent Systems, arXiv:2510.18699, 2025

  22. [22]

    S. Zhou, K. Wang, and H. Yin,Dstack: A Zero Trust FrameworkforConfidentialContainers,arXiv:2509.11555, 2025

  23. [23]

    D. M. Rothschild, M. Mobius, J. M. Hofman, E. W. Dillon, D. G. Goldstein, N. Immorlica, S. Jaffe, B. Lucier, A. Slivkins, and M. Vogel,The Agentic Econ- omy, arXiv:2505.15799, 2025

  24. [24]

    M.Stein,HowAreAIAgentsUsed? Evidencefrom177,000 MCP Tools, arXiv:2603.23802, 2026

  25. [25]

    Agent-OSI: A Six-Layer Reference Stack for Decentralized Agent Networking, arXiv:2602.13795, 2026

  26. [26]

    UltraHorizon: Long-HorizonAgentReasoningBenchmark, arXiv:2509.21766, 2025

  27. [27]

    Androulaki et al.,Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains, EuroSys, 2018

    E. Androulaki et al.,Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains, EuroSys, 2018

  28. [28]

    Cosmos SDK,Cosmos SDK Documentation, Online docu- mentation, 2026

  29. [29]

    Ritual Network,Ritual Documentation, Online documen- tation, 2026

  30. [30]

    Foundation for Intelligent Physical Agents,FIPA ACL Message Structure Specification, 2002

  31. [31]

    Finin, R

    T. Finin, R. Fritzson, D. McKay, and R. McEntire,KQML as an Agent Communication Language, CIKM, 1994

  32. [32]

    Kubernetes,Kubernetes Documentation, Online documen- tation, 2026

  33. [33]

    Istio,Istio Documentation, Online documentation, 2026

  34. [34]

    Envoy Proxy,Envoy Documentation, Online documenta- tion, 2026

  35. [35]

    Moritz, R

    P. Moritz, R. Nishihara, S. Wang, A. Tumanov, R. Liaw, E. Liang, M. Elibol, Z. Yang, W. Paul, M. I. Jordan, and I. Stoica,Ray: A Distributed Framework for Emerging AI Applications, OSDI, 2018

  36. [36]

    Bebel and D

    J. Bebel and D. Ojha,Ferveo: Threshold Decryption for Mempool Privacy in BFT Networks, Cryptology ePrint Archive, Paper 2022/898, 2022

  37. [37]

    Buterin, D

    V. Buterin, D. C. A. Johnson, Y. Weiss, S. Bains, and others,EIP-4337: AccountAbstractionUsingAltMempool, Ethereum Improvement Proposals, 2021-2026

  38. [38]

    Coinbase Developer Platform,Agentic Wallet Doc- umentation, https://docs.cdp.coinbase.com/agentic- wallet/welcome, 2026

  39. [39]

    De Rossi, D

    M. De Rossi, D. Crapis, J. Ellis, and E. Reppel,EIP- 8004: Trustless Agents, Ethereum Improvement Proposals, 2025-2026

  40. [40]

    clawed back

    Coinbase Developer Platform,x402 Documentation, https://docs.cdp.coinbase.com/x402/welcome, 2025-2026. Theappendicesholdthefulltechnicaldetailsforreviewerswho want them: protocol grammar, failure handling, derivations, schemas, extended related work, and evidence mapping. 13 // Agent lifecycle REGISTER { agent _id, name, capabilities[], stake, metadata } ...

  41. [41]

    Looks up B in registry

  42. [42]

    Posts full params to DA

  43. [43]

    Submits INVOKE tx --------> INVOKE included in block N Payment escrowed t=2 Block N propagates t=3 v--------------------> B’s sidecar:

  44. [44]

    Sees INVOKE in block N

  45. [45]

    Fetches params from DA

  46. [46]

    Gets response

    Calls local container t=4 Container processes t=5 5. Gets response

  47. [47]

    Submits RESPOND tx RESPOND in block N+k Escrow released to B t=6 A’s sidecar: <-------------+

    Posts result to DA <-------------------- 8. Submits RESPOND tx RESPOND in block N+k Escrow released to B t=6 A’s sidecar: <-------------+

  48. [48]

    Fetches result from DA

  49. [49]

    Paid 0.001 AGNT

    Delivers to A’s container t=7 A has the result. Paid 0.001 AGNT. Fully verified on-chain. audit path asunavailable. By re-execution alone, an auditor can’t prove cryptographically that the attested output was wrong. In our current scope, deterrence comes only from the economic and reputational structure, with reputation decay and interaction history cost ...

  50. [50]

    Type 1 batch pre-state retrievalisasequentialblobfetch,soDAreadamplification is minimal

    T_DA: retrieving the challenged batch pre-state from the DA layer — 1–5 minutes under current EigenDA, ac- counting for geographic distance. Type 1 batch pre-state retrievalisasequentialblobfetch,soDAreadamplification is minimal

  51. [51]

    T_detect: computingthecorrectstaterootbyre-executing the batch and comparing — under 1 minute, dominated by sequential trie execution of at most 250K typed operations

  52. [52]

    T_proof: constructing the fraud proof transaction that referencespre-stateanddisputingbatch—under1minute

  53. [53]

    agent marketplace on Fabric

    T_submit: submitting the proof transaction and achieving Layer Root inclusion — under 5 minutes at expected congestion. The worst honest case still fits: T_DA + T_detect + T_proof + T_submit stays inside our budget of about8–12 minutes. The 1-hour window is therefore conservative, with a 5–7× safetymarginforDAoutages,includingpartitionrecoveryand monitorr...

  54. [54]

    Each transaction contributes exactly one edge per de- clared dependency; no pairwise intersection computation is needed

    O(n) construction instead of O(n²) conflict detection. Each transaction contributes exactly one edge per de- clared dependency; no pairwise intersection computation is needed. This is a direct consequence of the domain narrowing, not an algorithmic improvement over Vegeta — it is infeasible in Vegeta’s setting because EVM storage access patterns are not d...

  55. [55]

    TheINVOKE-before-RESPONDinvariantispartofthein- teraction protocol’s correctness definition; violating it is a protocol fault

    Correctness semantics, not performance optimization. TheINVOKE-before-RESPONDinvariantispartofthein- teraction protocol’s correctness definition; violating it is a protocol fault. In ROCOCO/Vegeta’s setting, dependency- order violation is a serializability violation — a perfor- mance/consistency issue, but the transactions are still "valid" computations u...

  56. [56]

    Vegeta plus agents

    Trustdomain.ROCOCOtargetssymmetric-trustdatabase participants; Vegeta targets permissioned BFT validators; AGNT2 targets mutually-untrusting agents across organi- zational boundaries. The declared-dependency approach in AGNT2 relies on thecallee’ssignature on a RESPOND naming its parent INVOKE — the dependency edge is cryptographically attested by a mutua...