Data Flow

How data flows through VeilNet Conflux.

Egress Flow

The VeilNet Conflux egress pipeline is fundamentally different from WireGuard, OpenVPN, or IPsec.
Traditional VPNs bind the TUN interface to one writer and one reader, forming a single-threaded choke point.
Although some batching may occur, these systems lack any real backpressure control.
When traffic spikes, packets are silently dropped with no recovery and no notification to the application layer.

VeilNet Conflux is architected entirely differently.
Except for the TUN interface itself, every component is asynchronous, non-blocking, horizontally scalable, and fully backpressure-aware.
No packets are ever dropped inside Conflux — pressure is absorbed, redistributed, or scaled across multiple dynamic pipelines.

Below is the egress flow of VeilNet Conflux:

TUN interface

When the host generates an IP packet, it first arrives at the VeilNet-managed TUN interface — a virtual network interface that makes Conflux interoperable with all standard IP-based applications and operating systems.

Egresser

The Egresser processes outbound packets.
It maintains an internal buffer so that the TUN queue stays under minimal pressure at all times.

If an egresser becomes saturated, Conflux will instantiate additional egressers on demand, distributing load without dropping packets.
To prevent resource waste, idle egressers automatically dissolve after a short grace period — similar to garbage collection.

Each Egresser is destination-specific, handling packets for a single destination Conflux instance.

Stream

After a packet reaches an Egresser, it establishes (or reuses) a Stream to the destination by obtaining a fresh Shared Secret via Kyber KEM.
The Reinforcement Learning engine decides whether to open a new Stream or utilise existing Streams depending on load and quality metrics.

Simultaneously, the Egresser bundles up to 25 IP packets into a single VeilNet data message.
Once the Stream is ready, the message is encrypted using the Shared Secret and signed using Dilithium DSA.

Route

While encryption is underway, the Egresser selects the optimal route using the Control Channel.
Routes are chosen by a Reinforcement Learning decision model using real-time performance data and historical behaviour.

A route contains only the next hop and the final destination signature — never the full path.
Each intermediate Conflux node independently selects the next hop, allowing the network to adapt dynamically at every step.

Tether

The Tether is the WebRTC integration layer.
It manages a pool of WebRTC data channels to the same remote Conflux instance and performs final-stage load balancing before packets leave the current host.

The Reinforcement Learning engine determines:

  • which data channel is optimal
  • when to create additional WebRTC channels
  • how to distribute packets across the aggregated channels

Currently, Conflux uses Cloudflare TURN to ensure WebRTC connectivity when direct paths are unavailable.

Backup Pipeline

Under extreme conditions — for example, when all WebRTC connections fail, including TURN relay — the Egresser temporarily falls back to the Control Channel as a backup transport.

In this mode:

  • No Route selection occurs
  • No Tether is used
  • Data messages are sent directly to the destination after Stream creation

Warning:
The backup pipeline is only a temporary fallback.
It automatically disables itself once WebRTC becomes available again.
Expect significantly higher latency and lower throughput compared to the main pipeline.

Ingress Flow

The ingress flow of VeilNet Conflux mirrors the egress flow, but in the reverse direction and without performing any route selection. Incoming data messages are decrypted, validated, unpacked, and delivered back into the host networking stack. The ingress flow is shown below:

Note:
The inbound Stream corresponds directly to the outbound Stream created by the source Conflux instance.
Both sides share the same Shared Secret and Stream ID, ensuring symmetric encryption, authentication, and identity binding.

Note:
For return traffic, the destination Conflux instance will spawn an Egresser targeting the original source.
The source Conflux instance will then instantiate a corresponding Ingresser to receive those messages.
This symmetrical Egresser/Ingresser pairing ensures reliable bi-directional communication without requiring persistent tunnels.

Relay Flow

VeilNet Conflux natively supports peer-relay functionality. Any Conflux instance can act as a relay for other instances without requiring a TURN server, and without maintaining persistent tunnels. This relay pipeline is significantly simpler than the main egress or ingress flows.

When a data message arrives at a Conflux instance and the message is not destined for that instance, Conflux activates the Route-selection logic to choose the optimal next hop. Once the next route is selected, the data message is immediately forwarded along that path.

Relay nodes do not decrypt or inspect packet contents, and simply forward the encrypted payload. This preserves end-to-end privacy while enabling multi-hop, multi-path routing throughout the VeilNet overlay.