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.
Questions and ideas about BCP
BCP is discussed on the participants' forum; proposals to change the document go through RFCs and GitHub.
Open the BCP category on the forum