How an Anti-Sybil Filter Can Be Fair to Real Players

Imagine finishing a quest, seeing your points arrive, then finding a warning beside your season position. What changed? Did the task fail? Did you lose your place? Is the warning asking you to do something else?

A fair-play rule is only useful to an ordinary player if those questions have clear answers. A short condition buried in a handbook is a start. The rest is how the game explains the condition when you meet it.

We use an anti-sybil filter to limit abuse by people operating multiple accounts. Here, we want to look at the player experience around that filter: which decisions should stay separate, what a failed check means, and how to inspect a result without guessing at hidden criteria.

Separate the questions you are asking#

Playing, getting a task verified, moving up the season board and qualifying for a payout are different questions. A single vague status cannot explain all of them.

In Denshin, the payout eligibility check is separate from participation and season position. You can play and appear on the board while that condition is still unmet. The published condition is an accepted on-chain transaction during the season. A verified swap or a counted Denshin Sync can satisfy it; a task that only reads a holding does not establish the same evidence. The fair-play handbook gives the rule and its limits.

That separation matters when reading a warning. Missing payout evidence does not itself mean your completed tasks vanished or your season points stopped counting. Equally, a position on the board is not a promise of payment. Eligibility, final standing and the season's reward rules still have their own jobs.

Explain a failed task check before calling it suspicious#

A task can fail verification for a perfectly ordinary reason. You might have acted on a different network, used an address other than the main wallet, or completed the action before starting the mission. A recent transaction may also need time to become visible to the check.

Those are useful explanations because they point to something you can inspect. Compare the task's network, wallet and conditions with what you actually did. If the action was too early, waiting will not change its timing. If it is merely recent, another check later may be enough. Re-running verification is free, with a short wait after an empty result.

Our verification guide describes these cases. A failed task check, by itself, is not a finding that somebody operated a farm. We should not make a player infer an accusation from an unhelpful error.

This is also why the wording matters. An explanation such as "the action predates this mission" gives you a next step. A generic "try harder" turns a precise rule into uncertainty.

Let the points history carry the explanation#

Sometimes the task is complete and the surprise is a number. The expected increase may include a profile bonus, a referral credit or a team reward that has not arrived yet. Looking only at the total makes those different causes look alike.

Denshin keeps an entry-by-entry points history with a reason for each credit. The points handbook explains how those entries relate to season and lifetime totals. Start there when a balance looks wrong. Find the particular entry and compare its source with the action you completed.

For our team, that is a better starting point for investigating a mistake than a screenshot of a total with no context. It narrows the question: which action, which credit, which total? A clear record does not make errors impossible. It makes a suspected error easier to describe and check.

Keep the ordinary route understandable#

An anti-abuse system can be difficult to reason about internally. That does not mean every player should have to learn its implementation before taking a first step.

The ordinary route should stay readable: follow the mission's instructions, use the wallet and network it checks, and inspect the result. Payout eligibility should be explained where it matters while the season is still open. A player should have time to understand an unmet condition rather than discover it after planning around an assumed result.

We also want limits to remain visible as rules about an activity. Daily and referral limits constrain how particular sources contribute. They should not require you to guess which personality, spending pattern or social presence the game prefers.

This is a design standard, not a claim that every screen is already perfect. When an explanation is unclear, improving it is part of the work.

Know what a simple condition can and cannot establish#

A transaction is evidence of an action. It is not proof that an address belongs to a unique human being. Keeping the condition simple does not make deliberate multi-account abuse acceptable, and it does not remove the need to review actual abuse.

The distinction protects the meaning of the rule. We should neither advertise it as a perfect identity test nor treat an ordinary verification problem as proof of wrongdoing. The public rules describe prohibited conduct separately from the evidence needed for payout eligibility.

If your history still looks inconsistent after checking the relevant entry, bring the specific issue to a channel listed on our official links page. Keep the question concrete. You do not need to share a seed phrase or private key for anyone to understand a points entry.

The standard we want to meet is practical: you should be able to tell what happened, which rule applies and where to ask about a possible mistake. A fair filter has to protect the season while leaving that ordinary path through the city clear.