Token Utility

Overview

This document specifies the concrete utility mechanisms of the $INCOG token — how the token is used within the protocol, what functions it enables, and why each utility function is designed the way it is. Token utility is not a branding claim; it is an architectural property of the protocol that determines how the token integrates with protocol functions.

Relay Node Registration

Mechanism

Node operators who wish to register as relay nodes in the INCOG Mesh Network must demonstrate $INCOG token holding above a minimum threshold. This registration prerequisite is enforced by the relay registry smart contract, which verifies token balance before accepting a node registration transaction.

The minimum holding threshold is a governance-controlled parameter, initially set to balance accessibility (enabling broad participation) with Sybil resistance (making large-scale fake node registration economically costly).

Utility Rationale

The token holding requirement for node registration serves multiple purposes:

Sybil resistance: An adversary attempting to register many fake nodes to gain influence over relay path construction must hold the minimum token amount per node. This creates an economic cost that scales linearly with the number of Sybil nodes, making large-scale Sybil attacks costly.

Incentive alignment: Node operators with token holdings have an economic stake in the protocol's success. This aligns operator interests with honest relay operation — behaving dishonestly or providing poor-quality relay service damages the token's value, directly harming the operator's holdings.

Network quality baseline: Token holding serves as a soft signal of commitment to the network. Operators who have made an economic commitment to the protocol are more likely to maintain their relay nodes professionally than anonymous, tokenless participants.

Token Movement

The token is not locked or staked in the traditional sense during node operation. Operators maintain their own wallet and can transact freely. However, if a node operator's wallet balance falls below the minimum threshold, the relay registry contract updates the node's status to ineligible for new circuit construction at the next directory update. Existing circuits are allowed to expire normally.

This design avoids the complexity of staking and slashing mechanisms while maintaining the economic alignment benefit of the holding requirement.

Priority Relay Access

Mechanism

Certain relay capacity is reserved for priority routing, accessible only to $INCOG token holders above a threshold tier. Priority routing provides:

• Higher-capacity relay paths with guaranteed minimum throughput
• Lower-latency relay configurations
• Access to exit nodes with higher-quality connectivity

Priority access is verified by the INCOG Browser's relay selection module, which presents a signed token balance proof to the relay network when requesting priority paths.

Token Balance Proof

Token balance verification for relay priority access uses a privacy-preserving balance proof mechanism. Rather than requiring the browser to reveal its wallet address to the relay network (which would create a persistent identifier), the browser generates a zero-knowledge proof of token balance:

Proof: "I hold ≥ [threshold] $INCOG tokens, committed to address [blinded commitment]"
Verification: Relay network verifies proof against on-chain state without learning the wallet address

This mechanism allows priority access without creating a new privacy leakage vector — the relay network learns only that the user holds sufficient tokens, not which address holds them.

Governance Participation

Mechanism

$INCOG token holders participate in on-chain governance through a token-weighted voting system. Governance proposals cover:

• Protocol parameter updates (reward pool sizes, minimum uptime thresholds, etc.)
• Protocol upgrade ratification
• Treasury fund allocation
• Hardware certification standard updates
• Geographic multiplier adjustments

Voting weight is proportional to token holding at the time of the vote's snapshot block.

Governance Scope

Governance is intentionally scoped to protocol parameters and resource allocation — it does not extend to decisions that would compromise the protocol's privacy properties or architectural integrity. Specifically, governance cannot:

• Reduce the minimum encryption standards of the relay protocol
• Enable logging of relay traffic
• Mandate identity disclosure by node operators

These properties are protected at the protocol architecture level, not subject to governance override.

Quorum and Threshold Requirements

Governance decisions require a minimum quorum of participating token supply and a minimum approval threshold. Different proposal types carry different requirements:

High quorum and approval requirements for significant changes prevent capture of governance by a minority of token holders.

Ecosystem Access Features

Hardware Certification Participation

Organizations wishing to manufacture INCOG-certified hardware for the relay network must hold $INCOG tokens above a certification partner threshold and pay a token-denominated certification fee. This fee is directed to the protocol treasury and used to fund ongoing certification infrastructure.

Developer Protocol Access

Third-party developers building applications that integrate with INCOG's privacy infrastructure APIs access the protocol through a tiered access model:

• Free tier: Basic API access with rate limits, available without token holding
• Standard tier: Increased rate limits and SLA guarantees, requiring a minimum token holding
• Premium tier: Full API access with dedicated support, requiring a higher token holding threshold

This tiered model creates organic demand for token holding from ecosystem developers without restricting access entirely to token holders.

Utility Demand Model

The aggregate demand for $INCOG utility creates several distinct demand vectors:

Node operator demand: Operators must hold tokens for registration eligibility. As the network expands with more node operators, this creates sustained organic holding demand proportional to network growth.

User priority access demand: Users seeking priority relay performance hold tokens to unlock priority paths. This demand is proportional to the user base and their sensitivity to relay performance.

Governance demand: Protocol participants who wish to influence governance decisions hold tokens for voting weight. This demand is proportional to the stake that governance participants have in protocol outcomes.

Developer ecosystem demand: Third-party developers hold tokens for API access tiers. This demand is proportional to ecosystem development activity.

These demand vectors are structurally independent — they do not collapse together in adverse market conditions, providing multiple foundations for sustained token utility.