Mission-first incentive design

Reward roadmap

Phased reward economics on an EVM-native stack

CitizeAi_ uses Solidity contracts and ERC-20 CTZAI inside a wallet-connected EVM dApp. The architecture changed; the civic mission, treasury discipline, and phased reward logic did not. This page is the canonical narrative for Phase 1 — fixed rewards, Phase 2 — fixed rewards + guardrails, and Phase 3 — deterministic dynamic rewards.

On this page

What stays valid, what changes, why the ladder still fits

Still strategically valid

The three-phase ladder—fixed rewards, then fixed rewards + guardrails, then deterministic dynamic rewards—remains the right sequencing: discovery and operational learning first, resilience before opaque formulas, and published, checkable math only when real usage evidence exists.

Mission-first economics are unchanged: rewards support narrow, intentional, proof-based civic-tech participation—not passive browsing, generic engagement mining, yield framing, or attention pay-outs.

Treasury discipline and bounded incentives stay central; phases exist to protect credibility, auditability, and user trust—not to chase narrative complexity. Across phases, expansion should remain treasury-disciplined: prefer new allocation rounds from existing supply and clear lane budgets over implying that scale requires revisiting the 2B fixed cap—see the White Paper (`#supply-discipline-lanes`).

What must change in wording

Implementation is Solidity on an EVM-compatible chain; CTZAI is ERC-20. The dApp integrates through ABIs, deployment addresses, and standard wallet flows—not stack-specific middleware from earlier documentation.

Settlement is ordinary ERC-20 transfer from treasury-funded reward vaults after proof-based claim verification; parameters live in on-chain storage and published configuration.

Copy should refer to verified bytecode, timelocked parameter paths where deployed, and read models in this dApp—so partners and users always know where to verify expectations.

Why the phased logic still matches EVM reality

Phase 1 favours constants and explicit rules that wallets, auditors, and newcomers can sanity-check. Phase 2 adds operational guardrails without hiding the reward spine. Phase 3—only if shipped with governance discipline—would encode deterministic dynamic rewards: rule-based, not discretionary “we moved the number,” not a black-box score.

Why this phased model fits the new token context

CTZAI remains mission-supporting, not the purpose of CitizeAi_: the product is civic transparency infrastructure—extensions and attestations in the reading flow—not a token campaign.

Exchangeability can strengthen adoption incentives by making settlement more legible to participants where markets and regulation allow. That increases the duty to keep rewards clear, bounded, and responsibly governed—not the reverse.

Because the token can matter to users in practice, the incentive layer must be especially explicit: predictable categories, proof-based settlement, treasury caps, and communicated transitions between phases.

The phased roadmap is therefore not outdated after the move to ERC-20 / Solidity / EVM—it is more relevant: the same discipline reduces misread risk when people encounter CTZAI through wallets and public markets.

Economic philosophy across phases

CitizeAi_ starts simple on purpose: fixed rewards are easier to explain, audit, and budget—and faster to harden against abuse while user-quality signals are still sparse.

Complexity should follow evidence, not speculation. Launching with an opaque or constantly moving reward formula would trade short-term storytelling for long-term mistrust; partners, grant reviewers, and contributors deserve checkable rules.

The reward layer reinforces transparency-seeking participation; it is not a passive-earn mechanic. Anti-abuse posture and treasury release discipline are first-class design constraints at every phase.

Timelines are not promises; phase changes require explicit communication, governance where applicable, and aligned contract upgrades.

Phase 1 — fixed rewards

Discovery · operational learning · credibility

Phase 1 pays known amounts for narrow, intentional, proof-based actions that the contracts and documentation explicitly support. Users can form stable expectations; treasuries can plan emissions; engineers can tune defenses with clearer baselines.

On-chain settlement: after the extension issues a proof, you confirm claims and any separate withdrawals from your wallet in this dApp. Network fees are yours in the native token—CitizeAi_ does not sponsor routine user gas in phase 1.

Proof-based reward settlement tied to supported extension events—not generic page views or undefined “engagement.”
Published gross amounts (per action category) that anyone can compare to on-chain parameters.
Straightforward audits: constants and explicit storage fields beat emergent heuristics for early trust.
Treasury control: fixed schedules simplify budgeting, caps, and release discipline alongside vault funding.
Faster operational hardening: monitoring, signer rotation, pauses, and cap tuning start from a stable reward spine.
Early anti-abuse tuning with interpretable signals: spikes and gaming patterns are easier to reason about when the reward mapping is not moving every week.
Fit for early adoption: while participation depth and quality signals are still forming, simplicity reduces misalignment risk.

What Phase 1 is not

Not passive browsing rewards or pay-for-time-on-site.
Not a yield product, APR narrative, or “earn while you scroll” framing.
Not a promise that parameters never change: it is the correct first step, not “final forever.”

Phase 1 is how CitizeAi_ earns mechanical credibility on EVM: the same ERC-20 settlement users already understand, with rules they can verify in the contract surface.

Fixed rewards, presale entry, and gas — one frame

Phase-1 gross amounts in CTZAI (e.g. political highlights vs media defaults) are constants in Solidity—they do not auto-scale with secondary-market prices. Participants interpret rewards next to native gas for claims (Model A) and next to how they acquired CTZAI (including presale `tokenPrice`). Treasury programmes (e.g. France-first) are budgeted in CTZAI from existing supply; launch pricing should avoid inflated optics, dust-like optics, and overpaying per action relative to mission and budget—see the white paper Launch pricing rationale (`#launch-pricing-rationale`).

Phase 2 — fixed rewards + guardrails

Bridge phase · resilience without opacity

Phase 2 keeps the same core reward logic: still fixed amounts per supported action class. The evolution is protection and operations: additional layers that reduce overspend, sybil pressure, and quality-collapse risks as volume grows.

Tighter budgets and per-period ceilings aligned to treasury planning.
Stronger sybil resistance and abuse monitoring tied to on-chain and operational telemetry.
Quality gates where appropriate—still rule-based, still explainable.
Richer campaign and accounting controls: clearer segmentation of action categories and programme scopes.
Treasury release discipline paired to market rounds or similar scoped budgets in the Solidity modules.
Improved participant communications when limits tighten—readability is preserved by design.

This is intentionally a bridge: it scales resilience without jumping to a fully dynamic payout engine that users cannot reconstruct from published rules.

Guardrails answer the question: “How do we grow without turning the incentive layer into a black box?”—by hardening the same transparent spine.

Phase 3 — deterministic dynamic rewards

Maturity model · evidence-gated

Deterministic dynamic rewards mean adjustments happen through a published, deterministic formula—inputs might include quality signals, treasury health, participation rates, budget discipline, anti-abuse indicators, or campaign goals—but the same inputs must yield the same outputs for everyone reviewing the rule set.

Transparent, checkable logic suitable for user explanation, partner review, and stakeholder credibility.
Rule-based dynamics—not ad hoc manual tweaks presented as mechanics.
Bounded incentive layer remains: formulas live inside governance and engineering constraints, not unconstrained discretion.
Triggered only when evidence supports it: enough volume, abuse history, and treasury learning to justify the added complexity.

What Phase 3 is not

Not “we change rewards whenever we want” without a public rule.
Not opaque admin discretion masquerading as economics.
Not a black-box scoring fantasy: if it cannot be explained, it does not ship as Phase 3.

Phase 3 is a maturity state, not a day-one feature: deterministic dynamic rewards reward the project for learning in public—without trading away audit culture.

Communicating phase transitions

Each transition should be announced in advance where practicable, with before/after parameter visibility: contract addresses, storage slots or getter surfaces, and dApp read models updated in lockstep.

Users should always be able to answer: what action pays what, under which caps, funded by which budget, and how to verify it—across Phase 1, Phase 2, and (if launched) Phase 3.

Complexity follows evidence

Dynamic formulas are powerful and risky. CitizeAi_ refuses to simulate sophistication: deterministic dynamic rewards belong in the roadmap after there is enough real usage, incident history, and treasury telemetry to justify the engineering and communication load.

Until then, fixed rewards and guardrailed fixed rewards deliver most of the civic value—measurable participation with minimal mystique—on the ERC-20 settlement layer participants already use.

Recommended visual layer (and library choice)

Charts should earn their pixels: we use D3.js for custom process / progression diagrams where off-the-shelf chart types misrepresent the idea. We use Chart.js for compact comparative summaries when a small number of dimensions benefits from side-by-side reading. Every graphic is paired with caption text so it never stands alone.

D3.js — phase progression

The horizontal three-phase flow above is implemented with D3.js so connectors, spacing, and labels stay accessible and theme-aware. It encodes order and dependency, not numeric precision—appropriate for roadmap storytelling tied to governance communication.

Chart.js — maturity emphasis profile

The grouped bar chart below uses Chart.js because it is the fastest path to a legible, low-maintenance comparison across a few ordinal dimensions. The scores are illustrative (2–5 scale) showing how emphasis shifts—not live on-chain metrics.

HTML comparison table

The phase comparison table stays semantic HTML: best for audit-style reading, copy/paste, and accessibility without chart overhead. Use it when you need exact wording per cell, not bar lengths.

If a visual does not reduce cognitive load or clarify tradeoffs, omit it: prose plus the table alone remain publication-ready.

Illustrative emphasis profile by phase (ordinal)

Ordinal illustration only—not a live dashboard. Interpret as directional emphasis (legibility, treasury predictability, anti-abuse tooling, evidence required), not investment guidance.

Comparison across phases

Use this table for at-a-glance **policy and operations** differences. Contract-level truth remains **on-chain** for your deployment.

Dimension	Phase 1 — fixed rewards	Phase 2 — fixed + guardrails	Phase 3 — deterministic dynamic rewards
Core reward rule	Fixed gross per supported action class; easy to quote.	Still fixed gross per class; scope and budgets tighten around the same spine.	Published formula maps inputs → reward; same inputs ⇒ same outputs.
User expectation	Stable numbers; minimal surprise if parameters are versioned clearly.	Stable reward math; stricter eligibility / caps may bite sooner—communicated explicitly.	Users learn a checkable function; must be taught like open rules, not vibes.
Treasury posture	Strong predictability; simplest emission planning.	Harder budgets and release discipline reduce overspend risk.	Adaptive to health signals; still bounded by published math.
Anti-abuse	Baseline caps, cooldowns, pauses—enough to learn patterns.	Elevated monitoring, sybil pressure controls, segmentation.	Can incorporate abuse indicators into deterministic terms—not hidden scores.
Opacity risk	Low if constants stay documented and verified.	Low–medium; more moving parts, still rule-first.	Medium by default; mitigated only by radical transparency and audits.
Typical gate to enter	Ship audited Solidity vaults + ERC-20 settlement; operational playbooks live.	Volume / abuse / treasury data justify extra rails without a new economic engine.	Evidence + governance readiness to ship and explain a deterministic formula safely.

Propagation checklist — keep narratives aligned

When updating copy or contracts, cross-check these surfaces so the phased reward story stays consistent:

**White Paper** — reward economics section and any roadmap graphics.
**White Paper — Treasury reserve strategy** — 800M / 40% bucket table aligned with Tokenomics and deployment.
**Tokenomics** — rewards chapter, phase callouts, and links to this page.
**About → Reward roadmap** — this canonical page.
**About → France-first Treasury Architecture** — custody, gas model (Model A), ops vs reward treasuries.
**Political / Media rewards** — debug panels, parameter docs, extension copy.
**Smart contracts overview** — catalogue text matching **Solidity** modules.
**Governance overview** — timelocks, parameter owners, and **transition** comms.
**Roadmap / coming soon** — avoid promising Phase 3 mechanics before **evidence** and **governance** are ready.

If two pages disagree, **prefer verified deployment state** and **this roadmap’s definitions**—then fix the drift.