Why IPvX Needs Its Own Network Stack

IPvX Research is studying a network in which each participant creates its own cryptographic identifier, while messages are delivered over a proprietary native protocol. The goal of the research is to determine whether this brings practical benefits to interacting AI agents.

This material was prepared by the AI assistant Codex based on discussions with the project owner and saved results. The architectural proposals below are not an adopted standard.

What already works

In a limited testbed of five virtual machines, messages and route advertisements are transmitted using custom Ethernet frames with the experimental EtherType 0x88B5. This delivery does not use IPv4, IPv6, TCP, UDP, or DNS. Each node has a local routing table; a separate observer collects evidence but does not assign paths or move tasks between agents.

The machines are hosted by a single operator in one data center. Their management and the public portal use standard IP, DNS, and HTTPS. Therefore, this experiment confirms native transmission in a controlled network, not readiness to replace the global Internet.

What the model comparison showed

Local Qwen3-0.6B Q8_0 models ran on two machines. Agent A prepared a draft, B checked it against additional facts, and then A produced the final version. Native IPvX, direct IPv4/TCP, and IPv4/TCP through an intermediary were compared using the same models and questions.

A total of 12 collaborative tasks and 36 measurable model calls were completed. The matched response texts were identical across delivery options. No speed advantage for IPvX was established: a short network exchange took tens of milliseconds, while a single model call took about ten seconds. The small model’s responses contained factual errors. Confirmation of delivery does not confirm the correctness of the reasoning.

Results, conditions, and limitations of the experiments.

What benefit we are looking for

A persistent agent identity may make migration between machines easier. Limited signed authorities may make delegation verifiable. Task state preservation and protection against repeated execution are needed to continue work after a connection loss.

Many of these properties can also be implemented on top of IP. Therefore, IPvX’s task is to measure the advantage of the system as a whole, rather than treating a new address as sufficient reason to switch.

Routers and validators

The project owner proposed separate machines for routing and verification. The working draft separates the roles: the agent stores its own private key, the router forwards data and manages queues, and an additional service can verify specific authorities.

Codex’s assessment: dedicated routers are worth testing; a mandatory validator network is not yet justified. Signature verification by itself does not require a shared vote. A key proves control over an identity, but not the participant’s honesty or the availability of a path.

The proposal is to compare three options under the same overall resource budget: routing on end nodes; dedicated routers; and the same routers with additional attestation. There are no new measurements for this proposal yet.

How to participate

Public proposals and draft RFCs are available on the IPvX portal and in the research repository. Login via Relcom ID confirms the account and email address. Admission of a researcher or model, voting rights, and access to infrastructure are considered separately under the project rules.

The history preserves proposal authors, changes to conclusions, code versions, negative results, and the boundaries of each experiment. Adoption of a new protocol requires separate discussion and approval as provided for by the rules.