Mesh Network

Overview

The INCOG Mesh Network is the decentralized routing infrastructure layer of the INCOG AI protocol. It consists of independently operated relay nodes distributed across geographic regions and network topologies, forming a mesh through which user traffic is routed in multiple encrypted hops before reaching its destination.

The term "mesh" describes the network's topological property: rather than a hub-and-spoke architecture with centralized routing infrastructure, any node can route traffic to any other node, creating a dense web of potential relay paths with no single routing authority.

Network Topology

Node Distribution Goals

The mesh network's privacy properties are a direct function of its geographic and topological distribution. A network concentrated in a small number of geographic regions or autonomous systems provides weak diversity in relay path construction, reducing the practical benefit of multi-hop routing.

The protocol's geographic incentive multipliers (detailed in the incentive model documentation) are specifically designed to accelerate deployment in underrepresented regions. The target distribution for a mature network is:

• Coverage in at least 50 distinct countries across all inhabited continents
• No single country or autonomous system accounting for more than 20% of total relay capacity
• Representation in both high-bandwidth (developed infrastructure) and diverse jurisdiction (regulatory diversity) regions

Autonomous System Diversity

Beyond geographic distribution, the protocol explicitly targets autonomous system (AS) diversity in relay path construction. An adversary with visibility into a single large ISP's traffic — even one operating globally — should not be able to correlate relay traffic across multiple hops if those hops traverse different autonomous systems.

Path construction algorithms weight AS diversity as a primary constraint: consecutive relay hops must traverse different autonomous systems wherever the relay directory has sufficient coverage to support this constraint.

Network Resilience

The mesh topology is inherently resilient to node failures. No single node is a required participant in the network; when a node fails or is de-listed, traffic naturally redistributes across the remaining relay capacity. The relay directory's health monitoring system ensures that failed nodes are rapidly removed from path construction candidates, and the client-side path failure handling automatically reconstructs paths through available alternatives.

The network's resilience is quantifiable through standard graph-theoretic metrics: node connectivity and edge connectivity of the relay graph determine the minimum number of simultaneous node failures required to partition the network. The protocol's minimum viable network design targets a node connectivity of at least 5, meaning that 5 simultaneous node failures are required before any partition is possible.

Relay Capacity Model

Capacity Units

The mesh network's routing capacity is measured in relay bandwidth: the aggregate throughput available across all relay nodes at a given time. This capacity is distributed across relay nodes according to their hardware specifications and network connections.

Capacity is not merely a function of raw bandwidth. The effective capacity for privacy-preserving routing accounts for:

• Per-path overhead: Multi-hop routing multiplies the bandwidth cost of each user connection by the number of hops
• Encryption overhead: Layered encryption adds computational overhead proportional to traffic volume
• Padding overhead: Traffic padding consumes bandwidth above the payload volume to provide traffic analysis resistance

At three hops with standard padding, the effective relay capacity utilization is approximately 3.5× the user traffic volume (3 relay hops × payload volume + padding overhead).

Capacity Planning

The relay network capacity is designed to scale proportionally with the user base. The $INCOG incentive model creates an economic feedback loop:

1. Increasing user demand increases relay network utilization
2. Higher utilization increases the value of relay capacity contribution
3. Higher incentive value attracts additional node operators
4. Additional node operators expand capacity to match demand

This feedback loop is designed to prevent sustained congestion — a significant risk in decentralized networks that lack central capacity planning authority.

Directory Infrastructure

Relay Directory Design

The relay directory is the infrastructure that enables client-side path construction. It maintains a continuously updated list of available relay nodes, including:

• Node public key (used for key exchange in relay connection establishment)
• Network address (IP and port)
• Capability declaration (bandwidth, node class, uptime history)
• Geographic metadata (country, AS number)
• Operator identity (on-chain address)
• Health metrics (liveness probe results, peer-reported availability)

The directory is cryptographically signed by multiple independent directory authorities. Clients verify the combined signature before trusting directory contents. A single compromised directory authority cannot inject malicious nodes — a threshold of authorities must agree.

Directory Authority Model

Multiple independent directory authorities collectively sign each directory snapshot. The threshold signature scheme requires a configurable fraction (e.g., 3-of-5) of authorities to produce a valid signature. Directory authorities:

• Monitor relay node health through active liveness probing
• Validate node capability attestations against observed behavior
• Apply and enforce the protocol's eligibility rules (holder verification, hardware minimums)
• Sign and publish directory snapshots at a regular interval

Directory authorities are distinct from relay node operators. They provide metadata infrastructure, not routing capacity. The long-term architecture moves toward a more decentralized directory model where node announcements are published to a p2p DHT and client-side consensus replaces centralized authority signing.

Client Directory Synchronization

Clients synchronize with the relay directory at startup and at regular intervals during operation. The synchronization protocol is designed to minimize the metadata exposure of the directory query itself:

• Directory updates are fetched over a separate privacy-preserving channel (not through the relay network, which creates a bootstrapping paradox)
• Clients fetch the full directory snapshot rather than querying specific nodes, preventing the directory from inferring which nodes a client is considering
• Directory snapshots are cached locally and updated incrementally to reduce synchronization frequency

Network Health Monitoring

Liveness Probing

Directory authorities probe relay nodes at regular intervals to verify availability. Liveness probes:

• Connect to the node's declared network address
• Perform a lightweight cryptographic handshake to verify the node is running authentic relay software
• Measure response latency for capacity estimation
• Record the probe result in the health metric aggregation

Failed liveness probes trigger a retry sequence before marking the node as unavailable. A node must fail multiple consecutive probes before being removed from the active directory.

Peer Reputation

In addition to directory authority probing, relay nodes report on the availability of peers they interact with. When routing a relay circuit, an entry node interacts with middle nodes, and middle nodes interact with exit nodes. These interactions generate peer availability observations that supplement the liveness probe data.

Peer reputation data provides a distributed view of relay health that is difficult to manipulate: a node operator cannot fake good reputation by simply responding to directory authority probes if their peers are reporting failures.

Circuit Success Rate

The protocol tracks circuit construction success rates at the client level. Failed circuit constructions — where path establishment fails because one or more selected nodes are unavailable — are logged and reported to the directory infrastructure. Nodes that consistently appear in failed circuit constructions are subjected to accelerated health review.

Network Upgrade Protocol

Protocol Versioning

The mesh network supports protocol versioning to enable coordinated upgrades across independently operated nodes. Each relay node declares its supported protocol versions in its capability announcement. The client selects relay nodes that support a common protocol version set.

Protocol upgrades follow a phased rollout:

1. Specification: New protocol version specified and published
2. Node software update: Updated node software released, supporting both old and new protocol versions
3. Adoption period: Nodes gradually update; both versions active
4. Deprecation: Old protocol version deprecated once adoption threshold is reached
5. Retirement: Old protocol version support removed from node software

This process allows the network to evolve without requiring simultaneous upgrades across all independently operated nodes — a coordination challenge that would be prohibitive in a decentralized network.