When users join a Mobile Mining project, they usually begin with simple tasks.
They open the application every day. They mine. They invite friends. They build communities. Some users create content, operate Nodes or help verify other users.
Every action is based on rules published by the project.
However, the rules may change after several months or several years.
New KYC requirements may appear. Reward formulas may change. Conversion rates may be reduced. Referral Rewards may depend on conditions that did not exist before. Some balances may be locked, reduced or removed.
This creates an important question:
Should a project use new rules to change rewards that users earned under the old rules?
Projects Need the Right to Change
No system can remain unchanged forever.
A project may need to change its rules to:
- Stop bots and fake accounts.
- Correct calculation errors.
- Protect the token supply.
- Follow new laws.
- Protect personal data.
- Prevent fraud.
- Support long-term operations.
- Adjust rewards for future contributions.
These changes may be necessary.
However, the project must clearly separate rules for future work from new rules applied to past work.
New Rules Should Apply to New Work
If a project changes its reward formula, users should receive notice before the change begins.
The notice should explain:
- When the new rule will begin.
- Which activities will be affected.
- How rewards will be calculated.
- Whether KYC conditions will change.
- Whether old rewards will remain protected.
- Whether users can stop participating if they disagree.
After receiving clear information, users can decide whether they want to continue contributing.
This is a transparent change.
Past Contributions Should Be Protected
A new rule should not automatically remove work completed under an old rule.
For example, a user may have invited someone when KYC was not required. Several years later, the project may add a KYC requirement for Referral Rewards.
The new condition may be necessary to stop fake accounts. However, the project should still explain:
- How long will the old reward remain protected?
- Will the inviter lose the entire reward?
- What happens if KYC is not available in the invited user’s country?
- Should an inviter be responsible for another person’s actions?
- Will rejected rewards be burned or returned to another pool?
Users should not carry the full cost of delayed KYC or changes made by the project.
A project may change the rules for tomorrow. It should not erase the work completed yesterday.
When Is It Fair to Correct Old Rewards?
In some cases, a project may need to correct rewards that were already recorded.
This may be fair when:
- There is clear evidence of a fake account.
- A user used prohibited bots or automated tools.
- The system counted the same reward more than once.
- There is a technical error that can be verified.
- The activity broke rules that already existed when the work was completed.
- The law requires the project to block or reject a transaction.
However, the project should not only tell users that an account is “not eligible.”
The project should provide:
- A clear reason.
- The rule that was broken.
- The information used to make the decision.
- A deadline for submitting an appeal.
- A process for reviewing the case.
- An expected review time.
Fraud prevention is necessary. But fraud prevention should not become a reason to avoid giving an explanation.
Delayed KYC Should Not Erase Rewards
KYC may be required before tokens can be transferred to a wallet.
However, KYC and reward calculation are two different tasks.
Even when tokens cannot be transferred, a project can still:
- Record the user’s contribution.
- Calculate rewards every month.
- Confirm eligible rewards.
- Separate rewards that are waiting for KYC.
- Protect confirmed allocations.
- Give users a monthly report.
- Provide an appeal process when errors occur.
“Waiting for KYC” should not mean “we do not know whether your reward exists.”
If KYC is not available in a country, users in that country should not be punished for failing to complete a process that the project has not provided.
Every Balance Needs a Clear Status
Not every number on a dashboard has the same meaning.
A project should clearly separate:
- Estimated rewards.
- Confirmed rewards.
- Rewards waiting for KYC.
- Rewards under review.
- Allocated rewards.
- Rewards transferred to a wallet.
- Rejected rewards and the reason for rejection.
If all of these amounts are displayed only as “Balance,” users may misunderstand what they actually own.
A transparent dashboard should show what has been recorded and what the user truly controls.
Reward Rules Must Exist Before Users Work
Before asking users to mine, invite others, create content or operate Nodes, a project should publish:
- The reward formula.
- Eligibility conditions.
- KYC requirements.
- The date when rewards are finalized.
- The distribution schedule.
- Token lock periods.
- Reasons why rewards may be removed.
- The appeal process.
- The project’s right to change its policy.
- How earlier rewards will be treated after a policy change.
Users cannot make an informed decision if important conditions appear only after they have already contributed.
The KYCFIRST Standard
KYCFIRST proposes a simple principle:
NEW RULES FOR NEW WORK.
PROTECT REWARDS ALREADY EARNED.
A responsible project should:
- Announce changes before applying them.
- Never change balances without notice.
- Avoid applying new conditions to old work without a valid reason.
- Protect rewards that are waiting for KYC.
- Give users the right to appeal.
- Explain every rejected reward.
- Disclose where removed rewards will go.
- Calculate and review rewards every month.
Changing a policy is not always wrong.
The problem begins when a project accepts contributions under one set of rules and later uses another set of rules to avoid responsibility.
Users should know the rules before they contribute.
Core Teams should protect work already completed.
Fairness should not begin after Mainnet.
