A single author arXiv preprint from Jinliang Xu proposes a protocol neutral trust layer — Root identity, Registrar onboarding, authorization aware discovery, and signed invocation — that would sit beneath MCP, A2A, and ANP.
Before an agent in one organization can call an agent in another, someone has to decide which agents are allowed to discover each other, how their identities are verified, and what happens when something goes wrong. That pre-connection decision is the problem a new arXiv preprint, OpenAgenet/OAN: Open Infrastructure for Trusted Agent Interconnection, sets out to name — and to propose an answer for.
The paper is a single-author submission by Jinliang Xu, posted to arXiv on 2 June 2026 and revised the following day as v2, and it lives in cs.MA (Computer Science > Multiagent Systems), per the arXiv listing for 2606.03161. That matters for the read: it is a proposal, not a peer-reviewed standard, and the "trusted" in the title is OAN's own design objective, not an externally verified property.
As agents move out of isolated applications and into open, multi-operator networks, the agents on either side of a call need to answer a handful of questions before the call happens. The paper frames those questions as: where did this identity come from, what governance state is it in, is it allowed to be discovered right now, is the evidence on offer fresh, and is there pre-connection trust evidence to act on. Skip any of them, and discovery, selection, and invocation all become guesswork.
That gap is real. Agent-to-agent protocols like MCP, A2A, and ANP are evolving in parallel, and none of them, on their own, settle the cross-operator trust question. They define how agents talk; they don't define who is allowed to be in the room.
OAN, which the abstract describes as an "open infrastructure project" and a "protocol-neutral" trust layer, sits beneath those interaction protocols rather than replacing them. The architecture is built from five named components, per the paper:
The explicit non-goal matters too: the paper states OAN does not replace agent interaction protocols, tool protocols, model orchestration frameworks, or application-level workflows. It is a layer beneath them. That positioning is closer to DNS and TLS than to a new agent-to-agent protocol.
A few things are worth flagging for anyone reading the paper as a candidate architectural bet.
"Trusted" is self-attested. The trust in OAN runs through Root governance. That means the security of the system is, in practice, the security of whoever runs the Root and the Registrar set, and the integrity of the onboarding process. The paper's framing of "trusted" is a design objective, not an independently verified property.
The authorization bulletin has a substrate. Authorization-aware discovery in OAN is backed by a tamper-evident bulletin — a record of who is allowed to do what — and the paper's design leans on a blockchain-style substrate to give that bulletin finality and replication. That is a real choice with real tradeoffs: cost, finality assumptions, validator assumptions, and the operational footprint of running consensus.
v2 came a day after v1. The revision timeline — v1 on 2 June 2026, v2 on 3 June 2026, per the arXiv listing — is a signal to read v2 carefully and check what changed before treating the design as stable.
No third-party adoption evidence yet. At the time of writing, there is no independent implementation, deployment, benchmark, or production usage in evidence for OAN. The architecture is the proposal; the ecosystem is not yet there.
The honest read is that OAN is a coherent architectural bet on a real problem. The pre-connection trust gap across multi-operator agent networks is not going to solve itself, and the choice to stay protocol-neutral — to be the trust layer that sits beneath MCP, A2A, ANP, and whatever comes next — is a defensible position rather than a marketing one.
The honest caveats are also part of the bet. It is a single-author arXiv preprint, not a peer-reviewed standard. The performance profile is unverified. The governance model is self-defined. The authorization bulletin carries substrate tradeoffs that the reader inherits. And the broader agent-protocol landscape is genuinely unsettled — MCP, A2A, ANP, AGNTCY, and ACP are all evolving, and the winner-take-all question is open.
So the question to hand back to the reader is straightforward: does a layer like this belong in your stack, and what would you need to see to decide? Independent reference implementations, third-party evaluations of the trust model, a clearer picture of how OAN interacts with the trust assumptions already embedded in MCP or A2A, and any signal of multi-organization Root governance are the things that would move this from a proposal worth reading to a proposal worth piloting.