{"id":"bce6eb4b-58d5-4d0c-ac97-49e705047c35","arxiv_id":"2505.00749","paper_version":2,"verdict":"CONDITIONAL","confidence":"LOW","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"The paper presents a protocol architecture, thread-based messaging tools, and a live Solana escrow contract for enabling interoperable, paid collaboration among AI agents.","lead":"Coral Protocol is a whitepaper describing an open infrastructure for interconnecting AI agents, with standardized messaging, coordination, and a Solana-based escrow payment system. It aims to become a vendor-neutral common layer for the emerging Internet of Agents.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Algorithm 1 omits Claim/refund logic and any task-completion predicate; as specified, funds release on the agent's own signature, so 'paid only when tasks are fulfilled' is not enforced.","rationale":"The strongest claim has two parts: an infrastructure proposal (communication/coordination) and a concrete payment artifact. The infrastructure parts are honestly scoped; Section 7 explicitly says team formation, role assignment, and orchestration are manually handled. The payment artifact is where the paper makes a falsifiable, live assertion. For that assertion to hold, the escrow program must actually condition release on task fulfillment. The manuscript's own Algorithm 1 does not contain such a condition, and the prose descriptions of claim point to self-authenticated withdrawal rather than verified completion. This is not a complaint about lack of formal verification or audit; it is an internal mismatch between the central claim and the supplied technical specification. The reader's weakest_assumption correctly flags absent audit/replication and network effects, but it does not identify the specific missing release predicate; hence partial agreement. A single source-level check, whether Claim contains any completion predicate, settles the issue. If it does not, the central claim cannot be accepted as stated; if it does, the paper should show that predicate. I keep the verdict CONDITIONAL rather than REJECT because the paper is a whitepaper and the missing logic may exist in deployed code that the pseudocode simply fails to present; however the condition must be explicit: release the actual Claim/refund source and demonstrate the completion check.","tokens_in":30983,"tokens_out":6468,"duration_ms":66551,"concrete_test":"Obtain the escrow program source referenced by the Coraliser repository and inspect the Claim instruction (Algorithm 1 omits it). If Claim's only checks are signer == agent_wallet, amount <= max_cap, claimed[agent_id] is false, and deadline not passed, run an Anchor integration test that calls init_session + deposit + claim with no task-completion oracle or authority approval; if the agent receives funds, the 'paid only when tasks are fulfilled' claim is falsified. If Claim instead requires an explicit task_completed flag signed by the session authority or an oracle, verify that the flag cannot be set by the claiming agent and re-run the same test. If no source is released, the conditional verdict should require that source as a precondition.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The paper's strongest concrete claim is that the live Solana escrow contract (Algorithm 1) enforces conditional payment so agents are paid only when tasks are fulfilled. The supplied contract logic does not support that claim. Algorithm 1 (Section 8.2) contains only InitSession and Deposit: it records authority, operator, agent ids, wallets, developer pubkeys and max_caps, checks input lengths and caps, and transfers tokens into a vault. It contains no release predicate tied to task completion, no requester-completion signal, and no verification step. The Claim and refund_leftover instructions that the narrative depends on (Section 8.3, Figure 6) are never defined in Algorithm 1. More importantly, the described claim path (Section 8.1) requires only that an agent prove with an Ed25519 signature that it is the 'rightful claimant'; the checks are identity, max_cap, and the six-hour window. Nothing in the state machine prevents an agent from calling claim immediately after Deposit, before any work is done. At best the escrow enforces identity, cap, and deadline conditions; the stronger statement that payment is conditioned on task fulfillment is unsupported by the presented design. This is an internal gap in the central artifact, not merely a missing audit.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents Coral Protocol, an open infrastructure intended to interconnect AI agents across vendors and platforms. It proposes thread-based messaging and coordination built on the Model Context Protocol (MCP), a 'Coral Server' that mediates agent interactions, a Coraliser toolchain for onboarding external agents and tools, and a Solana-based escrow contract for agent payments. The manuscript reviews related interoperability efforts (A2A, ANP, AGNTCY, NANDA, Synergetics, watsonx), describes the Coral architecture, introduces the escrow contract in Algorithm 1, reports a two-week testnet beta that processed $73k in mock USDC, and gives a GitHub-triggered intelligent software testing application as a use case. The authors position the protocol as filling a gap for communication, coordination, trust, and payments in multi-agent AI systems.","tokens_in":31174,"tokens_out":3405,"duration_ms":36316,"significance":"If the core claims were fully substantiated, the paper would be a useful position piece and protocol sketch for an important open problem: interoperability and incentivization in multi-agent AI systems. Its strengths include a clear layered architecture, a concrete and minimal escrow contract sketch with explicit invariants (caps, claim window, single-vault design), and a credible use case with a public repository link. The paper honestly discloses several limitations, notably that team formation and reputation are not yet implemented and that the current wallet is receive-only. However, the significance is currently limited because the central payment guarantee is not actually enforced by the presented contract logic, the 'live' escrow claim rests on self-reported testnet activity without independent audit or reproducibility, and several headline capabilities are explicitly deferred. The paper is better read as a design whitepaper than as a verified system description.","major_comments":[{"comment":"The central claim that the escrow contract enforces 'paid only when tasks are fulfilled' is not supported by the presented logic. Algorithm 1 defines only InitSession and Deposit; it contains no claim instruction, no refund instruction, and no task-completion predicate. The claim path described in Section 8.3 requires only an Ed25519 signature proving that the caller is the rightful agent, a check against max_cap, and the six-hour window. As specified, an agent can call claim immediately after Deposit and receive payment before performing any work. The contract as presented enforces identity, caps, and deadline, but not conditional fulfillment; this is a load-bearing gap between the paper's strongest promise and its technical artifact.","section":"Section 8.2, Algorithm 1"},{"comment":"There is an internal inconsistency about what is live. The Stage 1 row of the roadmap table states that Algorithm 1 already supports 'direct token deposits, withdrawals, and refunds,' but Algorithm 1 contains no withdrawal or refund procedures. Likewise, Section 8.3 states that the program contains 'just four public instructions,' while Algorithm 1 shows only two procedures. The testnet beta claim and the 'Live' status for Stage 1 therefore lack a matching, complete specification in the manuscript.","section":"Section 8.4 and Section 8.3"},{"comment":"The paper's Introduction lists Secure Team Formation and related coordination as core capabilities of Coral, but Section 7 states that team composition, role assignment, and coordination are currently handled manually by developers, and Figure 8.4/Table 1 shows reputation-driven selection as a 'Planned' Stage 3 item. The abstract and introduction overstate the current system. The manuscript should explicitly separate currently implemented features (thread-based messaging, escrow deposit, manual team orchestration) from roadmap features, otherwise readers cannot tell what the protocol actually provides today.","section":"Section 7"},{"comment":"The only empirical evidence for the escrow contract is a two-week public beta on Solana testnet that processed $73k in mock USDC without invariant breaches. This claim is reported without a deployment address, reproducible instructions, or a third-party audit report, and the contract logic is presented as pseudocode, not verified Solana program code. Given that the paper makes strong trustless-payment guarantees, this level of evidence is insufficient to support the 'live' and 'guarantee paid only when fulfilled' assertions. Please provide either the verified program with an audit trail or soften the claims to match the pseudocode-level validation.","section":"Section 8.4"}],"minor_comments":[{"comment":"The terms 'Coralised' and 'Coralized' are used inconsistently across sections; please standardize.","section":"Throughout"},{"comment":"The identifier 'M AX_AGEN T S' appears with spaces due to formatting; it should read MAX_AGENTS.","section":"Algorithm 1, line 15"},{"comment":"The text says the wallet is currently used only to receive payments once a team task is successfully completed, but Section 8 describes claim and refund flows. Please align these descriptions to clarify what is implemented versus envisioned.","section":"Section 6.1.2"},{"comment":"The sentence 'The ... scenario file defines the flow' contains a placeholder and should be completed or removed.","section":"Section 9.2"},{"comment":"The table is referred to as 'Table 8.4' in the text; it should be labeled with a caption and referenced by number consistently.","section":"Table in Section 8.4"},{"comment":"The caption says 'messages in grey are optional' but the figure is not embedded in the text provided; if the figure is included, please clarify what the grey elements denote.","section":"Figure 6"}],"recommendation":"major_revision","confidential_remarks":"The manuscript reads more like a project whitepaper than a complete research paper. The main scientific value is the concrete escrow contract sketch and the honest discussion of what is and is not implemented. However, the central 'conditional payment' guarantee is not actually present in the supplied algorithm, so the authors must either add the missing release predicate and refund/claim procedures, or substantially weaken the trustless-payment claims. I would encourage the editor to ask for a revised version that separates design from implementation and provides verifiable evidence for any 'live' status."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Dear colleague,\n\nThe headline: the strongest concrete claim in this whitepaper—that the Solana escrow contract pays agents only when tasks are fulfilled—is not supported by the contract logic presented in the paper. Algorithm 1 defines only InitSession and Deposit. The Claim and refund instructions are described in prose but never specified, and the described claim path requires only an Ed25519 signature proving identity, a cap check, and a six-hour window. Nothing stops an agent from calling claim immediately after deposit. The paper's own state machine does not tie payment to task completion. That is an internal gap, not merely a missing audit.\n\nNow the credit. The paper is a solid architecture survey: it honestly compares A2A, ANP, AGNTCY, NANDA, Synergetics, and watsonx Orchestrator, and it clearly identifies gaps it wants to fill. The thread-based messaging over MCP and the Coraliser automation are genuinely useful ideas; a plugin that turns any MCP server into a Coral agent is a practical on-ramp. The single-vault escrow design is coherent as far as it goes, and the two-week testnet beta with $73k in mock USDC is a real data point, though not independently reproducible from the manuscript.\n\nThe soft spots are proportionate. The payment-condition gap is load-bearing: it undermines the abstract's \"paid only when tasks are fulfilled\" and the Section 8 takeaway. Second, Section 7 admits team formation, role assignment, and reputation scoring are not implemented and are handled manually by developers, which conflicts with the introduction's framing of \"secure team formation capabilities\" as a core feature. The protocol's value depends on network effects that aren't demonstrated; every agent must run a Coral server and use its MCP tools, and there's no adoption evidence beyond the paper's own examples. No audit report, no formal verification, and the \"just four public instructions\" claim in Section 8.3 contradicts Algorithm 1's two procedures.\n\nThat said, the paper is unusually honest for a whitepaper. It flags its own limitations in Section 7 and the roadmap. It's a design proposal, not a validated research contribution.\n\nWho's it for? People working on agent interoperability standards or agent payment rails. It's worth reading as an architecture sketch and a survey, and it could spark a good conversation in a reading group, but I wouldn't cite it as a result.\n\nRecommendation: send it to peer review. A serious referee will have real work to do on the escrow claim and the framing gap, but the paper deserves that effort; it's a serious, well-structured proposal that engages the literature. Expect major revision.\n\nBest,\n[You]","headline":"A promising agent-interoperability architecture whose central payment guarantee is not actually enforced by the presented contract—worth peer review, not publication as-is.","tokens_in":31792,"tokens_out":3725,"would_cite":false,"duration_ms":33296,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":["68T42"],"pacs":[],"model":"deepseek-v4-flash","headline":"Coral Protocol proposes open infrastructure in which AI agents coordinate over threaded messages and get paid through a Solana escrow contract that releases funds only when tasks are fulfilled.","keywords":["AI agents","multi-agent systems","interoperability protocol","Model Context Protocol","Solana escrow","smart contracts","agent payments","decentralized infrastructure"],"falsifier":"On Solana testnet, deploy the escrow program described in Algorithm 1 and attempt, within one session, a second claim by the same agent after exhausting its cap, a withdrawal above an agent's max_cap, a refund before the six-hour window, or a deposit of a token different from the session's mint; any one of these succeeding falsifies the claimed invariants. A cheaper check is whether any real transaction on Solana mainnet matches the lifecycle the paper calls live.","tokens_in":30738,"feed_emoji":"🤖","tokens_out":10359,"duration_ms":96119,"temperature":0.7,"pith_summary":"Coral Protocol sets out to be a common, vendor-neutral substrate for the 'Internet of Agents': open infrastructure that lets AI agents built by different organizations find each other, converse in persistent threads, join temporary teams, and transact. The paper's most concrete and testable claim is a live Solana escrow contract that holds a task budget in a single vault and pays each agent only when the task is fulfilled, with per-agent withdrawal caps and a refund window for anything unclaimed. The communication layer builds on the Model Context Protocol: every agent runs a Coral server exposing thread tools, and 'coraliser' adapters wrap existing tools and third-party agents so they can participate without internal rewrites. A sympathetic reading is that Coral is claiming to close the gap left by earlier agent protocols — which handle messaging, identity, or orchestration but not the combination with payments — thereby turning multi-agent collaboration into a market with code-enforced trust.","feed_headline":"Solana escrow contract pays AI agents only for work done","feed_subtitle":"Coral Protocol's open stack adds thread-based messaging and trustless on-chain payments to the Internet of Agents.","key_machinery":"The mechanism is the pairing of a thread-based communication server with an on-chain escrow. The Coral MCP server exposes six thread primitives — list_agents, create_thread, add_participant, send_message, wait_for_mentions, close_thread — so agents coordinate by structured mentions in persistent conversations rather than ad-hoc API calls. The escrow contract of Algorithm 1 carries the payment guarantee: session initialization records the authority, an optional operator, agent identities, payment wallets, and per-agent max_caps; deposits move tokens into one vault; and a claimed-bitmap makes double-claims a trivial lookup. Its three stated design points are the single vault (each added agent costs $O(1)$ keys, no new accounts or rent), bitmap bookkeeping against replay attacks, and an operator role that lets a delegated ops wallet refund without exposing root authority keys.","core_discovery":"The central claim is that interoperable AI agents need one shared stack, and that Coral supplies it at three levels: standardized thread-based messaging (agents list one another, create threads, send messages, and wait for mentions instead of polling); modular onboarding through Coralisers that wrap MCP servers or legacy agents into compliant 'coralised' participants; and a blockchain trust layer. The load-bearing artifact is Algorithm 1, a Solana escrow program whose init_session and deposit procedures lock funds in a single program-derived vault, record each agent's destination wallet and maximum cap, and mark claims in a bitmap; an agent redeems payment with its own signature, and the authority can refund leftovers after a six-hour grace window. The paper reports that a two-week Solana testnet beta processed $73k in mock USDC without invariant breaches, and it treats the escrow as already live for direct token deposits, withdrawals, and refunds. Coral is explicit that team composition, role assignment, and reputation scoring are not yet implemented and are currently handled manually by developers, with native task management and reputation scheduled for later roadmap stages.","pith_inferences":["The natural next test of the escrow claim is a public mainnet deployment with real funds and an independent audit; until then the reported testnet beta is the only public evidence for the invariant guarantee.","The trust guarantee ultimately lives in how 'task fulfillment' is decided — the contract's release conditions depend on a requester or verifier signal — so an autonomous verification oracle is the missing piece that would make the escrow truly agent-to-agent rather than agent-to-human.","If on-chain reputation scoring ships as planned, reputation becomes portable across applications and vendors, which would make Coral less a messaging standard and more a labor market for machine intelligence.","An interop experiment the paper describes but does not report running would settle the vendor-neutrality claim: two agents built on different frameworks, coordinated through Coral alone, completing one task end to end."],"forward_implications":["If adopted, any Model Context Protocol-compliant tool or agent can join the network through a Coraliser without custom integration code, shrinking the $N \\times M$ integration problem to a single standard interface.","Conditional escrow turns agent labor into a market: requesters can prepay unknown agents in safety, agents collect automatically for delivered work, and abandoned tasks refund the payer after the claim window closes.","Because each agent in a session has its own wallet and cap, one escrow session can settle multi-party workflows and revenue splits without extra contracts.","A public ledger of all payments yields an audit trail of who paid whom, when, and under what conditions, independent of Coral's own databases.","Thread-and-mention messaging lets applications be composed by message flow, so the same micro-agent can serve several products and be swapped or versioned without glue code."],"supporting_citations":[{"why":"Supplies the Model Context Protocol standard that Coral's thread-based server interface and coralisers build on.","marker":"[1]"},{"why":"Presents the Agent-to-Agent interoperability protocol that Coral positions against and extends with payments and team logic.","marker":"[17]"},{"why":"Defines the A2A capability-card and task-object model whose ideas Coral re-uses in its discovery and messaging design.","marker":"[18]"},{"why":"Describes the open 'Internet of Agents' standards initiative that motivates Coral's role as a unifying substrate.","marker":"[15]"},{"why":"Surveys multi-agent LLM collaboration mechanisms and grounds the paper's claim that agents must coordinate collectively.","marker":"[19]"},{"why":"Supplies the conversational multi-agent programming framework whose agent-to-agent interaction model Coral's threads and mention-based routing extend.","marker":"[21]"}],"fun_headline_variants":["Open protocol ties AI agents with Solana escrow payments","Coral Protocol: shared stack for interoperable AI agents","Solana escrow handles agent payments, but team roles manual","Coral's thread messaging and on-chain escrow link AI agents","Agent collaboration via Coral: standard messages, trustless pay"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"Coral's value exists only if enough independent agents actually run its server and speak its thread protocol — a network effect the paper assumes rather than demonstrates — and the escrow's safety claim rests on pseudocode plus a self-reported testnet run, not on a released audit or public replication.","fun_headline_variants_meta":{"raw":{"variants":["Open protocol ties AI agents with Solana escrow payments","Coral Protocol: shared stack for interoperable AI agents","Solana escrow handles agent payments, but team roles manual","Coral's thread messaging and on-chain escrow link AI agents","Agent collaboration via Coral: standard messages, trustless pay"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000442,"raw_usage":{"total_tokens":2222,"prompt_tokens":909,"completion_tokens":1313,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":525,"completion_tokens_details":{"reasoning_tokens":1229}},"tokens_in":525,"tokens_out":1313,"duration_ms":9153,"temperature":1.0,"reasoning_tokens":1229,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-16T04:46:49.143575+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"On Solana testnet, deploy the escrow program described in Algorithm 1 and attempt, within one session, a second claim by the same agent after exhausting its cap, a withdrawal above an agent's max_cap, a refund before the six-hour window, or a deposit of a token different from the session's mint; any one of these succeeding falsifies the claimed invariants. A cheaper check is whether any real transaction on Solana mainnet matches the lifecycle the paper calls live.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the Model Context Protocol standard that Coral's thread-based server interface and coralisers build on."},{"cited_title":"Google Developers Blog (April 2025), https:// developers.googleblog.com/2025/04/a2a-a-new-era-of-agent-interoperability","cited_arxiv_id":null,"evidence_quote":"Presents the Agent-to-Agent interoperability protocol that Coral positions against and extends with payments and team logic."},{"cited_title":"Google Developers Blog (April 2025),https://developers.googleblog.com/en/ a2a-a-new-era-of-agent-interoperability/","cited_arxiv_id":null,"evidence_quote":"Defines the A2A capability-card and task-object model whose ideas Coral re-uses in its discovery and messaging design."},{"cited_title":"Galileo AI Blog ( https://www.galileo.ai/blog/ agntcy-open-collective-multi-agent-standardization) (Mar 2025), accessed: April 2025","cited_arxiv_id":null,"evidence_quote":"Describes the open 'Internet of Agents' standards initiative that motivates Coral's role as a unifying substrate."},{"cited_title":"In: Proceedings of the Conference on Language Model (COLM 2024) (2024), best Paper, LLM Agents Workshop at ICLR 2024","cited_arxiv_id":null,"evidence_quote":"Supplies the conversational multi-agent programming framework whose agent-to-agent interaction model Coral's threads and mention-based routing extend."}],"review_version":1}