Phase 1 · France-first · Treasury discipline
France-first Treasury Architecture
How CitizeAi_ structures treasury custody, CTZAI reward funding, operational native-gas management, and future sponsorship readiness for the France-first phase-1 rollout—Solidity / EVM, mission-first and operationally explicit.
Treasury architecture is how CitizeAi_ keeps CTZAI reward programmes, operational resilience, and on-chain administration separable, auditable, and sustainable. On the user-pays gas default (Model A), routine participant transactions are not blanket-subsidised from treasury; the design makes that boundary intentional.
Treasury design exists to support sustainable civic transparency participation—not speculative complexity or marketing-driven mechanics.
On this page
Architecture overview — three treasury layers
Phase 1 deliberately separates Reward Treasury (CTZAI programme inventory and flows), Operations Gas Treasury (native token for project-controlled transactions), and a Future Sponsorship / Relayer Layer (not active by default). Political Transparency and Media Transparency browser extensions share treasury discipline but are distinct operational surfaces for allocation and monitoring.
Reward Treasury
Active · phase 1Purpose CTZAI inventory and programme funding for proof-based rewards—separate from day-to-day native gas for user wallets.
What it funds Allocation rounds, reward vault top-ups, tranches aligned to France-first rollout and product reality—not abstract global population scaling.
Phase 1 status Active: funds Political and Media reward surfaces subject to caps, windows, and governance/timelock where deployed.
Control Multisig-custodied treasury wallets recommended; large moves via approved workflows and published address books.
Operations Gas Treasury
Active · phase 1Purpose Holds the chain’s native gas token for CitizeAi_-controlled on-chain work—not a standing budget to pay every user’s claim gas.
What it funds Deployments, administration, parameter updates, monitoring reactions, emergency operations, treasury refills of CTZAI vaults, and infrastructure transactions initiated by operations keys.
Phase 1 status Active as the operational gas float; thresholds and refill rules are runbook-defined per deployment (placeholders on this page, not live balances).
Control Multisig or equivalent segregated operational custody; segregated from reward CTZAI balances where practicable.
Future Sponsorship / Relayer Layer
Reserved · not defaultPurpose Architectural readiness only: possible selective gas sponsorship or meta-transaction / relayer flows if product evidence warrants them.
What it funds Would require dedicated budgets, allowlists, rate limits, and explicit programmes—none of which are phase-1 defaults.
Phase 1 status Inactive / not default: no general gasless UX promise; participants should assume wallet-paid gas for claims, withdraws, staking, and votes unless a future comms + contract programme says otherwise.
Control Would ship only with governance-approved parameters and security review; until then, treat as documentation placeholder.
This separation improves security (blast radius), transparency (what budget paid for what), and sustainability (reward economics stay legible beside explicit network fees).
Treasury reserve — 800M CTZAI (40% of fixed supply)
Registry view (not a live on-chain balance dashboard): the project reserves 800,000,000 CTZAI for treasury-controlled purposes, split into eight buckets at genesis (multisig addresses per bucket). The remaining 1.2B CTZAI is outside this treasury reserve — presale, vesting, public distribution, and reward vault inventory are funded from that non-treasury slice (separate mint target or downstream transfers). Buckets map to the civic-tech suite (transparency rewards, participation, moderation, enterprise bootstrap, market access, ops, partnerships, contingency) under fixed supply — no new mint per product.
- Treasury reserve (target)
- 800,000,000 CTZAI
- Non-treasury supply (60%)
- 1,200,000,000 CTZAI
France-first readiness: Political and Media programmes should draw primarily from the core transparency — rewards bucket (and downstream vault flows); exchange / liquidity stays separate for market-access decisions. Moderation and participation lanes have dedicated buckets — preserving audit clarity.
| Bucket | Target (CTZAI) | Phase 1 intent | Bucket status |
|---|---|---|---|
| Core transparency — rewards reserve Political and Media extension reward programmes, France-first transparency rounds, reward vault top-ups. | 200,000,000 CTZAI | France-first transparency rounds and Political / Media reward surfaces — multisig-controlled programme budgets. | Active · phase 1 |
| Civic participation products Programme co-creation, citizen and union/worker participation products, consultation and social-dialogue deployments. | 150,000,000 CTZAI | Participation products and consultation deployments — bounded, milestone-tied budgets. | Active · phase 1 |
| Moderation & governance reserve Content moderation product lane; proposal, appeal, and arbitration budgets; contextual filtering and governance deployments. | 100,000,000 CTZAI | Moderation and governance tooling lanes — appeals, arbitration, and policy deployments as products mature. | Active · phase 1 |
| Client bootstrap & enterprise Institutional onboarding, co-funded pilots, enterprise / association / party / union launch support, first client activation. | 100,000,000 CTZAI | Pilot and onboarding support for institutions and associations — co-funded where applicable. | Active · phase 1 |
| Exchange / liquidity / market-access Listing optionality, liquidity prep, market-access strategy — not a promise of listing or price support. | 100,000,000 CTZAI | Market-access preparation only — not day-to-day reward accounting or price support. | Active · phase 1 |
| Operations / audits / legal / infra Security reviews, audits, infra, legal / compliance, operational resilience. | 70,000,000 CTZAI | Audits, legal, infra, and ops resilience — segregated execution float. | Active · phase 1 |
| Ecosystem growth & partnerships Civic-tech and research/data partnerships, integrations, distribution support. | 50,000,000 CTZAI | Partnerships and integrations that extend distribution without diluting core ops lines. | Active · phase 1 |
| Strategic contingency & governance flexibility Contingency buffer; governance-approved reallocation flexibility; strategic reserve. | 30,000,000 CTZAI | Governance-gated or multisig-only strategic moves — not routine vault refills. | Active · phase 1 |
Figures are canonical economics aligned with `CTZAITreasuryConstants` / deploy scripts. Verify real balances on your block explorer; assign one multisig per bucket in production.
France-first treasury logic
Phase 1 emphasises a France-first rollout: treasury allocation should track supported domains, extension availability, and measured participation—not a fictional “global TAM” narrative.
Allocation rounds stay bounded and measurable: budgets attach to product milestones and observed claim patterns, preserving treasury discipline and credible communication.
Political Transparency and Media Transparency may share high-level treasury policy but should be monitored and reported as separate surfaces (abuse shapes, gas bands, programme health can differ).
Implementation is Solidity on EVM: addresses, multisig signers, and refill cadence must match your deployment—this page states design intent, not live chain state.
Launch pricing, France programmes, and treasury discipline
Presale `tokenPrice` (wei per 1e18 CTZAI) is not a marketing headline: it sets how many CTZAI contributors receive per native wei, and therefore how much native must be raised to sell the round’s allocation. It must stay coherent with phase-1 fixed gross rewards in CTZAI, Model A user-paid gas, and illustrative France-first programme budgets (e.g. internal ~5M CTZAI gross programme need over 12 months in planning docs)—not a speculative early-stage valuation story.
Treasury funds reward vault inventory and programme rounds; users pay gas for routine claims. Do not interpret launch pricing, reward constants, or gas in isolation: read `CTZAIPresale` storage, reward vault parameters, and fee reality on the same chain together.
Launch pricing rationale — ETH-native scenarios, deprecated **0.002** placeholder, and **default** **1e13** wei profile.
Who pays what in phase 1?
Default posture: users pay their own gas for routine wallet-initiated state changes. Treasuries fund CTZAI liquidity in vaults and operational transactions—not open-ended per-user gas subsidy.
| Action | Default payer | Treasury layer involved | Notes |
|---|---|---|---|
| Wallet sign / enablement (off-chain) | User (no EVM gas for signature alone) | — | Binding to contract and chain id still required in production; subsequent on-chain steps use user gas. |
| Political Transparency reward claim | User | Reward Treasury (CTZAI inventory → vault) | User pays network fee; CTZAI credited per proof and live parameters. |
| Political reward withdraw (if enabled) | User | Reward Treasury (indirect: vault liquidity) | Second step when deployment separates internal credit and wallet transfer. |
| Media Transparency reward claim | User | Reward Treasury (CTZAI inventory → vault) | Same Model A gas rule as political line; caps / cooldowns per deployment. |
| Media reward withdraw (if enabled) | User | Reward Treasury (vault liquidity) | Optional extra transaction when withdraw is exposed separately. |
| Staking actions (stake / unstake / related) | User | Primarily — (user wallet); vault architecture funded historically via treasury programmes | User-initiated vault interactions; no phase-1 default relayer. |
| Roadmap governance vote (on-chain ballot, if deployed) | User | — | Voting wallet pays gas; distinct from treasury admin keys. |
| Admin / ops transactions (parameters, pauses, rotations) | CitizeAi_ operations | Operations Gas Treasury | Timelocked or multisig paths as implemented; not end-user gas subsidy. |
| Treasury refills (CTZAI → reward vaults, native top-ups) | CitizeAi_ operations | Reward Treasury and/or Operations Gas Treasury | Refills are governed events—monitor balances and schedules in runbooks. |
| Future sponsorship / relayer flows | Not default (would be programme-specific if ever enabled) | Future Sponsorship / Relayer Layer | Inactive in phase 1 by default; would require explicit product and budget decision. |
Reward Treasury
The Reward Treasury funds CTZAI reward programmes: inventory that flows into Political and Media reward vaults under fixed phase-1 economics, proof-based claims, and bounded rounds.
It supports France-first allocation-round logic—budgets tied to rollout reality and observed eligible demand—not unconstrained emissions storytelling.
Custody should be strict: segregate reward CTZAI planning from native gas floats so audits can answer what paid for incentives vs what paid for operations.
- Allocation discipline — tranches, caps, and freeze/pause posture documented per deployment.
- Funding windows — align vault top-ups with round schedules and treasury approvals.
- Separation from gas budget — do not commingle CTZAI programme accounting with native gas operational wallets without clear policy.
- Monitoring — track vault balances, claim rates, burn vs plan, and anomalies alongside extension telemetry.
Operations Gas Treasury
This treasury holds native tokens (e.g. ETH on an L2) used to pay gas for transactions signed by project operations—deployments, maintenance, refills, governance parameter paths, and incident responses.
It is not the default wallet for user claim gas in phase 1: Model A keeps routine user transactions user-funded, preserving treasury predictability and reducing abuse surface from open sponsorship.
Operational resilience depends on healthy native balances: monitoring, alerting, and refill governance are first-class—especially when network congestion or deployment bursts spike costs.
Operational policy parameters (placeholders)
The following are illustrative field names only. Real thresholds live in internal runbooks and deployment-specific monitoring—not as fixed numbers on this public page.
- Alert threshold
- Configure per chain — e.g. notify when operational native balance crosses a risk band defined in ops playbooks (value not stated here).
- Minimum operating balance
- Configure per chain — floor under which only critical transactions proceed until refill (value not stated here).
- Target refill balance
- Configure per chain — post-refill target band after multisig-approved top-up from cold / treasury sources (value not stated here).
Never treat this box as a live dashboard. Verify balances on your block explorer and internal tools.
Relayer / sponsorship readiness (future-only)
Relayer or meta-transaction infrastructure is not active by default in phase 1. The project does not promise gasless participation for routine claims.
The layer exists as architectural readiness: if measured onboarding friction and abuse data justify selective help, CitizeAi_ could evaluate sponsored paths—only with explicit budgets and contracts.
Any future programme would be narrow, allowlisted or rate-limited, and documented—never an unbounded “we pay all gas” posture by stealth.
Examples of **future** patterns (not current defaults)
- First successful claim sponsorship for a time-boxed onboarding experiment.
- Allowlisted campaign sponsorship tied to a specific market round.
- Governance participation sponsorship for a defined ballot window—if governance approves.
Until such a programme ships on-chain and in official comms, assume user-paid gas for all routine actions.
Multisig and control model
Treasury-facing wallets—both CTZAI reward paths and native gas operations—should be multisig-controlled (or equivalent threshold custody) to reduce single-key failure and internal fraud risk.
Reward Treasury custody benefits from multisig so large vault refills and programme reallocations receive deliberate approval and audit trail.
Operations Gas Treasury should likewise use segregated multisig policy: high-value refills and sensitive admin actions pass through reviewed workflows.
Together this improves resilience, auditability, and governance discipline—aligned with credibility before complexity.
Monitoring and refill governance
Operational readiness for France-first phase 1 includes continuous checks—not a one-time deployment task.
Reward contract balances — CTZAI available vs liabilities implied by claims and windows.
Native gas balances — operational wallets vs alert and minimum bands from runbooks.
Unusual claim spikes — possible abuse, campaign effects, or integration issues on Political vs Media lines.
Failed or stuck operational txs — nonce management, gas price, reverts on admin paths.
Refill status — scheduled top-ups, multisig queue, and dependency on cold storage.
Treasury health narrative — internal dashboards reconciling plan vs actuals for rounds and gas spend.
Phase 1 policy statement
Default phase-1 model = user-pays gas for routine on-chain actions. Treasury funds programme integrity (CTZAI rewards, vault liquidity) and operations (native gas for project transactions)—not blanket end-user gas sponsorship. This keeps the rollout simpler, more credible, and easier to secure while adoption and abuse patterns are still measured.