> 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/incentive-model.md). # Incentive Model ## Overview The INCOG AI incentive model is the economic architecture that sustains decentralized infrastructure operation over the long term. It is designed to solve a specific coordination problem: how to maintain a globally distributed, privacy-respecting relay network without a central operator willing to absorb operational costs, and without relying on altruistic participation that historically fails to produce adequate scale and reliability. The model approaches this as a mechanism design problem: the goal is to construct a reward structure in which the optimal strategy for self-interested participants produces the outcomes the network needs — sufficient capacity, geographic diversity, operational continuity, and honest relay behavior. *** ## Network Growth Economics ### Bootstrap Phase Dynamics In the early network phase, the relay network has low utilization, limited geographic coverage, and a small anonymity set. This phase is the most challenging from an incentive perspective: the network's privacy properties are weakest, making it hardest to attract the privacy-conscious users who would generate utilization, but without utilization, operator rewards are low. The protocol addresses bootstrap dynamics by: **Front-weighting incentives**: The relay incentive pool distribution schedule is weighted toward the early deployment period, providing higher-than-long-run-equilibrium rewards to early node operators. Early operators receive an implicitly higher reward per unit of capacity because the total network share is small and the reward pool is large relative to capacity. **Non-utilization-dependent base rewards**: In the bootstrap phase, a portion of relay rewards are based on verified availability (uptime) rather than purely on traffic served. This provides a stable income floor for operators even when traffic volumes are low, preventing operator churn during the growth phase. ### Steady-State Economics As the network matures and traffic volumes grow: * Per-unit-capacity reward efficiency increases as more traffic flows through the relay network * Operator reward income becomes more predictable and calibratable against hardware costs * The relay network develops a competitive market structure: operators with efficient hardware and favorable network connectivity earn higher returns ### Long-Term Sustainability Transition Token-funded incentives are sustainable only so long as the incentive pool retains value relative to operator costs. The long-term sustainability of the network requires a transition toward fee-based revenue supplementing or replacing token issuance. Revenue sources in the long-term model include: * **Premium relay subscriptions**: Users paying for priority relay access generate revenue directed to the protocol treasury and supplementing the operator incentive pool * **Ecosystem API fees**: Third-party applications using INCOG infrastructure APIs pay usage fees * **Hardware certification fees**: Hardware manufacturers pay token-denominated certification fees * **Enterprise infrastructure**: Organizations deploying INCOG relay infrastructure for their employees generate enterprise subscription revenue As these revenue streams develop, the protocol can reduce reliance on token issuance for operator rewards, extending the sustainability of the incentive model beyond the initial token allocation horizon. *** ## Operator Return Calculation ### Estimating Operator Returns Node operators can estimate their expected monthly rewards based on: 1. **Estimated throughput**: Based on available upstream bandwidth, contribution fraction, and expected relay utilization 2. **Uptime commitment**: Expected operational continuity for the month 3. **Geographic multiplier**: The multiplier applicable to the operator's region 4. **Node class**: Tier and optional exit node contribution Using the reward formula: ``` estimated_reward = (estimated_throughput × uptime_rate × geo_multiplier × class_weight) / expected_network_total_share × monthly_reward_pool ``` This calculation is an estimate — actual rewards depend on the total network throughput in the period and the reward pool size, both of which can change over time. ### Hardware Payback Analysis For operators purchasing dedicated hardware (home routers or dedicated relay hardware), the expected time to recover hardware cost depends on: * Hardware purchase price * Expected monthly reward at current network parameters * Token price at time of reward (introducing price uncertainty) The protocol deliberately does not publish "expected returns" in fiat currency terms, as these depend on factors (token price, network utilization) that the protocol cannot control. Operators should model their own hardware payback under conservative assumptions. *** ## Incentive Alignment Analysis ### Node Quality Incentives The reward formula creates incentives for specific quality behaviors: **Uptime incentive**: The uptime multiplier declines steeply below tier-appropriate thresholds, creating a strong incentive to maintain continuous operation. An operator running at 94% uptime when the Tier 1 threshold is 95% receives no reward for the month — a significant penalty for marginal underperformance. **Throughput quality incentive**: Cross-attestation verification means that only traffic confirmed by adjacent nodes counts toward rewards. Operators cannot game throughput by generating fake traffic without incurring equivalent real network costs. **Geographic diversity incentive**: The geographic multiplier creates a direct economic incentive to deploy in underrepresented regions. An operator choosing between deploying in a crowded Western European market (1.0× multiplier) and a underrepresented African region (2.5× multiplier) earns 2.5× the per-throughput reward for geographic coverage. **Exit node incentive**: The exit node bonus compensates operators for the additional operational overhead and legal considerations of exit node operation. Exit nodes handle abuse reports, require professional network connectivity, and carry additional operational complexity. The bonus reflects this overhead. ### Defection Penalties The incentive model includes explicit penalties for defection behaviors: **Forged attestation detection**: The cross-attestation verification system produces detectable anomalies when operators forge throughput data. Detected forgery results in forfeiture of the current month's pending reward and de-listing from the relay directory, eliminating future reward eligibility. **Sybil registration detection**: Nodes registered from the same AS block or exhibiting correlated throughput patterns (consistent with a single physical infrastructure serving multiple registered nodes) are flagged for audit. Confirmed Sybil registrations result in proportional reward reduction across the affected nodes. **Protocol non-compliance**: Nodes whose relay software has been modified in ways that degrade privacy properties (detectable by the cryptographic relay protocol) fail circuit health monitoring and are de-listed. *** ## Relay Market Structure ### Competitive Dynamics The relay network, once mature, operates as a competitive market for routing capacity. Operators compete for a share of the reward pool based on their throughput contribution. This competitive structure: * Incentivizes investment in efficient hardware and high-quality network connectivity * Rewards operators who can provide capacity in high-demand geographic regions * Creates natural price discovery for the value of relay capacity ### Concentration Prevention Unconstrained competitive markets for infrastructure capacity tend toward concentration: a few large operators with scale advantages capture a dominant share of revenue. Privacy networks are particularly vulnerable to concentration risk — a single operator controlling 30%+ of relay capacity gains significant traffic analysis capability. The INCOG incentive model includes concentration prevention mechanisms: **Reward cap per operator**: A single registered operator receives rewards on at most N% of total network throughput (where N is governance-determined), regardless of actual contribution share. This prevents a single operator from capturing an overwhelming share of the relay market. **Operator diversity bonus**: Operators contributing capacity through multiple independent hardware deployments across different geographic regions receive a small bonus for architectural diversity, incentivizing distribution of capacity rather than consolidation. **Diversity monitoring**: The relay directory tracks operator concentration metrics and publicly reports them. Governance can adjust incentive parameters to correct concentration trends. --- # 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/incentive-model.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.