▸ Roadmap

Roadmap

Overview

The INCOG AI protocol is being built in deliberate, sequenced phases. Each phase delivers a self-contained, functional product while establishing the technical infrastructure required for the next phase. This sequencing reflects a deliberate architectural philosophy: no phase ships until the previous phase's infrastructure has been validated in production, and no phase makes claims about capabilities that have not yet been built.

The roadmap is honest about current state. It does not present speculative future capabilities as existing infrastructure. Phases marked as planned or in development are engineering specifications, not shipped systems.

Phase 01 — Privacy URL Shortener

StatusLive

Overview: The first INCOG AI product is a privacy-preserving URL shortener. Every link generated strips tracking parameters, masks referrer headers, and logs zero click data. This product is intentionally narrow in scope: it delivers concrete, verifiable privacy value without requiring any of the complex distributed infrastructure that later phases depend on.

What it does:

Removes all known tracking parameters (UTM tags, fbclid, gclid, msclkid, mc_eid, and 25+ others) from submitted URLs
Generates clean short links in the incog.ai/s/ namespace
Routes link redirects without logging the clicking user's IP, browser, or device characteristics
Retains zero click analytics data by architecture — there is no click logging system

Why it matters for the protocol:
The URL shortener is the first demonstration that INCOG AI ships working privacy products before building a narrative. It establishes the team's execution capability, seeds the early user base, and provides a low-friction entry point for users who may later adopt the Privacy Browser and Mesh Network.

Technical infrastructure delivered:

Privacy-preserving redirect handling
Tracking parameter stripping logic (reused in browser layer)
Referrer header masking

Phase 02 — Privacy Browser

StatusIn active development

Overview: The INCOG Privacy Browser is the core product of the protocol — a hardened browser client with privacy protection built into the execution model rather than added as an extension layer. This is a long build. The browser must modify behavior at the engine level, and engine-level modifications require rigorous testing across the full diversity of web content.

Delivery scope:

Fingerprint reduction engine:

Canvas API normalization at the rendering pipeline level
WebGL parameter table-based normalization
AudioContext output normalization
Navigator API normalization (platform, languages, userAgent, hardwareConcurrency, deviceMemory)
Screen and window dimension normalization
Performance timing precision reduction

Session-level isolation:

Per-context, per-session storage partitioning (cookies, localStorage, sessionStorage, IndexedDB, Cache API)
Service worker isolation model
Cross-origin state leakage prevention
Storage clearing on session termination

Telemetry blocking:

Request-layer interception of known telemetry endpoints
Analytics SDK pattern detection and blocking
Referrer header stripping and normalization
Third-party cookie blocking

Encrypted DNS:

DNS-over-HTTPS integration with configurable resolver
DNS query isolation from browsing context identifiers
DNSSEC validation

Initial relay integration (limited, configurable):

Basic relay routing for sensitive browsing contexts
Relay client bundled with browser distribution
User-controlled relay enable/disable

Why this takes time: Modifying a browser engine without breaking the web is a substantially more difficult engineering challenge than building an extension. The session isolation model, in particular, must be carefully validated to ensure it does not break legitimate cross-site authentication patterns, OAuth flows, and other scenarios where some cross-origin state sharing is both intended and necessary.

Milestone targets:

Alpha release to closed technical testers: Early development phase
Beta release to early access registrants: Development milestone
Public release: To be determined based on alpha/beta validation

Phase 03 — Relay Testnet

StatusPlanned — begins after browser Phase 02 reaches beta

Overview: The INCOG Mesh Network testnet is the first deployment of the decentralized relay routing infrastructure. The testnet operates with a limited set of vetted node operators and browser clients, validating the relay protocol, reward verification system, and circuit construction algorithms under real-world network conditions.

Delivery scope:

Relay protocol implementation:

Three-hop circuit construction with full layered encryption
Fixed-size cell protocol with padding
ECDH-based per-session key exchange
Circuit lifecycle management (construction, rotation, teardown)
Path failure detection and automatic reconstruction

Relay directory system:

Directory authority infrastructure
Node capability announcement and health monitoring
Threshold-signed directory snapshot distribution
Client-side directory synchronization

Node operator tooling:

Relay node software (testnet release) for server deployment
Node registration interface
Operator monitoring dashboard
Testnet reward tracking (non-mainnet tokens)

Testnet reward system:

Cross-attestation verification system
Throughput measurement and verification
Uptime tracking and scoring
Test token distribution to verify reward calculation logic

Testnet operator requirements:

Technically sophisticated operators (server-class deployments for testnet)
Commitment to report bugs and protocol anomalies
Agreement to testnet-only reward terms (no mainnet token equivalence)

Why testnet before mainnet: Relay protocol bugs discovered in production with real token rewards and real user privacy at stake are significantly more damaging than bugs discovered in a controlled testnet environment. The testnet allows protocol validation without the full consequences of errors.

Phase 04 — Node Hardware Pilot

StatusPlanned — begins after relay testnet validation

Overview: The hardware pilot introduces the first INCOG-certified consumer relay hardware, enabling home users to contribute relay capacity without server-class technical expertise. The hardware pilot begins with a limited production run of certified devices distributed to a qualified operator cohort.

Delivery scope:

Hardware certification program:

Hardware certification specification finalized
Manufacturing partner certification process
Secure boot chain and firmware signature infrastructure
Hardware security element integration and testing

First certified hardware:

Production run of INCOG-certified home router hardware
Plug-and-play deployment targeting non-technical operators
Hardware-backed cryptographic attestation capability
Secure OTA firmware update mechanism

Hardware-tier reward structure:

Hardware attestation verification in reward contract
Tiered reward multiplier for certified hardware vs. software-only nodes
Manufacturing certification fee mechanism

Mainnet relay rewards launch:

Mainnet $INCOG relay reward issuance begins
Cross-attestation verification on mainnet
First monthly reward distribution cycle

Operator onboarding infrastructure:

Self-service node registration portal
Hardware setup guide and support documentation
Operator community channels

Phase 05 — Wallet Integration

StatusPlanned — begins after relay infrastructure is stable

Overview: The INCOG Wallet module is integrated natively into the Privacy Browser, providing privacy-preserving on-chain interaction that extends the browser's privacy guarantees to blockchain transactions.

Delivery scope:

Core wallet functionality:

BIP-32/BIP-44 HD key derivation with context isolation extension
Address rotation by default for all receive operations
Client-side transaction signing
Multi-asset support (EVM-compatible chains as primary)

Privacy features:

Address clustering resistance (UTXO management, change output discipline)
Relay-routed transaction broadcasting
Transaction timing randomization
Dust defense mechanism

Browser integration:

Browser chrome wallet interface (isolated from web content)
Permission-gated web application wallet API
Session-scoped wallet access grants
$INCOG reward claim integration (claim relay node rewards from browser)

Security:

Encrypted seed storage with Argon2id key derivation
Hardware key isolation where browser execution environment supports it
Explicit confirmation UI for all signing operations

Phase 06 — Private Inference Layer

StatusPlanned — begins after wallet integration is complete

Overview: The INCOG LLM module delivers privacy-preserving language model inference capabilities embedded in the browser. Local inference provides the strongest privacy guarantees; relay-routed inference provides a fallback for hardware-constrained devices.

Delivery scope:

Local inference runtime:

WebAssembly + WebGPU inference runtime
Curated model library (sub-7B parameter models for consumer hardware)
Context management with session-scoped memory only
Model verification and integrity checking

Relay-routed inference:

Inference provider integration with relay-routed request routing
Provider selection interface (configured by relay routing)
Mode selection UI (local vs. relay-routed)

Browser integration:

Browser chrome inference interface (isolated from web content)
Permission-gated browser inference API for web applications
Multi-session inference isolation

Privacy validation:

Zero persistent prompt storage audit
Network isolation validation (local mode)
Content isolation validation (no web content API leakage)

Phase 07 — Global Mesh Expansion

StatusLong-term — begins as network matures

Overview: Following the successful deployment of the relay testnet and hardware pilot, Phase 07 focuses on scaling the relay network to global coverage — targeting 1,000+ active relay nodes across all major geographic regions and autonomous systems.

Focus areas:

Geographic expansion:

Structured outreach to underrepresented regions
Operator community development in target regions
Hardware distribution partnerships for high-priority regions

Protocol optimization:

Performance optimization of relay routing based on production data
Dynamic geographic multiplier tuning based on network distribution metrics
Circuit construction algorithm refinement based on real-world path failure patterns

Resilience improvements:

Cover traffic implementation at sufficient network scale
Relay directory decentralization (DHT-based announcement system)
Exit node policy framework refinement

Governance activation:

Full on-chain governance system activation
Community governance of relay network parameters
Protocol upgrade process formalization

Ongoing: Protocol Research

Parallel to product development, the INCOG protocol team conducts ongoing research into future protocol extensions:

Zero-knowledge relay verification: ZK-SNARK-based throughput attestations that allow reward verification without revealing participation metadata.
Private information retrieval for directory: PIR-based relay directory queries to prevent directory queries from revealing node selection intent.
Mixnet protocol upgrade: Architecture for upgrading the relay protocol to a mixnet model for stronger anonymity at higher latency tolerance.
Confidential inference integration: Hardware TEE-based inference for provider-side content privacy in relay-routed inference mode.

These are research directions, not product commitments. They will be incorporated into the protocol roadmap as their technical maturity and resource availability allow.

Roadmap Governance

The roadmap is subject to revision based on:

Technical discoveries during development
Community governance decisions affecting priorities
Resource and timing realities
New protocol research findings

Significant roadmap changes will be communicated to the community through protocol governance channels before implementation. The protocol team is committed to honest communication about progress, setbacks, and timeline changes — no phase will be represented as complete until it is demonstrably deployed and functional.

View original documentation