Turnkey development of an anti-sybil verification system

Anti-sybil system: why sybil activity passes filters

Most anti-sybil systems are assembled as a set of standalone rules with thresholds: minimum balance, number of transactions, address age.

Bypassing them costs less than it seems — activity is split across hundreds of small addresses, and each one individually looks like a regular participant. Bot protection turns into a race where the patch always catches up to the previous bypass method.

The second weak point is broad ranges and template lists. A filter built on a single feature either cuts out live users or lets the entire farm through: whoever runs sybil accounts has more data for tuning than a team that sees only a snapshot of the network at a specific moment.

But the root of the problem is deeper. A check that looks at an address in isolation does not see connections between accounts: multi-accounts are funded from the same sources, act in the same windows, and repeat the same fund movement routes.

Without clustering by common sources, matching transaction times, and repetitions in transfer chains, these signals are simply not taken into account.

Then the accumulation effect kicks in. A single operator manages dozens of wallets, passes the filter many times, and takes a share intended for the community.

The cost shows up in token distributions: the incentive is devalued, honest participants lose interest, and the distribution stops reflecting real activity — and this becomes noticeable only after payouts, when nothing can be rolled back. We break down how this is addressed.

Protection effect: less sybil activity, fewer false blocks

The system does not divide participants into "us/them" but calculates a risk score across a set of features: account age, distribution of activity over time, intersections with already flagged clusters, and reaction to changes in reward conditions.

Weights and the threshold are tuned to the project's mechanics, so the sybil activity share drops severalfold and stays at that level as the number of participants grows, rather than "drifting" with the load.

The second metric is false blocks of honest participants. Instead of a ban, graduated measures are applied: weight reduction, a confirmation request, and delaying payout until review.

The false block rate stays at tenths of a percent rather than several percent, as with rigid threshold rules.

Appeal review speeds up because the decision is explainable: the moderator sees which features triggered and with what weight, rather than "the system decided so." Typical cases are resolved by automatic recheck, and a human gets involved only in disputed ones — review time drops from hours to minutes, and the volume of manual moderator work falls severalfold.

Participant trust is also measured by specific values: the share who return after the first check, the number of support requests per thousand active users, and the share of appeals reviewed in the user's favor.

A clear reason for rejection and the ability to contest a decision retain users better than promises in the rules.

At acceptance, we verify: the sybil activity share before and after is known, the threshold is tuned to the project's mechanics, a decision log with rationale is maintained, the false block metric is included in reporting, and appeal review fits within the agreed time.

Options for building an anti-sybil system and their limitations

Choosing a method for an anti-sybil system is not about finding the most accurate one: the alternatives differ in what data they rely on and what price the project pays for a false positive.

Rule-based checks work at the start, a relationship graph — once history has accumulated, behavioral features — when labels are available. Below are four approaches and the point where each begins to fail.

What a combination of approaches provides

In practice, the bet is not on a single method: thresholds remove obvious noise, a relationship graph assembles clusters, behavioral features provide a risk score, and manual moderation resolves disputed cases.

External reputation aggregators such as Gitcoin Passport add a signal but depend on users' willingness to collect verifications.

The main limitation of the combination is that it must be calibrated on the specific project's data; otherwise, honest participants from shared infrastructure end up blocked.

Implementation stages: from data analysis to regulations

Anti-sybil checks do not transfer well "as is": the signs of multi-accounts are different for each project, and an error costs symmetrically — we either block a live user or let a farm through.

Therefore, the order of stages is strict, and thresholds are tuned only after the project's real data has been analyzed.

1. Data audit. We look at what is available: transaction history, address connections, roles in contracts, funding sources. We immediately assess completeness — where data is scarce, any rule will produce noise.
2. Criteria definition. We fix what we consider a multi-account specifically here: an address cluster, a common source of funds, synchronous actions. Each criterion — in writing and with rationale.
3. Check design. We combine signals into a single score: feature weight, a combination of several weak signals, manual review of disputed addresses. Separately, we decide where the output is blocking and where it is only a flag for human review.
4. Threshold tuning. We select boundaries on real data and look at two values: the false positive rate versus the rate of missed clusters. The threshold must not cut off legitimate scenarios — bridges, exchange, and custodial addresses.
5. Historical validation. We run the rules on past distributions and state snapshots, comparing them with the actual result. It becomes clear which rule has an effect and which adds noise.
6. Handover of regulations. We provide a description of the rules, exception registries, the procedure for updating thresholds, and handling user requests. The system remains manageable without our involvement.

After implementation, thresholds change deliberately: every change has a reason, and the result is validated against history.

Implementation artifacts: rules, thresholds, diagrams, appeals

An anti-sybil system is handed over to the client not as a ready-made service but as a set of rules that their team can change independently.

If the rejection logic lives only in correspondence with the contractor, the first drift in behavior — new sybil schemes, a change in farm infrastructure — will require a new development cycle.

Therefore, at acceptance we fix artifacts that describe not only the implementation but also every decision made: what we consider a signal, why, and under what combination we block.

• Feature dictionary — a table: feature name, source, accumulation window, weight, trigger threshold. A separate column "why this is a signal" — so that six months later no one deletes a feature without understanding what it catches.
• Relationship diagram — an entity graph: accounts, devices, withdrawal addresses, behavioral clusters. It shows which edges are built automatically, which are confirmed manually, and how conflicts between sources are resolved.
• Threshold policy — which combinations produce an automatic rejection, which go to manual review, and how the threshold is recalculated when baseline activity changes.
• Appeal procedure — review timelines, who makes the decision, what the user attaches, in which cases the verdict is rolled back, and how this is reflected in their history.
• Rule configurations — in the client's repository, with versioning: a threshold change goes through review and can be rolled back with one revision.
• Test set — labeled examples with the expected verdict, on which we run any rule change before rollout.
• Monitoring — false rejection rate, manual review rate, and distribution of triggered features over time.
• Documentation — system map, data model description, and instructions for adding a new feature and including it in reporting.

We consider the artifacts accepted when your team has added a feature and changed a threshold by hand without our help. Describe the task — we will come back with an estimate and a plan for how much of the rules and documentation we hand over in your case.

Case study: cleaning up multi-accounts without blocking live participants

The case is a rewards program where accruals were made for on-chain activity.

Before implementing a separate check layer, duplicates were filtered out by rules matching subnet and device fingerprint: obvious clusters were filtered out, but live participants also fell under the common operator address.

What it was like before implementation

A manual review of a sample showed: about 34% of addresses among recipients were in clusters with a common source of first top-up, meaning the reward was taken not by one participant but by dozens.

The false block rate reached 19% — addresses were merged only by subnet and close creation time. The queue of requests took weeks to review, and some live participants simply left the program.

What we changed

We built a multi-layered anti-sybil system: a graph of transfers and first top-ups, matches by activity time, behavioral features — fan-out withdrawals to one wallet, micro-transfers between one's own addresses, identical sequences of actions — plus address reputation.

It is not a single rule that decides but the sum of scores; the disputed range goes to manual review with a log of reasons. Public reviews of Gitcoin rounds show the same picture: without separation by features, a subnet filter cuts live users.

What the result was

The sybil activity share among recipients fell from 34% to 4%, false blocks — from 19% to 1.5%, and the manual review queue shrank by about six times.

The threshold is refined on new waves without rebuilding the model, and for each address it is clear which feature contributed a score — rolling back a decision remains manageable.

How does rule-based checking differ from a behavioral model?

Rule-based checking is a set of deterministic conditions: minimum balance, address age, activity within a given window, a limit per funding source, mandatory completion of a step. The decision is made instantly and explained in one line — you can see which condition triggered.

But thresholds are known and reproducible: an automated farm tunes addresses to them more cheaply than bypassing them costs.

A behavioral model looks not at individual values but at structure: who appears with whom in the same transactions, how intervals between actions are distributed, and how repeatable the sequences are.

This reveals coordination that cannot be described by a threshold — a common funding source, synchronous actions, and flows between wallets. The cost is false positives on live participants and the need for regular retraining for new schemes.

In practice, there is only one workable option — a hybrid approach. Rules form the first layer and filter out obvious cases, providing an explainable decision and protection against mass scripted entry.

The model works on the remainder and adds checking accuracy where features are blurred. Disputed triggers are not silently discarded but go to recheck based on an additional feature.

We measure checking accuracy with two numbers at once: the share of abuses that passed the filter and the share of honest participants who were cut off. An operational metric is added to them — how many cases per thousand decisions go to manual review.

The hybrid approach keeps both indicators manageable: rules cover the clear cases, the model covers the rest, and the manual review queue stays short.

Disputed cases, data privacy, and rule updates

The check relies on pseudonymized identifiers: address hash, aggregated behavioral features, and timestamps.

Raw personal data does not enter the perimeter — identity verification takes place with a specialized provider, and only confirmation of the fact and a trust level come back to us. This approach complies with GDPR requirements and resolves the main security service concerns.

The data volume is limited by a window: fresh events are stored for a limited period, then collapsed into counters, and raw records are deleted. The registry does not grow linearly with the number of transactions, and yet any decision is reproducible from the stored aggregates.

Appeals are built into the perimeter rather than moved outside: a rejection enters the queue, an engineer reviews the address history and connections between features, if an error is confirmed the score is recalculated, and the case becomes a labeled example.

We update thresholds through regression on accumulated cases — rules against new bypass methods do not increase the false block rate.

What to do when bypass methods change?

Rules and thresholds are configuration, not code. A new pattern is first evaluated in shadow mode: we look at whom it would have affected, compare it with historical cases, and only then enable it. Rollback is a single configuration edit, without a release or downtime.

Let's discuss the task: what is needed to start the check

Starting a check is a conversation about data and decisions, not about choosing a ready-made product.

An anti-sybil system works at the intersection of transaction history, internal analytics, and user behavior rules, so we first find out which signals you already collect and which are missing for robust conclusions.

Below is what we clarify in the first conversation so we can come back with a task estimate and a working implementation plan.

• What data about address connections exists now: transfer history, wallet clusters, labels for exchanges, bridges, and accrual services.
• Which data accesses need to be opened: network nodes, indexers, exports from billing and the user registry, login and device logs.
• Where the line runs between "suspicious" and "blockable," and who makes the final decision — an automated system, an operator, or a combination with manual review.
• Which trigger thresholds are acceptable so as to filter out multi-accounts and farms without affecting bona fide users.
• Whether an appeals perimeter is needed and how to review false positives so as not to lose real customers.
• Which integration points matter first: registration, wallet, reward accrual, affiliate programs.
• Requirements for storing exports and restricting access to sensitive data.

After the conversation, we fix the composition of signals and thresholds, note dependencies on access, and come back with an estimate and a plan: the order of stages, what we validate on the real stream, and when we enable the containment model. Describe the task — we will come with a concrete proposal on timelines and scope of work.