Pith. sign in

REVIEW 3 major objections 4 minor 2 cited by

Agent-OSI proposes a six-layer reference stack that turns HTTP 402 into a payment challenge, letting autonomous agents interoperate and settle pay-per-use services across platforms.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-02 23:24 UTC pith:3VNSO5XL

load-bearing objection Solid systems architecture; the 402-as-payment-challenge pattern is the real contribution, but the settlement-verifiability claim outruns what the prototype actually enforces. the 3 major comments →

arxiv 2602.13795 v2 pith:3VNSO5XL submitted 2026-02-14 cs.NI

Agent-OSI: An Interoperability Architecture for Communication and Settlement in the Decentralized Internet of Agents

Wenxin Xu , Taotao Wang , Yihan Xia , Shengli Zhang , Soung Chang Liew This is my paper
classification cs.NI
keywords Internet of AgentsAgent-OSIHTTP 402protocol stackdecentralized AIverifiable executionA2A messagingblockchain escrow
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

The paper proposes Agent-OSI, a six-layer reference stack for a decentralized Internet of Agents: secure transport, asynchronous agent messaging, identity and authorization, settlement and metering, verifiable execution and provenance, and semantic interoperability and orchestration. Its central move is to treat HTTP 402 (Payment Required) as an application-level payment challenge—like HTTP 401 for authentication—so a service returns a signed quote, the client pays through a pluggable payment backend (escrow contract, payment channel, or signed off-chain receipt), and the client's receipt binds payment to the specific request. The prototype, AgentMarket, uses a blockchain escrow for settlement and signed execution logs for verifiable provenance. In the paper's measurements, keeping negotiation and delivery off-chain cuts on-chain session gas by roughly 51% relative to a more on-chain baseline, and for generative workloads the blockchain confirmation time is largely hidden by task execution. If the architecture holds, agents from different vendors could discover, pay for, and verify each other's work without a central platform as the trust anchor.

Core claim

The paper's central claim is that the Web's existing 402 status code can be repurposed as a generic 'payment challenge': a machine-readable demand for payment carrying a signed quote, routing information, expiration, nonce, and receipt-verification rules. This turns payment into the same kind of challenge-response step as authentication, while leaving the actual settlement rail—escrow contract, payment channel, signed off-chain receipt—as a pluggable choice. Agent-OSI then ties layers together with signed artifacts: the quote is bound to the request hash and nonce, the receipt is verified against on-chain events, and the provenance object binds the delivered artifact to the service agent's i

What carries the argument

The load-bearing mechanism is the HTTP 402 Payment Challenge: a 402 response carries a signed quote with price, payee identity, payment network, expiration, nonce, and a receipt specification, so payment becomes a challenge-response step rather than a proprietary billing call. On top of that, the stack defines controlled cross-layer artifacts—the quote (Layer 4, settlement and metering), the receipt, and a provenance object (Layer 5, verifiable execution and provenance) that binds the output to the service identity via a signed execution-log hash and content hash. These signed artifacts, along with the request-hash/nonce binding, are what prevent a service from equivocating between what was

Load-bearing premise

The stack's 'verifiable settlement' assumes that an off-chain verifier will inspect the signed execution log and decide the work was actually done, because the prototype's escrow contract checks only the payment receipt—not the execution evidence—and the paper does not implement such a verifier, completion rule, or dispute mechanism.

What would settle it

Run the AgentMarket prototype with a service agent that signs an execution log for one task but returns a different artifact; if the escrow releases funds after receipt verification, without any check of the log's content or correspondence to the delivered artifact, then 'verifiable execution' is not enforced and the central settlement claim fails.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • Any HTTP-speaking service can expose a pay-per-use API by returning a 402 challenge; the client needs no proprietary billing SDK, only a way to read the signed quote and produce a verifiable receipt.
  • Per-session on-chain execution cost drops by about 51% (from roughly 326k to 159k gas) when negotiation and delivery stay off-chain, making decentralized settlement more affordable for high-frequency agent interactions.
  • For generative workloads, settlement confirmation can be as little as a third of total time and is masked by model execution, so on-chain payment is practical for tasks like image generation.
  • For lightweight, high-frequency tool calls, settlement confirmation dominates latency, so asynchronous or batched settlement is needed in that regime—a boundary the paper states explicitly.
  • Replay protection follows from binding each receipt to a request hash and nonce, so retries and idempotent payments are safe without double-spending.

Where Pith is reading between the lines

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

  • Editorial extension: if the 402 challenge body were standardized as a common header or JSON envelope, existing HTTP APIs could become agent-payable with minimal changes; the paper stops short of proposing that standard, but its design implies it.
  • Editorial extension: composing outputs from multiple agents would create a chain of receipts and provenance objects; the paper does not specify composite provenance verification, so a two-agent pipeline would be a natural stress test of the stack's audit trail.
  • Editorial extension: swapping the signed-log L5 backend for a TEE attestation or zero-knowledge proof in the same stack would quantify how much stronger assurance costs in gas and latency; the paper leaves that comparison open.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. The paper proposes Agent-OSI, a six-layer reference stack for a decentralized Internet of Agents, built on top of TCP/IP and existing Web standards. The central idea is to treat HTTP 402 (Payment Required) as an application-level payment challenge—analogous to HTTP 401 for authentication—that triggers settlement through pluggable backends, instantiated in the prototype as an EVM escrow contract. The architecture layers cover connectivity/messaging, identity/auth, settlement/metering, verifiable execution/provenance, and semantic interoperability. The authors implement a prototype ('AgentMarket') using XMTP, ECDSA identities, an Ethereum escrow on a local Anvil testbed, and signed execution logs, and they evaluate cost, latency, and throughput. The measured results show that keeping negotiation and delivery off-chain reduces per-session gas cost by approximately 51% relative to a Web3 baseline, and that for generative workloads, blockchain confirmation latency is largely masked by task execution time.

Significance. If the claims are fully supported, Agent-OSI would be a valuable reference architecture for agent interoperability. The paper names a concrete, Web-compatible mechanism (HTTP 402) for pay-per-use settlement, identifies cross-layer interfaces, and provides a public prototype with careful latency/cost measurements using medians and p10–p90 ranges. The honest discussion of open issues (Section VI) is a strength. However, the load-bearing claim of 'verifiable settlement' is not actually demonstrated by the prototype, and the headline cost-reduction numbers are inconsistent between the introduction and the evaluation. These issues must be resolved before the architectural contribution can be accepted as stated.

major comments (3)
  1. [§I vs §V-B-1] The Introduction (second contribution bullet) claims that keeping negotiation and delivery off-chain 'reduces on-chain interactions by over 95% compared with a more on-chain interaction baseline.' The Abstract and Section V-B-1 report a ~51% reduction in session gas cost (≈326k to ≈159k gas). If 'on-chain interactions' means transaction count rather than gas, that metric is never measured or reported in Section V. If the 95% figure is a typo or refers to a different baseline, the paper must state the precise metric and provide the corresponding data. As written, the headline claim is inconsistent with the experiments.
  2. [§III.E, §V.A.2, §IV.D (Fig. 2, step 13)] The paper claims that Agent-OSI 'cryptographically binds payments to execution provenance (L5)' and that escrow release is governed by a 'completion rule' that may reference L5 evidence. In the prototype, L5 is a signed, auditable execution log, and the EVM escrow contract verifies only the payment event (quote/nonce/request hash) and the escrow release condition—not the signature on the provenance log, the execution-log hash, or the output CID. There is no on-chain verification of L5 evidence, and no off-chain verifier, completion rule, or dispute mechanism is specified. Section VI.3 explicitly admits that disputes and admissible evidence are 'especially under-specified.' Consequently, 'verifiable settlement' in a trust-minimized sense is not demonstrated; a malicious service agent could lock payment and return arbitrary provenance, and the contract would still release funds. The paper
  3. [§V-B-1] The Web 3.0 baseline used for the 51% cost comparison is under-specified. The text says it is a 'dAPP escrow baseline that anchors order/session metadata on-chain to support dispute handling,' but no contract code, transaction sequence, or gas breakdown is given. To make the cost reduction reproducible, the baseline must specify which transactions are included (e.g., order creation, payment, release, dispute hook), what metadata is stored on-chain, and how gas is measured (base fee vs priority fee, total vs session-only). Without this, the reader cannot verify whether the comparison is fair or whether the ~51% figure is an artifact of an arbitrarily expensive baseline.
minor comments (4)
  1. [General] The manuscript contains several typos and formatting artifacts: 'TOW ARD' in the title header, 'e.g., e.g.,' in Section III.B, and garbled glyphs in Figure 1 (e.g., 'ὑ2', '/commen◎s'). A careful proofread is needed.
  2. [Fig. 3 caption] The caption uses 'Web 2.0 baseline' and 'Web 3.0 baseline' inconsistently: the panel (a) legend says 'Web 3.0 baseline (off-chain + escrow)' while the note below says 'Web 2.0 baseline ... has zero on-chain cost and is omitted.' Clarify which baseline is which.
  3. [§V-B-1] The definition of 'gasUsed' should be explicit: the sum of gas for which transactions? The text says 'sum of gas used over the minimal set of EVM transactions required to complete one paid session (network fees excluded).' Are base fee/priority fee excluded from gasUsed or from the cost metric? This is presumably standard gas units, but a precise statement improves reproducibility.
  4. [§VI.4] The open issue 'What does “verifiable execution” mean in practice?' is directly relevant to the paper's main contribution. Consider moving this discussion earlier (e.g., into Section III.E) to set expectations about assurance levels before the prototype evaluation.

Circularity Check

0 steps flagged

No significant circularity: the 51% gas reduction is a measured design comparison, not a prediction derived from fitted inputs; self-citations are background.

full rationale

Agent-OSI is a reference architecture, not a quantitative derivation. The central quantitative claim—approximately 51% on-chain gas reduction—is an experimental comparison between two implemented workflows (Section V-B-1, Fig. 3a): Agent-OSI keeps service gating/negotiation off-chain, while the Web3.0 baseline anchors session metadata on-chain. This is a design tradeoff measured directly, not a parameter fitted to data and then renamed a prediction; no equation in the paper is solved for a quantity that is then asserted as an independent result. The throughput bound sessions/s ≈ tx/s/2 is a conservation relation from the lock/release transaction count, not a fitted law. The main caveat is not circularity but an assurance gap: L5 is instantiated as signed provenance logs, and the escrow contract cannot itself verify those logs. Section VI explicitly concedes that "Disputes are especially under-specified" and that TEE/ZK/signed-log assurances are "often over-interpreted." That is an under-specified correctness claim, not a definitional reduction. Self-citations [3], [11], [14] are used only as background (Web3 survey, identity/account work, ZK option for L5); they are not invoked as an external uniqueness theorem or as the load-bearing justification for any predicted result. No ansatz is smuggled in via citation, and the layering reuses named standards (HTTP 402, DID, XMTP, in-toto) as declared building blocks rather than renaming a known empirical pattern as a new result. Therefore no circular step is exhibited.

Axiom & Free-Parameter Ledger

1 free parameters · 4 axioms · 0 invented entities

The stack itself contributes no fitted parameters; the only load-bearing hand-set number is the 2s Anvil block time, which the latency conclusion depends on. The core design rests on axioms about HTTP 402 semantics, signed logs as execution evidence, the adequacy of existing identity/messaging primitives, and local-chain fidelity to public-chain behavior. No new tokens, chains, or physical entities are introduced.

free parameters (1)
  • Anvil block_time = 2 s
    Fixed on the local Anvil testbed; controls the settlement-confirmation latency in Fig. 3(b). With a public 12s block time, the 'blockchain latency is masked by generative execution' conclusion would weaken.
axioms (4)
  • ad hoc to paper HTTP 402 can be repurposed as an application-level payment challenge with machine-readable quote/receipt semantics
    This is the paper's design premise: RFC 9110 only defines the status code; the paper assigns the quote/receipt semantics itself (Section III-D).
  • ad hoc to paper Signed execution logs are sufficient to bind payment to execution (L4-L5 binding) in the prototype
    Prototype L5 uses ECDSA-signed canonical logs rather than TEE/ZK; the escrow contract cannot verify them, so 'verifiable settlement' relies on an off-chain audit path not implemented (Section V-A-2, VI-4).
  • domain assumption Existing decentralized identity (DID/VC) and messaging (MLS/DIDComm/XMTP) primitives provide the security properties L3/L2 require
    The architecture inherits security, scalability, and durability from these protocols without demonstrating them in the prototype (Sections III-B, III-C).
  • domain assumption EVM escrow on a local Anvil testbed behaves like a public-chain settlement backend
    Latency and cost measurements use a local chain with fixed 2s block time; public-chain finality, fees, and RPC limits differ (Section V-B).

pith-pipeline@v1.3.0-alltime-deepseek · 9801 in / 14868 out tokens · 122839 ms · 2026-08-02T23:24:55.650261+00:00 · methodology

0 comments
read the original abstract

Large Language Models (LLMs) are accelerating the shift from an Internet of information to an Internet of Agents (IoA), where autonomous entities discover services, negotiate, execute tasks, and exchange value. Yet today's agents are still confined to platform silos and proprietary interfaces, lacking a common stack for interoperability, trust, and pay-per-use settlement. This article proposes \textit{Agent-OSI}, a functional interoperability architecture for a decentralized IoA, whose core contribution is agent-to-agent (A2A) communication and a Web-compatible, backend-agnostic settlement protocol built on HTTP 402 (Payment Required); identity, verifiable execution, and semantic orchestration are treated as boundary layers with interfaces to existing standards. We treat HTTP 402 as an application-layer challenge-response primitive -- analogous to HTTP 401 for authentication -- whose settlement backend (escrow contract, payment channel, or signed off-chain receipt) is a pluggable choice, instantiated via a blockchain escrow in our prototype. We implement a prototype and evaluate its communication and settlement performance. Results show that, for generative workloads, end-to-end latency is dominated by task execution rather than settlement confirmation, and that keeping negotiation and delivery off the settlement backend reduces per-session settlement cost by approximately 51\% relative to a more on-chain baseline.

Figures

Figures reproduced from arXiv: 2602.13795 by Shengli Zhang, Soung Chang Liew, Taotao Wang, Wenxin Xu, Yihan Xia.

Figure 1
Figure 1. Figure 1: The Agent-OSI reference stack, a six-layer agent stack [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Sequence diagram of the cross-layer interaction. The workflow coordinates A2A messaging, payment challenge and [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Performance of the Agent-OSI prototype. (a) [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗

discussion (0)

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

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. SoK: Blockchain Agent-to-Agent Payments

    q-fin.GN 2026-04 unverdicted novelty 7.0

    The first systematization of blockchain-based agent-to-agent payments organizes designs into discovery, authorization, execution, and accounting stages while identifying trust and security gaps.

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

    cs.MA 2026-04 unverdicted novelty 6.0

    AGNT2 introduces a dedicated three-tier execution layer for agent economies using sidecar agents, fast bilateral channels, sequenced multi-party rollups, and L1 settlement to address the mismatch with general-purpose chains.

Reference graph

Works this paper leans on

15 extracted references · 2 linked inside Pith · cited by 2 Pith papers

  1. [1]

    Internet of agents: Weaving a web of heterogeneous agents for collaborative intelligence,

    W. Chen, Z. You, R. Li, Y . Guan, C. Qian, C. Zhao, C. Yang, R. Xie, Z. Liu, and M. Sun, “Internet of agents: Weaving a web of heterogeneous agents for collaborative intelligence,” inProceedings of the International Conference on Learning Representations (ICLR), 2025

    2025

  2. [2]

    Internet of agents: Fundamentals, applications, and challenges,

    Y . Wang, S. Guo, Y . Pan, Z. Su, F. Chen, T. H. Luan, P. Li, J. Kang, and D. Niyato, “Internet of agents: Fundamentals, applications, and challenges,”IEEE Trans. Cogn. Commun. Netw., 2025, accepted in Oct. 2025; preprint available as arXiv:2505.07176

    arXiv 2025

  3. [3]

    Web 3.0: A survey on the architectures, enabling technologies, applications, and challenges,

    B. Cao, S. Xiao, L. Shi, T. Wang, J. Chen, J. Wang, X. Ling, H. Xu, S. Zhang, and E. Liu, “Web 3.0: A survey on the architectures, enabling technologies, applications, and challenges,”IEEE Commun. Surv. Tutor., 2025

    2025

  4. [4]

    Security of internet of agents: Attacks and countermeasures,

    Y . Wang, Y . Pan, S. Guo, and Z. Su, “Security of internet of agents: Attacks and countermeasures,”IEEE Open J. Comput. Soc., vol. 6, 2025

    2025

  5. [5]

    A survey on decentralized identifiers and verifiable credentials,

    C. Mazzoccaet al., “A survey on decentralized identifiers and verifiable credentials,”IEEE Commun. Surveys Tuts., 2025, early Access

    2025

  6. [6]

    Rfc 9420: The messaging layer security (mls) protocol,

    IETF, “Rfc 9420: The messaging layer security (mls) protocol,” https: //www.rfc-editor.org/rfc/rfc9420, 2023, accessed: 2026-01-25

    2023

  7. [7]

    Interledger protocol (ilp),

    Interledger, “Interledger protocol (ilp),” https://interledger.org/rfcs/, 2024, accessed: 2026-01-25

    2024

  8. [8]

    Rfc 9110: Http semantics,

    IETF, “Rfc 9110: Http semantics,” https://www.rfc-editor.org/rfc/ rfc9110, 2022, accessed: 2026-01-25

    2022

  9. [9]

    Slsa supply chain levels for software artifacts,

    OpenSSF, “Slsa supply chain levels for software artifacts,” https://slsa. dev/, 2024, accessed: 2026-01-25

    2024

  10. [10]

    in-toto: A framework to secure the software supply chain,

    in-toto Authors, “in-toto: A framework to secure the software supply chain,” https://in-toto.io/, 2024, accessed: 2026-01-25

    2024

  11. [11]

    Account service network: A unified decentralized web 3.0 portal with credible anonymity,

    T. Wang, S. Zhang, Q. Yang, and S. C. Liew, “Account service network: A unified decentralized web 3.0 portal with credible anonymity,”IEEE Netw., vol. 37, no. 6, pp. 101–108, 2023

    2023

  12. [12]

    Rfc 6749: The oauth 2.0 authorization framework,

    IETF, “Rfc 6749: The oauth 2.0 authorization framework,” https://www. rfc-editor.org/rfc/rfc6749, 2012, accessed: 2026-01-25

    2012

  13. [13]

    Ethereum: A secure decentralised generalised transaction ledger (yellow paper),

    G. Wood, “Ethereum: A secure decentralised generalised transaction ledger (yellow paper),” https://ethereum.github.io/yellowpaper/paper.pdf, 2014, accessed: 2026-01-25

    2014

  14. [14]

    Zero-knowledge federated learning: A new trustworthy and privacy-preserving distributed learning paradigm,

    T. Wang, Y . Jin, Q. Yang, Y . Xia, L. Shi, and S. Zhang, “Zero-knowledge federated learning: A new trustworthy and privacy-preserving distributed learning paradigm,”IEEE Commun. Mag., 2026, accepted in Jan. 2026; preprint available as arXiv:2501.15530

    Pith/arXiv arXiv 2026

  15. [15]

    Sdxl: Improving latent diffusion models for high- resolution image synthesis,

    D. Podellet al., “Sdxl: Improving latent diffusion models for high- resolution image synthesis,” https://arxiv.org/abs/2307.01952, 2023, arXiv:2307.01952

    Pith/arXiv arXiv 2023