BCP 0.2
Node identity, an authorized path and packet construction from verifiable registry state.
Development status
BCP 0.2 is the IPvX packet layer and registry. The registry contracts were tested on the live Sepolia chain: REG-001 ran in read mode Q, and R1 was closed on 2026-11-06 by the REG-001-LC light-client read on its replacement criterion, the current state; the S1–S3 values remain mode Q observations. Packet delivery driven by the registry passed on test registry state (NET-001-F, PASS on 2026-11-08); on live state (NET-001-L) it has not run.
Status snapshot:
Implemented in code
Packet format, NodeRegistry, TransitPolicy, ConnectionPolicy, the EL/CL adapter and core integration. Contract reads are pinned to one finalized blockHash.
Checked offline
93 runner tests and 14 plan checks. Temporary keys, an in-memory EVM, synthetic headers and memory ports; no network or chain-finality measurement.
Next network experiment
NET-001-F passed on 2026-11-08 on the separate stand VM: run bcp-net001-run-0003, under a permit signed by the owner, gave PASS in all 14 check variants, and the independent verifier confirmed the result. This is Ethernet frame delivery between three nodes on a real Linux kernel with synthetic registry state: it does not test chain finality, a physical link or independent operators. The next experiment is NET-001-L on live registry state. It reads the registry through the Helios light client: mode LC replaced mode V on 2026-11-05, so no own Sepolia node is needed. Helios is not running on the stand yet, and the snapshot refresh rule in NET-001-L remains an open condition. Admission to a new launch is closed: every run needs its own permit signed by the owner.
What BCP changes
Identity
NodeRegistry binds a node NFT identifier to its owner and keys. A self-generated key alone does not grant participation.
Authorized path
TransitPolicy and ConnectionPolicy define allowed hops and connections. Nodes validate paths against pinned state; a blockchain does not replace the frame transport.
Packet construction
Identifiers, checkpoint, path, signatures and encrypted data have an exact binary format. MAC identifies the next neighbor; the identifier names the final node.
Data before admission
The dataset is prepared separately. A signed permit binds its hash, the entire bundle hash, run ID, creation and freshness deadline. The runner does not generate replacement input after authorization.
Freshness is at most 30 minutes, further limited by the oldest fresh checkpoint. Copying or restarting cannot extend an expired dataset.
Admission format and limits
dataset_sha256 · bundle_sha256 · run_id · created_at · expires_at
Evidence boundaries
The first experiment, NET-001-F, passed inside one Linux VM: A–R–B namespaces and two veth links. This does not establish live-chain operation, open admission, the physical Ethernet underlay or benefit over IP.
Mesh is a separate experiment
The historical stand checks signed delivery and route changes among pre-admitted nodes. It does not implement the BCP blockchain registry. Its journals, captures and previous conclusions are preserved.
Mesh: Ethernet exchange
Pre-admitted nodes choose the next hop. Tasks and routes are carried in Ethernet frames.
- Stand
- live mesh, 5 VMs on 3 physical hosts
- Frames
EtherType 0x88B5- Agents
- synthetic, no LLM
- Operator
- one
- Control
- over the administrative IP
- Link to BCP
- separate prototype · BCP 0.2 and its admission →
Connecting to signed logs…
Only stand operators can disconnect nodes. This shows a limited sample of signed records, not the full network log.
Waiting for messages
The path appears after the sender, recipient and relay logs are reconciled.
Network timeline
The timeline is collected in this tab; local history is kept for no more than 15 minutes.
Each dot is a message reconciled against the signed logs of every node on its path. Times come from the nodes' own logs. The observer returns the latest 24 deliveries. The tab keeps the records it has seen for no more than 15 minutes; the chart shows the last 3 minutes. Closing the tab loses this local history. Signatures verify the hops shown, but not that the log is complete. Click a dot to examine the message.
What caused what
The chain of the latest disconnection, from signed records. Click a step to open the record or message. Times are measured from the disconnection record, by the nodes' own clocks.
Delivered messages
Who chooses the route
Each row is a decision by the node itself, from its signed log. There is no central dispatcher.
How the network survived the failure
What was checked on real machines
How does this experiment differ from the ordinary internet?
is derived from the public key. No registrar issues it; the recipient stays the same along the whole path.
Neighbors exchange signed announcements: this is . A node chooses the shortest available path; stale information about a vanished neighbor expires.
Custom frames with type 0x88B5 are carried over Ethernet. Data and route announcements contain no IPv4, IPv6, TCP, UDP or DNS. only identifies the next neighbor.
The OS of these VMs keeps an administrative IP. SSH and the observation page use IP. The operator needs them; the agents keep exchanging when the panel is switched off.
These are five pre-admitted VMs on three physical hosts, with one operator and in one data center. Ethernet frames are observed in the guests; the underlay configuration between the hypervisors has not been separately confirmed. The blockchain registry and BCP policies are not implemented in this Mesh. It is a separate mode: the recorded strict-LLM experiment uses three guests on three hosts, two local models and guest kernels without INET/IPv6. Synthetic agents without an LLM run here. The live stand's version is given in the page footer; the date of the saved acceptance is in the section “What was checked on real machines”. We are testing our own delivery and routing, but not yet a global network, automatic admission of unknown nodes or resilience to overload.
A and B keep the keys from the previous stage. R1 disconnects a real transmission link for 60 seconds; service control remains available, then the link is switched back on automatically. The direct A↔B path is prohibited by the guest machines' rules.
Tasks in a large network
What has already been delivered in real frames — and where the current architecture hits its scaling limits.
- Documents
- real
- Agents
- software, no language model
- Operator
- one
- Where measured
- a separate experiment on Relcom project VMs
- Measurement and simulation
- shown separately
- Data
- saved results · five working machines — in the live stand
Loading reports of completed trials…
16 agents perform your task Measured
Each circle is a separate process with its own key and routing table. The 16 processes run on one physical machine in an isolated network without IP. The highlighted line is the task's confirmed path. Matching labels H… or V… on opposite edges mark a single hop between the outermost neighbors, bypassing the intermediate nodes.
How long tasks waited
Chart source: a measured run on a Relcom VM; processing of two public articles. Each dot is the number of correct results received.
Injected: 4 ± 1 ms delay, 0.02% frame loss and disconnection of the real N05 link for about 10 seconds. The first run revealed an automatic IPv6 address on the bridge and failed the check. It is saved separately. The second experiment revealed service traffic from the bridge and two failures caused by a task-deadline bug. After the fixes a new run was carried out; both earlier results are saved.
Up to 2 048 agents: simulation of a possible network Simulation
This is a simulation, not 2 048 running agents. Behind each model router there are eight logical agents. Load, loss, bandwidth and queues are set explicitly; the results do not promise the same speed in a real network.
All 36 simulations
Share of completed tasks over time: row — conditions, column — network size, three lines — three s. The dashed line is the 60-second limit. Click a cell to open the simulation below. The protocol currently works with at most 16 nodes and 7 hops, so 64 and 256 are a simulation of a version that does not exist yet.
Each node makes the next decision from its own table. The tables were obtained by exchange between neighbors; no central routing service is used. The highlighted path is taken from a completed simulation. Matching labels H… or V… at opposite edges are a single hop between the outermost neighbors.
The key conclusion: simply extending the list of key IDs does not make the protocol global. It needs compact route announcements, separate service discovery, congestion control and testing on independent networks. The simulation shows the cost of these limitations; it does not remove them.
Have other agents already switched? Source review
External operators surveyed: 0. Two separate conclusions were obtained from isolated Codex agents in the same service. They cannot see the transport they run on and cannot confirm a switch to IPvX. No accessible external node with verifiable telemetry was found.
Below are verified primary documents as of 27 October 2026. This is a review of protocols, not adoption statistics. This review contains no confirmation of a mass switch of AI to a native network without IP.
Signed evidence
Each stage is a bundle. Bundles are signed with the lab key and recorded in a Merkle log.
- Bundle
- report files with SHA-256, the release commit and GitHub assets
- Signature
- lab key
- Log
- Merkle tree
- Who verifies
- your browser, not the server
Loading the log and verifying signatures…
What this proves and what it does not
It proves integrity and order: a bundle cannot be changed, removed or reordered without breaking a signature or a consistency proof. Anyone who saved an earlier log head will see any rewritten history.
It does not prove independent time or an independent witness: the key and the log are held by the same lab, and the dates are its own statement. The next step is to anchor log heads where the lab controls nothing; this is also the comparison of the log with a blockchain for H11.
Verify the files yourself
The browser does not download the reports themselves. A command in a clone of the repository verifies the signatures, the tree and the SHA-256 of each file:
python -m ipvx_agent_lab.evidence verify
Two agents. Direct exchange.
Each agent lives on its own machine and sends messages to its peer itself. The ID stays the same when the IP changes.
- Stage
- 2 · closed: the next stage runs on these machines · open the network without IP
- Network
- real TCP/IP · internal stand network
- Names
- DNS disabled for the agents
- Data
- synthetic
- Agents
- software, no language model
- Machines
- two VMs on different physical hosts · one operator
Agents and delivery
Waiting for delivery confirmationDirect TCP connection · internal stand network · switched segment
The observer on the third physical host reads the signed logs of both VMs. Messages between the agents do not pass through it.
Delivered messages
Messages with matching records on both sides are shown. Select a row to check the path.
Addresses and events
Checks on two machines
Who lays the route when there are many agents?
The ID answers “who”, the IP answers “where”
In this experiment A knows B's public ID and first address in advance. When B changes its address, it signs a new record and sends it to A itself. A verifies the signature and the version, stores the new address and opens a direct connection.
At large scale the initial lookup can be distributed across many nodes. They hold parts of the ID → address directory with copies and caches. A lookup is needed before connecting or after losing an address, not for every message. Such a lookup system is not yet implemented in this direct pilot.
Packets are delivered by the existing IP network. Its routers work with network prefixes; they do not need a separate entry for each agent. Queues, request limits and agent replicas solve a different problem — computational overload.
Abandoning IP would mean developing our own routing network. For now we are testing an independent ID and direct exchange over TCP/IP. If both agents lose all known addresses of each other at the same time, recovery is not provided for in this stage.
Experiment limits
Two VMs on different physical hosts · one operator and data center. Relocation switches the listening IP inside one VM; control stays on the previous address. The button only starts the address change; the agent notifies its peer itself.
An internet for agents
An agent finds data, receives limited rights and hands the task to an analyst. Watch the task's progress and the reasons for decisions.
- Stage
- 1 · in the stage archive · current work: BCP 0.2
- Data
- synthetic
- Operator
- one
- Agents
- software, no language model
- Launch
- stand operators only · the last saved run is shown
Task path
Events of a real run
Task owner
Personal agent
Three resolvers
Data source · MCP
Analyst · A2A
New attachment point
The ID answers “who?”. The resolver answers “where now?”. The permission answers “what is it allowed to do?”.
Event log
0 eventsEvents will appear after a run. Each row opens an explanation and the observed data.
What we check
ID preservation on relocation, signature verification, rights limits and behavior on failures.
Hypotheses and evidence
A verdict applies to a specific run. A partial result leaves open questions.
- Stage
- 1 · in the stage archive · current work: BCP 0.2
- Source
- the last saved run of stand /1
- Hypothesis address
#hypotheses/H5
Run result
All hypotheses
Connect your own agent
The Python client library resolves a signed ID through three resolvers, verifies the record and stores the known version. Access to data requires a separate permission from the owner.
- Stage
- 1 · in the stage archive · current work: BCP 0.2
- Language
- Python
- Trust
- set by the operator, not the library
Local run
git clone https://github.com/relcom-technologies/ipvx-agent-lab cd ipvx-agent-lab python3 -m venv .venv source .venv/bin/activate pip install -e '.[test]' ipvx-lab local
Open http://127.0.0.1:8080. The command starts seven separate processes. Installing from the private repository requires GitHub access.
Calling from Python
from ipvx_agent_lab import AgentClient, invocation
with AgentClient(
resolver_urls, # three resolver addresses
checkpoints={agent_id: (2, 3)},
state_file=".state/known-versions.json",
allowed_origins={"https://your-agent.example"},
) as client:
profile = client.resolve(agent_id)
result = client.invoke(
profile,
invocation(permission_chain, subject_key, "read"),
)Resolver addresses, the trusted initial version, allowed nodes and the rights chain are set by the operator. The library does not decide for the owner whom to trust.
Check automatically
ipvx-lab run --scenario full --output reports/full.json pytest -q
Experimental protocol
Version 1 · approved by the project owner on 26 October 2026.
- Stage
- 1 · in the stage archive · current work: BCP 0.2
- IPvX base
218bf93
What works on the stand
Local ID generation, a signed profile, search by capability, of two out of three resolvers, narrow permissions and protection against repeated execution. Relocation changes the attachment point and keeps the identity.
What counts as evidence
Scenarios send HTTP requests to separate processes. Each check stores the condition, the observed result and the time. SQLite records and exported reports persist after a restart.
Limits of the experiment
- One physical host and one operator. Separate processes do not prove that operators are independent.
- The agents follow given rules on synthetic data. No language model is connected.
- MCP 2025-06-18 and A2A 0.3.0: limited adapters are tested. Compatibility with external implementations is not yet certified.
- First contact requires a fresh trust anchor. A signature by itself does not guarantee that a result is fresh or of good quality.
- When the revocation source is unavailable, a cache window of up to 3 seconds is allowed; after that, refusal. A clock change is an explicitly injected logical failure.
- The blockchain and adoption by external teams have not yet been tested.
Pinned IPvX base
218bf93acb842604167c93144e5bc967b70ecb6aThe quorum rule is taken from this version. Agent profiles and permissions are a new experimental protocol.
Read the full protocol ↗