> 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/wallet/transaction-privacy.md). # Transaction Privacy ## Overview Transaction privacy encompasses the set of techniques and protocol-level constraints that minimize the amount of information observable by third parties from a user's on-chain activity. The INCOG Wallet approaches transaction privacy as a multi-layered problem: on-chain transaction graph analysis, network-layer transaction broadcast attribution, and application-layer behavioral correlation each constitute distinct threat vectors that require specific countermeasures. ## On-Chain Privacy Analysis ### The Public Ledger Problem All transactions on public blockchains are permanently recorded in an immutable, globally accessible ledger. This ledger is queryable by anyone — blockchain analytics companies, law enforcement, counterparties, and passive observers — without the knowledge or consent of transacting parties. The pseudonymous address system of most public blockchains provides only superficial privacy: addresses are pseudonyms, not anonyms, and can be linked to real-world identities through a variety of techniques. ### Transaction Graph Analysis Transaction graph analysis treats the blockchain as a directed graph where nodes are addresses and edges are transactions. Analysts apply clustering heuristics to group addresses that are likely controlled by the same entity: **Common input ownership heuristic**: When a transaction combines inputs from multiple addresses, the blockchain analytics assumption is that all input addresses are controlled by the same party (because signing multiple inputs requires possession of all corresponding private keys). This allows analysts to cluster apparently independent addresses into a single identity. **Change output heuristic**: Transactions that have one "payment" output and one "change" output — a common structure — can often be identified by the structural properties of each output. The change output, returned to the sender's control, links to the sender's other addresses. **Address reuse**: When the same address is used in multiple transactions, all those transactions are trivially linked to a common identity. **Dusting attacks**: Small amounts ("dust") are sent to an address of interest. When the recipient subsequently spends funds, the dust is typically included as an input, linking the targeted address to other addresses in the transaction. ### INCOG Wallet Countermeasures **Address rotation** prevents address-reuse linkability entirely. Each receive address is used at most once, making address-reuse-based clustering inapplicable. **UTXO management** addresses the common-input-ownership heuristic by maintaining strict separation between UTXO sets derived from different contexts. The wallet avoids combining UTXOs from different derivation contexts in a single transaction, preventing cross-context linkability through the common-input heuristic. **Change address discipline** ensures that change outputs are sent to freshly derived addresses that are structurally indistinguishable from payment outputs. The wallet uses matching script types for payment and change outputs to avoid the structural change output heuristic. **Dust defense** applies a configurable dust threshold — transactions sending amounts below the threshold to an address of interest are not automatically included in subsequent transaction inputs without explicit user confirmation. ## Network-Layer Broadcast Privacy ### The First-Broadcast Problem When a transaction is first broadcast to the peer-to-peer network, the broadcasting node's IP address is typically visible to peers that receive the transaction. This creates a network-layer linkage between the transaction and the broadcaster's IP address, which can be correlated with other identifying information to attribute the transaction to a specific individual. Several blockchain analytics firms actively monitor peer-to-peer network broadcasts to collect IP-to-transaction associations. Even if the on-chain transaction graph is otherwise unattributed, the first-broadcast linkage can deanonymize the transaction submitter. ### Relay-Routed Broadcasting All transaction broadcasts from the INCOG Wallet are routed through the INCOG relay network. The transaction is transmitted from the exit node to the blockchain network, preventing the recipient peer from observing the user's real IP address. Additionally, the wallet introduces a configurable random delay between transaction signing and broadcast. This timing randomization prevents correlation between transaction creation time (potentially observable through application behavior) and broadcast time. ### Dandelion++ Protocol Compatibility For blockchains whose peer-to-peer networks support Dandelion++ or similar stem-phase broadcast protocols, the wallet supports this mechanism as an additional layer of network broadcast privacy. Dandelion++ routes transactions through a small number of peers before transitioning to standard flood propagation, reducing the effectiveness of source inference attacks. ## Amount Privacy ### Amount-Based Fingerprinting Transaction amounts are publicly visible on most blockchains and constitute a fingerprinting signal. Distinctive amounts — large round numbers, unusual precision, amounts matching known institutional transaction patterns — can serve as identifying signals or allow transaction linking across the graph. ### Amount Normalization Where the target protocol supports it, the INCOG Wallet normalizes transaction amounts to a set of standard denominations. This reduces the information content of transaction amounts as a fingerprinting signal. For blockchains where amount normalization is not natively supported, the wallet can optionally split payments into multiple transactions of standard sizes, trading transaction efficiency for amount-based fingerprint resistance. This is an advanced option presented to users who prioritize privacy over fee efficiency. ## Timing Privacy ### Temporal Behavioral Analysis Even when transaction content and amounts are obfuscated, temporal patterns can reveal behavioral characteristics. The time of day, day of week, and inter-transaction timing intervals of on-chain activity can contribute to a behavioral fingerprint that survives address rotation. ### Timing Randomization The INCOG Wallet applies configurable timing randomization to transaction submission. The randomization model: * Transactions are submitted within a user-configurable timing window (e.g., within 30 minutes of signing) * Within the window, the submission time is drawn from a uniform distribution * Batch operations (multiple transactions) are spread over the timing window rather than submitted simultaneously This randomization disrupts time-of-day and inter-transaction timing analysis without significantly impacting the practical utility of the wallet. ## Privacy-Preserving Smart Contract Interaction ### Smart Contract Metadata Exposure Smart contract interactions expose additional metadata beyond simple value transfers: the specific function called, the parameters passed, and the state changes that result are all publicly observable. For DeFi interactions, this can reveal trading strategies, position sizes, and interaction patterns. ### Interaction Isolation The INCOG Wallet applies the same context isolation model to smart contract interactions as to simple transfers. Each smart contract interaction is associated with an isolated address context, preventing the aggregation of interactions across different applications into a unified behavioral profile. ### Calldata Privacy Where zero-knowledge proof systems or other cryptographic privacy protocols are supported by the target contract, the wallet facilitates privacy-preserving interaction modes. As zk-compatible protocols mature on major chains, the wallet will integrate these mechanisms to provide programmable privacy for smart contract interactions. ## Forward-Looking Privacy Mechanisms ### Shielded Transaction Support The INCOG Wallet architecture is designed to support shielded transaction mechanisms where available (e.g., Zcash sapling/orchard, Tornado Cash-style commitments for compatible chains). Shielded transactions break the direct linkability of input and output addresses through cryptographic mixing, providing stronger on-chain anonymity than address rotation alone. Integration of shielded transaction support is planned as a protocol extension, contingent on regulatory compatibility analysis and security review of supported mechanisms. ### Zero-Knowledge Proof Integration For chains with native zk-proof support, the wallet will integrate proof-based transaction privacy mechanisms. These allow users to prove properties of their transactions (e.g., sufficient balance, correct computation) without revealing the underlying transaction data, enabling privacy-preserving smart contract interaction that goes beyond what address rotation can achieve. --- # 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 current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://incogai.gitbook.io/incogai-docs/incog-docs/wallet/transaction-privacy.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.