Reward Dashboard Guide

The Reward Dashboard is where Cysic Network participants register and claim the CYS rewards distributed to their address by the on-chain RewardDistributor. Each UTC day, participation is settled into a Merkle-root-anchored ledger published on Cysic chain; the dashboard is how you redeem your share of that ledger.

This guide explains what the dashboard does, how the underlying enroll/claim mechanism works, and how to verify everything yourself. The protocol-level reward formula and emission schedule are covered separately in Tokenomics and Emissions.

What This Dashboard Does

The dashboard has two places you'll use:

• My Rewards — the page that opens by default. Shows your accumulated rewards, registers new ones from the latest published settlement, and claims whatever has unlocked into your wallet. This is where you'll spend most of your time.
• Epoch Viewer — click 🌳 Epochs in the top-right of the navigation bar. Lets you inspect the Merkle leaves for any past day's settlement and independently verify the day's distribution against both the published metadata and the live on-chain root, all in your browser.

The dashboard is a thin client. It reads everything from the public Cysic chain and from publicly hosted Merkle data; nothing about your rewards is stored or computed on a server you have to trust. If you would rather not use a web frontend, you can call the RewardDistributor contract directly via RPC — see Tokenomics and Emissions for the contract address.

Before You Start

You will need:

1. A self-custody Ethereum-compatible wallet loaded with the on-chain address you intend to use as your Cysic Network identity. The dashboard uses RainbowKit and works with most popular wallets, including MetaMask. The address you connect must be the same address that has been bound as your identity for Cysic Network participation — this is the address the RewardDistributor writes to.
2. Cysic Network configured in your wallet. When you connect for the first time, RainbowKit will prompt you to add the network if it is not already present. The chain id is 4399 and the default RPC is https://rpc-evm.cysic.xyz.
3. A small amount of CYS for gas. Each enroll or claim transaction is paid for by the same wallet that receives the rewards. Gas costs on Cysic chain are low.

How Rewards Reach Your Wallet

This is the section worth reading carefully — the mechanism is somewhat counterintuitive on first contact.

The Mental Model: a Claims Counter

Think of the RewardDistributor as a claims counter run by an automated clerk:

• Once per UTC day, the clerk receives a settlement transaction from the operator. The transaction carries the funds for that day plus a single 32-byte fingerprint — the Merkle root — that compactly represents every participant's running cumulative entitlement.
• The clerk does not push payments to anyone. The contract has no per-address ledger of "owed N CYS" — it only stores the fingerprint. The actual ledger of "who is owed how much" lives in a public file (the Merkle leaves at merkle.openforge.one/<YYYY-MM-DD>.json).
• To collect, you walk up to the counter with two things: the cumulative amount you are owed (read from the public ledger) and a small Merkle proof (computed locally by the dashboard from the leaves file). The clerk hashes them together and checks the result against the posted fingerprint. If it matches, you are paid.

When you collect, the clerk does two things at once:

1. Hands you 30% of the new entitlement immediately, transferring CYS to your wallet in the same transaction.
2. Opens a 180-day savings account for the remaining 70%, which then drips back to your wallet linearly over 180 days (one block at a time — Cysic chain produces one block every 5 seconds).

The first step — "register the new entitlement, take the 30%" — is called enroll. The second step — "sweep whatever has dripped from your savings accounts" — is called claim.

Why You Submit the Proof Yourself

At the Cysic Network's scale (thousands of participants), pushing individual payments from one operator address every day would not scale — gas grows linearly with participant count, and any single failed transfer would stall the entire batch. The Merkle-root-and-self-claim model is the standard pattern for distributions of this size (widely used by large airdrops and reward programs on Ethereum and elsewhere): the operator commits a single root each day and pays the gas for that commitment, and each participant submits a proof for their share whenever they want to collect. Gas on Cysic chain is very low, and you decide the cadence — claim weekly, monthly, or once at the end of each vesting window.

The dashboard automates the proof-side mechanics for you. When you connect your wallet, it downloads the latest leaves file, finds your row, and computes your Merkle proof in the browser. You only have to click a button.

The 30/70 Split

When you enroll, each new entitlement splits in two: 30% goes to your wallet immediately, in the same transaction, and the other 70% unlocks gradually over 180 days, block by block — no cliff, no monthly tranches. After 180 days the entire 70% is claimable. See Tokenomics and Emissions for more.

A simplified picture of one entitlement over time:

Day 0    Day 30   Day 60   Day 90   Day 120  Day 150  Day 180
│────────│────────│────────│────────│────────│────────│
30% paid                                              ↑
immediately                                           remaining 70%
on enroll                                             fully unlocked

            ▲
            you can claim what has unlocked so far,
            at any time

You can call claim once at the end of 180 days to collect the entire 70% in one transaction, or call it periodically — both are fine. Unclaimed unlocked amounts simply continue to sit in the contract until you collect them; nothing expires.

The Action Buttons

The dashboard has two action buttons in two places:

• Claim lives in the Reward Breakdown card, next to "Available to Claim". Always visible; enabled only when at least one of your vesting accounts has unlocked some amount you haven't collected yet. One click sweeps all currently-unlocked amounts to your wallet in a single transaction.
• Enroll / Enroll & Claim lives in the Pending Rewards card, which only appears when the published ledger says you have new rewards to register. The same button switches its label depending on what else is going on:
  • Labeled Enroll when there's nothing currently claimable from prior vesting. One click registers your new cumulative amount, transfers the 30% immediate portion to your wallet, and opens a vesting account for the 70%.
  • Labeled Enroll & Claim when there's also unlocked vesting waiting to be collected. Same as above, plus it sweeps the unlocked amounts in the same transaction. Prefer this when offered — it saves gas vs. doing the two separately.

If neither button is enabled and the Pending Rewards card is missing, you are fully caught up: nothing new to enroll, nothing claimable.

Common Confusions

I haven't checked the dashboard in days. Did I miss any rewards?

No. The Merkle ledger is cumulative, not per-day. Every settlement publishes the running total each address has earned since day one. When you eventually enroll, the contract pays out the entire delta between your previously-enrolled amount and the latest published total in a single transaction. There is no expiry and no penalty for waiting.

Why is only 30% of my new reward in my wallet right after I enroll?

The remaining 70% is sitting in a vesting account associated with your address inside the RewardDistributor contract. You can see it in the Vesting Schedule table at the bottom of the dashboard, with a progress bar showing how much has unlocked so far. Click Claim (or Enroll & Claim) to sweep the unlocked portion to your wallet whenever you like.

When does the 180-day vesting clock start? When the rewards were earned, or when I clicked Enroll?

Neither, exactly. Vesting starts at the most recent settlement block at the moment you enroll — typically within a few hours of the prior UTC midnight. This is a deliberate design choice: it keeps the contract simple while ensuring vesting starts no later than the most recent epoch boundary, regardless of whether you check in daily or once a month.

The trade-off: if you wait and enroll on day 30 to collect the rewards from days 1 through 30, vesting on the entire 70% begins from day 30's settlement, not from each reward's original epoch. So it is slightly to your advantage to enroll regularly (e.g. weekly), but you do not lose any principal by waiting.

What happens if I enroll twice on the same day?

Inside the same settlement window, the contract merges your second enroll into the same vesting account it created for the first. You will see one combined entry in Vesting Schedule, not two — this avoids cluttering your account with many small entries.

Can I skip enroll and just claim?

No. Claim only sweeps amounts already unlocked in vesting accounts the contract knows about. Until you enroll, the contract has no record of any entitlement for you; new amounts must be registered first. The 30% immediate portion also requires enroll — there is no separate path that pays it.

My transaction failed with a proof error. What happened?

Almost always: you tried to enroll in the few-second window between when the operator settled a new epoch on-chain and when your browser's cached proof became stale. The contract retains the previous Merkle root for one full epoch as a buffer, so the conflict window is very small in practice. If you do hit it, refresh the page (the dashboard will fetch the latest leaves and recompute your proof) and try again.

How do I know the amount the dashboard shows is correct?

Click 🌳 Epochs in the top navigation and pick a date. The viewer downloads the leaves and metadata for that day and reconstructs the Merkle root entirely in your browser, then compares it against both the metadata file and the live on-chain merkleRoot(). If both checks come back green, the day's distribution is independently verifiable — no server trust required. See Verifying It Yourself below.

My wallet (or the block explorer) shows my enroll or claim transaction with value 0. Did the transfer fail?

No. The transaction-value figure shown by both your wallet's history view and the explorer's top-level Value field is only the amount of CYS you sent into the contract together with the call (its msg.value). Both enroll and claim are function calls that take no CYS from you — the contract is what sends CYS out to you as it executes. So the transaction shows up as 0 value on both surfaces, even though your wallet's balance went up.

To see how much CYS actually entered your wallet from a given transaction, open your address page on the explorer and click Coin balance history. Each row there is one balance change for that address; the Delta column is the signed amount your balance moved on that transaction. For an enroll or claim, the Delta is the real CYS the contract paid you (after subtracting the gas you paid for the same transaction).

The dashboard's Claim History table sidesteps this confusion entirely by reading the contract's Claimed and Enrolled events directly — those are the authoritative on-chain record of what was paid, independent of how any wallet or explorer chooses to present the transaction.

Reading the Dashboard

The My Rewards page shows several cards and a table. From top to bottom:

Epoch Info Card

A summary of the current settlement epoch, sourced from the metadata file published alongside the Merkle leaves. Fields:

• Epoch number — sequential, starting at epoch 0 on UTC 2026-04-27.
• Epoch Budget E·U(e) — the total CYS distributed across all participants in this epoch, after applying the unlock ratio.
• Unlock Ratio U(e) — the fraction of the baseline budget being distributed this epoch (ramps from u₀ toward 1; see Tokenomics).
• Participants — the number of addresses with nonzero allocation in this epoch's leaves file.
• Merkle Root — the on-chain fingerprint, abbreviated. Click "View settle tx" to see the corresponding settlement transaction on the explorer.
• View full epoch → — opens the per-epoch viewer for this date.

Reward Breakdown Card

Your account state, expressed as an equation:

Total Income  =  Locked  +  Unlocked
                            ├── Claimed Amount
                            └── Available to Claim

• Total Income — the cumulative CYS the contract has registered for you so far.
• Locked — the portion still in vesting accounts (not yet released).
• Unlocked — the portion that has been released linearly over time.
  • Claimed Amount — already in your wallet (the 30% immediate paid at enroll plus any vesting amounts you have claimed since).
  • Available to Claim — released but not yet swept; click Claim to collect.

These four numbers always add up: Locked + Claimed + Available = Total Income.

Pending Rewards Card

Appears only when the Merkle ledger says you are owed more than what you have already enrolled. Shows:

• The new amount waiting to be enrolled.
• The 30/70 breakdown that the enroll transaction will produce.
• The Enroll (or Enroll & Claim) button.

If this card is missing, you are fully caught up with the latest settlement.

Vesting Schedule Table

One row per vesting account — the 70% portion of one enroll. (The 30% immediate isn't shown here; it went to your wallet at enroll time.) Oldest first. Columns:

• # — the vesting account index.
• Total Amount — the 70% that was put into this account.
• Start Date / Full Unlock Date — the start and end of this account's 180-day window. Click either cell to toggle to the underlying block height.
• Progress — fraction of the account's total amount that has unlocked.
• Current Unlocked — amount unlocked so far (cumulative since the start of this account).
• Claimed — amount you have already swept out.

Once an account is fully unlocked and fully claimed, it scrolls off the table — the contract advances an internal pointer past it so future claim calls do not waste gas re-iterating finished accounts.

Claim History Table

A reverse-chronological log of every CYS payout that has actually arrived in your wallet from the distributor. The table is reconstructed in your browser by scanning the contract's Claimed and Enrolled events for your address — every row corresponds to a real on-chain transfer that you can verify independently.

Columns:

• # — sequence number (newest first).
• Date — block timestamp of the payout. Click the cell to toggle to the underlying block height.
• Source — Immediate Release for the share paid into your wallet at enroll time; Linear Unlock for amounts you swept from a vesting account via Claim. The two together account for every wei in Claimed Amount on the Reward Breakdown card.
• Amount — gross CYS the contract paid you in this row.
• Transaction — abbreviated transaction hash; click to open it on the block explorer.

When you click a transaction through to the explorer (or look at the same transaction in your wallet's history), the value will read 0. That does not mean nothing was paid — see the FAQ entry above for what that value actually means and where to find the real balance change.

Verifying It Yourself

Two layers of public data make every distribution independently auditable:

1. The Merkle leaves file at https://merkle.openforge.one/<YYYY-MM-DD>.json — every participating address plus its cumulative entitlement, in wei.
2. The metadata file at https://merkle.openforge.one/<YYYY-MM-DD>.meta.json — the epoch number, the baseline E, the unlock ratio U(e), the participant count, ΣCS, the Merkle root, and the on-chain settlement transaction hash.

These artifacts support two independent verification paths.

Verify the day's distribution

The Epoch Viewer (opened from 🌳 Epochs in the navigation) rebuilds the Merkle tree from the leaves file directly in your browser and runs two checks:

• The rebuilt root matches the metadata file's recorded root.
• The rebuilt root matches the live merkleRoot() returned by the on-chain contract.

If both come back green, the day's distribution is consistent end-to-end and no party — including the operator — can have tampered with the result without breaking the checks. If either check fails, the data should not be trusted.

Verify your own reward

If you have your own input data for the epoch — D (DOGE mined that day, in koinu), Z (verifiable network services), R (your quality multiplier) — you can reproduce the reward math by hand:

1. Compute your Computing Score: \(\mathsf{CS}_i = (D + Z) \cdot R\).
2. Read \(E\), \(U(e)\), and \(\Sigma_j \mathsf{CS}_j\) from the metadata file.
3. Compute your expected reward: \(\mathsf{Reward}_i = E \cdot U(e) \cdot \mathsf{CS}_i / \Sigma_j \mathsf{CS}_j\).
4. Compare against the per-epoch delta in cumulativeAmount from the leaves file — this day's leaf minus the previous day's leaf for your address.

The on-chain implementation distributes integer wei amounts via the largest-remainder method so the per-epoch total is exactly \(E \cdot U(e)\); a hand-computed value should match within one wei.

The contract address and third-party audit report are listed at the bottom of Tokenomics and Emissions. Anyone — participant or not — can run the verification.