> For the complete documentation index, see [llms.txt](https://incogai.gitbook.io/incogai-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://incogai.gitbook.io/incogai-docs/incog-docs/architecture/data-flow.md). # Data Flow ## Overview This document maps the data flows through the INCOG AI protocol system — what information is created, where it flows, who observes it at each point, and what privacy properties are maintained at each stage. Understanding data flows is essential for evaluating the system's privacy claims, identifying residual leakage, and reasoning about the effects of component failures. *** ## Browsing Session Data Flow ### Session Initialization ``` User opens INCOG Browser │ ▼ Browser generates session-scoped fingerprint normalization seed [Seed is random, not derived from any persistent identifier] [Seed is stored in volatile memory only] │ ▼ Browser initializes isolated storage context for session [No persistent state carried from prior sessions] [No shared state with other active tabs] │ ▼ Relay client connects to relay network [Fetches relay directory update if stale] [Directory fetch routed through privacy-preserving channel] │ ▼ Pre-builds relay circuits (3-hop) for immediate use [Circuit construction visible to: E (entry node), M (middle), X (exit)] [Entry sees: client IP, M's address] [Middle sees: E, X addresses] [Exit sees: M's address] [No node sees full path] │ ▼ Session ready for user interaction ``` ### Page Load Data Flow ``` User navigates to URL │ ▼ Browser DNS resolution [DNS query sent via DoH to configured resolver] [ISP does not observe DNS query] [DoH resolver observes query: destination domain] │ ▼ Browser requests resource through relay circuit [Request encrypted in 3 layers before leaving browser] [Entry node: decrypts outer layer → sees encrypted request + M address] [Middle node: decrypts middle layer → sees encrypted request + X address] [Exit node: decrypts inner layer → sees HTTP/S request + destination] [Exit node connects to destination on behalf of client] │ ▼ Destination server receives HTTP/S request [Sees: exit node IP address, request headers (normalized)] [Does not see: client real IP] │ ▼ Response returned through relay path [Encrypted by exit, middle, entry nodes before delivery to browser] │ ▼ Browser receives response │ ▼ JavaScript execution environment initialized for origin [Canvas/WebGL APIs return normalized values] [navigator.* APIs return normalized values] [Storage APIs scoped to isolated context] │ ▼ Telemetry requests intercepted [Analytics, tracking, advertising requests identified and dropped] [No telemetry data leaves browser] │ ▼ Page renders in isolated context ``` ### Session Termination Data Flow ``` User closes browser or ends session │ ▼ Browser volatile state erased [Cookies cleared] [sessionStorage cleared] [In-memory session objects dereferenced and garbage collected] [Fingerprint normalization seed zeroed and regenerated] │ ▼ Relay circuits gracefully torn down [DESTROY cells sent to entry nodes] [Circuit state cleared at all relay nodes] │ ▼ Session keys zeroed at relay nodes [Forward secrecy guaranteed: no session data recoverable from future key compromise] │ ▼ Next session starts from clean state ``` *** ## Relay Network Data Flow ### Circuit Construction Flow ``` Browser Client │ ├─── Selects entry node E from relay directory ├─── Selects middle node M (different AS from E) ├─── Selects exit node X (different AS from M, E) │ ▼ Authenticated key exchange with E Client → E: ClientHello (client ephemeral public key) E → Client: ServerHello (E identity cert + E ephemeral public key) Client verifies E cert against directory Client derives K_E │ ▼ EXTEND request to E Client → E: Encrypted(K_E, EXTEND{M_address, client_ephemeral_M}) E → M: CREATE{client_ephemeral_M} M → E: CREATED{M_ephemeral_public_key} E → Client: Encrypted(K_E, EXTENDED{M_ephemeral_public_key}) Client derives K_M │ ▼ EXTEND2 request through circuit Client → E: Encrypted(K_E, Encrypted(K_M, EXTEND2{X_address, client_ephemeral_X})) E → M: Encrypted(K_M, EXTEND2{X_address, client_ephemeral_X}) M → X: CREATE2{client_ephemeral_X} X → M: CREATED2{X_ephemeral_public_key} M → E: Encrypted(K_M, EXTENDED2{X_ephemeral_public_key}) E → Client: Encrypted(K_E, Encrypted(K_M, EXTENDED2{X_ephemeral_public_key})) Client derives K_X │ ▼ Circuit complete. Information known to each party: Client: K_E, K_M, K_X, full path E: Client IP, M address (not X or destination) M: E address, X address (not client or destination) X: M address (not E, client, or destination initially) ``` ### Traffic Flow Through Circuit ``` Client: Creates payload P for destination D Computes: C = Encrypt(K_E, Encrypt(K_M, Encrypt(K_X, P || relay_header{D}))) Sends C to E in RELAY cells Entry Node E: Receives RELAY cells from client Decrypts outer layer: C' = Decrypt(K_E, C) = Encrypt(K_M, Encrypt(K_X, P || relay_header)) Validates auth tag for E's layer Determines next hop from relay_header (sees M address, not final destination) Forwards C' to M in RELAY cells Middle Node M: Receives RELAY cells from E Decrypts middle layer: C'' = Decrypt(K_M, C') = Encrypt(K_X, P || relay_header) Validates auth tag for M's layer Determines next hop from relay_header (sees X address, not final destination) Forwards C'' to X in RELAY cells Exit Node X: Receives RELAY cells from M Decrypts final layer: P_and_header = Decrypt(K_X, C'') = P || relay_header{D} Validates auth tag for X's layer Opens TCP connection to destination D Sends payload P to D What each node observes in steady state: E: {client_IP, M_address, ciphertext, timing, volume} M: {E_address, X_address, ciphertext, timing, volume} X: {M_address, destination D, plaintext_payload, timing, volume} Destination D: {X_IP, request content} ``` *** ## Reward Verification Data Flow ``` Node N accumulates monthly relay activity │ ▼ N's relay software generates attestation records: For each circuit interaction in period: AttestationRecord { node_id: N.public_key period: YYYY-MM peer_node_id: adjacent node's public key bytes_exchanged: u64 circuit_count: u32 timestamp: u64 signature: Sign(N.private_key, above) } │ ▼ N assembles monthly attestation bundle Includes own throughput attestation Includes references to peer attestations (obtained through peer exchange) Signs bundle with N.private_key │ ▼ N submits attestation bundle to reward contract Contract verifies N.signature against registered N.public_key Contract checks peer attestation references for corroboration Contract calculates N's verified_throughput = min(self_reported, peer_corroborated) │ ▼ Contract accumulates all nodes' verified_throughput for the period Calculates total_network_throughput Applies uptime_multiplier, geographic_multiplier, class_weight Calculates each node's reward_share │ ▼ N claims reward Contract releases N's reward from relay incentive pool Transfer recorded on-chain ``` *** ## Wallet Transaction Data Flow ``` User initiates transaction in INCOG Wallet │ ▼ Wallet derives fresh address for transaction HD derivation: m / purpose' / coin' / account' / context' / new_index address = derive(HD_path, master_seed) index incremented in wallet state │ ▼ Transaction constructed locally Inputs selected from UTXO set (respecting context isolation) Change output directed to freshly derived change address Fee estimated from local block data Transaction serialized in memory │ ▼ Transaction signed locally Private key derived for each input address: ephemeral, used once Signing performed in browser sandbox (key not accessible to web content) Signed transaction serialized │ ▼ Signed transaction routed through relay for broadcast Relay circuit established (if not already active) Signed transaction transmitted through relay to blockchain peer Peer receives transaction — sees exit node IP, not user IP Transaction broadcast to blockchain network │ ▼ Transaction confirmed on-chain Browser monitors for confirmation via relay-routed RPC queries Wallet state updated with confirmed transaction Used address marked spent in UTXO set ``` *** ## Information Minimization Summary The following table summarizes what information is observable at each system boundary: | Observer | What They See | What They Don't See | | ------------------- | ---------------------------------------------------- | ----------------------------------- | | ISP | Encrypted traffic to relay entry node | Destinations, content, DNS queries | | Entry relay node | Client IP, encrypted payload, timing | Destination, content, full path | | Middle relay node | Adjacent IPs, encrypted payload | Client IP, destination, content | | Exit relay node | Destination, decrypted payload | Client IP, full routing path | | Destination server | Exit IP, request content | Client IP | | DNS resolver (DoH) | Domain being resolved | Client behavior beyond query | | Relay directory | IPs of directory-querying clients | Which nodes are being queried | | Reward contract | Signed attestation bundles | Traffic content, routing details | | INCOG AI (operator) | Relay directory statistics, aggregate network health | Individual user traffic, identities | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://incogai.gitbook.io/incogai-docs/incog-docs/architecture/data-flow.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.