{"id":"0826930e-96d1-46b0-9a2d-c4f5067cfef5","arxiv_id":"2602.13795","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"Agent-OSI gives agents a layered interoperability stack and an HTTP-402 payment challenge, with a prototype showing ~51% lower on-chain settlement cost when negotiation and delivery stay off-chain.","lead":"Agent-OSI is a six-layer protocol stack that would let AI agents from different platforms discover, talk to, and pay each other without one company in the middle. A prototype test finds that keeping negotiation and delivery off the blockchain cuts on-chain settlement cost by about 51% while keeping receipts verifiable.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"L5 'verifiable execution' is signed logs that the L4 escrow cannot check; the claimed binding of payment to execution depends on an unspecified off-chain completion/dispute rule, so 'verifiable settlement' is not actually demonstrated.","rationale":"The reader's conditional verdict and weakest-assumption analysis identify the core gap: L5 is instantiated with signed provenance logs that the L4 escrow contract cannot verify, so the claimed 'verifiable settlement' depends on an off-chain verifier/completion/dispute mechanism that is neither specified nor implemented. This is exactly the load-bearing concern for the architecture's central promise. The paper itself signals this in Section VI, admitting disputes are under-specified and 'verifiable execution' has ambiguous meaning. The prototype is a reasonable systems contribution, and the measured cost/latency numbers are useful, but the headline claim of cryptographically binding payment to execution via an escrow is not realized in the current code. The reader's verdict of CONDITIONAL with medium correctness risk is appropriate. I did not find a different, stronger concern: the 'over 95%' vs '~51%' discrepancy is a presentation issue, but the verifiability gap is more fundamental. Independent support (public reproducible code, clear measurements) is acknowledged, but it does not close the gap because the relevant enforcement logic is absent. Therefore I recommend no change to the reader's verdict.","tokens_in":10080,"tokens_out":2169,"duration_ms":23480,"concrete_test":"Inspect the escrow contract's release function in the public prototype repository (agent-market). If release does not verify (a) an ECDSA signature over requestHash and output CID by the SA's L3 identity, and (b) that the signed execution-log hash matches a value committed during the lock phase, then the claim is not implemented. Concretely, run an adversarial test: have the SA lock payment, return a provenance object with no actual computation, and call release. If funds are released, on-chain settlement does not verify execution, and the 'verifiable settlement' claim fails. This test settles whether the measured gas reduction preserves a meaningful binding between payment and execution.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that Agent-OSI provides an architecture where HTTP 402 bridges application intent with 'verifiable settlement' that 'cryptographically binds payments to execution provenance (L5)'. The prototype instantiates L5 as signed, auditable execution logs (Section V.A.2), and the escrow contract releases funds per a 'completion rule' (Fig. 2, step 13). However, the paper never specifies or implements an on-chain check of the L5 provenance signature, the execution-log hash, or the output CID. The EVM escrow can only verify the payment/receipt event, not that the service actually performed the agreed computation. Sections III.E and VI admit that TEE/ZK/signed logs have different assurance levels and that disputes are 'especially under-specified'. Thus the 51% gas savings are achieved by moving execution evidence off-chain while the settlement contract is blind to it. Without an off-chain verifier, arbitration rule, or a contract that can verify the signed evidence, a malicious SA can lock payment, return arbitrary provenance, and still have escrow release funds. The claim that settlement is 'verifiable' in a trust-minimized sense is therefore not supported by the prototype; it is deferred to unspecified future dispute mechanisms. This is the weakest load-bearing assumption because the value of the architecture rests on the payment-to-execution binding.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":10445,"tokens_out":3937,"duration_ms":34690,"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":[{"comment":"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.","section":"§I vs §V-B-1"},{"comment":"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","section":"§III.E, §V.A.2, §IV.D (Fig. 2, step 13)"},{"comment":"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.","section":"§V-B-1"}],"minor_comments":[{"comment":"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.","section":"General"},{"comment":"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.","section":"Fig. 3 caption"},{"comment":"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.","section":"§V-B-1"},{"comment":"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.","section":"§VI.4"}],"recommendation":"major_revision","confidential_remarks":"The paper is a systems/architecture proposal with a prototype, and it is within the scope of a networking venue. The main concerns are overclaiming in the introduction and the lack of a true L4–L5 binding. These are fixable in revision by either implementing a lightweight on-chain check (e.g., commit/reveal of provenance hash) or by reframing the contribution as an auditable architecture with explicit trust assumptions. I do not see a fundamental circularity or fabricated-results issue; the measured numbers look plausible and the baseline, while under-specified, is likely fair once clarified."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Read Agent-OSI. My take: the useful contribution is the HTTP 402 payment-challenge pattern and the clean six-layer decomposition; the strongest claims about verifiable settlement, however, run ahead of what the prototype actually enforces.\n\nWhat is new: the composition. None of the individual primitives are novel — MLS, DIDs, ILP, escrow contracts, MCP all exist — but organizing them into a six-layer stack with explicit cross-layer bindings, and treating HTTP 402 as a generic payment challenge in the same spirit as HTTP 401, is a fresh and useful design move. The field needs exactly this kind of plumbing. The prototype instantiates the whole stack with commodity tools, the code is public, and the measurements are reported properly with medians and p10–p90 ranges. The ~51% gas reduction for off-chain negotiation/delivery compared with the Web3 escrow baseline is supported by the reported experiments, and the latency decomposition convincingly shows that generative execution dominates settlement confirmation for heavy workloads.\n\nThree soft spots, in order of importance. First, the introduction claims 'over 95%' reduction in on-chain interactions, but no such metric is defined or measured; the abstract and Section V report ~51% gas reduction. Those are different quantities, but the 95% figure is dangling and reads as overclaiming. Second, the Web3 baseline is under-specified — we are told it anchors order/session metadata on-chain, but not what contract operations are included, which makes the 51% number hard to audit. Third, and most substantive: L5 in the prototype is signed execution logs, and the escrow contract cannot verify those signatures, the log hash, or the output CID. It only checks payment events. So 'verifiable settlement' as demonstrated means verifiable payment, not verifiable execution. The payment-to-execution binding depends on an off-chain verifier or dispute mechanism that is not specified or implemented. The authors do acknowledge this in Section VI, which is to their credit, but the abstract and introduction get ahead of it.\n\nNone of this kills the architecture. The modular design can accommodate TEE or ZK attestations later, and the open-issues section is honest about what is missing. The paper just needs to calibrate its claims to the prototype.\n\nWho it is for: researchers and engineers working on agent interoperability, decentralized payment rails, or agent marketplaces. It deserves a serious referee — I would accept it for review and recommend major/minor revision, mainly to fix the 95%/51% discrepancy and rewrite the verifiability language. I'd bring it to a reading group if the group follows IoA systems; otherwise it is a competent architecture paper worth citing.","headline":"Solid systems architecture; the 402-as-payment-challenge pattern is the real contribution, but the settlement-verifiability claim outruns what the prototype actually enforces.","tokens_in":10885,"tokens_out":3002,"would_cite":true,"duration_ms":26357,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["Internet of Agents","Agent-OSI","HTTP 402","protocol stack","decentralized AI","verifiable execution","A2A messaging","blockchain escrow"],"falsifier":"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.","tokens_in":9977,"feed_emoji":"🤖","tokens_out":10623,"duration_ms":84731,"temperature":0.7,"pith_summary":"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.","feed_headline":"Agent-OSI makes HTTP 402 a payment challenge for autonomous agents","feed_subtitle":"The six-layer stack cuts on-chain session costs by about 51% while keeping each payment tied to a verifiable receipt","key_machinery":"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","core_discovery":"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","pith_inferences":["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."],"forward_implications":["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."],"fun_headline_variants":["Agent-OSI turns HTTP 402 into a payment challenge for agents","Web-compatible settlement for the Internet of Agents","Agent-OSI cuts on-chain settlement costs by 51%","HTTP 402 as the missing payment layer for autonomous agents"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Agent-OSI turns HTTP 402 into a payment challenge for agents","Web-compatible settlement for the Internet of Agents","Agent-OSI cuts on-chain settlement costs by 51%","HTTP 402 as the missing payment layer for autonomous agents"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000189,"raw_usage":{"total_tokens":1189,"prompt_tokens":777,"completion_tokens":412,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":521,"completion_tokens_details":{"reasoning_tokens":342}},"tokens_in":521,"tokens_out":412,"duration_ms":4692,"temperature":1.0,"reasoning_tokens":342,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-02T23:24:55.650261+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[],"review_version":1}