3. Encryption and Proxying: Envoy Proxy, Web3-mTLS and E2EE Isolation

Separating discovery and connection logic (the Control Plane: announcements, the super-nodes' Kademlia table and the rendezvous of document 02) from data transfer (the Data Plane) is a classic pattern of high-load systems. In the reference implementation the role of the Data Plane is played by an integrated Envoy Proxy instance; any program that gives the encrypted channel of document 19 may take its place. This provides microsecond latencies, L4/L7 load balancing and hardware-accelerated encryption, leaving Super-Nodes with the sole function of "blind routers".

3.1 Envoy Proxy as the Data Plane (Sidecar Pattern)

In the reference implementation every AI agent (both client and provider) is deployed together with a lightweight Envoy sidecar container.

Envoy functions: Managing timeouts, retries, circuit breaking when a node goes down, and keeping persistent connections (keep-alive HTTP/2 and gRPC).

Dynamic configuration (xDS API): Envoy does not use static configuration files. The local Lagrix client (Control Plane) keeps the addresses it learns — from announcements (document 17), from the rendezvous and from the relays (document 02). As soon as it learns a new address of the needed Provider or a backup Relay bridge, the client sends this data over gRPC (through the EDS/CDS protocols) directly into Envoy's memory. The proxy rebuilds routes on the fly, without a restart, providing zero downtime (Zero Downtime Routing).

3.2 Web3-Native mTLS (Mutual Authentication)

In corporate networks (Zero Trust) the security standard is Mutual TLS (mTLS), where server and client check each other's certificates. In a decentralized Web3 network there are no central Certificate Authorities (such as Verisign). Lagrix solves this with elliptic-curve cryptography (secp256k1).

Ephemeral key generation: When a session starts, Envoy generates a temporary TLS certificate (x509).

Web3 signature: The local agent takes this certificate and signs it with the key of its node's wallet — the one wallet through which the node's elements pay and are paid (changelog entries 22 and 39).

Cryptographic handshake:

Agent A connects to Agent B.

They exchange certificates and Web3 signatures.

Each extracts the public address (Ethereum Address) from the signature and checks that it matches the other side's node wallet recorded in the escrow deal (document 04, section 4.1).

Result: The agents mathematically prove their identity at the transport level. A Man-in-the-Middle (MitM) attack is impossible: even if an attacker intercepts the IP, they cannot forge the wallet's cryptographic signature.

3.3 E2EE and Payload Isolation (Payload Blindness)

This is the most important point for maintaining the legal status of a "Mere Conduit" (Neutral provider). The infrastructure (Super-Nodes/Relays) must physically be unable to read the context of an AI request (Prompt) or the answer (Inference Result).

A multi-layer envelope architecture (Onion-lite routing) is used:

Outer layer (Transport): Envoy encapsulates packets in a standard TLS 1.3 tunnel to the Super-Node. The Super-Node sees only headers: sender IP, recipient IP, packet size — enough to route the packet and nothing more.

Inner layer (Payload E2EE): The data itself (for example, JSON with a system prompt) is encrypted with a symmetric key (AES-256-GCM or ChaCha20-Poly1305). This key is generated through the Diffie-Hellman protocol (ECDH) exclusively between the Client and the Provider during the handshake.

Legal shield: A Super-Node passing traffic through itself operates on an encrypted Blob object (a black box). If illegal or toxic content is transferred inside, the Super-Node owner is protected by cryptography: they will mathematically prove in any court that they had no decryption keys, and therefore could not perform moderation (DPI).

3.4 Metadata Obfuscation (Protection Against Traffic Analysis)

Even if a Super-Node does not see the content, attackers can analyze packet sizes (Traffic Pattern Analysis). For example, a short request and a long answer is a typical pattern of LLM text generation. To protect the confidentiality of corporate clients:

Padding: Envoy automatically pads encrypted E2EE packets with random bytes up to fixed sizes (for example, 4KB, 16KB, 64KB).

Effect: To an outside observer (and to the Super-Node) all passing traffic looks like an absolutely uniform stream of binary blocks of the same size. Identifying the nature of the task (video generation, code search or a transactional request) becomes impossible.

3.5 Keys of H2H conversations and A2A deals (changelog entry 33)

H2H — MLS (IETF RFC 9420). People's conversations are encrypted with the open MLS standard: the key changes with every message, so a key stolen today does not open yesterday's messages, and after the next key update not future ones either. A node's public key package is signed by the node's wallet: the other side checks the signature and knows which wallet's owner it talks to. A super-node serves as the delivery service: it keeps only public key packages, relays and holds encrypted messages — text of up to 64 KB, held for an offline recipient for up to 30 days and up to 1 MB per recipient; it has no private keys. Conversations are never written to a blockchain.

Attachments (changelog entry 52). A file never travels through a super-node. The sender encrypts it with a random key, keeps it on its own node or in storage it chooses, and puts into the MLS message the file's name, size and type, a download address that cannot be guessed and expires, the key and the hash of the file. Only the recipient can open the file, and the hash shows that it was not changed after sending.

A2A — a one-time session key. A deal's key is created at the handshake (ECDH, section 3.3) and deleted when the session ends.