Tokenomics and Emissions
The emission schedule for hardware nodes, including DogeBox and future hardware products designed by Cysic, releases CYS gradually over a multi-year on-chain schedule rather than distributing it upfront. Within each epoch, the budget set by the schedule is split pro-rata among that epoch's active nodes by their measured contribution — so a node's share reflects what it contributed relative to the rest of the network, not a discretionary allocation.
Understanding the Emission Schedule
Hardware node operators are allocated 13.39% of total CYS supply (around 133.9 million tokens), distributed over 10 years. The schedule is structured to reward early operators with a higher per-year share, then normalize over time as the network matures and participation becomes increasingly self-sustaining. The first five years break down as:
| Year | % of Hardware Node Allocation | % of Total CYS Supply |
|---|---|---|
| 1 | 30% | 4.01% |
| 2 | 20% | 2.67% |
| 3 | 15% | 2.0% |
| 4 | 10% | 1.34% |
| 5 | 7% | 0.94% |
Over time, this structure enables a smooth transition from an early growth phase — optimized for onboarding and rapid decentralization — into a more balanced, scalable model where incentives remain aligned with verified participation and long-term ecosystem health.
The Rewarding Rule
This section specifies a deterministic, participation-weighted reward mechanism for hardware nodes. The mechanism converts measurable contributions — baseline uptime and incremental network services — into a unified Computing Score (CS). Epoch rewards are distributed pro-rata by score, so each node's reward tracks its real contribution rather than a discretionary allocation.
Each epoch, every eligible hardware node \(i\) is assigned a Computing Score \(CS_i\). The protocol defines an epoch reward budget \(E\), which is derived from the annual hardware-node emission schedule. Emission release is modulated by an epoch-indexed time function \(U(e)\), so issuance follows an on-chain timeline. Here, \(e\) denotes the epoch number, and \(U(\cdot)\) is defined as:
where \(u_0 \in [0,1]\) is the initial unlock factor, and \(E_{\text{stable}}\) (Estable) is the epoch at which \(U(e)\) reaches 1. Node \(i\)'s reward for the epoch is computed as:
This construction guarantees that total distribution for the epoch is exactly \(E \cdot U(e)\), regardless of the number of participants, while naturally allocating larger shares to nodes with higher verified contribution.
Epoch Definition and Initial Parameter Values
An epoch is defined as one UTC day. Epoch 0 begins at UTC 2026-04-27, and the epoch index increments by one per UTC day thereafter.
For the initial rollout, the concrete parameter values are:
- \(E_{\text{stable}}\): the epoch corresponding to UTC 2027-04-26 (one year after epoch 0). For \(e \ge E_{\text{stable}}\), \(U(e) = 1\).
- \(u_0\): 0.2. This value is chosen based on the scale of network development — it sets the initial fraction of the epoch budget to unlock when participation is still ramping up, and is calibrated so that early-stage emissions remain conservative relative to the expected size of the active node base.
- Baseline \(E\): the annual hardware-node emission schedule allocation divided evenly across all epochs in that year. For example, the Year 1 baseline is approximately \((4.01\% \times \text{total CYS supply}) / 365\) per epoch.
- Top-ups: the project may raise \(E\) above the scheduled baseline from time to time (for treasury rebalances, campaigns, or other operational reasons). \(E\) is never reduced below the baseline, and historical rewards are never recalculated when \(E\) changes.
Computing Score
The Computing Score is defined as:
where
- D: the node's uptime measurement, calculated as the DOGE mined per day and expressed in koinu (1 DOGE = 10⁸ koinu). All scoring arithmetic is performed in integer koinu rather than decimal DOGE so the protocol never has to round at fractional boundaries. It represents a node's baseline "always-on" contribution, derived from measured mining output, and the value is anchored to verifiable mining evidence (signed pool receipts and proofs of shares) rather than node self-reporting, so it cannot be inflated.
- Z: additional verifiable work performed for the network during the scoring window (e.g., state-root validation attestations, governance vote participation, ZK verification, and other protocol-defined edge tasks). It captures incremental services that strengthen the network beyond passive uptime. Each task type has objective verification rules built in — a node only earns Z for work the protocol can independently confirm, which prevents "free-work" inflation.
- R: a multiplier capturing node quality and alignment, computed mechanically from verifiable signals such as reliability tier, uptime attestations, and stake locks. It rewards participants who go beyond simply running the hardware and staying online — engaging with the Cysic Network's broader ecosystem and governance earns a higher multiplier.
DOGE mined per day is used as a practical proxy for node uptime. Because a node can only mine when it is powered on, connected, and operational, sustained mining output provides a high-signal indicator that the hardware node has remained online throughout the epoch. Importantly, the mined DOGE is not merely a scoring input: it is intended to offset or fully cover the node's electricity costs, allowing operators to keep their hardware running continuously without paying out-of-pocket operating bills. This design aligns incentives with real-world sustainability: nodes that are reliably online are both economically self-sustaining and more valuable to the network.
By anchoring every input to verifiable evidence and distributing each epoch's budget pro-rata by Computing Score, the protocol provides a transparent and scalable foundation for incentivizing hardware-node participation over the network's full lifecycle.
Smart Contract Deployment and Audit
Reward distribution is executed on-chain by the RewardDistributor smart contract, which is deployed at 0x155DD70F1a055EF845dD4b52Bf800E80FcD87ddd on the Cysic network. The contract has undergone an independent third-party security audit by Exvul, and the full audit report is available here.
For per-epoch transparency, every daily settlement publishes two artifacts:
- Merkle leaves (every participating address plus its cumulative reward, in wei) at
https://merkle.openforge.one/<YYYY-MM-DD>.json - Metadata file (epoch number, baseline E, U(e), distribution budget, participant count, \(\Sigma_j \mathsf{CS}_j\), Merkle root, on-chain settle tx) at
https://merkle.openforge.one/<YYYY-MM-DD>.meta.json
Anyone — participant or not — can independently reconstruct the Merkle root from the leaves file and verify it matches the on-chain root for the same epoch. No server trust is required.
Participants with access to their own input data can also verify the reward arithmetic independently — by recalculating their own \(\mathsf{CS}_i\) and using \(\Sigma_j \mathsf{CS}_j\) to derive their share of \(E \cdot U(e)\).
Users can interact with the contract directly via RPC, or through the WebUI — see the Reward Dashboard Guide for usage.