Data Flow

Overview

The VeilNet Anchor Protocol defines the data-plane behavior of the VeilNet overlay network.

Anchor is responsible for encrypted session establishment, routing decisions, packet encapsulation, and transmission across the overlay. It is executed within Conflux runtimes, but its design and semantics are protocol-level concerns rather than Conflux-specific implementation details.

Anchor differs fundamentally from traditional tunnel-based VPN protocols such as WireGuard, OpenVPN, and IPsec.

Conventional VPN designs typically bind a TUN interface to a single reader and writer pair, resulting in a serialized processing path. While limited batching may be applied, these systems provide no explicit backpressure propagation across protocol stages. Under burst conditions, packets are commonly dropped at internal queues without feedback to upstream components.

Anchor is designed around a different model.
With the exception of the operating-system–provided TUN interface, all protocol stages are asynchronous, non-blocking, backpressure-aware, and elastically scalable. Packet pressure is absorbed, redistributed, or deferred within protocol pipelines rather than dropped.

The following sections describe the egress, ingress, and relay flows as defined by the Anchor Protocol.

Egress Flow

The egress flow describes how outbound packets generated by a host or embedded application are processed by the Anchor Protocol and injected into the VeilNet overlay.

TUN Interface

Outbound IP packets generated by the host networking stack are first delivered to the VeilNet-managed TUN interface.

The TUN interface provides compatibility with standard IP-based applications and operating systems. It represents the only synchronous boundary in the data path; all subsequent Anchor processing stages are decoupled from the TUN queue.

Egresser

Within Anchor, an Egresser is responsible for processing outbound packets destined for a specific remote Anchor endpoint.

Each Egresser maintains internal buffering to ensure that the TUN queue remains under minimal pressure. When sustained load is detected, the Anchor runtime may instantiate additional Egresser instances dynamically, distributing traffic across multiple parallel pipelines.

Egressers are lifecycle-managed by demand:

• New instances are created under pressure
• Idle instances are retired after a short grace period

Stream

Packets handled by an Egresser are transmitted over a logical Stream associated with a destination Anchor endpoint.

A Stream is established by deriving a fresh shared secret using Kyber KEM. Stream creation, reuse, or rotation is determined by local reinforcement learning (RL) policies based on observed load, quality, and stability metrics.

Packets are batched prior to transmission. Up to 25 IP packets may be encapsulated into a single Anchor data message. Each message is then:

• Encrypted using the Stream shared secret
• Authenticated and signed using Dilithium DSA

Route

Route selection is performed as part of the Anchor Protocol’s forwarding logic.

Routes are selected using control-plane information received via the Master control channel. Each Anchor instance applies its own reinforcement learning policy, informed by:

• Real-time performance observations
• Historical path behavior
• Reachability and liveness signals

A route descriptor contains:

• The next hop
• A cryptographic signature identifying the final destination

The complete end-to-end path is never encoded or disclosed. Each intermediate Anchor instance independently selects the next hop, allowing dynamic adaptation at every relay.

Tether

The Tether layer is the Anchor Protocol’s WebRTC transport integration.

Tether manages a pool of WebRTC data channels to a given remote Anchor endpoint and distributes traffic across them. Local RL policies determine:

• Channel selection
• Channel creation and teardown
• Load distribution across available channels

When direct peer-to-peer connectivity is unavailable, Anchor may use relay-assisted WebRTC connectivity to establish transport paths.

Backup Pipeline

If all WebRTC transport paths are unavailable, the Anchor Protocol temporarily falls back to transmitting encrypted data messages over the control channel.

In this mode:

• Route selection is bypassed
• The Tether layer is not used
• Messages are sent directly after Stream establishment

This mode exists solely to preserve connectivity and is automatically disabled once primary transport becomes available. Its latency and throughput characteristics differ substantially from the main data path.

Ingress Flow

The ingress flow defines how inbound Anchor data messages are processed and delivered back to the host networking stack.

Incoming messages are:

1. Received via the active Anchor transport
2. Decrypted using the corresponding Stream shared secret
3. Authenticated and validated
4. Unpacked into individual IP packets
5. Injected into the host via the TUN interface

Ingress processing does not perform route selection. The inbound Stream corresponds directly to the outbound Stream created by the sender, using the same Stream ID and cryptographic material.

Return traffic follows the same protocol semantics. The responding endpoint creates a corresponding Egresser, while the origin endpoint instantiates a matching Ingresser, forming a symmetric, on-demand bidirectional flow without persistent tunnels.

Relay Flow

The Anchor Protocol supports native peer relay functionality.

When an Anchor data message arrives at an intermediate node and the destination does not match the local identity:

1. Route-selection logic selects the next hop
2. The encrypted message is forwarded immediately

Relay nodes do not decrypt, inspect, or terminate sessions. They forward encrypted envelopes only, preserving end-to-end confidentiality while enabling multi-hop, multi-path routing across the VeilNet overlay.