▸ Architecture

System Design

Overview

This document specifies the system design of the INCOG AI protocol at the component and interface level. It covers the technical architecture of each major system, the interfaces between systems, the data models used, and the key design tradeoffs made in each area.

Component Architecture

Browser Client

The INCOG Browser is built on a fork of an open-source browser engine (Chromium-based), with modifications applied at the engine level to implement privacy-preserving behaviors that cannot be achieved through extensions or content scripts.

Key engine modifications:

Fingerprint normalization layer: Intercepted at the V8 JS engine interface for JS API calls and at the rendering pipeline for canvas/WebGL output. Normalization is applied before results are returned to JavaScript, not through script injection.
Request interception layer: Modified network stack that inspects outbound requests before transmission. The interception layer applies telemetry blocking, header normalization, and relay routing decisions at the network service layer.
Storage partitioning: Modified storage backend that enforces per-origin, per-session partitioning for all storage APIs (cookies, localStorage, IndexedDB, Cache API, service workers).
Process isolation model: Modified site isolation policy that enforces separate processes per browsing context (not just per origin), with stricter IPC restrictions between contexts.

Relay client integration: The relay routing client is integrated as a browser service running in the browser's network service process. All network requests pass through the relay client when relay routing is enabled.

Component interfaces:

[Web Content Process]
    ↓ IPC (limited, sanitized)
[Browser Process]
    ↓ Network Service IPC
[Network Service Process]
    ├── [Relay Routing Client]
    │       ↓ TCP/UDP
    │   [Relay Network]
    └── [Direct Network Stack] (fallback, non-relay)

Relay Node Software

The relay node software is a standalone daemon designed to run on embedded hardware or server deployments. It is implemented in a systems language (Rust) for performance and memory safety.

Subsystems:

Connection manager: Accepts inbound relay connections, manages circuit state, and handles connection lifecycle
Crypto subsystem: Implements the relay protocol's layered encryption, key exchange, and authentication
Routing engine: Maintains circuit routing tables, forwards cells between adjacent nodes
Attestation engine: Generates cryptographic attestations of relay activity for reward verification
Directory client: Maintains an updated view of the relay directory for outbound circuit construction
Management interface: Local web UI and CLI for operator monitoring and configuration

State model:

Node State:
  identity_keypair: (private_key: SE, public_key: published in directory)
  active_circuits: Map<CircuitID, CircuitState>
  peer_connections: Map<NodeID, Connection>
  attestation_buffer: Vec<AttestationRecord>

CircuitState:
  circuit_id: CircuitID (local link)
  upstream_link: Option<Connection>  (toward client)
  downstream_link: Option<Connection>  (toward exit)
  session_key: SessionKey (SE-managed)
  created_at: Timestamp
  bytes_forwarded: u64

Relay Directory Service

The relay directory service is a distributed system operated by directory authorities. Each authority runs the directory daemon, which:

Aggregates node capability announcements and liveness probe results
Produces signed directory snapshots at regular intervals
Participates in the threshold signature scheme for snapshot signing

Directory snapshot format:

DirectorySnapshot {
  version: u32
  timestamp: u64
  valid_until: u64
  nodes: Vec<NodeDescriptor>
  authorities: Vec<AuthorityInfo>
  signature: ThresholdSignature
}

NodeDescriptor {
  node_id: PublicKey
  addresses: Vec<SocketAddr>
  capabilities: NodeCapabilities
  geographic_info: GeoInfo
  operator_id: OnChainAddress
  uptime_score: f32
  bandwidth_capacity: u64
  exit_policy: ExitPolicy
  signed_at: u64
  node_signature: Signature
}

Reward Contract

The reward contract is a smart contract deployed on the INCOG protocol's target chain. It:

Accepts attestation bundle submissions from node operators
Verifies attestation bundle signatures using on-chain registered node public keys
Calculates per-node reward shares based on the verified attestation data
Distributes rewards from the relay incentive reserve according to calculated shares

Contract interface:

interface IRelayReward {
    // Called by node operators to submit monthly attestation bundle
    function submitAttestation(
        bytes32 nodeId,
        AttestationBundle calldata bundle,
        bytes calldata signature
    ) external;

    // Called by governance to update reward parameters
    function updateRewardParameters(
        RewardParameters calldata params
    ) external;

    // Called by node operators to claim calculated rewards
    function claimReward(bytes32 nodeId) external;

    // View functions
    function getPendingReward(bytes32 nodeId) external view returns (uint256);
    function getNetworkStats(uint256 period) external view returns (NetworkStats memory);
}

Interface Specifications

Browser ↔ Relay Client Interface

The browser's network service communicates with the relay routing client through a local IPC interface. This interface is not exposed to web content.

RelayClient Interface:
  open_circuit(destination: SocketAddr, options: CircuitOptions) 
    → CircuitHandle | Error
  
  write(handle: CircuitHandle, data: &[u8]) 
    → BytesWritten | Error
  
  read(handle: CircuitHandle, buf: &mut [u8]) 
    → BytesRead | Error
  
  close_circuit(handle: CircuitHandle) 
    → ()
  
  get_circuit_info(handle: CircuitHandle) 
    → CircuitInfo
  
  get_relay_status() 
    → RelayStatus

Node ↔ Node Protocol

Adjacent relay nodes communicate using a binary protocol over TLS-protected TCP connections. The protocol is message-framed with fixed 514-byte cells.

Cell format:
  [0..3]   CircuitID (4 bytes, little-endian u32)
  [4]      CellType (1 byte enum)
  [5..513] Payload (509 bytes, padded to length)

CellType values:
  0x00: PADDING (link-level keepalive, no circuit association)
  0x01: CREATE (circuit creation initiation)
  0x02: CREATED (circuit creation confirmation)
  0x03: RELAY (encrypted relay payload)
  0x04: DESTROY (circuit teardown)
  0x05: EXTEND (circuit extension request, within RELAY payload)
  0x06: EXTENDED (circuit extension confirmation, within RELAY payload)

Design Tradeoffs

Performance vs. Privacy: Hop Count

The most significant performance-privacy tradeoff in the relay protocol is hop count. Each additional relay hop adds:

Network round-trip latency proportional to the geographic distance between hops
Protocol overhead for the additional encryption layer
Circuit construction time

Against this cost, each additional hop improves privacy by:

Expanding the set of nodes that would need to be controlled for a complete traffic correlation attack
Reducing the geographic region in which a single surveillance authority could correlate both endpoints of the relay path

The protocol defaults to three hops for this reason: two hops provide entry and exit separation (preventing IP-destination correlation) but leave a single intermediate node that is a relatively high-value compromise target. Three hops provide meaningful intermediate diversity at a performance cost that is acceptable for most use cases.

Anonymity Set vs. Network Size

The relay network's privacy properties are strongest when many users are active simultaneously. However, building a large user base requires demonstrating compelling privacy value, which requires the relay network to already exist. This bootstrapping challenge is mitigated by:

Prioritizing browser-layer privacy features (fingerprint resistance, telemetry blocking) which do not depend on network size
Implementing relay routing as a configurable feature that users can enable when the network reaches sufficient size
Using the economic incentive model to build relay capacity ahead of user demand

Decentralization vs. Quality Control

A fully permissionless relay network (where anyone can contribute nodes without verification) maximizes decentralization but creates quality control challenges. Malicious or poorly maintained nodes degrade routing quality and create security risks.

The INCOG protocol uses a semi-permissioned model: node operators must complete on-chain registration with token holding verification, but the technical requirements are accessible to a broad range of operators. This trades some decentralization for quality assurance.

Hardware Attestation vs. Accessibility

Requiring hardware-backed attestations for full relay reward eligibility creates a barrier for operators who cannot or do not want to purchase certified hardware. The protocol addresses this through the multi-tier reward model: software-only nodes participate and receive reduced rewards, while certified hardware operators receive full rewards. This preserves accessibility while creating incentives for the stronger security guarantees that hardware attestation provides.

View original documentation