Tokenomics

Mission-first economics

CitizeAi_ is mission-first, product-first, civic-transparency-first. Economics serve auditable participation across transparency, participation, moderation, and future infrastructure lanes—not token speculation as the headline.

One fixed token, multiple product economies: CTZAI coordinates programme budgets and treasury discipline without minting per new product. Company revenue (services, SaaS, managed operations) is not the same as token inflation.

The dApp connects wallets to verified Solidity deployments. If copy and chain state disagree, on-chain state wins.

CTZAI at a glance

If your deployment uses a wrapper, fork, or proxy not described here, deployed contracts prevail.

Why CTZAI exists

CTZAI is designed to do specific jobs in the ecosystem—without reframing the project as a financial product.

One ERC-20 token across the full civic-tech suite

CTZAI is the single capped asset for all lanes that need on-chain settlement: transparency rewards today; participation and moderation programmes tomorrow. New products do not justify new issuance—they draw treasury allocation, client-funded CTZAI lines, or both.

Across lanes, CTZAI may act as reward settlement, programme stake (proposal / appeal / arbitration where designed), client budget funding, participation commitment, and scoped governance surfaces—always product-bounded, never implied global token-weighted rule.

TokenomicsPage.supplyTitle

Fixed supply discipline: the canonical token contract mints the full cap once at deployment to the initial holder (typically treasury or custody). There is no admin mint function on `CTZAIToken` after deploy.

No ongoing hidden inflation from the token contract itself: circulating supply changes through transfers, programme funding, vesting releases, presale allocation, withdrawals, and similar visible flows—not from a silent mint key in that token.

No geography-based reminting: expanding to new markets is expected to use treasury allocation and budgeting from the existing 2B cap, not a new mint per country.

Bounded emissions for rewards: extension vaults are treasury-funded; they do not mint CTZAI. Gross amounts per supported action are phase-1 fixed by design (with timelocked governance where implemented), subject to live configuration.

Product lanes (strategic map)

Four families share one token and one treasury discipline. Live vs roadmap is explicit for each:

Treasury reserve strategy — 800,000,000 CTZAI (40%)

Genesis allocation only—not new minting. Eight segregated buckets (multisig per bucket in production) improve reporting versus a single opaque wallet. Total = 800,000,000 CTZAI.

Read the White Paper table for full purpose text per bucket. The figure below is a planning view—verify balances and custody on your target network.

White Paper — Treasury reserve strategy (full table) — canonical bucket definitions and phase notes.

Programme budgets and allocation rounds

Expansion—new geography or new product lane—uses governance-approved rounds from existing supply: tranches, caps, market_id-style tagging where deployed, and expiry of unused authorizations.

Clients may co-fund CTZAI programme lines under treasury policy; that is budgeting, not stealth inflation.

Revenue model of CitizeAi_ (the company)

Sustainable operations require real service revenue: implementation, SaaS, managed programme operations, analytics/compliance, moderation administration, white-label deployments, institutional onboarding.

Token issuance is not revenue. Future products may increase CTZAI utility and company revenue simultaneously—without expanding supply.

White Paper — Company revenue model (full detail)

How value moves through the ecosystem

The following is a schematic view. Arrow strength, timing, and eligibility depend on deployment configuration and on-chain state.

• Genesis mint funds the initial allocator (often treasury).
• Treasury programmes budgets into presale, vesting schedules, staking custody, reward vault liquidity, and other roadmap buckets.
• Presale and vesting move CTZAI toward contributors and schedules per contract rules.
• Staking locks CTZAI in the vault as commitment; it does not itself print new CTZAI.
• Reward vaults pay proof-based claims from deposited CTZAI; users and programme treasuries withdraw to wallets.
• Wallet settlement is ordinary ERC-20 transfer—any secondary liquidity or pricing is external to the core mission contracts.

Rewards, staking, and anti-abuse

Rewards apply to intentional, supported actions (e.g. specific extension interactions), verified through cryptographic proofs and replay protection. They are not a generic reward for scrolling, passive time-on-site, or undefined “engagement.”

Phase-1 fixed reward model: default gross amounts are constants in the Solidity sources (e.g. political highlight vs toolbar defaults; media fixed gross)—subject to timelocked parameter changes where the contract allows. Always verify live values on your network.

Participant / programme split: political and media vaults default to 80% user share and 20% programme (company) share in basis points, routed to configurable programme treasury for its accrued balance—see the chart below. Deployed parameters may differ after governance operations.

Why a split: the participant receives the majority; the programme share helps fund bounded reward programmes, audits, operations, and ecosystem support. It is not passive yield, not an extractive “tax on browsing,” and not the product’s purpose — it is treasury discipline for mission-first civic infrastructure. Gross vs net: tokenomics and docs often cite gross per action; your wallet accrues the participant leg after the split until you withdraw (if your deployment uses internal balances first). Gas: phase 1 is user-paid — read reward figures next to network fees; there is no promise of net financial gain.

Anti-abuse: daily caps, cooldowns, market-round budget caps and windows, paused states, signer rotation with timelocks, and related guards bound abuse surface. Exact limits are deployment-specific.

Why exchangeability matters here (without hype): when CTZAI can be exchanged in the broader economy (where legally permitted and technically available), the same fixed reward can feel more tangible to participants. That practical clarity can help attract more citizens into transparency-oriented tools—while the mission remains civic infrastructure, not speculation.

Reward roadmap — how fixed rewards, guardrails, and deterministic dynamic rewards fit the EVM stack and civic mission.

Transactions and network fees (phase 1)

Model A (active in phase 1): participants sign and broadcast routine transactions from their own wallets—reward claims, optional withdrawals, staking (approve + stake, unstake request / complete), and governance votes where exposed.

Fees are paid in the chain’s native token, not CTZAI. The project does not run a default relayer or paymaster for these paths; operational treasuries fund project-originated operations, not everyday user gas.

If a future sponsored or relayed programme ships, it will be explicit in configuration and communications—until then, assume user-paid gas for every routine on-chain action.

White Paper — Phase 1 gas payment model · Gas Model page (product configuration)

Presale and vesting (modular)

Presale (`CTZAIPresale`) and vesting (`CTZAIVesting`) are separate modules. They handle sale windows, caps, contributor accounting, and schedule-based release without changing the fixed total supply.

Pricing, whitelists, hard caps, and per-wallet limits are on-chain parameters. Do not infer them from this page alone—use the debug read models and block explorer for your deployment.

Native `tokenPrice` in `PresaleConfig` (wei per 1e18 CTZAI) is set at deployment and stored on-chain. The legacy 0.002 native per 1 CTZAI figure in older docs is deprecated; the default implementation profile centers on 1e13 wei (0.00001 native per 1 CTZAI) with optional `low` / `high` scenarios (5e12 / 2e13 wei). Illustrative tables are coherence checks only—deployed bytecode and storage override narrative. See Launch pricing rationale (`#launch-pricing-rationale`) and the scenario table there.

Governance boundaries (honest framing)

In the current phase, CTZAI balance is not the default driver of broad protocol governance in the sense of one-token-one-vote over the whole roadmap. Operational module-level controls (owner, timelocks, freezes, parameter updates) live in specific contracts as implemented.

Roadmap governance—what the organisation builds next, how products roll out, and how civic safeguards evolve—is the primary governance story today for most readers. Any future token-weighted or DAO-style voting would require explicit contracts, deployment, and documentation—not an assumption from holding CTZAI.

White Paper — Governance

Geographic expansion and treasury rounds

Go-to-market may emphasise a focus geography (e.g. France-first) for product and regulatory pragmatism. That does not imply a new mint for each new geography.

Expansion uses treasury allocation rounds from existing supply—localisation, partnerships, reward budgets, moderation pilots, institutional programmes—without new minting per product. Market identifiers and round budgets support scoped programmes; active reward inventory should stay KPI-gated and time-bounded, distinct from the 2B total-supply headline. The Treasury reserve strategy (800M CTZAI in eight buckets) is the planning complement—see the White Paper Token & economics section (`#supply-discipline-lanes`).

Exchangeability supports the mission—not the other way around

Authority, risks, and how to read this page

This page is informational and non-exhaustive. It is not legal, tax, or investment advice.

No guarantee of financial outcome: holding or using CTZAI may involve loss of value; no return is promised.

No guarantee of liquidity or listing: secondary markets may be absent, illiquid, or discontinued.

Verify allowances, balances, parameters, and contract addresses on your target network using the debug hub and explorer.