White paper — Vision & Execution (civic transparency infrastructure)

CitizeAi_ is not designed as a token project searching for a use case. It is designed as a civic-tech suite that begins where ordinary citizens already are: inside the reading flow, on familiar news pages, confronting political names, media brands, ownership structures, public subsidies, and accountability questions in real time. The first mission is practical civic utility, not wallet acquisition.

That design choice gives CitizeAi_ a second strategic role: it can serve as an accessible entry point into dApp participation for regular citizens who would not begin with a wallet, a token, or a governance interface on their own. The bridge is intentional. A citizen first encounters useful transparency tooling in-browser; only later, if the citizen chooses, the experience can continue into a wallet-native dApp for proof review, claims, staking, or roadmap-governed participation. In other words, CitizeAi_ does not ask citizens to become “crypto users” first. It asks whether civic-tech can make optional on-chain participation legible, useful, and worth choosing.

This distinction matters. The browser products remain the primary user-facing layer. They must deliver value without a wallet, without CTZAI, and without any obligation to continue on-chain. The dApp is the optional execution layer for explicit, auditable actions. CTZAI remains the settlement, budgeting, and coordination layer beneath that experience. Product utility first, dApp participation second, token mechanics third: that is the order that keeps the mission credible.

The broader civic-tech suite extends this same logic beyond the two live transparency products. Transparency is the gateway because it is the lowest-friction civic utility surface; prototype-stage information-integrity extensions and later participation layers build on that foundation without collapsing maturity into a single headline.

The broader civic-tech suite should now be read in three maturity bands. First, the live transparency layer: Political Transparency and Media Transparency. Second, the prototype layer: Content Moderation and News Debunking, both of which expand CitizeAi_ from transparency into information-integrity tooling while remaining early-stage products rather than finalized public deployments. Third, the longer-horizon participation and governance infrastructure layers. This sequencing keeps the narrative operationally honest: usefulness first, prototypes second, broader civic coordination later.

The EVM / Solidity stack exists to make settlement auditable and interoperable: extensions surface intentional actions; the wallet-connected dApp (Scaffold-ETH 2–style wallet flows) is where users review claims and sign routine transactions; smart contracts enforce caps, splits, and deployment rules. Reward and governance posture is summarized in Core principles below—so this foreword stays short while the commitments stay explicit.

France-first rollout keeps datasets, UX, and operator focus coherent before breadth—without new minting for geography. New products do not justify new CTZAI issuance: expansion uses treasury allocation rounds from the existing 2B cap, client-funded programme budgets, or both. Programme authorizations should expire, revert, or be re-approved—not leak silently. Predictability and auditability come before narrative complexity.

**Live today:** **Political Transparency** and **Media Transparency** browser extensions (France-first datasets and supported domains), plus the wallet-native **Solidity / EVM** dApp for claims, presale, vesting, staking, and governance surfaces (**testnet-stage maturity** where deployed). **Prototype stage** in this document: **Content Moderation** and **News Debunking** browser extensions in the broader suite—**not** described here as finalized public products. **Not live as full products** in this document’s sense: roadmap-governed **participation** and **institutional** modules beyond the live transparency pair—those remain **roadmap-described** unless separately announced.

CTZAI is a fixed-supply ERC-20: settlement, budgeting, coordination, and bounded incentives—not the project’s purpose, not passive yield, not “earn for browsing,” and not default governance for everything. Presale native proceeds (raised through `CTZAIPresale`) fund execution readiness—engineering, security, legal, launch operations, and contingency—while CTZAI treasury reserve buckets (e.g. 800M / 40%) are a separate planning layer from those proceeds (see Presale proceeds — use of funds).

CitizeAi_ combines direct product revenue, bounded programme treasury logic, and token-based coordination: the live browser extensions are paid products, while CTZAI and the 80/20 reward architecture support the suite’s on-chain settlement and sustainability model.

A useful way to read CitizeAi_ is in two layers. Layer 1 is the actual product experience: a reader installs a browser extension, encounters structured political or media context while reading, and gains value without needing a wallet or token. Layer 2 is optional and begins only when a user chooses to continue into the wallet-connected dApp for proof review, claims, staking, or roadmap-governed actions. This separation is intentional: the civic product must remain legible and useful even for people who never claim CTZAI.

That layered model is also the project’s adoption thesis. CitizeAi_ is building a path by which ordinary citizens can encounter dApp participation through civic usefulness rather than through speculation, trading, or abstract protocol messaging. The browser extension layer lowers the entry barrier by meeting people in familiar reading behaviour; the wallet-connected dApp becomes relevant only when a citizen sees enough value to continue into explicit, reviewable, on-chain action. In this sense, the civic-tech suite is not only a product architecture but a citizen onboarding architecture: from transparency in flow, to optional wallet literacy, to bounded participation in auditable digital civic infrastructure.

For many users, the first practical entry into the CitizeAi_ ecosystem is therefore a paid civic-tech product, not a token purchase: the extensions are useful on their own, and optional dApp participation comes later.

**Problem (one line):** reading environments optimize engagement, not accountability; public data exists but rarely appears **in the reading flow**; wallet-native settlement can align participation with auditability only when emission rules stay narrow and honest.

**Differentiation:** political vs media rewards use **separate contracts**; actions are **proof-bound** and **capped**; users **sign** in the audited dApp—not inside privileged extension contexts.

• Citizen bridge to dApp: the suite is designed to make optional dApp participation legible to regular citizens through useful civic-tech products first—not through token-first onboarding.

**Modular stack:** `CTZAIToken`, **`CTZAIPresale`** (native raise; contributor CTZAI release), **`CTZAIVesting`**, staking vault, **`ctzai_extension_reward`**, **`ctzai_media_extension_reward`**, **`ctzai_roadmap_governance`** (headline governance story now), **`ctzai_dao_policy`** (secondary / expandable)—each with a clear ABI boundary.

**Supply discipline:** **one** fixed ERC-20, **multiple** programme lanes, **no** new mint per product or geography. Phase 1 stays **fixed-reward**. **Roadmap governance** leads “what we build next”; DAO-style modules are **scoped**.

**12–24 month proof:** stable extension ↔ dApp ↔ chain handoff; install → active → wallet → **claim success**; bounded abuse; **treasury / KPI** alignment; credible reporting—**before** aggressive dynamic reward engineering.

Presale proceeds are expected to fund contract hardening, audits, integration, France-first rollout, liquidity optionality preparation, and runway—see Presale proceeds — use of funds for planning bands (not on-chain guarantees).

In plain terms: civic usefulness and comprehension in the reading flow first; wallet review and signing in the dApp only when you choose—the same order as the layered model above.

France does not suffer from a total absence of political or media information. It suffers from a distribution problem, a timing problem, and a usability problem. Public-interest data exists. Open data exists. Reports exist. Databases exist. But too much of that information still lives outside the citizen’s real decision moment: outside the article, outside the reading flow, outside the everyday interface through which public opinion is actually formed. In a high-speed information environment, that distance is no longer a minor UX flaw. It is a democratic weakness.

That is why the timing is right for CitizeAi_. We are entering a period in which adding structured civic context to political and media information is becoming essential democratic infrastructure. France is moving toward the 2027 presidential cycle at a moment of unusually deep mistrust in both politics and the information environment.

At the same time, the media landscape itself is under pressure. Traditional news organisations are facing declining engagement, trust erosion, and structural transformation. Yet this is not an argument against professional journalism. Quite the opposite. It is an argument for making professional news environments more legible, more contextualised, and more useful to citizens at the exact moment they read. Trust is not rebuilt by asking people to leave the article and go search through external repositories. Trust is rebuilt by helping them read better, with more context, more structure, and more memory.

This is the opening CitizeAi_ is designed for. The first deployment does not try to pull citizens away from the news ecosystem. It does the reverse. It starts on professional news and media domains, because that is where democratic attention still matters most. The wager is simple: if citizens return to classical news environments but are better equipped while reading — with structured context on political figures, accountability indicators, outlet ownership, public subsidies, funding structure, and other public-interest signals — then civic-tech stops being a niche repository model and becomes a practical reading companion.

No more PDF. No more database. No more repository browsed by fourteen insomniac experts. The information has to arrive under the citizen’s fingertips, at the exact moment interpretation happens.

This matters especially in an election cycle. In the noise of daily coverage, too many politically relevant facts disappear into churn: judicial affairs, attendance records, mandate performance, structural media interests, recurring accountability indicators. In a world of open data, those signals should not remain permanently available only to experts who know where to search. They should become durable civic markers inside ordinary reading behaviour. The democratic promise of open data is not fulfilled when data merely exists; it is fulfilled when citizens can actually use it in context.

That is also why CitizeAi_ should be understood as more than a browser extension strategy. It is an entry architecture for a new phase of civic-tech. The first layer is immediate and practical: help people read political and media information more intelligently, in context, on the pages they already visit. The second layer is optional and more ambitious: introduce wallet-native civic infrastructure in which proofs, incentives, participation, and governance become reviewable, bounded, and auditable. The point is not to force citizens into crypto culture. The point is to use the maturation of dApp and DAO infrastructure to make participation more legible, more explainable, and more accountable than it used to be.

In CitizeAi_, this evolution remains mission-first. The product begins with two crucial transparency extensions because the immediate democratic need is clear: help citizens navigate the news landscape before the next French presidential election with more context, more memory, and more critical distance. From there, the wider suite can open new forms of bounded civic participation: product-scoped governance, transparent moderation logic, structured public-interest review, and, where appropriate, new coordination surfaces bringing together journalists, experts, academics, citizens, politicians, and union representatives. Not DAO theatre. A gradual civic interface shift: from static repositories to live context, from passive reading to informed participation, from abstract Web3 promises to concrete democratic utility.

The crypto incentive matters in that architecture, but it must be read correctly. It is not a payment for passive attention, not a bounty on scrolling, and not a speculative substitute for civic purpose. It is a bounded re-engagement and participation mechanism: one way to make it more attractive for citizens to remain inside professional news environments while being better equipped to interpret what they read. In a context where parts of the public increasingly drift toward low-trust or low-quality information sources, a voluntary alliance with the news and media ecosystem is a strategic choice. CitizeAi_ does not seek to weaken that ecosystem. It seeks to help make it more legible, more navigable, and more democratically useful.

That is why now. Because trust is low. Because elections are approaching. Because media authority is contested but still essential. Because citizens need context where they read, not only where experts archive. Because civic-tech can finally move from the margins to the interface. And because the tools now exist to build that bridge responsibly.

CitizeAi_’s first users are not a vague “general public.” They are a set of adjacent early-adopter groups connected by one practical need: they want political and media information to be easier to interpret, more transparent, and more trustworthy at the exact moment they read it. The project’s early market is therefore behavioural before it is demographic. It starts with people already inside the news flow, extends to people who have partly withdrawn from it, and also reaches users who approach the product from crypto utility or civic-engagement logic rather than from journalism alone.

The first core segment is news-engaged transparency seekers. These are readers who already consume professional news, already care about politics or public life, and want more context while reading rather than after the fact. They are the most natural first users because CitizeAi_ begins directly on news and media domains. France is not a market with no willingness to pay for news: Reuters Institute’s 2025 France profile reports that 11% pay for online news, while trust in news overall is only 29%. That combination matters. It means there is already a paying and attention-rich base for professional information, but that credibility and value must increasingly be delivered through better interfaces, not just stronger editorial claims.

The second core segment is mistrustful but re-engageable citizens. These are people who still care about politics, institutions, and public decisions, but who have partially disengaged from classical media or public discourse because they perceive the environment as noisy, partial, polarised, or structurally opaque. This is a large strategic opening in France. OECD data shows that only 34% of French people reported high or moderately high trust in the national government in 2023, while only 18% trusted political parties and 33% trusted news media; only 26% believed that the political system lets people like them have a say. In other words, the opportunity is not to ask citizens to trust more blindly, but to help them verify more easily and read with better civic context.

The third core segment is crypto-mature utility seekers. These are users already familiar with wallets, token logic, or on-chain participation, but increasingly selective about what deserves attention. They are not looking for another speculative object; they are looking for a product with visible utility, coherent economics, and a mission they can defend without irony. France now has a meaningful base for this segment. Adan’s 2025 study reports that 92% of French people have heard of digital assets, and the 2026 barometer reports that 11% of the French population own at least one crypto-asset, while 14% have already purchased crypto-assets at some point and 32% of non-holders say they might acquire them in future. That does not make France a crypto-majority society, but it clearly means there is now a substantial pool of crypto-aware and crypto-familiar users who can recognise the difference between utility-backed infrastructure and empty token theatre.

The fourth core segment is civic-tech and participation-oriented users. This includes citizens already motivated by transparency, accountability, democratic quality, institutional reform, public-interest technology, and new forms of participation. This audience matters not only because it may adopt early, but because it can validate and amplify the product. OECD’s work on open government and trust supports this logic directly: transparency, access to information, integrity, and the feeling of political voice are linked to stronger trust and better democratic engagement. CitizeAi_ fits this audience because it does not begin with abstract governance rhetoric; it begins with practical transparency tools and can later extend toward more structured, auditable participation.

A sharper ICP page should also reflect two underestimated but strategically important sub-segments. The first is local and regional media readers. This matters because trust in professional news is not flat across the ecosystem. Reuters Institute has previously highlighted that in France, local and regional news brands perform particularly well on trust, and its broader 2025 work continues to note the strategic value of local and regional titles. For CitizeAi_, this means early partnership and adoption should not be imagined only through large national brands. Local and regional ecosystems may offer a higher-trust, higher-legitimacy path into the market.

The second underestimated sub-segment is young, digitally fragmented news users — especially students, early-career adults, and politically socialised younger citizens. They are not necessarily loyal readers of traditional homepages, but they are central to the future of political information consumption. Reuters Institute’s 2026 report on young news audiences argues that the biggest shift is not a retreat from news altogether, but a move away from news websites toward social platforms, video, creators, and newer interfaces. France-specific Reuters data also reports 37% using social media for news weekly. That makes this segment highly relevant for CitizeAi_: the project can meet younger users at the edge of professional media and help reconnect them to more structured, contextualised information environments.

A third underestimated group is journalists, newsroom innovation teams, educators, researchers, and fact-checking-adjacent actors. They are not the primary retail ICP, but they matter early because they can function as validators, critics, distribution multipliers, and design interlocutors. They can help shape how the product is understood: not as anti-media infrastructure, but as a transparency layer that strengthens legibility around politics, ownership, incentives, and information integrity. Their importance is strategic even when their number is smaller than the consumer audience. This is especially relevant in a market where traditional news organisations are struggling with declining engagement, low trust, and stagnating digital subscriptions.

Taken together, these segments create a stronger thesis than a one-audience model. CitizeAi_ is not only trying to convert existing news readers into transparency-tool users. It is also trying to re-engage citizens who no longer fully trust the information environment, attract crypto-mature users toward a serious public-interest use case, and offer civic-tech communities a product that begins with immediate utility rather than abstract governance promises. That bridge logic is the real ICP. The early market is where those groups overlap: citizens who want more context, more reliability, and more agency in how they interpret what they read.

The acquisition logic follows the same structure. Media collaborations and a France-first PR strategy are best suited to reach news-engaged users, local/regional audiences, and legitimacy-sensitive citizens. Crypto-native and wallet-aware channels are best suited to attract utility-seeking digital users who can recognise the project’s fundamentals. Civic-tech, research, and transparency networks are best suited to bring in amplifiers, validators, and participation-oriented communities. This means the first customer base is not random: it is a deliberately assembled coalition of adjacent user groups that can reinforce one another.

In practical terms, CitizeAi_’s early ICP can therefore be read as a structured sequence:

1. readers already following the news and seeking better transparency;
2. mistrustful but re-engageable citizens who still want credible signals;
3. crypto-mature users attracted by serious utility and bounded token design;
4. civic-tech and participation-oriented communities;
5. local/regional news audiences as a high-trust partnership segment;
6. younger, digitally fragmented news users who need a bridge back to contextualised professional information;
7. newsroom, education, research, and fact-checking-adjacent actors as ecosystem validators and multipliers.

That segmentation is strategically coherent because it matches both sides of the project. The browser-extension layer serves immediate public usefulness in the reading flow. The dApp layer serves optional, reviewable, wallet-native participation for the subset of users ready to go further. The strongest first users are therefore not just “people interested in politics” or “people interested in crypto.” They are people for whom transparency, context, and credible digital participation are beginning to converge into the same product need.

Democratic health depends on what millions of people read in practice—not only on what experts publish elsewhere. The decisive moment for transparency is often **the moment of reading**: a citizen is already in motion, trying to understand who is speaking, who is implicated, and who benefits from a narrative. If that moment requires leaving the page for every name check, ownership lookup, or subsidy search, transparency becomes a privilege for the few with time and skill—not a habit for the many.

Political Transparency is a France-first browser extension. On supported French news pages it detects named public figures, public-office holders, and declarants in scope, highlights them in the article text, and opens structured transparency context grounded in public declarative data—accountability context while you read, with less manual search friction than tab-hopping for every name.

Media Transparency is a sibling browser extension—not a skin of the political product. On participating outlets (by domain) it surfaces ownership, public subsidies, funding, and other outlet-level structural signals—source literacy in the reading flow, so readers can see more of the structure and money behind the brand, not only the headline.

Keeping **people** and **outlets** in **separate products** avoids a noisy overlay that mixes accountability questions with ownership questions. **Product first, optional incentives second, governance as infrastructure:** **CTZAI** and the **Solidity** stack support **auditable, bounded** programme mechanics—they do **not** redefine the civic mission.

Both extensions are useful without a wallet and without CTZAI. In-flow transparency is designed to work without connecting a wallet. Optional on-chain steps exist only when a user opens the CitizeAi_ dApp and chooses wallet flows.

This utility-first design does more than protect the mission from crypto-first distortion. It also creates a realistic public pathway into dApp usage. Most citizens will never start from staking screens, token dashboards, or governance interfaces. They may, however, start from a useful browser product that helps them interpret politics and media more intelligently while reading. CitizeAi_ uses that asymmetry deliberately: transparency first, optional wallet-native participation later. The result is a civic-tech entry ramp into dApp behaviour that begins with comprehension, not speculation.

The **wallet-connected dApp** is a **supporting layer** for proof review, claims, staking, and roadmap governance—surfaces that need **explicit consent and cryptographic signing**. It does **not** replace the extensions as the main user value, and it is **not** the project headline.

Transparency tooling often fails on adoption: manual steps, unclear incentives, and weak linkage between user effort and an immutable ledger. Without measurable interaction semantics, operators cannot distinguish genuine engagement from spam, sybil-style farming, or scripted abuse.

Centralized loyalty points are opaque and revocable; they rarely interoperate with wallets or community governance. Users and regulators increasingly expect provenance for political and media content, yet few systems combine in-flow context, wallet-native settlement, and transparent emission rules.

CitizeAi_ addresses this by defining narrow, reviewable reward events (for example highlight clicks and toolbar opens), binding them to unique on-chain identifiers, and enforcing caps and splits directly in contract code.

With the extensions installed, citizens read on **supported French domains** as usual. **Political Transparency** detects and **highlights** in-scope public figures and opens **structured accountability context** in-flow. **Media Transparency** maps **participating outlets** to **ownership, subsidies, and funding** signals for **source literacy**—again **without** treating every article as a reason to open another tab. That **reading-layer** value is **independent** of wallets and CTZAI. When—and only when—a user takes a **narrow, programme-defined** interaction that can be attested, the stack may offer an **optional** path: structured handoff to the **wallet-native dApp**, where the user **reviews** the proof and **signs** the **EVM** transaction. Short-lived **signed attestations** bridge intentional off-chain gestures to on-chain `claim_reward` entrypoints; **Solidity** enforces replay protection, caps, cooldowns, and treasury splits.

From gesture to settlement (optional path): intentional extension affordance → attested proof (bound to chain id, contract, recipient, freshness/TTL rules) → dApp review → wallet signature → contract execution → optional withdraw or further flows per deployment. Phase 1 default: the user pays native-token gas for routine on-chain actions unless verified configuration states otherwise.

The CitizeAi_ **EVM-compatible** dApp connects standard wallets (e.g. via EIP-1193 providers), surfaces token, presale, vesting, staking, governance, and reward flows, and keeps **deployed contract addresses, chain configuration, and ABIs** aligned with verified Solidity builds—so integrators always know which **interface** they call. CI and release processes should treat **ABI JSON**, **address registries**, and generated client types as authoritative alongside on-chain verification. That artefact authority model matches the Token and Tokenomics pages: **live bytecode, storage, and published config** override informal copy.

Political extension flows focus on public-life transparency signals (for example declarative disclosures aligned with reference datasets such as HATVP on supported sites). The media extension focuses on ownership and funding transparency via the CitizeAi_ API—without mixing political features into that product line.

A separate beta web platform (`beta_frontend`) explores broader knowledge-graph and governance UX; it complements the extensions and contracts but does not replace on-chain accounting for CTZAI rewards described here.

CitizeAi_ is civic transparency infrastructure: it is meant to **improve transparency in France’s political and media arenas** by bringing structured context into the reading flow—where people already consume news and public information—so that accountability and media literacy are practical, not theoretical. **The user benefit is immediate without any token claim:** highlights, context, and outlet signals work as long as the extensions are installed.

The product line is intentionally split into two browser extensions. Political Transparency surfaces contextual public-life transparency signals while you read—who is named, what official disclosures exist, how narratives recur—so users can interpret public discourse with evidence in view. Media Transparency surfaces ownership, funding, and source-structure signals so users can evaluate outlets and framing with structural insight, not guesswork. Both are designed to be valuable even when no token is involved: they address a public-interest information problem first.

**CTZAI is not here to define the project**—it exists to reinforce deliberate transparency-seeking behaviour and to help adoption and retention around the products. Optional incentives are not why these products exist—**product first, reward second**. They reinforce *intentional* transparency-seeking behaviour: narrow, named actions that can be attested, proof-bound, capped, and treasury-disciplined. They are not a generic reward for scrolling, passive browsing, undifferentiated clicks, or undefined “engagement.”

This is also why CitizeAi_ can matter beyond its immediate reward mechanics. If designed correctly, the project can help normalize a different public understanding of dApps: not as abstract speculative interfaces, but as optional civic execution surfaces connected to real public-interest use cases. In that sense, the suite can widen access to dApp participation by anchoring it in transparency, comprehension, and explicit consent. The citizen does not need to start as a Web3-native participant. CitizeAi_ is built so that civic usefulness can come first.

The same discipline applies to sustainability. CitizeAi_ is not built on the assumption that token mechanics alone should fund delivery. The live browser products can generate ordinary fiat revenue through paid access; service lines can generate additional operational revenue; and the phase-1 20% programme treasury share helps sustain the incentive infrastructure itself. This separation is strategically healthy: it reduces pressure to over-financialise the token, while preserving a bounded on-chain mechanism for programme continuity.

This distinction matters for partners, users, and oversight. CitizeAi_ is not a click-farming product, not an attention-mining scheme, not “earn for browsing,” and not a passive reward system. Incentives do not monetize attention in the abstract; they settle bounded, audited claims when users take specific transparency-oriented steps that contracts and operators can verify.

CTZAI and on-chain rails support the mission. The token is primarily a settlement, ecosystem coordination, and reward asset inside a documented Solidity suite—presale and vesting allocations, extension-reward settlement after claims, and staking locks that express long-term alignment. Exchangeability (where markets and law allow) can strengthen motivation for civic-tech participation; it is an adoption amplifier, not the project’s purpose, and implies no promise of liquidity, listing, or profit. Staking is not APR or yield: it is a commitment, eligibility, and anti-abuse layer that modulates suggested caps and multipliers under the fixed-reward model. The civic mission does not exist to justify the token; the token exists to keep the programme measurable, bounded, and wallet-interoperable.

Governance in the current phase emphasizes **roadmap governance** and operational controls described in this paper—not default token-weighted voting over routine product parameters. Policy DAO and similar contracts are **secondary / expandable** infrastructure. CTZAI is not described here as a default “governance token”; that separation is intentional.

End users interact through the browser chrome: **Political Transparency** and **Media Transparency** are the **primary** surfaces for civic context. Extensions scope permissions to relevant hosts and emit reward events only for defined affordances. Services issue campaign maps and cryptographically bound proofs; the dApp assembles **contract calls**, requests **signatures** through the user’s wallet, and broadcasts **transactions** to an **EVM** JSON-RPC endpoint for inclusion in blocks.

On-chain, CTZAI balances and per-contract ledgers reconcile claims and withdrawals; the staking vault exposes eligibility (tier ≥ 1, maturity met, no pending unstake, not paused) and suggested caps/multipliers—extension reward contracts still enforce proofs and their own limits. The diagram below summarizes the left-to-right flow from citizen to chain.

Phase 1 operational economics on an EVM stack are not captured by a single “typical transaction” snapshot. CitizeAi_ models user-borne chain cost in two linked layers: per-user transaction scenarios (what an individual may sign when claiming, withdrawing, staking, or voting) and aggregate adoption scenarios (how many French users on supported domains move through the funnel from reader to installer to wallet-connected claimant). Treasury stress-testing elsewhere in this paper already depends on funnel outputs; transaction costs scale with the same volumes—multiplied by gas bands and effective fee markets on the not-yet-frozen production network.

The civic mission remains first: Political Transparency and Media Transparency browser extensions deliver in-flow accountability signals whether or not anyone claims CTZAI. Settlement rails are second: they must stay honest about gas and fees so participation remains realistic for ordinary users—not optimised as a speculative convenience narrative.

Gas discipline is therefore an implementation requirement for France-first rollout: small, fixed phase-1 rewards only remain credible if the chain’s fee environment preserves a sensible reward-to-fee relationship for the actions users repeat most often.

Behind the modelling sits a simple behavioural funnel. A person must first encounter value in the extension, then return often enough for the product to matter, then decide whether the optional wallet step is worth taking, and only then become a claimant or repeat participant. That is why the paper treats installs, active use, wallet connection, successful claims, and repeat participation as different stages of one journey, not as interchangeable growth numbers. The core product challenge is not “get everyone on-chain”; it is make in-flow transparency useful enough that some users rationally choose to continue.

The Gas Model is the phase-1 rule that routine user actions (claims, optional withdraws, staking moves, on-chain votes) are signed and paid for by the user’s wallet in the chain’s native token. The dApp ships with an explicit `GAS_MODEL` configuration (`user_pays`; relayer, sponsorship, and paymaster paths off by default) so UX, treasury framing, and contract usage stay aligned.

This is the same Model A posture documented in the Phase 1 gas payment model subsection and Who pays gas in phase 1? table above. The following card links the live dApp surfaces where participants actually confirm transactions.

CitizeAi_ should be understood not as a single-category product, but as a multi-layered civic-tech system positioned across five adjacent fields: news and media transparency, browser-linked token utility, structured civic participation, trust-rebuilding media initiatives, and information-integrity networks. That is its core strategic difference. Most adjacent projects are strong in one field. CitizeAi_ is designed to connect several of them in sequence: transparency in the reading flow first, optional token utility second, and bounded participation and governance later.

In the first field, CitizeAi_ sits near products such as NewsGuard, Ground News, and AllSides. These tools improve information literacy by helping users assess source reliability, compare media framing, or identify bias patterns. NewsGuard, for example, explains that it rates websites and apps using journalistic criteria and provides "Nutrition Labels" for users. These are important comparators because they prove there is real demand for tools that make the information environment more legible. But they remain primarily analysis, rating, or comparison layers. They do not combine political and media transparency in the reading flow with an optional tokenized participation architecture. CitizeAi_ is therefore more layered: it does not stop at source assessment; it links transparency to utility and, over time, to civic participation.

In the second field, CitizeAi_ sits near browser- or search-adjacent crypto products such as Brave / BAT and Presearch. These projects demonstrate that token-linked digital habits can create attraction, retention, and ecosystem effects. But their primary logic is not civic transparency. Their center of gravity is browser/search behavior and token utility, whereas CitizeAi_ ties optional incentives to bounded public-interest use: understanding political actors, media ownership, public subsidies, and later information-integrity workflows. In that sense, CitizeAi_ is more mission-grounded and less attention-extractive than typical browser-token models.

In the third field, CitizeAi_ sits near civic-participation and digital-democracy infrastructures such as Decidim, vTaiwan, and Polis. These systems are strong references for consultation, deliberation, and participatory process design. But they do not generally begin inside the citizen’s everyday reading flow. CitizeAi_ differs by using browser-native transparency as the entry point and only then extending toward optional participation, governance, and coordination layers. It is, in effect, a civic-tech on-ramp rather than a participation portal first.

A fourth adjacent reference is Kleros, which represents governance- and dispute-resolution-oriented crypto infrastructure. Kleros is relevant because it shows how rule-bound, cryptoeconomic coordination can be operationalised. But it is not a public-information product and does not begin from citizen-facing media or political transparency. CitizeAi_ therefore differs both in audience and in order of operations: transparency first, optional participation second, bounded governance later. That sequence is strategically important because it keeps the project legible to ordinary citizens before asking them to care about governance.

A fifth and increasingly relevant reference field is local and regional trust-oriented media initiatives. This matters because CitizeAi_ is not aligned with replacing professional media. It is aligned with rebuilding trust inside professional media ecosystems and helping readers return to them with better context. Reuters Institute’s 2025 work notes that local and regional news brands enjoy the highest rates of trust of any media in France, and Reuters has separately highlighted how newsrooms are experimenting with transparency as a way to rebuild trust. This is highly relevant to CitizeAi_. It means the project is not only adjacent to media-literacy tools; it is also aligned with efforts inside journalism itself to make reporting more legible, accountable, and trusted. CitizeAi_ can therefore be positioned as a trust-rebuilding civic-tech layer for professional media ecosystems, not as an anti-media substitute.

A sixth field is fact-checking networks and newsroom innovation labs. These are especially relevant for the future News Debunking prototype. The European Fact-Checking Standards Network (EFCSN) describes itself as the voice of European fact-checkers that uphold and promote high standards, build professional links, and strengthen transparent and effective responses to misinformation. The International Fact-Checking Network (IFCN) at Poynter describes itself as supporting fact-checkers worldwide through networking, capacity building, and collaboration. JournalismAI, meanwhile, frames itself around using AI to make journalism better through shared experimentation and case studies. These are not direct competitors to CitizeAi_; they are ecosystem reference points. Their existence shows that there is already a professional layer of information-integrity actors, standards, and collaborative practice. CitizeAi_'s News Debunking prototype can later integrate these kinds of stakeholders through a scoped DAO-like review layer composed of journalists, experts, academics, and citizens. Nicely put: the DAO would not be a replacement for professional fact-checking; it would be a structured coordination surface that helps decide which reviewed signals, contested claims, or debunking contexts are sufficiently relevant, robust, and useful to surface in the extension for end users.

That point is strategically important. The News Debunking prototype should not be narrated as "CitizeAi_ will become the fact-checker of everything." It should be narrated as a civic-tech interface and governance layer that can connect professional verification ecosystems, structured public-interest review, and end-user legibility. Existing fact-checking networks bring standards, methods, and editorial discipline. CitizeAi_ can bring reading-flow distribution, structured product design, and optional governance-enabled prioritisation. In that sense, the future DAO is best understood as a collaborative filtering and escalation layer that sits downstream of professional verification practice and upstream of user-facing extension logic.

The result is a distinctive position. CitizeAi_ is more civic and participatory than source-rating tools, more useful and democratically grounded than generic browser-token incentive models, more embedded in everyday information consumption than many participation platforms, and more product-distributed than most fact-checking or newsroom-innovation ecosystems. It does not ask users to choose between reading better, participating digitally, and understanding token utility. It aims to connect these functions within one coherent France-first civic-tech suite.

Beta web platform

The `beta_frontend` application (Next.js, PostgreSQL/Prisma, JWT auth) prototypes governance and knowledge experiences that may converge with on-chain DAO contracts over time; treat it as experimental UX unless a specific deployment is announced as canonical.

CitizeAi_ EVM dApp

Production wallet flows for CTZAI (ERC-20), presale, vesting, staking vault, extension reward claims, and governance documentation pages live here. Extensions should deep-link users into these routes so **connection, transaction review, and signing** stay in an audited web surface, not inside privileged extension contexts.

Why route a treasury share on every gross accrual?

A 100% participant payout looks generous on a slide but is fragile operationally: security reviews, RPC and indexer uptime, abuse monitoring, legal triage, dataset maintenance, and honest communication all have real cost. The 20% programme-treasury lane is the disciplined way to keep the same contract rules funding both user settlements and long-horizon programme health—without hiding subsidy inside inflation or vague “foundation” budgets. Parameters—including basis points—are deployment truth: verify on-chain getters and ABI before treating any number as a promise.

Gross vs what the participant accrues

Documentation and UX often show gross CTZAI per eligible action (e.g. political 1.00 vs 0.10 CTZAI by path; media 0.5 CTZAI before split). The participant share is not the gross: it is gross × participant_bps / 10_000 (e.g. 80% of gross when bps are 8000). The treasury share is the remainder. Some flows expose a `previewClaimSettlement` (or equivalent read) so wallets can show expected net to the signer before broadcast—still subject to final on-chain checks, caps, and daily limits.

Political vs media—same split, different rails

Do not merge the two programmes mentally. Political rewards distinguish highlight-driven disclosure (interaction type 1) from toolbar popup open (interaction type 2) with different phase-1 gross defaults. Media rewards centre on notification / toolbar paths with one phase-1 gross, tighter caps and cooldowns, and freshness-bound proofs. Each vault maintains its own merkle / attestation semantics and nonces; a proof valid for one product is not portable to the other.

Gas (Model A)

In phase 1, users pay their own gas for wallet-initiated transactions—including `claimReward` / `claimRewardWithMarket` and any withdraw step the deployment exposes. The treasury share of the accrual is not a blanket gas subsidy; sponsorship, relayers, or paymasters remain off by default and roadmap-governed if introduced later.

Phase 1 gas payment model (who pays)

Governance, timelocks, and deployment truth

Material parameter moves (treasury address, reward amounts, basis points, caps, pause) should follow the project’s published governance and timelock posture where applicable—readers should assume multisig / timelock complexity for production deployments. Marketing PDFs and screenshots decay; verified contract addresses, deployment manifests, and read-only calls are the source of truth for what users actually sign against.

Company revenue is not token issuance. CitizeAi_ is built to fund real engineering, deployments, product operations, support, legal work, and long-term civic-tech execution through a combination of direct product revenue, service revenue, and mission-aligned programme economics. CTZAI handles on-chain settlement, budgeting, and coordination where appropriate; it is not a substitute for a real business model.

In the near term, CitizeAi_ has a direct retail product layer as well as broader institutional and programme revenue potential. The two live browser products already use a citizen-facing access model: Political Transparency is offered at 9.99 EUR per year or 39.99 EUR lifetime, while Media Transparency is offered at 9.99 EUR per year or 29.99 EUR lifetime. That pricing matters strategically because it confirms that the extensions are standalone civic-tech products with immediate value in the reading flow, not merely token-adjacent interfaces waiting for speculative demand.

This distinction is important for how the ecosystem should be understood. A citizen does not need to begin by buying CTZAI, connecting a wallet, or entering a crypto-native interface. The first entry point is the product itself: pay for access to a useful transparency tool, use it in ordinary browsing, and only later decide whether optional dApp participation is worthwhile.

This direct product revenue is complemented by broader service-layer revenue. Future lines for parties, unions, institutions, associations, and aligned organisations may include implementation fees, subscription / SaaS, managed programme operations, analytics / reporting / governance support, moderation administration, white-label deployments, institutional onboarding, and optional client-funded CTZAI programme lines where treasury policy allows.

At the same time, CitizeAi_ also operates with a programme-sustainability mechanism inside its reward architecture. In the phase-1 extension reward design, gross reward accruals are split on an 80% participant / 20% programme treasury basis. That 20% treasury share is not the same thing as ordinary fiat company revenue, and it should not be described as passive profit extraction. It is better understood as a mission-aligned sustainability rail: a bounded mechanism that helps fund the infrastructure, monitoring, legal triage, dataset maintenance, treasury discipline, and ecosystem continuity required to keep the programme credible over time.

Taken together, this creates a more robust model than either extreme. CitizeAi_ does not rely only on token optics, and it does not rely only on fiat product subscriptions. It combines paid civic-tech products, optional service lines, and bounded programme treasury logic within one coherent operating model. That structure is stronger both for mission credibility and for crypto-industry relevance.

Keep three ledgers mentally separate: company revenue (fiat from extension subscriptions, lifetime purchases, and service contracts), programme treasury funding (the 20% programme treasury share and other CTZAI programme allocations used to sustain reward infrastructure and ecosystem continuity), and token reserve / treasury architecture (fixed-supply CTZAI buckets, allocation rounds, and on-chain programme budgets). These layers are related, but they are not interchangeable.

This separation matters strategically. The company can grow through paid product access, service lines, implementation work, managed operations, analytics, governance support, and client-funded programme budgets without needing to expand token supply whenever the product roadmap expands. That reduces pressure to financialise CTZAI beyond its bounded coordination role and makes the fixed-supply model more defensible over time.

CitizeAi_ should not be read through a single-lens revenue model. The project combines at least three economic layers that serve different purposes.

First, there is direct company revenue: users may pay for the live browser products through annual subscriptions or lifetime access, and aligned organisations may pay for implementation, reporting, managed operations, moderation support, or white-label deployments.

Second, there is programme treasury sustainability inside the reward system itself. The phase-1 extension reward architecture routes gross accruals on an 80% participant / 20% programme treasury basis. That treasury share is not a claim that the company “earns yield” from user behaviour in a simplistic sense. It is a bounded programme mechanism designed to keep the reward system economically honest by funding the infrastructure and operational burden that a proof-based civic incentive system actually creates.

Third, there is the broader CTZAI treasury and reserve architecture: fixed-supply allocation buckets, allocation rounds, and governed programme budgets that support expansion across transparency, participation, moderation, and future infrastructure lanes.

This layered structure matters because it prevents a common category error. CitizeAi_ is not a token-first project pretending to have products, but it is also not a pure SaaS product with incidental crypto branding. It is a civic-tech suite whose product revenue, treasury logic, and on-chain coordination layer are designed to reinforce one another without collapsing into the same accounting category.

**One fixed ERC-20 for the full civic-tech suite:** CTZAI is implemented in **Solidity** with **2,000,000,000** units (18 decimals), **minted once** at deployment. It supports **multiple programme rails** (transparency rewards today; participation, moderation, and institutional pilots tomorrow) as **settlement, budgeting, coordination, and scoped-governance** surfaces—**not** a default “vote on everything because you hold tokens” design, **not** passive yield, **not** an inflation printer. Circulation follows transfers, presale, vesting, treasury allocations, staking, and withdrawals—**no** hidden mint in `CTZAIToken`. **Treasury reserve strategy** (below) plans **800,000,000 CTZAI (40%)** in **eight named buckets**—complementary to presale, vesting, and other published programmes.

**`CTZAIPresale`** raises **native currency** only (`contribute` with `msg.value`); caps, timers, whitelist, and **`FundReleaseConfig`** govern how contributor CTZAI unlocks (`withdrawImmediateFunds`, `claimVestedTokens`). **`CTZAIVesting`** is a separate vault for other beneficiary programmes with per-schedule cliffs and durations—presale contributors are **not** required to use it.

The staking vault locks CTZAI for alignment and on-chain eligibility signals: tier from effective stake, maturity after each stake epoch, no eligibility while unstake is pending, and suggested daily caps / modest bps multipliers for fixed rewards—not APR, passive yield, or emissions from the vault.

Extension rewards credit predominantly the participant (see split below) while routing a treasury share to sustain operations, audits, and ecosystem growth. Claims are proof-based and intentionally narrow—not passive yield, not attention mining, not APR. Depending on deployment, a separate withdraw step may move CTZAI to the user wallet after an internal credit. Exact numeric caps (daily claims, cooldown seconds) are deployment-specific—verify on-chain parameters and verified ABI before relying on them.

Future upgrades may unify accounting so more flows settle directly in CTZAI; any change to contribution assets, presale wiring, or settlement paths should be published in advance with matching documentation and, where relevant, governance notices.

Internal allocation modelling derives annual CTZAI needs from a bottom-up funnel: reachable readers on supported domains, install and active-user rates, wallet connection, rewarded actions per connected user, claim success after caps and anti-abuse checks, plus a fraud reserve. The planning unit is funded, verifiable actions—not a percentage of the national population. France-round programme needs are intended to sit primarily under the **Reward & market-allocation** line of the **Treasury reserve strategy** (Token section), not a discretionary pool without a documented home.

Governance-facing documentation describes a 12-month France round on the order of five million CTZAI gross programme need (base-case funnel outputs plus reserve), released in tranches—for example four—only after KPI gates (launch validation, product–market signal, scale confirmation) rather than as a single upfront lump sum. Exact authorizations, dates, and on-chain execution remain subject to approved proposals and live deployments.

At that illustrative scale, the round is still a small fraction of fixed supply (about 25 basis points of two billion CTZAI): the binding constraints are execution quality, emission credibility, and treasury control—not abstract token scarcity.

Beyond allocation maths and tranche gates, CitizeAi_ maintains a deliberate treasury architecture for phase 1: separate concerns for CTZAI reward inventory, native gas for project-controlled operations, and future sponsorship / relayer readiness. The split exists for security (blast radius), transparency (what budget paid for what), and sustainability (reward economics stay legible next to explicit network fees).

The France-first rollout applies to the Political Transparency and Media Transparency browser extensions on the Solidity / EVM path. Reward Treasury flows fund proof-based programmes and vault top-ups; Operations Gas Treasury funds deployments, administration, refills, and incident transactions—not, by default, every end-user gas bill. A future sponsorship / relayer layer is architectural reserve only: not the phase-1 default (see Phase 1 gas payment model in this document).

Custody should favour multisig (or threshold-equivalent) wallets for both reward and operations gas paths; large refills and sensitive admin actions warrant controlled approvals, monitoring of vault and native balances, and runbook-defined alert bands—aligned with the treasury monitoring specification that follows.

**Roadmap governance is the headline story in the current phase.** `ctzai_roadmap_governance` targets product-scoped decisions—what to build next—with explicit on-chain options and tallies suitable for transparent reporting. **Product-scoped governance** is the default: **participation, moderation, and institutional** lanes may use **different** on-chain or off-chain procedures—always **bounded**, never “governance theatre.” Tallies are **not** weighted by CTZAI balance unless a future upgrade documents that model end-to-end.

CTZAI is **not** a token-weighted governance instrument by default: holding or transferring CTZAI does not entitle accounts to votes through the ERC-20 contract alone. Day-to-day legitimacy grows from shipped product, clear notices, and honouring published parameters—not from premature claims of full decentralization.

**Policy DAO (`ctzai_dao_policy`)** and similar modules are **secondary / expandable**: allowlisted ranked ballots on roadmap strings, with incentives and aggregation patterns defined per deployment. They can help prioritize ecosystem work as membership and process mature; they do not replace roadmap governance as the primary narrative for product direction in this document.

Treasury-funded allocation rounds (including France phase 1) are intended to be approved through explicit proposals: budget from **existing fixed supply**, no covert inflation, scope of funded extension actions, tranche release conditioned on KPI gates, reporting obligations, and treatment of unused funds at expiry.

Governance contracts are separate from extension reward economics: they coordinate priorities; they do not mint CTZAI unless a future upgrade explicitly links them. Any future utility that ties CTZAI balance or staking to voting power must ship as a deliberate protocol upgrade with matching public documentation.

The addition of a prototype News Debunking extension does not change the governance hierarchy of the project. Roadmap governance remains the primary present-day governance story for CitizeAi_ at ecosystem level: what product priorities evolve next, which lanes mature, and how bounded programme scope is advanced. Any DAO-like mechanism attached to News Debunking should be understood as product-scoped governance, not as a general claim of full ecosystem decentralization.

In practical terms, the News Debunking DAO is best framed as a bounded review and prioritization layer composed of journalists, experts, and citizens. Its role is to support credibility workflows, prioritization, signaling, and structured civic participation around a debunking product surface. It should not be framed as final editorial authority, legal adjudication, or a blanket replacement for institutional accountability. It is a prototype governance mechanism attached to a prototype product.

Product-scoped DAO language should remain narrow and explicit, especially for the News Debunking prototype, so governance ambition does not outrun deployment maturity.

dApp pages under `/dao` and governance documentation should reflect **live addresses and ABIs** for the selected chain; always confirm `ContractAddressesStatus` (or equivalent) before interacting.

On-chain parameters, deployed contract addresses, and approved actions supersede any narrative summary in this document.

Separately from governance contracts, the political extension reward contract (`ctzai_extension_reward`) implements **operational owner governance**: sensitive configuration changes use a timelock, can be canceled while pending, and can be permanently frozen per config family (reward economics, ERC-20 token binding, chain id, signer). This is not CTZAI-holder governance; it is a control surface for a funded reward deployment.

Future ecosystem-wide DAO governance over CTZAI allocations (if any) remains conceptually separate: it would require explicit contracts, vote mechanics, and documentation—not an implicit reading of reward-contract admin controls.

For default political reward economics, timelock behaviour, and freeze semantics, see operator documentation in the contracts repository and on-chain getters (`get_reward_policy`, `get_governance_status`, or equivalents per ABI).

`CTZAIVesting` admin controls include ownership transfer (accept flow), emergency claims pause, admin-actions pause, and two-step propose/apply for the ERC-20 token address and optional presale contract pointer—no built-in timelock on those pointer updates unless the deployment adds one later. This is operational contract administration, not CTZAI-holder DAO governance.

On-chain: replay protection via unique `extension_event_id`, action-type validation, daily and per-action caps, cooldowns, and safe withdrawal flows. Off-chain: rate limiting, abuse scoring, and short-lived signed attestations with chain/contract binding should be treated as mandatory for production deployments.

Privacy: prefer hashing opaque identifiers before anchoring metadata; disclose what the extensions and APIs retain. Political and media incentives may implicate regional rules—operators should obtain counsel before public campaigns.

Operational security: keep **ABI sync**, **address registries**, and generated client code in CI so wallet UIs cannot drift from verified deployments; monitor events for anomalous claim spikes.

Vesting: understand revocation as claw-back of unvested remainder only—vested rights already accrued remain claimable subject to pause and funding. Rely on schedule storage, totals, and events rather than marketing summaries.

CitizeAi_ deliberately launches with fixed rewards: transparent, easy to audit, and measurable—never passive browsing pay-outs, generic engagement mining, APR, or yield farming. Rewards reinforce transparency-seeking actions. Where ERC-20 transferability exists, it can make participation more tangible for citizens and help grow the user base for civic-tech tools—without changing the fact that the mission is transparency impact, not speculation.

The ladder below summarizes the same phased model. For the full publication-ready narrative (strategy, phase detail, visuals, and alignment checklist), open About → Reward roadmap. Timelines are advisory—governance and operator communications supersede any graphic.

Distribution starts with credibility: browser extensions in official stores where possible, clear release notes, and support channels that can explain reward rules without hype. France concentrates datasets and operator attention so funnel metrics and treasury gates are meaningful before broad rollouts.

Supported-domain expansion is a function of data quality and attestation reliability—not maximal surface area. Partnerships with media literacy, civic tech, and policy audiences should reinforce transparency outcomes, not speculative trading narratives.

Public communications should precede parameter changes that affect user expectations; the same discipline applies when moving from testnet rehearsal to mainnet production.

Track claim success rate, median confirmation time, rejection reasons (replay, caps, invalid proofs), 7d/30d retention of claimants, supported domain coverage, and staking participation by tier.

Publish periodic transparency reports—similar in spirit to Presearch’s open operational narrative—summarizing parameter changes, incident response, and treasury flows attributable to the protocol.

At programme level, align product analytics with treasury views: funnel conversion, claim success and rejection breakdown, daily burn versus plan, runway on spendable budget, and gate readiness—so incentives and budget release stay tied to validated demand rather than headline population statistics.

CitizeAi_ should report product health and programme discipline through a lane-based public KPI framework, not through one undifferentiated growth dashboard. Different product lines solve different civic problems, operate at different maturity levels, and justify different decisions about rollout, governance, and treasury activation. The role of the KPI framework is therefore not to maximize visible numbers. It is to make operational truth legible: where users are finding value, where optional dApp continuation is working, where abuse or low-quality participation is appearing, and where programme budgets should hold, continue, or scale. This is consistent with the white paper's current posture, which already ties success to claim health, rejection quality, retention, burn discipline, runway, and KPI-gated release rather than to abstract market-size storytelling.

The framework should be organized around six layers shared across the suite: reach and activation, product usefulness, optional dApp continuation, integrity and safety, treasury and programme discipline, and governance or readiness status. This allows the same reporting logic to operate across live and prototype lanes while preserving maturity truth. Live transparency lanes can report operational and treasury-linked KPIs now. Prototype lanes such as Content Moderation and News Debunking should report readiness, quality, and review-process KPIs first, with economic activation remaining explicitly secondary until product maturity and governance safeguards justify it.

For Political Transparency and Media Transparency, public KPI reporting should focus on whether users install the product, return to it, use the contextual surfaces while reading, and choose to continue into wallet-native actions where relevant. The most important indicators are install-to-active conversion, supported-domain usage, wallet-connect conversion, claim success rate, rejection mix, repeat claimant quality, burn versus plan, runway on spendable budget, and concentration signals. These already align with the current operator KPI posture documented elsewhere in the white paper.

For Content Moderation, the KPI model should be readiness-first. At prototype stage, the important public signals are stability, contextual-rule interaction, false-positive complaint rate, exception-usefulness, governance workflow responsiveness, and clear economic activation status. The purpose is to show that the lane is becoming operationally and civically legible before any stronger treasury or reward narrative is attached to it.

For News Debunking, the framework should be richer and more governance-sensitive. The important public signals are valid submission rate, duplicate or rejected intake rate, evidence sufficiency, time-to-package-readiness, reviewer participation by class, approval-versus-hold-versus-challenge ratios, extension surfacing rate for approved debunk packages, package open/read rate, appeal or revision frequency, and explicit activation status. This makes the lane understandable as a structured review and publication system rather than as a simplistic truth-voting mechanism.

For roadmap governance and other participation surfaces, the framework should focus on proposal throughput, participation rate, time-to-finalization, implementation follow-through, and evidence-linked tranche readiness. Governance should not be reported as raw turnout theatre; it should be reported as a product-direction mechanism tied to real delivery and bounded treasury discipline.

The public KPI framework should also distinguish clearly between public transparency reporting and internal operator diagnostics. Public reporting should explain product use, usefulness, integrity posture, and treasury discipline in ways that are intelligible to readers, partners, and contributors. Internal dashboards may go deeper into claim-level telemetry, proof failures, suspicious concentration, reviewer bottlenecks, or domain-level mapping errors. This distinction keeps public reporting honest without exposing every low-level operational signal as if it were a public-facing product metric.

Finally, KPI reporting should remain tied to gate logic. A healthy CitizeAi_ programme is not one that simply grows numerically. It is one that clears the next justified decision threshold. The KPI system should therefore support at least three public gate interpretations: launch validity, product-market signal, and scale readiness. These gates should help determine whether a lane continues as-is, expands in a bounded way, or pauses for correction before further treasury authorization or product rollout.

Official repositories, deployed addresses, and network selection belong in the dApp and operator runbooks. Use footer links and published channels for community and security disclosures.

This document does not replace legal entity disclosures where required for regulated activities; seek counsel for public campaigns and regional compliance.

This white paper is informational and may evolve. It is not investment, tax, or legal advice. CTZAI and on-chain parameters can change with governance, upgrades, or new deployments; always verify live state. Holding CTZAI does not by itself grant protocol governance rights in phase 1; such rights arise only from the dedicated governance contracts and parameters published for each deployment.

Testnet assets and staging deployments are for testing and education; they may carry no monetary value. Nothing herein constitutes an offer to sell securities in any jurisdiction.