DEV Community: KeepFlow

Sybil attacks on airdrops: up to 80% of participants are bots

KeepFlow — Mon, 08 Jun 2026 10:52:12 +0000

That's the real picture in 2026. Not a worst-case scenario — the baseline expectation for any unprotected token launch.

A token launch costs the project millions: marketing, distribution, infrastructure, team time. And most of it goes not to real users, but to farming operations.

How a farming operation is actually structured:

→ Operator rents 10K+ devices (anti-detect browsers running in cloud infrastructure) → Each runs a separate wallet with pre-warmed activity history → Fake names, purchased KYC documents, automated social task completion → After distribution — sell tokens immediately, move to next airdrop

This isn't a hobby. It's a $100M+ industry with dedicated teams, infrastructure providers, and a secondary market for "warmed" wallets.

What doesn't work:

→ KYC — farmers buy real identity data on the darkweb or use KYC-as-a-service → Wallet age requirements — pre-warmed months before launch, sometimes years → Social tasks (follow, retweet, join Discord) — automated by scripts, or done by $0.10/task labor → On-chain reputation (Gitcoin Passport, BrightID) — useful, but farmers buy aged accounts on secondary markets

What works: device fingerprinting + cross-wallet linking.

When the system sees 1,000 wallets being created from 50 devices — that's a clear signal no amount of wallet warming can hide. Even the most expensive farming operation is bottlenecked by physical device count.

Real case: NFT collection airdrop, 47,000 wallet connect attempts in the first hours of launch. 12,000 linked via device fingerprint into clusters. Largest cluster: 1 device created 480 wallets in 90 minutes.

Final result: 92% of airdrop went to unique real users. $340K worth of tokens saved at post-launch price.

Critical for Web3: no mandatory KYC required. Just proof-of-uniqueness via device. Composability with on-chain reputation systems is preserved. No identity-verification UX that gates out real users.

The math protocol teams need to run:

→ If your airdrop distributes $5M in tokens and 80% goes to farmers → $4M wasted → The community feels cheated, the token has worse price discovery, real supporters get diluted

If your next airdrop loses 80% to farmers, the failure isn't the airdrop. The failure is launching without Sybil resistance and pretending it's an even distribution.

Discover how Tracio helps protocols identify Sybil attacks without adding KYC friction.

The complete guide to bot detection for iGaming operators

KeepFlow — Tue, 26 May 2026 10:45:32 +0000

Bot detection in iGaming is different from bot detection in any other industry. The stakes are higher (regulated money flows), the adversaries are more sophisticated (professional farming operations), and the tolerance for false positives is lower (blocked legitimate players churn fast and complain loudly).

This guide covers what actually works in 2026 — across signup, gameplay, bonus claim, and withdrawal. It's written for product, operations, and risk teams at operators that have moved past "we'll figure it out later."

The threat landscape

iGaming operators face four overlapping bot categories. Each requires different detection strategies.

Category 1: Account creation bots. Mass-register fake accounts to claim welcome bonuses, abuse promo codes, or build inventory for later resale. Typically run from anti-detect browsers in cloud infrastructure. The cheapest and highest-volume attack pattern.

Category 2: Gameplay bots. Automated betting on math-edge games (some sportsbook props, certain casino variants). The bot identifies positive-EV scenarios and bets at machine speed. Rare but expensive when present.

Category 3: Collusion and chip dumping bots. Coordinate multiple "players" at the same poker table to dump chips to one account. Often combined with manual operators directing the bot fleet.

Category 4: Scraping and data extraction bots. Pull odds data, line movements, or game state for resale to syndicates. Don't directly cost money but enable other forms of fraud at scale.

The first category is the volume play — 80%+ of bot traffic by raw count. The others have lower volume but higher per-incident cost.

Why traditional defenses fail in iGaming

Standard anti-bot approaches that work in other industries break down in iGaming:

CAPTCHA fails on UX grounds. iGaming has the lowest tolerance for friction of any industry. A 5-second CAPTCHA delay measurably reduces conversion at signup and bet placement. Operators that deployed CAPTCHA at high-stakes flows generally rolled it back within a quarter.

IP-based blocking fails on geo-routing. Players legitimately use VPNs (privacy, accessing operators in licensed jurisdictions). Bot operators also use VPNs. The IP layer can't distinguish them.

KYC document verification catches the lazy 30%. Sophisticated bot operations use real documents — purchased from data markets, family members' documents, KYC-as-a-service operations. Documents pass verification while the underlying identity is still synthetic.

Behavioral velocity rules catch only the dumbest bots. Modern bots deliberately throttle to mimic human pace. They've trained on what gets flagged and adapted.

Static fingerprinting libraries get reverse-engineered. Anti-detect browser vendors specifically target fingerprinting tools and patch their products to spoof correct values. Within 30 days of any major detection library update, evasion is back to near-100% effectiveness.

The pattern: single-layer defenses are systematically defeated by professional adversaries. Multi-layer defenses are required to maintain effectiveness.

The layered detection model

Modern iGaming bot detection works across five layers, each catching different attack patterns:

Layer 1: Network signals (server-side). TCP/TLS fingerprinting, ASN reputation, request timing patterns. Critical for catching cloud-infrastructure attacks regardless of client-side spoofing. Server-side signals are the foundation because they're hardest to fake.

Layer 2: Device characteristics (client-side). Canvas rendering, WebGL signatures, audio fingerprinting, hardware concurrency, sensor data on mobile. Multiple probes with coherence checks between them.

Layer 3: Behavioral patterns. Mouse movement entropy, keystroke dynamics, scroll behavior, form-fill timing. Real humans have natural variance that's hard to fake organically.

Layer 4: Environmental coherence. Cross-layer consistency checks. Does the claimed UA match the WebGL renderer? Does the audio fingerprint match the browser/OS combination? Does the network signal align with the claimed location?

Layer 5: Cross-account device linking. Has this device been seen at other accounts on your platform? Has it been seen at other operators (via anonymized cross-customer signal sharing)? Building the device-to-account graph is where multi-accounting detection lives.

**The key insight: **any individual layer can be defeated. Defeating all five layers coherently is dramatically harder. The detection power comes from the combination, not from any single signal.

Deployment points in the iGaming flow

Where you place detection matters as much as what detection you deploy. Five deployment points in the typical iGaming flow:

Signup. Capture device fingerprint, check against known fraud clusters, evaluate cross-account linking. Goal: prevent fake account creation before welcome bonus is claimable.

Bonus claim. Re-verify at the moment of claim. Goal: catch accounts that passed signup verification but show signs of being part of a farming cluster (3rd+ account from same device, behavior patterns matching abuse cohort).

Bet placement. For competitive games and high-stakes bets, verify device authenticity in real-time. Goal: catch gameplay bots before bets are accepted.

Withdrawal. Final verification before money leaves the platform. Goal: catch fraud that slipped through earlier layers, including changes in device patterns that suggest account compromise.

Each deployment point uses the same underlying detection infrastructure but with different rule weights. The signup deployment cares heavily about cross-account linking. The withdrawal deployment cares about behavioral consistency (does this withdrawal flow match the player's historical patterns).

The bonus abuse detection pattern

Bonus abuse is the highest-volume problem for most operators. The detection pattern that works:

Pre-claim check at signup. If the device fingerprint has been seen on 2+ previously bonused accounts in the last 90 days, deny the welcome bonus eligibility immediately.

Behavioral verification at claim. Genuine players have varied behavior patterns. Bonus abusers tend to follow scripts: claim → meet minimum wager → withdraw → next account. The pattern is statistically detectable across the lifecycle.

Network proximity check. Multi-account farms route through similar IP infrastructure even when individual IPs differ. Same ASN, same /24 subnet, same VPN exit nodes appearing across accounts is a strong cluster signal.

Cross-operator signal sharing. A device fingerprint flagged as abusive at one operator can be flagged at others via anonymized cross-customer signals. This is where industry collaboration pays off.

Real result from a mid-tier operator: 78% reduction in bonus abuse incidents over 90 days. Welcome bonus cost-per-acquisition dropped 22% because the same marketing spend now reached more unique players instead of multi-accounts of existing ones.

The collusion detection pattern

Collusion is harder than bonus abuse because the attackers want to look like normal players for most of their activity. Detection has to identify coordinated patterns across multiple accounts that individually look fine.

Device cluster detection. Even with anti-detect browsers, coordinated colluders often share infrastructure characteristics: same hosting provider, same time-of-day patterns, similar device fingerprint clusters with small deliberate variations.

Behavioral synchronization. Real players act independently. Colluders coordinate. Detection looks for patterns like: same player joins poker table within 30 seconds, same betting cadence, action timing that suggests external coordination.

Transactional analysis. Money flows reveal collusion that behavioral analysis misses. Player A consistently loses to Player B at high stakes. Player C deposits, plays one hand, loses all to Player D, withdraws. Patterns invisible at individual-player level become obvious at network level.

Cross-table device linking. When the same device fingerprint appears at the same table under different accounts, the case is closed regardless of behavior.

This detection is more compute-intensive than bonus abuse — it requires building and analyzing the player-interaction graph in near-real-time. But the per-incident financial impact justifies the investment.

The integration architecture

Practical deployment looks like this:

Player action (signup / login / claim / bet / withdraw)
↓
Frontend SDK collects device fingerprint (~50ms)
↓
Backend verify-call to detection service (~50ms)
↓
Verdict returned: ALLOW / CHALLENGE / BLOCK
↓
Operator system applies verdict:
ALLOW → proceed normally
CHALLENGE → step-up verification (SMS, email, biometric)
BLOCK → deny action with audit trail

The latency budget is tight in iGaming. Bet placement can't wait 200ms. Detection systems that don't fit a 50ms latency budget are non-starters for in-game deployment.

The verdict logic on the operator side should be tunable per deployment point. Withdrawal can tolerate stricter rules (false positive customer asks "why was my withdrawal delayed" and you explain). Bet placement requires looser rules (false positive customer doesn't make their bet and churns).

Metrics that matter

Bot detection effectiveness should be measured across these dimensions:

True positive rate. % of actual bots correctly blocked. Hard to measure directly because you don't always know what was a bot. Best measured via cohort analysis: do blocked accounts subsequently show patterns confirming they were bots (chargeback rate, post-block evasion attempts, etc.)?

False positive rate. % of legitimate players incorrectly blocked. Critical metric. Industry benchmark: <0.5% false positive rate is acceptable. Above 1% causes meaningful churn from legitimate frustrated players.

Detection latency. Time between bot account creation and detection. Real-time detection (sub-second) is the gold standard. Same-day detection is acceptable for some categories. Anything slower means money has already left.

Coverage by attack pattern. Different attack categories require different detection. Measure separately: bonus abuse detection rate, gameplay bot detection rate, collusion detection rate, scraping detection rate.

Operator cost per detection. Total cost of detection infrastructure / number of bots caught. This metric correlates with vendor selection and rule tuning quality.

Common deployment mistakes

Five mistakes operators make that prevent effective bot detection:

Mistake 1: Deploying only at one stage. Operators sometimes deploy at signup only and skip later stages. Sophisticated attackers route around signup detection by buying aged accounts from secondary markets. Multi-stage deployment is necessary.

Mistake 2: Treating false positives as acceptable. "Some legitimate players will be inconvenienced" is the easiest concession to make in fraud prevention. It's also the most expensive in the long run. Each false positive is a real customer with a real LTV walking out.

Mistake 3: Not auditing detection rules quarterly. Bot operators adapt. Rules that worked 6 months ago may be missing the current attack patterns. Detection logic needs ongoing tuning, not set-and-forget configuration.

Mistake 4: Skipping cross-customer signal sharing. Operators that operate in isolation miss intelligence that cross-customer networks provide. Sharing anonymized fingerprint signals across operators is industry-standard in 2026 — operators not participating are at a competitive disadvantage.

Mistake 5: Optimizing for catch rate at the expense of player experience. A detection system that catches 99% of bots but adds 200ms latency to every bet is worse than one that catches 92% with no latency impact. Player experience is the constraint to design within.

Vendor selection criteria

When evaluating bot detection vendors, the questions that matter most:

→ What's your detection coverage by attack category? Vendors that excel at credential stuffing may be weak at multi-accounting. Match capabilities to your highest-priority threats.
→ What's your latency at our scale? P99 latency under load is the real test, not marketing benchmarks.
→ How do you handle anti-detect browsers specifically? This is the iGaming-specific question. Generic answers ("we have ML") suggest weak capability. Specific answers (polymorphic code, server-side coherence checks, behavior modeling) suggest serious capability.
→ What's the false positive rate at customer deployments similar to ours? Get specifics. Industry benchmark <0.5%. Anything higher is concerning.
→ How does cross-customer signal sharing work? Does it preserve privacy? Is it opt-in? How fast do signals propagate?
→ What's the integration timeline? Days vs months indicates platform maturity.

Pricing matters but should be secondary. The economic gap between effective and ineffective detection at iGaming scale dwarfs any pricing differences between vendors.

The bottom line for operators

Bot detection at iGaming is not a problem you solve once and forget. It's an ongoing capability that needs investment, measurement, and iteration.

The operators winning in 2026 treat bot detection as a core competency, not a vendor checkbox. They measure detection effectiveness, tune rules quarterly, participate in cross-operator intelligence networks, and treat false positive rates as a customer experience metric.

The operators losing in 2026 deployed something three years ago, declared the problem solved, and haven't audited it since. They're bleeding money to evolving attack patterns and don't know it.

If you're in the second category, the first step is a detection audit. The second step is vendor evaluation with the criteria above. The third step is staged deployment across signup, claim, login, and withdrawal points.

The total investment is meaningful but the ROI is consistently 10–100× in the first year for operators above $10M GGR. The math doesn't favor inaction.

Want to audit your current bot detection stack?
See how Tracio helps iGaming operators identify sophisticated fraud patterns in real time — with low latency and low false positives.

How much money are you losing to fraud? A quick calculator.

KeepFlow — Tue, 19 May 2026 10:04:43 +0000

Most business owners massively underestimate fraud losses — because they've never measured them. The number is hidden across line items, support tickets, marketing reports, and chargebacks. Nobody owns it. Nobody sees the total.

This calculator gives you a fast estimate. Spend 5 minutes with it. The result usually surprises people.

Step 1: Pick your category

Fraud math is vertical-specific. Pick yours.
iGaming / online gambling: bonus abuse, multi-accounting, collusion FinTech / lending: account takeover, synthetic identity, loan stacking E-commerce: promo abuse, returns fraud, card-not-present fraud Crypto / Web3: Sybil attacks, airdrop farming, KYC bypass AdTech / publishers: click fraud, impression fraud, conversion fraud SaaS: free tier abuse, trial abuse, account sharing

Step 2: Industry benchmarks

These are conservative estimates from published research and real customer data:

iGaming: → Bonus abuse: 5–15% of bonus budget → Multi-accounting: 15–40% of new signups → Collusion (poker products): 1–3% of revenue → Total impact: 8–20% of revenue

FinTech: → ATO: 0.5–2% of active accounts per month → Synthetic identity (loan products): 5–10% of portfolio → Loan stacking: 2–5% of approved loans → Total impact: 3–10% of revenue

E-commerce: → Promo abuse: 5–10% of discount budget → Returns fraud: 5–10% of total returns → Card-not-present fraud: 0.3–1% of transaction volume → Total impact: 3–8% of revenue

Crypto/Web3: → Airdrop farming: 50–80% of distribution → Sybil attacks: highly variable → Total impact: massive variance, use-case dependent

AdTech: → Click fraud: 15–25% of paid clicks → Impression fraud: 10–20% of impressions → Conversion fraud: 10–30% of affiliate-driven conversions → Total impact: 15–30% of ad spend

SaaS: → Free tier abuse: 20–40% of free signups → Trial abuse: 30–60% of trial signups → Total impact: 5–15% of potential revenue

Step 3: Quick calculation

Take your relevant number from above. Multiply by the conservative end (the lower bound).

Example for an iGaming operator with €4M annual bonus budget: → €4M × 5% (low end) = €200K/year minimum loss → €4M × 15% (high end) = €600K/year realistic loss

Example for a FinTech with $100M loan portfolio: → $100M × 5% synthetic identity exposure = $5M/year potential loss → Even 50% catch rate at device layer = $2.5M/year saved

Example for an e-commerce with $5M/month revenue: → $5M × 5% promo abuse = $250K/month → Annual: $3M lost to promo abuse alone

Step 4: Hidden costs people miss

The numbers above are direct losses. Add the hidden costs:

→ Customer support time on fraud-related tickets (10–20% of total ticket volume) → Chargeback fees ($15–25 per chargeback, plus the lost goods) → Brand damage when fraud victims blame your business → Opportunity cost of fraud-fighting team → Compliance penalties (in FinTech especially)

These hidden costs typically add another 30–50% to the direct loss number.

Step 5: Compare to defense cost

Tracio pricing: → Plus: $99/month = $1,188/year (50K verifications/month) → Business: $499/month = $5,988/year (250K verifications) → Enterprise: custom from there

Realistic catch rate for a properly deployed device intelligence layer: 60–80% of attempts.

Cost-savings ratio examples: → iGaming operator with €400K/year bonus loss: spend €6K, save €280K. Ratio: 47×. → FinTech with $2.5M/year synthetic identity exposure: spend $6K, save $1.5M+. Ratio: 250×. → E-commerce with $3M/year promo abuse: spend $6K, save $1.8M. Ratio: 300×.

These are conservative. Most customers see 100×+ ROI in the first year.

Why most businesses skip this calculation

Three reasons fraud loss stays invisible:

→ It's spread across multiple line items — no single number ever shows up in dashboards → "Fraud" is everyone's problem and nobody's problem (operations blames marketing, marketing blames finance, finance blames compliance) → Teams without dedicated fraud expertise default to assuming "it's under control"

The honest answer for most businesses: it isn't under control. You just haven't measured it.

What to do with the number

If your calculated loss is over $50K/year: → Investment in device intelligence pays for itself in the first quarter → Build a business case, get budget approved, deploy

If between $10K–$50K/year: → Edge case. Worth doing, but ROI is months instead of weeks → Start with free tier (2,500 verifications/month) to validate the calculation

If under $10K/year: → You're either very small or measuring wrong → Most teams underestimate by 5–10×. Re-check with broader categories included.

Bottom line

The cost of inaction is typically 5–10× cost of solution. The question isn't "should we invest in fraud prevention" — it's "how fast can we deploy."

Talk to your team about doing this calculation honestly. If the answer is "we don't actually know," that's the data point worth acting on.

How polymorphic fingerprinting beats anti-detect browsers in 2026

KeepFlow — Wed, 13 May 2026 10:18:31 +0000

Anti-detect browsers let one user appear as 100 different ones. Each "profile" gets its own canvas fingerprint, WebGL signature, fonts list, time zone, screen resolution. For farming operations, they're tool #1.

The fundamental problem with traditional fingerprinting in 2026: static JavaScript code is easily studied. Anti-detect vendors reverse-engineer it within a week and patch their products to return "correct" answers to specific probes. The detection vendor responds with new probes, the anti-detect vendor patches again. The defender always plays catch-up.

Polymorphic fingerprinting changes this dynamic.

The polymorphic approach

Instead of one JS file with 1,200 checks, polymorphic fingerprinting works like this:

A pool of 50–100+ variants for each check
Each client gets a unique combination on page load (rotating daily)
Function names, variable names, check order — all randomized
Anti-debugger traps on critical functions
Code obfuscation + minification — unreadable for static analysis

What this gives you:

→ Anti-detect vendors can't patch against all variants simultaneously — they'd have to maintain 50× the patches → Reverse engineering requires dynamic analysis of every client load → The window for evasion effectiveness shrinks from months to days

The shift in dynamic matters more than any single technical detail. In a static-code world, an evasion that works today works for months. In a polymorphic world, today's evasion expires by next week. Farming operations stop being profitable when the cost of staying ahead exceeds the value extracted.

Server-side coherence checks

Polymorphic code is only half the answer. The second half is server-side validation.

Some computations happen on the client (for speed), but critical decisions are confirmed on the server with coherence checks between probes.

Example: if probe A says "Chrome 120 on macOS" but probe B computes a timing pattern typical of Chrome 95 on Linux — that's an inconsistency. The server flags it.

Anti-detect browsers can spoof individual signals consistently, but maintaining coherence across 1,200 signals — including ones that depend on real GPU computation, real network behavior, real OS-level APIs — is much harder than spoofing 50 well-known canvas/WebGL probes.

What anti-detect browsers can't fake well

Five categories where evasion remains hard:

WebGL renderer fingerprinting. Real GPUs produce floating-point patterns that are hard to fake pixel-perfect. Anti-detect tools approximate, but coherence checks across multiple WebGL operations catch the seams. Render the same scene twice with slightly different parameters — real GPUs return mathematically consistent results, emulators drift.
Audio fingerprinting via AudioContext. Most anti-detect browsers return slightly off values that can be detected statistically. The signal is small per-probe but compounds across multiple measurements.
Performance API timing. Real devices have natural variance in operation timing — JIT compilation cycles, garbage collection, OS interrupts. Emulators render this too "flat." The variance pattern itself becomes a fingerprint.
WebRTC leaks. Even with VPN, you can catch real local IP via STUN requests in some configurations. Most anti-detect tools handle this, but inconsistencies between WebRTC and other network signals are common.
Behavioral signals. Anti-detect doesn't simulate mouse and keyboard organically. Behavior comes from scripts, which are easier to detect than humans. Real human input has jitter, hesitation, correction patterns that scripts don't reproduce naturally.

What this means for fraud teams

For a fraud team deploying this stack: you don't need to manually catch every evasion technique. The combination of polymorphic code + server-side coherence + behavioral biometrics raises the bar high enough that most farming operations move to easier targets.

The economics matter. A Multilogin license costs $99–199/month. An anti-detect browser farm with 1,000 profiles costs $5K–10K/month in infrastructure plus tool fees. If your defense forces them to update evasions weekly instead of monthly, you've quadrupled their operational cost. At some point, attacking your platform stops being worth it.

That's the goal. Not 100% prevention — that's not achievable. The goal is making yourself expensive enough that fraudsters move to softer targets.

What this means for security researchers reading this

Yes, dedicated effort can still evade. Polymorphic fingerprinting raises the cost, doesn't eliminate it. But raising the cost is the whole point of fraud prevention.

Specific areas where research is active:

→ Automated polymorphic-aware evasion (machine learning approaches to dynamically rewrite spoofing logic) → AI agents that don't need to spoof — they really run in real browsers, so device signals are genuine → Hardware-rooted fingerprinting using TEE (Trusted Execution Environment) — the next frontier where even anti-detect browsers can't lie

The arms race continues. Polymorphic is the current state-of-the-art on the defender side. Within 24–36 months, expect attackers to have automated polymorphic-evasion tools. The defender's response will likely involve hardware attestation.

In customer data

Across 2025 deployments at scale, anti-detect-driven fraud attempts dropped 73% year-over-year on protected flows. The pressure is working. Not eliminated — never eliminated — but materially reduced.

For teams running into anti-detect browser issues in production: the core lesson is to stop relying on static probes. Polymorphic + multi-layered + server-side is the only architecture that holds up against well-resourced adversaries.

If you're still on a static-code fingerprinting solution, your evasion problem is structural, not tactical. Switching tools or adding more probes won't help. The architecture itself needs to rotate.

That's the shift the industry is making in 2026. The question for your team isn't whether — it's how fast you make the switch before your fraud losses force the conversation.