▸ Wallet

Wallet Architecture

Overview

The INCOG Wallet is a privacy-preserving on-chain interaction layer integrated natively into the INCOG Browser. It is designed to minimize the information footprint of blockchain interactions: reducing on-chain attribution linkability, enforcing client-side signing isolation, and preventing wallet state from leaking across browsing contexts.

The INCOG Wallet is not a general-purpose wallet seeking feature parity with existing non-custodial wallets. It is a privacy-specialized wallet optimized for users whose primary concern is minimizing the surveillance surface of their on-chain activity, and it achieves this through deliberate constraints on functionality where those constraints produce privacy benefits.

Design Principles

Minimal Metadata Footprint

Every transaction submitted to a blockchain is permanently public. The INCOG Wallet is designed to minimize the metadata that an on-chain analyst can extract from a user's transaction history:

Address rotation: Each transaction uses a fresh derived address where possible, preventing the construction of a unified transaction graph attributable to a single user
Amount normalization: Where supported by the target chain, transaction amounts are normalized to standard denominations to reduce amount-based fingerprinting
Timing randomization: Transactions are submitted with configurable timing randomization to prevent time-of-day behavioral profiling
Gas price normalization: Gas price selection avoids anomalously high or low values that could serve as identifying signals

Client-Side Signing

All cryptographic signing operations are performed locally in the browser, within the INCOG Browser's isolated execution environment. Private keys never leave the client device in unencrypted form. Specifically:

Key derivation (BIP-32/BIP-44 hierarchical deterministic key generation) is performed locally
Transaction signing is performed locally using the derived private key
Only the signed transaction (not the private key or the signing request) is transmitted to the network

Context Isolation

The wallet operates within the INCOG Browser's context isolation model. Wallet state — including derived addresses, transaction history, and private key material — is isolated from web content contexts. Web applications cannot access wallet state without explicit user authorization through a defined wallet API, and even with authorization, access is scoped to the minimum information required for the interaction.

Key Management Architecture

Hierarchical Deterministic Key Derivation

The INCOG Wallet uses BIP-32 hierarchical deterministic (HD) key derivation as its cryptographic foundation. HD key derivation allows an unlimited number of distinct private keys (and corresponding addresses) to be derived from a single master secret (the seed), while maintaining the ability to recover all derived keys from the seed alone.

The seed is derived from a BIP-39 mnemonic (a sequence of English words) using PBKDF2 with HMAC-SHA512. The mnemonic is the sole recovery mechanism for all funds — there is no server-side backup or recovery path.

Derivation Path Structure

The INCOG Wallet uses a modified derivation path structure that incorporates session and context isolation:

m / purpose' / coin_type' / account' / context' / address_index

purpose': Hardened purpose indicator (e.g., 44' for BIP-44, 84' for BIP-84)
coin_type': Coin type per SLIP-0044 registry
account': Account index (supports multiple accounts per wallet)
context': Context isolation index — each browsing context receives an independent address space
address_index: Per-transaction address derivation index

The context' level is an INCOG-specific addition to standard derivation paths. It ensures that addresses derived for use in different browsing contexts are mathematically independent — an observer cannot link addresses used in context A to addresses used in context B even with knowledge of the extended public key for one context.

Seed Storage

The master seed is stored in the browser's encrypted storage, encrypted with a key derived from the user's wallet passphrase using Argon2id key derivation. The encryption scheme:

Argon2id with high memory and time cost parameters to resist brute-force attacks on the passphrase
Authenticated encryption (AES-256-GCM) for the seed
Separate encryption of the mnemonic backup, stored offline by the user

The encrypted seed never leaves the device. There is no remote backup service. This is a deliberate privacy-preserving design choice — a remote backup service would constitute a centralized store of sensitive key material.

Address Privacy

Address Rotation

The INCOG Wallet derives a fresh address for each transaction by default. Receiving addresses are rotated after each use, and change outputs are sent to newly derived addresses rather than recycled addresses. This address rotation strategy:

Prevents address-reuse-based linkability in transaction graph analysis
Makes it significantly harder to construct a complete spending history for a single user
Does not reduce fund recovery capability — all addresses are derivable from the seed

Address Clustering Resistance

Beyond address rotation, the wallet implements policies to resist common transaction graph clustering heuristics:

Common-input-ownership heuristic: The wallet avoids combining UTXOs from different address contexts in a single transaction, which blockchain analysts interpret as evidence of common ownership
Change address heuristic: Change outputs are sent to addresses that are indistinguishable (by type, derivation path structure, or script) from payment outputs
Round-number heuristic: Where possible, the wallet avoids round-number transaction amounts that serve as identifiable signals

Integration with Relay Network

Wallet transactions submitted through the INCOG Browser are routed through the INCOG relay network, preventing the recipient node's operator and network-level observers from linking transaction submissions to the user's IP address. This is important because blockchain node operators can log the IP address from which transactions are first broadcast — a metadata leakage vector that address rotation alone does not address.

Transaction Construction

Fee Estimation

Gas or transaction fee estimation is performed through a privacy-preserving mechanism that avoids querying fee estimation services with requests that could carry identifying metadata. The wallet uses:

Local fee estimation based on recently observed block data (obtained through the relay network)
Normalization of fee rates to common values to avoid distinctive fee signatures
Conservative estimates that prioritize confirmation probability over cost optimization in default mode

Multi-Asset Support

The wallet supports multiple blockchain assets through a plugin architecture. Each supported asset type has an associated module that implements:

Key derivation for the asset's address format
Transaction construction per the asset's protocol requirements
Fee estimation
Transaction broadcasting

Asset modules are included based on protocol governance decisions and community contribution. The wallet deliberately does not support every asset — inclusion requires a security review of the asset module and network compatibility with the relay-routed broadcasting architecture.

Wallet API for Web Applications

Permission Model

Web applications can request wallet access through a defined browser wallet API. The permission model is more restrictive than typical wallet APIs to minimize information exposure:

Address disclosure: Web applications receive one address per interaction, not the full address space
Transaction signing: Each signing request is presented to the user with full context; mass signing or batched signing without individual confirmation is not supported
Balance queries: Applications can query balance for disclosed addresses only; full balance enumeration across the address space is not exposed
Transaction history: Applications do not receive access to wallet transaction history through the API

Session Scoping

Wallet API access is session-scoped and context-scoped. A web application granted wallet access in one browsing context cannot access wallet state in another context, even within the same browser session. Permission grants do not persist across sessions — applications must request permission in each new session.

This session-scoped permission model prevents wallet state from becoming a cross-site or cross-session tracking vector. A site that has been granted wallet access cannot use that access to fingerprint or link the user across subsequent visits.

View original documentation