Stop the sybils. Protect
the rewards. Keep it fair

Most crypto abuse comes down to one person operating many wallets or accounts to take a share of rewards meant for real users. It shows up differently across the vertical: Crypto exchanges and trading apps: multi-accounting and bonus abuse, where one person runs parallel accounts to farm welcome bonuses, fee rebates, and referral payouts, or to bypass trading, withdrawal, and regional limits; Airdrops and token launches: sybil attacks and airdrop farming, where a farmer runs hundreds of wallets to qualify for a token allocation many times over; Dapps, launchpads, and quest platforms: account farms, where one person takes many allocation slots or repeats the same reward action again and again. ShieldLabs detects Multi-accounting, one person behind many wallets or accounts, using persistent visitor and user identification that holds across sessions regardless of wallet, email, IP, or browser.

Airdrop farming is when one person runs many wallets to qualify for a crypto airdrop multiple times, claiming a share of the token allocation that was meant to reward genuine users. The mechanics and the cost: A farmer drives dozens or hundreds of wallets through the qualifying actions a project rewards, then collects an airdrop on each one; It is not illegal, but it drains the allocation, distorts the project's user and community metrics, and concentrates tokens with farmers instead of the community. ShieldLabs detects when the same person is behind many of those wallets, so a project can weight or exclude them from the allocation.

ShieldLabs links many wallets back to the one person operating them by reading the device, browser, and connection behind each wallet connect, not the on-chain history. From a single JavaScript snippet on your dapp, wallet-connect, signup, or airdrop-claim page it returns: a 0-100 risk score on every wallet connect; persistent visitor and user identification that holds across sessions, cleared cookies, rotated IP, and fresh wallets; risk signals such as VPN, proxy, Tor, anti-detect browser, and IP reputation; High-Risk Events with Medium or High confidence, including Multi-accounting. ShieldLabs detects Multi-accounting directly when many wallet connects trace back to one device, browser, or identity, and delivers the score, signals, and events in the analytics dashboard and via API and Webhooks, so you can flag, weight, or hold a wallet before an airdrop is claimed.

No. ShieldLabs works at the web and device layer, not on-chain, and the two approaches cover different timing: It does not analyze wallet transactions, token flows, smart-contract interactions, or address clusters; On-chain sybil analysis looks at what wallets do after the fact; ShieldLabs reads the device, browser, and connection behind a wallet at the moment it touches your dapp, claim page, or quest flow; Because it works at the web layer, it can link many wallets to one operator before the claim, even when every wallet is fresh and has no on-chain history. ShieldLabs is built to run alongside on-chain analysis, not replace it, and most projects use both together.

Proof-of-personhood verifies that a wallet belongs to a unique human; ShieldLabs verifies whether many wallets are being run by one operator. The two answer different questions: Proof-of-personhood services use a biometric, social-graph, or document check, which adds real friction and a privacy trade-off, to confirm a unique human is present; ShieldLabs does not verify identity or humanity. It asks a narrower question: are these many wallets being operated by one person, from one device or one anonymized setup? ShieldLabs flags the farmer who passes, or skips, proof-of-personhood but still drives a hundred wallets from a single machine, so the two are often used together.

Yes. The mechanism is the same wherever one person can profit by operating many wallets or accounts, so it maps onto each surface: Crypto exchanges and trading apps: flags the multi-accounter running parallel accounts to farm welcome bonuses, fee rebates, and referral payouts; Token airdrops and points programs: flags the farmer running hundreds of wallets through the qualifying actions; Launchpads and IDO allowlists: flags one person taking many allocation slots; Quest and task platforms: flags repeated completion from one device; NFT mints: flags one person claiming many spots meant to be one per person. ShieldLabs identifies the person behind the wallets or accounts at the web layer, so the same risk score and High-Risk Events apply across every one of these flows.

Add one JavaScript snippet to your dapp, wallet-connect, exchange signup, or airdrop-claim page; integration takes about 5 minutes. The flow: Pass an optional UserHID, a hashed account or user identifier from your own system, once a user signs up or connects a wallet; Read the risk score, risk signals, and High-Risk Events on the first visit, in the analytics dashboard and via API and Webhooks for server-side flows; Test on real traffic first: the free tier includes 5,000 one-time identifications with no credit card required. ShieldLabs returns a score on the first visit and persistent identification on every visit after, so you can see results on your own traffic before rolling out to production.

ShieldLabs detects risky wallets out of the box and helps block fraudulent and abusive traffic. Each wallet connect gets a 0-100 risk score in one of three bands, plus any High-Risk Events, and you choose the action for each case: Dangerous (60-100): hold the wallet out of the airdrop or route it to manual review; Suspicious (30-59): flag the wallet for review or a reduced allocation; Trusted (0-29): let the wallet through with no extra steps. Use the free 5,000 identifications to see results on real traffic before rolling out to production. ShieldLabs stops sybil farming before the allocation goes out.