Skip to content

Economic Model

dev-mondoshawan edited this page Jul 1, 2026 · 1 revision

Economic Model

**Referenced Files in This Document** - [CSIGToken.sol](file://src/CSIGToken.sol) - [CountersigStaking.sol](file://src/CountersigStaking.sol) - [CountersigIdentity.sol](file://src/CountersigIdentity.sol) - [CountersigReputation.sol](file://src/CountersigReputation.sol) - [tokenomics.md](file://docs/tokenomics.md) - [README.md](file://README.md) - [CountersigStaking.t.sol](file://test/CountersigStaking.t.sol)

Table of Contents

  1. Introduction
  2. Project Structure
  3. Core Components
  4. Architecture Overview
  5. Detailed Component Analysis
  6. Dependency Analysis
  7. Performance Considerations
  8. Troubleshooting Guide
  9. Conclusion
  10. Appendices

Introduction

This document provides comprehensive economic model documentation for Countersig Network’s tokenomics and staking system. It covers the $CSIG token supply and distribution, token utility within the protocol, the staking and slashing lifecycle, fee structure and revenue distribution, incentive alignment among stakeholders, governance controls, and long-term sustainability considerations. The analysis synthesizes on-chain contracts and the authoritative tokenomics specification to present a unified view of the economic design.

Project Structure

The economic model spans three core on-chain contracts and supporting documentation:

  • $CSIG token contract: mintable testnet token with a capped faucet; mainnet will be non-mintable and fixed supply.
  • Staking contract: manages agent identity stakes, slash lifecycle, and token distribution upon execution.
  • Identity and Reputation contracts: anchor identities and store reputation scores; integrate with staking for status and score updates during slashing.
graph TB
subgraph "Economic Contracts"
CSIG["$CSIG Token<br/>CSIGToken.sol"]
STK["Staking<br/>CountersigStaking.sol"]
ID["Identity<br/>CountersigIdentity.sol"]
REP["Reputation<br/>CountersigReputation.sol"]
end
subgraph "Governance & Docs"
DOC["Tokenomics Spec<br/>docs/tokenomics.md"]
READ["Protocol Overview<br/>README.md"]
end
CSIG <-- "transfers" --> STK
STK --> ID
STK --> REP
DOC -. "guides parameters" .-> STK
READ -. "high-level context" .-> STK
Loading

Diagram sources

  • CSIGToken.sol:12-26
  • CountersigStaking.sol:28-331
  • CountersigIdentity.sol:18-227
  • CountersigReputation.sol:24-181
  • tokenomics.md:1-167
  • README.md:20-52

Section sources

  • README.md:20-52
  • tokenomics.md:1-167

Core Components

  • $CSIG token: fixed supply on mainnet; mintable on testnet for onboarding and faucet use.
  • Staking: enforces agent participation via stake, governs slash lifecycle, and distributes tokens upon execution.
  • Identity: anchors agent identities and status; integrates with staking for slash enforcement.
  • Reputation: stores 6-factor scores; zeros scores on slash execution.

Key economic parameters:

  • Fixed supply: 1 billion $CSIG (non-mintable on mainnet).
  • Distribution: treasury, team/contributors, ecosystem/partners, public sale, liquidity provision.
  • Staking: minimum stake adjustable by governance; challenge period governs slash disputes.
  • Fees: denominated in USD, settled in $CSIG at oracle-reported spot price; staged burn model for fee revenue.

Section sources

  • CSIGToken.sol:12-26
  • CountersigStaking.sol:69-142
  • CountersigIdentity.sol:33-101
  • CountersigReputation.sol:42-94
  • tokenomics.md:16-167

Architecture Overview

The economic architecture couples staking with identity and reputation to secure agent behavior and enable trustless verification. Slashing burns part of the stake while distributing the remainder to victims and reporters. Fees collected are routed according to governance-defined stages, with staged burn activation.

graph TB
subgraph "Economic Security"
STK["CountersigStaking"]
ID["CountersigIdentity"]
REP["CountersigReputation"]
end
subgraph "Token Layer"
CSIG["CSIGToken"]
end
subgraph "Governance"
GOV["TimelockController<br/>docs/tokenomics.md"]
end
CSIG --> STK
STK --> ID
STK --> REP
GOV --> STK
GOV --> ID
GOV --> REP
Loading

Diagram sources

  • CountersigStaking.sol:28-331
  • CountersigIdentity.sol:18-227
  • CountersigReputation.sol:24-181
  • tokenomics.md:133-146

Detailed Component Analysis

$CSIG Token Supply and Distribution

  • Supply: 1 billion $CSIG fixed on mainnet; no inflation.
  • Distribution buckets (mainnet):
    • Protocol Treasury: 40% (vested, 5-year linear release)
    • Team & Contributors: 20% (vested, 4-year cliff + 4-year vest)
    • Ecosystem & Partners: 15% (milestone-based releases)
    • Public Sale: 15% (utility access, not investment)
    • Liquidity Provision: 10% (2-year Unicrypt lock, options for re-lock/burn/treasury)
  • Testnet specifics: mintable token with capped faucet for onboarding.

Implications:

  • Strong long-term scarcity with predictable release schedules.
  • Treasury and team allocations are contract-enforced, preventing central control.
  • Public sale funds are used for ecosystem growth and not returned to treasury.

Section sources

  • CSIGToken.sol:12-26
  • tokenomics.md:16-46

Token Utility and Price Stability

  • Utility anchors:
    • Identity staking: mandatory to register agents; no alternative payment.
    • Oracle epoch prioritization: micro-fees for inclusion in reputation scoring epoch.
  • USD decoupling: fees quoted in USD and settled in $CSIG at oracle-reported spot price.
  • Adjustable parameters: minimum stake and query fee are governance-tunable to maintain target USD costs.

Rationale:

  • Prevents deflationary death spiral as $CSIG rises.
  • Ensures sustainable fee revenue for oracle operators and network maintenance.

Section sources

  • tokenomics.md:49-74
  • README.md:192-207

Staking Mechanism and Agent Participation

  • Deposit stake: operators approve and deposit $CSIG to back an agent identity; additional deposits accumulate.
  • Withdraw stake: operators must keep stake above minimum while active; full withdrawal requires suspending the agent first.
  • Minimum stake: adjustable by governance; enforced post-withdrawal to preserve security.

Security invariants:

  • Only registered, active agents can stake.
  • Operators must be the identity operator for deposit/withdraw actions.

Section sources

  • CountersigStaking.sol:154-193
  • CountersigIdentity.sol:120-141

Slashing Lifecycle and Token Distribution

  • Slash initiation: authorized committee member initiates slash with evidence; agent status suspended immediately.
  • Challenge period: operator can dispute within the timelock; if disputed, proposal cancelled and agent reinstated.
  • Execution: after challenge period, anyone can execute slash; distribution:
    • 50% to burn address
    • 25% to victim
    • 25% to reporter
  • Post-execution: agent marked Slashed; reputation zeroed.
sequenceDiagram
participant CM as "Committee Member"
participant ST as "CountersigStaking"
participant ID as "CountersigIdentity"
participant REP as "CountersigReputation"
participant V as "Victim"
participant R as "Reporter"
CM->>ST : initiateSlash(didHash, victim, evidenceHash)
ST->>ID : updateStatus(Suspended)
Note over ST : Challenge period begins
alt Operator disputes within window
Op->>ST : disputeSlash(didHash)
ST->>ID : updateStatus(Active)
Note over ST : Proposal cancelled
else Window passes undisputed
Anyone->>ST : executeSlash(didHash)
ST->>ID : updateStatus(Slashed)
ST->>REP : zeroReputation(didHash)
ST-->>0xdead : 50%
ST-->>V : 25%
ST-->>CM : 25%
end
Loading

Diagram sources

  • CountersigStaking.sol:205-293
  • CountersigIdentity.sol:164-179
  • CountersigReputation.sol:135-146

Section sources

  • CountersigStaking.sol:18-27
  • CountersigStaking.sol:205-293
  • README.md:147-188

Fee Structure, Revenue Distribution, and Burn Activation

  • Fee mechanics:
    • Denominated in USD, settled in $CSIG at oracle-reported spot price.
    • Minimum stake and query fee are governance-tunable to maintain target USD costs.
  • Fee routing stages:
    • Stage 1 (Bootstrap): 100% to validators/oracles; no fee burn.
    • Stage 2 (Transition): 80% validators, 20% burned; activated when fee revenue ≥ documented oracle operator costs for 3 consecutive months.
    • Stage 3 (Mature): 50% validators, 50% burned; activated after Stage 2 for 6 months with sustained revenue.

Rationale:

  • Gradual transition from subsidy to self-sustainability.
  • Burn activation ensures token velocity control aligned with operational costs.

Section sources

  • tokenomics.md:63-98
  • README.md:190-250

Economic Security Model and Risk Mitigation

  • Slashing burn: 50% of stake permanently destroyed; categorically separate from fee burn.
  • Legal framing: slashing burn is a network security property, not a deflationary benefit.
  • Governance timelock: hard security guarantee with 7-day mainnet delay; proposer/canceller roles defined; executor permissionless after delay.
  • Oracle operator economics: revenue from fee shares, treasury subsidies, and gas reimbursements; performance bond and separate staking contract for operator accountability.

Risk mitigations:

  • Multi-signature committee on testnet; mainnet path to on-chain arbitration.
  • Challenge period prevents immediate slash execution.
  • Terminal status “Slashed” prevents further participation.
  • Reputation zeroing upon slash ensures no downstream trust abuse.

Section sources

  • tokenomics.md:100-131
  • tokenomics.md:133-146
  • README.md:106-127

Governance Controls and Parameter Tunability

  • Roles and permissions:
    • DEFAULT_ADMIN_ROLE and UPGRADER_ROLE controlled by TimelockController.
    • STAKING_CORE_ROLE (slashing) and ORACLE_ROLE (score updates) isolated for security.
    • SLASHING_COMMITTEE_ROLE (testnet multisig) for slash initiation.
  • Locked vs. tunable parameters:
    • Locked: total supply, distribution percentages, vesting schedules, LP lock, timelock delay.
    • Tunable: minimum stake, query fee, burn activation thresholds, operator bond amounts, fee routing splits.

Section sources

  • README.md:348-358
  • tokenomics.md:149-163

Dependency Analysis

The staking contract depends on identity and reputation for status and score updates during slash execution. The token contract supplies the staking contract with $CSIG for transfers.

graph TB
CSIG["CSIGToken.sol"]
STK["CountersigStaking.sol"]
ID["CountersigIdentity.sol"]
REP["CountersigReputation.sol"]
CSIG --> STK
STK --> ID
STK --> REP
Loading

Diagram sources

  • CountersigStaking.sol:69-71
  • CountersigIdentity.sol:23-27
  • CountersigReputation.sol:29-36

Section sources

  • CountersigStaking.sol:69-71
  • CountersigIdentity.sol:23-27
  • CountersigReputation.sol:29-36

Performance Considerations

  • Staking operations are gas-efficient with minimal state reads/writes; batch operations possible for operators managing multiple agents.
  • Slashing lifecycle introduces a 7-day challenge window; permissionless execution reduces liveness risk.
  • Reputation updates occur off-chain with on-chain validation; ensure efficient epoch intervals to balance throughput and cost.
  • Governance parameter changes are upgradeable via timelocked admin, minimizing disruption.

[No sources needed since this section provides general guidance]

Troubleshooting Guide

Common issues and resolutions:

  • Insufficient stake after withdrawal: ensure remaining stake meets minimum while agent is Active; suspend first for full withdrawal.
  • Slash already pending: wait until proposal is cancelled or executed; dispute within challenge window if operator.
  • Challenge period active: cannot execute slash until window closes; cannot dispute after window ends.
  • Not operator: only the identity operator can deposit/withdraw stake; ensure correct wallet is used.
  • Zero address errors: ensure valid addresses for victim/reporter in slash initiation.

Validation references:

  • Unit tests demonstrate correct behavior for deposit/withdraw, slash initiation/dispute/execution, and distribution.

Section sources

  • CountersigStaking.sol:95-102
  • CountersigStaking.t.sol:149-191
  • CountersigStaking.t.sol:197-240
  • CountersigStaking.t.sol:245-287
  • CountersigStaking.t.sol:301-369

Conclusion

Countersig’s economic model aligns stakeholder incentives through mandatory identity staking, a robust slash lifecycle, and staged fee burn activation. The $CSIG token is designed as a work token with fixed supply and strong distribution controls, while governance ensures long-term sustainability and security. The separation of slashing burn from fee burn clarifies economic properties and legal framing. Together, these mechanisms create a sybil-resistant, accountable, and economically sustainable protocol ecosystem.

[No sources needed since this section summarizes without analyzing specific files]

Appendices

Economic Incentives Matrix

  • Operators: stake to participate; maintain minimum stake to remain active; dispute slashes to protect capital.
  • Oracle Operators: earn fee shares, subsidies, and gas reimbursements; maintain performance bond and uptime.
  • Committee: incentivized to report accurately; receive 25% of executed slash; face governance oversight.
  • Treasury/Ecosystem: fund oracle subsidies and ecosystem grants; manage LP lock options post-lock.

Section sources

  • tokenomics.md:115-131
  • tokenomics.md:100-112

Clone this wiki locally