Project Record

Sybil Detection (Internal + On-chain)

Open in an AI assistant with a suggested prompt

Preview prompt

Summarize the Ionitsa project record titled "Sybil Detection (Internal + On-chain)" for a technical reader.
Cover the problem or research question, implementation or method, evidence or results, and limitations.
Separate facts stated on the page from your own assessment, note anything unclear or unverified, and avoid promotional language.

Primary source: https://ionitsa.com/projects/sybil-detection.md
Canonical page: https://ionitsa.com/projects/sybil-detection/

Crypto fraud detection layer combining login/signup behaviour, allocation patterns, and on-chain wallet evidence.

Domains

CryptoFraudIdentity

Capability

Scoring & Decision Models

Methods

Graph AnalysisRisk ScoringHeuristics

Executive Summary

Sybil attacks, where one person operates many accounts, threaten token sales, governance, and any allocation process where the scarce resource is tied to identity. A single shared email or wallet is weak evidence because sophisticated operators rotate identifiers. The stronger signal is the shape of the behaviour: clusters of unusual logins, signup timing, country patterns, account quality, and on-chain deposits that start to look coordinated.

I built a composite risk layer for merit-based token sale applications that combined internal behavioural signals with wallet and deposit evidence. The first pass identified suspicious country and timing clusters across logins and signups; the second pass added score/activity features from GitHub, Twitter, wallet history, and platform score families; the final pass linked on-chain wallets that deposited through the same funding or deposit addresses.

The public sale context was large enough that manual review alone was not realistic. Legion reported that the merit-based portion of the Yield Basis sale closed with $195m deposited, 60,880 applicants, and 98x oversubscription. Demand was through the roof, so the detection layer needed to preserve legitimate applicants while making coordinated abuse visible quickly.

The model was also used to calibrate allocation filtering. The risk/score distribution showed two visible humps: a dense suspicious population and a cleaner applicant population. That made it possible to set a review threshold in the valley between the modes, rather than choosing an arbitrary cutoff.

The output was a prioritized review queue with evidence links, cluster IDs, and risk tiers. It was designed as a detection layer, not an automatic rejection engine, so compliance and operations teams could inspect the highest-risk groups without over-blocking legitimate applicants.

Problem

Single signals, such as a shared email, one suspicious country, or a weak wallet score, are too noisy to use as final decisions. The problem is to combine weak but correlated evidence into a cluster-level risk score: suspicious login/signup behaviour, country mismatch, account-quality scores, allocation patterns, and on-chain wallet relationships.

The system needs to separate coordinated low-quality applications from legitimate users while preserving an audit trail. Each flagged group should explain why it was surfaced: where the accounts came from, how they behaved, which score families were weak, and whether the related wallets shared deposit infrastructure.

Unsupervised Discovery Model

The first modelling pass did not assume labels. Each applicant was embedded into a mixed behavioural feature vector:

x_i = [t_i, c_i, k_i, s_i, w_i, a_i, z_i]

Where $t_i$ covers signup, application, and deposit timing; $c_i$ covers country and geographic consistency; $k_i$ covers KYC/profile completeness; $s_i$ covers social, developer, wallet, and on-chain score families; $w_i$ covers wallet structure; $a_i$ covers allocation fields; and $z_i$ covers categorical encodings such as country, domain, and applicant type.

Numeric features were imputed and robust-scaled; categorical features were imputed and one-hot encoded with rare-category handling. The discovery layer then combined three unsupervised views:

Isolation Forest: isolates globally unusual applicants in the high-dimensional feature space.
Local Outlier Factor: detects applicants that are locally sparse relative to similar neighbours.
DBSCAN: identifies dense behavioural clusters and marks points outside any cluster as noise.

The ensemble anomaly score was:

A_i = \operatorname{norm}(0.50 A_i^{IF} + 0.35 A_i^{LOF} + 0.15 A_i^{DBSCAN})

This created an unsupervised ranking of applicants and clusters before any manual penalty rules were applied. To make the score explainable, the high- and low-anomaly regions were also used as pseudo-labels for a tree model, producing feature-importance and permutation-importance reports for reviewer inspection.

Penalty Layer

The second pass made the unsupervised result auditable. Instead of relying on “the anomaly score says no,” the system derived binary good indicators and bad-action indicators from the same raw fields:

H_i = \sum_j g_{ij} - \sum_k b_{ik}

Where $g_{ij}$ is a positive signal for applicant $i$ under rule $j$ , and $b_{ik}$ is a penalty for suspicious action $k$ .

Good indicators included verified identity state, older accounts, credible wallet age, multi-chain presence, meaningful developer/social activity, clean handles, and non-suspicious timing slots. Bad-action indicators included dense signup or deposit slots, very new accounts, noisy social handles, country mismatch, free or very short email patterns, weak activity, suspicious wallet structure, and abnormal allocation behaviour.

The penalty layer had two jobs: it dampened applicants whose behaviour was badly derived after the unsupervised run, and it gave reviewers a compact explanation of why a cluster was suspicious.

Risk Composition

The final review score blended the unsupervised discovery model, interpretable penalties, wallet/deposit linkage, and KYC/profile consistency:

R_i = \alpha A_i + \beta P_i + \gamma W_i + \delta K_i

Where $A_i$ is the ensemble anomaly score, $P_i$ is the normalized penalty pressure derived from $H_i$ , $W_i$ is wallet and deposit overlap intensity, and $K_i$ is KYC/profile inconsistency. The production weights were calibrated per sale; the important design choice was preserving each component separately rather than collapsing everything into one opaque score.

The output retained anomaly score, DBSCAN cluster/noise labels, good/bad rule counts, wallet linkage evidence, and risk flags. A reviewer could therefore distinguish a sparse statistical outlier from a coordinated signup burst or a wallet-funded cluster.

Threshold & Allocation Calibration

For the sale allocation, the risk score was not treated as a black-box rank. The unsupervised score helped separate populations; the penalty layer explained why accounts landed on the suspicious side; and the wallet/deposit checks provided hard linkage evidence where available.

The useful chart was bimodal: one hump contained accounts with clustered, low-quality behaviour; the other contained cleaner applicants. The operating threshold was placed between these humps, where the population density dropped. This made allocation filtering easier to defend: prioritize accounts on the suspicious side of the observed separation, then inspect the evidence links before final action.

Implementation

Data: application records, login/signup metadata, KYC country fields, GitHub/Twitter/wallet scores, platform score families, application allocation fields, and on-chain deposit records.
Feature pass: build robust-scaled numeric features and one-hot categorical encodings from timing, country, KYC, score, wallet, and allocation data.
Discovery pass: combine Isolation Forest, Local Outlier Factor, and DBSCAN into an ensemble anomaly score and cluster/noise labels.
Penalty pass: compute binary good/bad indicators, penalise badly derived actions, and expose rule counts and flags.
On-chain pass: link accounts through wallet overlap, common funding paths, and wallets depositing from the same addresses.
Calibration pass: inspect the sale distribution, set the threshold between the two visible modes, and export review lists with evidence columns.

Trade-offs

Unsupervised models surface structure but do not prove intent. Rule penalties are explainable but can be gamed once attackers learn the monitored behaviours. The safer pattern is to use unsupervised clustering for discovery, penalties for interpretation, and thresholds as review triggers rather than final decisions. Periodic recalibration is needed because the distribution can shift from one sale or campaign to the next.