CYE Token: Tokenomics of the CyberEco Ecosystem¶

1. Abstract¶

CYE is the native utility token of the CyberEco ecosystem -- a human-centered digital platform where 30+ interconnected applications share identity, permissions, financial data, groups, and notifications through a common data layer. As the ecosystem transitions from its current centralized Firebase infrastructure toward a peer-to-peer and blockchain-based architecture (2027-2035), CYE provides the economic foundation for three critical functions: decentralized governance, incentive alignment for infrastructure contributors, and micro-transactions for cross-app data operations.

This document specifies the token's supply model, distribution, incentive mechanisms, governance framework, fee structure, and integration with the existing CyberEco data layer. It is intended to be a self-contained reference for developers, node operators, and community members who want to understand how the CYE token sustains the CyberEco ecosystem as a decentralized, community-owned platform.

CYE is designed as a utility token, not a financial instrument. Its purpose is to coordinate human and computational resources around a shared mission: building a digital ecosystem where users own their data and developers build on a shared, open foundation.

2. Token Purpose¶

The CYE token serves three interconnected purposes within the CyberEco ecosystem.

2.1 Governance¶

CYE enables token holders to participate in the democratic stewardship of the ecosystem. Holders vote on protocol upgrades, changes to the app registry, fee adjustments, grant allocations, and ecosystem-wide policies.

For example, when a new application like Demos (the community governance app) proposes changes to the shared permission model, CYE holders vote on whether those changes are adopted across all 30+ apps. This prevents any single developer or organization from unilaterally altering infrastructure that thousands of users depend on.

Governance is designed to be accessible. Quadratic voting (detailed in Section 6) ensures that broad participation matters more than concentrated wealth.

2.2 Incentive Alignment¶

As CyberEco decentralizes, the infrastructure that currently runs on Firebase -- storage, computation, real-time sync -- must be provided by a distributed network of nodes. CYE aligns the incentives of node operators with the needs of the ecosystem.

Nodes that contribute storage capacity, compute resources, and network reliability earn CYE in proportion to their contribution. Nodes that go offline, fail storage proofs, or behave maliciously are penalized. This creates a self-reinforcing system: the more useful the ecosystem becomes, the more CYE flows to the infrastructure providers that keep it running.

2.3 Micro-Transactions¶

CYE is the unit of account for data operations across the ecosystem. When a JustSplit user queries their shared expenses, when Hub synchronizes a user profile across apps, or when Plantopia reads environmental data from a shared group -- each operation has a small CYE cost that compensates the nodes hosting and serving that data.

These micro-transactions replace the Firebase pay-as-you-go billing model with a decentralized economy where users pay node operators directly. A generous free tier (Section 7) ensures that the token requirement never becomes a barrier to entry.

3. Supply Model¶

3.1 Fixed Supply¶

The total supply of CYE is fixed at 1,000,000,000 (one billion) tokens. All tokens are created at genesis. There is no mechanism for minting additional tokens after genesis -- no inflation, no governance vote can increase the supply. This hard cap ensures long-term scarcity and predictability for all ecosystem participants.

3.2 Emission Schedule¶

Although all tokens exist at genesis, they are not immediately circulating. Tokens are released into active circulation over a 10-year period according to a smart-contract-enforced emission schedule. This prevents supply shock and aligns token availability with ecosystem growth.

The emission curve follows a modified logarithmic schedule: higher emissions in the early years to bootstrap the network, tapering as the ecosystem matures and transaction fees become the primary compensation mechanism.

Year 1:  15% of allocation released
Year 2:  14% of allocation released
Year 3:  13% of allocation released
Year 4:  12% of allocation released
Year 5:  10% of allocation released
Year 6:   9% of allocation released
Year 7:   7% of allocation released
Year 8:   7% of allocation released
Year 9:   7% of allocation released
Year 10:  6% of allocation released

3.3 Deflationary Mechanism¶

A 0.1% burn is applied to every transaction fee collected by the network. When a user pays 0.01 CYE for a write operation, 0.00001 CYE is permanently destroyed. Over time, this mechanism reduces the circulating supply, creating mild deflationary pressure that rewards long-term participants.

The burn rate is governed -- CYE holders can vote to adjust it within the range of 0.01% to 1.0% as economic conditions evolve. The burn applies only to transaction fees, not to staking rewards, governance participation, or direct transfers between users.

4. Token Distribution¶

Allocation	Percentage	Tokens	Vesting Schedule
Community & Ecosystem	60%	600,000,000	Released over 10 years via node rewards
Development Fund	20%	200,000,000	4-year linear vesting
Founding Team	15%	150,000,000	4-year vesting with 1-year cliff
Ecosystem Grants	5%	50,000,000	Released as grants are approved

4.1 Community & Ecosystem (60%)¶

The majority of tokens are reserved for the people and machines that make the ecosystem work: node operators who host data, validators who verify storage proofs, developers who build new apps, and users who participate in governance. These tokens flow into circulation through the incentive mechanisms described in Section 5.

This is the largest allocation by design. CyberEco's first tenet is digital sovereignty -- the community should own the majority of the ecosystem's economic value.

4.2 Development Fund (20%)¶

The development fund sustains the core engineering team that maintains the shared data layer packages (@cyber-eco/types, @cyber-eco/firebase, @cyber-eco/auth, @cyber-eco/services), the StorageAdapter implementations, and the protocol itself. Tokens vest linearly over four years: 50,000,000 CYE per year, distributed monthly.

Ten percent of the development fund (20,000,000 CYE) is designated as an emergency reserve, held in a multi-signature wallet requiring 3-of-5 signatories.

4.3 Founding Team (15%)¶

Founding team tokens vest over four years with a one-year cliff. No team tokens are liquid in the first year. After the cliff, tokens vest monthly over the remaining 36 months. This ensures that the founding team's incentives are aligned with the long-term success of the ecosystem, not short-term token price.

If a team member departs before the cliff, their unvested tokens return to the Community & Ecosystem pool. If they depart after the cliff, vesting stops and unvested tokens return to the pool.

4.4 Ecosystem Grants (5%)¶

The grant pool funds external contributions to the ecosystem: new StorageAdapter implementations (IPFS, blockchain, PostgreSQL), new domain services, security audits, documentation, and community tooling. Grants are proposed and approved through the governance process (Section 6).

Grants are denominated in CYE but may be converted to stablecoins at the grantee's discretion, acknowledging that contributors need predictable compensation.

5. Incentive Mechanisms¶

The incentive layer transforms the CyberEco data layer from a centralized service into a decentralized economy. Each mechanism targets a specific infrastructure need.

5.1 Data Hosting Rewards¶

Problem: When CyberEco migrates from Firebase to a peer-to-peer network, someone must store and serve the data that Hub, JustSplit, Demos, and other apps depend on.

Solution: Nodes that store and replicate user data earn CYE proportional to their contribution. This mechanism is inspired by Filecoin's storage deals, adapted for the CyberEco data model where documents are smaller (user profiles, transactions, group memberships) but require low-latency access.

How it works:

A node registers as a data host by staking CYE (see Section 5.3).
The network assigns data segments to the node based on capacity, geographic proximity, and reliability history.
The node stores the data and responds to read/write requests from the DataLayerService orchestrator.
Periodically, the node must pass a storage proof -- a cryptographic challenge-response that verifies the data is intact and available.
Nodes that pass proofs earn CYE according to the reward formula.

Reward formula:

hosting_reward = base_reward * replication_factor * uptime_score

base_reward: A per-megabyte-per-day rate, set by governance (initially 0.001 CYE/MB/day).
replication_factor: Bonus for hosting data with fewer existing replicas. If a document has only 3 copies (the minimum), the replication factor is 1.5x. If it has 10 copies, the factor drops to 1.0x.
uptime_score: A rolling 30-day uptime percentage. 99.9% uptime yields a 1.0x score. Below 95%, the score drops to 0.5x. Below 90%, the node earns no hosting rewards.

Storage proofs: Every 6 hours, the network issues a random challenge to each hosting node. The challenge specifies a set of document IDs, and the node must return a Merkle proof demonstrating possession of the data. Nodes that fail three consecutive challenges are flagged for data re-replication and lose their hosting assignment for those documents.

5.2 Network Healing¶

Problem: In a decentralized network, nodes go offline. Hard drives fail. Users shut down their machines. If a document's replication count drops below the safety threshold, data loss becomes a risk.

Solution: Network healing rewards incentivize nodes to detect under-replicated data and re-replicate it before it is lost.

How it works:

Each node monitors the heartbeat of other nodes that share its data assignments.
When a peer misses three consecutive heartbeats (15 minutes), the monitoring node reports the potential data gap.
The network verifies the report and issues a healing bounty.
Any node with sufficient capacity can claim the bounty by downloading the data from surviving replicas and becoming a new host.
The healer earns 2x the normal hosting reward for the healed data, sustained for the first 30 days of hosting.

Automatic detection: The heartbeat monitoring system operates as a protocol-level service within the CyberEco data layer. It integrates with the existing SyncService architecture -- the same real-time broadcast mechanism that currently notifies apps of data changes is extended to include node health signals.

Concrete example: A JustSplit user's expense history is stored across five nodes. Two nodes go offline simultaneously due to a regional outage. The replication count drops from 5 to 3 (the minimum threshold). Three nearby nodes detect the gap, re-replicate the data, and earn healing bounties. The user's expense history remains available with zero downtime.

5.3 Uptime Staking¶

Problem: Anyone can register as a node, but the network needs to distinguish reliable operators from casual participants. Without a reliability signal, the network cannot make intelligent data placement decisions.

Solution: Nodes stake CYE to signal their commitment to reliability. Higher stakes unlock higher priority for hosting assignments and larger rewards. Persistent unreliability results in stake slashing.

Staking parameters:

Parameter	Value
Minimum stake per node	100 CYE
Stake tiers	Bronze (100), Silver (1,000), Gold (10,000)
Slashing trigger	>48 hours offline without notice
Slashing penalty	5% of staked amount
Graceful shutdown notice	Signal planned downtime via the protocol
Cooldown period	7 days to unstake after signaling withdrawal

Graceful shutdown: Life happens -- servers need maintenance, internet connections fail, people go on vacation. The protocol supports a graceful shutdown signal: a node announces planned downtime, the network re-distributes its data assignments proactively, and no penalty is applied. This is the protocol's way of honoring CyberEco's tenet of wellbeing by design -- we do not punish operators for being human.

Slashing: If a node disappears for more than 48 hours without a graceful shutdown signal, 5% of its staked CYE is slashed. Slashed tokens are split: 50% goes to the nodes that healed the resulting data gaps, and 50% is burned. Slashing is not punitive -- it is a coordination mechanism that compensates the network for unexpected re-replication costs.

5.4 Compute Contribution¶

Problem: Some CyberEco operations require computation beyond simple storage and retrieval. Encrypted computation on sensitive financial data (JustSplit settlements), aggregated analytics (Demos voting tallies), and AI-assisted recommendations all require compute capacity.

Solution: Nodes that provide encrypted computation capacity -- via Trusted Execution Environments (TEE) or Fully Homomorphic Encryption (FHE) -- earn CYE for processing compute tasks.

How it works:

A compute-capable node registers its hardware capabilities (TEE attestation, available memory, processing speed).
Applications post compute tasks to the compute marketplace, priced in CYE based on estimated complexity.
Registered compute nodes bid on tasks. The protocol selects the lowest qualified bid.
The selected node executes the computation within a TEE (or using FHE for maximum privacy) and returns the result.
The requesting application verifies the result via attestation and releases payment.

Compute marketplace pricing:

Task Type	Estimated Cost
Simple aggregation	0.01 CYE
Encrypted settlement calc	0.05 CYE
Multi-party computation	0.10 CYE
ML inference (small model)	0.50 CYE

TEE premium: Nodes with hardware-attested Trusted Execution Environments earn a 1.5x premium over software-only compute providers. Hardware attestation provides stronger guarantees that sensitive data (e.g., a user's financial transactions in JustSplit) is processed in an isolated, tamper-proof environment.

6. Governance Model¶

CyberEco's governance model is designed to prevent plutocracy while enabling efficient decision-making. It builds on the principles already embodied in the Demos governance app, extending them to protocol-level decisions.

6.1 Quadratic Voting¶

Voting power is calculated as the square root of tokens staked, not the raw token count.

voting_power = sqrt(tokens_staked)

Tokens Staked	Voting Power	Marginal Power of Last Token
1	1.00	1.000
100	10.00	0.050
10,000	100.00	0.005
1,000,000	1,000.00	0.0005

This means that a single holder with 1,000,000 CYE has the same voting power as 1,000 holders with 1,000 CYE each -- but in a linear system, the single holder would have the same power as all 1,000 combined. Quadratic voting makes broad community support more powerful than concentrated wealth.

6.2 Proposal Lifecycle¶

Every governance action follows a four-stage lifecycle:

Draft -- Any CYE holder with a minimum stake of 100 CYE can submit a proposal. Drafts are published to the governance forum for community review.
Discussion (7 days) -- The community debates the proposal. The author can amend the draft based on feedback. Other holders can signal early support or opposition without committing a binding vote.
Vote (7 days) -- The proposal is submitted for binding vote. Voting power is calculated via quadratic formula at the snapshot block (the block at which the voting period begins). Tokens must be staked before the snapshot to count.
Implementation -- If the proposal passes (simple majority of participating voting power, subject to quorum), the core team or an appointed implementer executes the change. For smart contract changes, a timelock (48 hours) applies between approval and execution.

6.3 Quorum¶

A minimum of 10% of total staked tokens must participate in a vote for it to be valid. If quorum is not met, the proposal can be re-submitted after a 14-day cooldown. This prevents low-turnout votes from making consequential changes.

6.4 Scope¶

Governance covers:

Protocol upgrades -- Changes to the data layer protocol, storage proof algorithms, or incentive parameters.
Fee changes -- Adjustments to operation costs, free-tier limits, and fee distribution ratios.
App registry -- Adding, removing, or modifying applications in the official CyberEco app registry.
Grant allocation -- Approving ecosystem grants from the 5% grant pool.
Burn rate -- Adjusting the transaction fee burn percentage within the 0.01%-1.0% range.

6.5 Delegation¶

Token holders who lack the time or expertise to evaluate every proposal can delegate their voting power to a representative. Delegation is:

Revocable -- Delegators can reclaim their voting power at any time.
Non-transferable -- Delegates cannot re-delegate power received from others.
Transparent -- All delegations are recorded on-chain and publicly visible.
Domain-specific -- A holder can delegate to different representatives for different proposal categories (e.g., delegate protocol decisions to a technical expert, fee decisions to an economist).

6.6 Constitutional Limits¶

Certain foundational principles of CyberEco are beyond the reach of governance. No proposal, regardless of support, can override:

Digital sovereignty -- Users own their data. The protocol must always support data export and deletion.
Privacy by default -- Permissions are checked on every operation. No proposal can introduce a "public by default" mode.
Storage agnosticism -- The StorageAdapter interface must remain the boundary between business logic and storage. No proposal can hardcode a specific backend.
Wellbeing by design -- No proposal can introduce engagement-maximizing patterns (dark patterns, addictive mechanics, or attention harvesting).

These constitutional limits are encoded in the governance smart contract as immutable constraints. They can only be changed through a constitutional amendment process requiring 75% supermajority and 30% quorum -- a deliberately high bar.

7. Fee Structure¶

Fees serve two purposes: they compensate infrastructure providers and they prevent spam. The fee structure is designed to be simple, predictable, and accessible.

7.1 Operation Costs¶

Operation	Cost (CYE)
Read (single document)	0.001
Write (single document)	0.01
Cross-app query	0.005
Batch operation (per op in batch)	0.005
Real-time subscription (per update received)	0.001

Batch discount: Batch operations cost 0.005 CYE per operation, compared to 0.01 CYE per individual write. This incentivizes efficient data access patterns and mirrors the batch optimization already built into the StorageAdapter interface's batchWrite() method.

Concrete example: A JustSplit group of 5 people settles a trip with 20 expenses. The settlement operation requires 20 reads (0.02 CYE) and 5 writes (0.05 CYE), totaling 0.07 CYE. Using batch writes, the cost drops to 20 reads (0.02 CYE) + 5 batch writes (0.025 CYE) = 0.045 CYE.

7.2 Free Tier¶

The first 1,000 operations per day are free for every account. This is a hard guarantee, not a promotional offer -- it is encoded in the protocol and can only be changed through governance.

The free tier ensures that CYE never becomes a barrier to entry. A casual JustSplit user who checks expenses a few times a day will never need to acquire CYE. A Demos participant who votes in a community poll will never pay a fee. The free tier covers the vast majority of individual use cases.

The free tier exists because CyberEco's mission is human-centered technology, not rent extraction. The token enhances the ecosystem; it does not gate it.

7.3 Fee Distribution¶

Fees collected from operations above the free tier are distributed as follows:

Recipient	Percentage	Purpose
Hosting nodes	70%	Direct compensation for storage and bandwidth
Development fund	20%	Sustains core protocol development
Burned	10%	Deflationary pressure (includes the 0.1% burn)

The 10% burn allocation absorbs the 0.1% per-transaction burn described in Section 3.3. The remaining burn allocation (approximately 9.9% of fees) is burned in a weekly batch, reducing operational overhead compared to per-transaction burns.

8. Anti-Spam and Sybil Resistance¶

A decentralized network must defend against spam (overwhelming the network with junk operations) and Sybil attacks (a single entity creating many fake identities to game incentives). CYE's anti-abuse mechanisms balance security with accessibility.

8.1 Minimum Stake for Write Access¶

Any account can read data within the free tier. However, creating an account that writes data to the network requires a minimum stake of 10 CYE. This is a modest barrier -- enough to make automated spam expensive, but low enough that a genuine user can participate easily.

Read-only access has no stake requirement. A new user can browse, search, and consume data before committing any CYE.

8.2 Rate Limiting by Stake Level¶

Above the free tier, the rate at which an account can execute operations scales with its stake:

Stake Level	Operations per Hour (above free tier)
10 CYE (minimum)	500
100 CYE	5,000
1,000 CYE	50,000
10,000+ CYE	Unlimited (fee-based only)

This ensures that high-volume users pay proportionally for their usage while preventing any single account from monopolizing network resources.

8.3 Proof-of-Personhood (Optional)¶

For governance participation, accounts can optionally complete a proof-of-personhood verification. Verified accounts receive a 1.5x governance weight boost -- their quadratic voting power is multiplied by 1.5.

Proof-of-personhood is never required. It is an opt-in mechanism for users who want to strengthen the legitimacy of their governance participation. The specific verification method (social vouching, biometric, or third-party attestation) is determined by governance.

This aligns with CyberEco's principle of privacy by default: identity verification is available but never compelled.

8.4 Progressive Fee Increase¶

Writers who exceed the free tier and their stake-based rate limit encounter progressive fee increases:

1x-2x rate limit: Fees increase by 50%
2x-5x rate limit: Fees increase by 200%
Above 5x rate limit: Operations are queued, not rejected, and processed at standard rates during off-peak periods

Operations are never rejected outright (except for clearly malicious payloads). Progressive fees create economic pressure against spam while ensuring that legitimate high-volume operations are eventually processed.

9. Integration with the CyberEco Data Layer¶

The CYE token layer integrates cleanly with the existing StorageAdapter pattern and DataLayerService orchestrator. The design principle is simple: the token layer wraps existing infrastructure without modifying it.

9.1 TokenizedStorageAdapter¶

The TokenizedStorageAdapter is a decorator that wraps any StorageAdapter implementation and adds CYE micro-payment logic:

interface TokenizedStorageAdapter extends StorageAdapter {
  // All standard StorageAdapter methods, plus:
  getBalance(userId: string): Promise<number>;
  deductFee(userId: string, operation: OperationType, count: number): Promise<FeeReceipt>;
  isWithinFreeTier(userId: string): Promise<boolean>;
}

The adapter intercepts every operation, checks whether the user is within their free tier, deducts the appropriate fee if not, and then delegates to the underlying adapter. From the perspective of domain services like SharedDataService or PermissionService, nothing changes -- they still call the same StorageAdapter interface methods.

9.2 Orchestrator Integration¶

Fee deduction happens in the DataLayerService orchestrator, before the adapter call. The modified read flow becomes:

Request: get(userId, collection, id)
  |
  +- 1. Permission Check
  |     +- Call permissionChecker(userId, collection, 'read', id)
  |     +- If denied -> throw AuthorizationError
  |
  +- 2. Fee Check (NEW)
  |     +- If within free tier -> proceed
  |     +- If not -> deduct 0.001 CYE
  |     +- If insufficient balance -> throw InsufficientBalanceError
  |
  +- 3. Cache Lookup
  |     +- key = `${collection}:${id}`
  |     +- If hit -> return cached value (fee still applies)
  |
  +- 4. Adapter Fetch
  |     +- adapter.getDocument(collection, id)
  |
  +- 5. Cache Set + Return result

Cache hits still incur fees because the data was produced and is being served -- the fee compensates the hosting node regardless of whether the specific read hits the network or the local cache.

9.3 Balance Management¶

User CYE balances are tracked on-chain (L1) or on a Layer 2 rollup for lower latency and cost. The TokenizedStorageAdapter queries balance state via a lightweight RPC call, cached aggressively (30-second TTL) to minimize latency.

For real-time balance updates during high-frequency operations, the adapter maintains an optimistic local balance that is periodically reconciled with the on-chain state. This mirrors the existing multi-level cache architecture: local state for speed, remote state for truth.

9.4 Self-Hosted Bypass¶

The token layer is optional. Nodes that host their own data (using a self-hosted StorageAdapter implementation) can bypass all CYE fees. This is by design:

A user running a personal node stores their own data -- they are both the provider and consumer, so there is no service to compensate.
A community running a shared node for its members can choose to operate fee-free internally.
An organization deploying CyberEco on private infrastructure has no obligation to interact with the token economy.

This ensures that CYE enhances the ecosystem without creating vendor lock-in to the token itself -- consistent with CyberEco's tenet of digital sovereignty.

10. Economic Sustainability¶

The CYE economy is designed to be self-sustaining within five years of mainnet launch, with the development fund serving as a bootstrap mechanism rather than a permanent subsidy.

10.1 Development Fund Runway¶

At current team size (1-3 people, per the project's constraints), the 200,000,000 CYE development fund provides over 10 years of runway at projected token values. The 4-year linear vesting ensures that the fund is not depleted prematurely, even in adverse market conditions.

10.2 Transition to Fee Sustainability¶

As the ecosystem grows, transaction fee revenue gradually replaces the development fund as the primary source of core development funding:

Year	Primary Dev Funding Source	Fee Revenue (% of Dev Costs)
1	Development fund	~5%
2	Development fund	~15%
3	Development fund + fees	~40%
4	Development fund + fees	~70%
5	Fees primarily	~100%
6+	Fees only	>100% (surplus)

The target is for the development fund to become unnecessary by year 5 of mainnet operation. At that point, the 20% fee allocation to the development fund sustains ongoing core development, security audits, and protocol maintenance.

10.3 Emergency Reserve¶

Ten percent of the development fund (20,000,000 CYE) is held in a multi-signature emergency reserve. The reserve is only accessible through a governance vote with 20% quorum and 66% supermajority. It exists to cover:

Critical security incidents requiring emergency patches
Legal defense costs
Black swan events that disrupt normal fee revenue

The reserve is not intended for routine development expenses. Its existence provides a safety net that allows the ecosystem to weather unexpected crises without compromising long-term sustainability.

10.4 Surplus Management¶

Once fee revenue exceeds development costs, surplus CYE accumulates in the development fund. Governance determines the use of surplus funds, with three standing options:

Increase the burn rate -- Accelerate deflation, benefiting all token holders.
Fund ecosystem grants -- Invest in new apps, adapters, and integrations.
Reduce fees -- Lower operation costs, expanding the free tier or reducing per-operation prices.

11. Roadmap¶

Phase	Timeline	Milestones
Pre-Token	2025-2027	Firebase-based infrastructure. No token. Build user base across Hub, JustSplit, Demos, and Plantopia. Prove product-market fit. Extract and publish data layer packages.
Testnet	2027-2028	CYE testnet launch. Storage proof prototype. Governance mechanism testing via Demos integration. First `IPFSStorageAdapter` implementation. Testnet faucet for developer onboarding.
Mainnet Alpha	2028-2029	CYE mainnet launch with limited functionality. Data hosting rewards begin. Token distribution to early contributors. Free tier active from day one. Alpha governance votes on initial parameters.
Mainnet	2029-2030	Full fee structure activated. Compute marketplace operational. Governance fully active. Network healing rewards live. Multiple `StorageAdapter` implementations in production.
Maturity	2030-2035	Self-sustaining token economy. Development fund optional. 30+ apps operating on decentralized infrastructure. Community governance handles all protocol decisions. `FirebaseStorageAdapter` retired.

Phase Details¶

Pre-Token (2025-2027): This is the current phase. The ecosystem runs entirely on Firebase, and users pay nothing. The focus is on building a compelling product that people actually use. The StorageAdapter pattern is proven, the data layer packages are published, and the architecture is validated at scale. No token is needed or appropriate at this stage -- tokenizing an ecosystem that has not proven its value is premature.

Testnet (2027-2028): The CYE testnet runs alongside the existing Firebase infrastructure. Developers experiment with storage proofs, governance votes, and fee mechanics using testnet tokens with no real value. The Demos governance app serves as the primary testing ground for the quadratic voting mechanism. The IPFSStorageAdapter is developed and tested, providing the first non-Firebase storage backend.

Mainnet Alpha (2028-2029): CYE launches on mainnet, but with training wheels. Fee rates are set conservatively, slashing is disabled for the first 6 months, and the governance scope is limited to non-critical parameters. The goal is to build confidence in the token economy before exposing it to adversarial conditions.

Mainnet (2029-2030): The full CYE economy is active. Hosting rewards, compute marketplace, network healing, uptime staking, and governance are all operational. The ecosystem begins its transition away from Firebase as nodes provide competitive storage and compute alternatives.

Maturity (2030-2035): The CyberEco ecosystem is fully decentralized. User data lives on a peer-to-peer network. The FirebaseStorageAdapter is deprecated and eventually retired. The CYE token economy sustains all infrastructure costs through transaction fees. The founding team's tokens are fully vested, and governance is entirely community-driven.

12. Risks and Mitigations¶

12.1 Regulatory Risk¶

Risk: Regulators may classify CYE as a security rather than a utility token, subjecting it to securities law requirements.

Mitigation: CYE is designed and operated as a pure utility token: - It grants no equity, profit-sharing, or dividend rights. - There is no Initial Coin Offering (ICO), no public sale, and no fundraising event. - Token value is derived from utility (paying for data operations and governance participation), not from speculative appreciation. - The ecosystem operates for two or more years without a token, demonstrating that CYE serves a functional purpose rather than a fundraising one. - Legal counsel reviews all token-related decisions before implementation.

12.2 Low Adoption¶

Risk: Users may not adopt the token, leaving the incentive mechanisms unfunded and the decentralized infrastructure underprovisioned.

Mitigation: The free tier ensures that the ecosystem is fully usable without CYE. Users can split expenses in JustSplit, manage their identity in Hub, and participate in Demos governance without ever acquiring a token. CYE enhances the experience (faster operations, governance participation, premium features) but does not gate it. If token adoption is slow, the ecosystem continues operating on its existing Firebase infrastructure until adoption catches up.

12.3 Price Volatility¶

Risk: If CYE's market price is volatile, the real cost of data operations becomes unpredictable, creating a poor user experience.

Mitigation: A fee oracle adjusts CYE-denominated fees to target a stable USD-equivalent cost. If CYE doubles in value, the oracle halves the CYE fees. If CYE drops by half, the oracle doubles them. The oracle uses a 24-hour moving average to smooth short-term volatility. This ensures that a JustSplit settlement always costs roughly the same in real terms, regardless of token price fluctuations.

The oracle's price feed is governed -- the community votes on the feed source and the smoothing parameters.

12.4 Centralization of Stake¶

Risk: Wealthy participants accumulate large CYE holdings, centralizing governance power and undermining the ecosystem's democratic principles.

Mitigation: Multiple mechanisms resist stake centralization: - Quadratic voting makes it quadratically expensive to accumulate governance power. - Per-entity stake caps limit any single entity (identified by proof-of-personhood or organizational registration) to a maximum of 5% of governance voting power, regardless of holdings. - Delegation enables small holders to pool their governance influence. - Constitutional limits ensure that even a 51% majority cannot override foundational principles like digital sovereignty and privacy by default.

12.5 Technical Failure¶

Risk: Smart contract bugs, storage proof failures, or network partitions could disrupt the token economy.

Mitigation: - All smart contracts undergo third-party security audits before mainnet deployment. - The mainnet alpha phase (Section 11) provides a 12-month period of limited-scope operation to identify and fix issues. - The emergency reserve (Section 10.3) provides funding for critical incident response. - The StorageAdapter pattern means the ecosystem can fall back to Firebase if the decentralized layer experiences critical failures -- the business logic in @cyber-eco/services is unaffected by the storage backend.

12.6 Network Bootstrap Problem¶

Risk: In the early days of the decentralized network, there may not be enough nodes to provide reliable storage and compute, creating a chicken-and-egg problem.

Mitigation: - The emission schedule (Section 3.2) front-loads token distribution, making early participation more rewarding. - During mainnet alpha, the core team operates bootstrap nodes that guarantee minimum service levels. - The Firebase infrastructure remains operational as a fallback throughout the transition period. - Hosting reward rates are set higher in the first two years and gradually decrease as the network grows -- early operators earn a premium for taking on the risk of a young network.

Appendix A: Glossary¶

Term	Definition
CYE	The native utility token of the CyberEco ecosystem
StorageAdapter	The interface that decouples business logic from storage backends
DataLayerService	The central orchestrator that coordinates permissions, caching, storage, sync, and webhooks
Storage proof	A cryptographic verification that a node possesses and can serve specific data
Quadratic voting	A voting mechanism where power equals the square root of tokens staked
Slashing	Penalty (partial stake forfeiture) for node misbehavior or extended downtime
Fee oracle	A mechanism that adjusts token-denominated fees to maintain stable real-world costs
TEE	Trusted Execution Environment -- hardware-isolated computation for sensitive data
FHE	Fully Homomorphic Encryption -- computation on encrypted data without decryption
Free tier	The first 1,000 daily operations per account, which incur no CYE cost
Sybil attack	An attack where one entity creates many fake identities to game a system
Proof-of-personhood	A verification mechanism that links an account to a unique human

Appendix B: Token Parameters Summary¶

Parameter	Value
Total supply	1,000,000,000 CYE
Emission period	10 years
Transaction fee burn rate	0.1% (goverable: 0.01%-1.0%)
Free tier	1,000 ops/day/account
Read fee	0.001 CYE
Write fee	0.01 CYE
Cross-app query fee	0.005 CYE
Batch operation fee	0.005 CYE/op
Subscription update fee	0.001 CYE
Fee distribution	70% nodes / 20% dev fund / 10% burn
Minimum write stake	10 CYE
Minimum node stake	100 CYE
Slashing penalty	5% of stake
Slashing trigger	>48h unannounced downtime
Governance quorum	10% of staked tokens
Constitutional amendment quorum	30% of staked tokens
Constitutional amendment majority	75% supermajority
Governance voting period	7 days
Governance discussion period	7 days
Stake cap per entity	5% of governance voting power
Healing reward multiplier	2x normal hosting reward
TEE compute premium	1.5x standard compute rate
Proof-of-personhood gov boost	1.5x quadratic voting power