Introducing Sybil Detection: On-Chain Behavioral Analysis for Any Ethereum Address

Why Sybil Detection Matters

Sybil attacks remain one of the most persistent threats in Web3. A single actor operating hundreds or thousands of wallets can manipulate airdrops, distort governance votes, farm rewards, and undermine the trust that decentralized systems depend on.

Detecting sybils is hard because each wallet looks plausible in isolation. The signals that distinguish a human-operated wallet from a scripted one are subtle: who does this wallet transact with? How was it funded? When does it transact? Does it have any verified identity?

Today, we're launching a new endpoint that answers these questions for any Ethereum address.

The New Sybil Detection Endpoint

The Sybil Detection API is available under our Identity API:

GET /api/v2/identity/address/{address}/sybil

For any Ethereum address or ENS name, it returns a sybil score (0-100, where higher means more likely sybil), a risk level, and a full breakdown of the behavioral indicators that produced the score.

Here's what the response looks like for a well-established wallet:

{
  "address": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
  "timestamp": "2026-02-19T14:30:00+00:00",
  "sybil_score": 12,
  "risk_level": "low",
  "indicators": {
    "count_unique_counterparties": 142,
    "count_unique_contracts_interacted": 37,
    "total_gas_spent_eth": 0.847,
    "funding_source_address": "0x71C7656EC7ab88b098defB751B7401B5f6d8976F",
    "transaction_time_entropy": 0.82,
    "identity_attestations": 3,
    "wallet_age_days": 1095,
    "transaction_count": 456
  }
}

A score of 12 with a "low" risk level means this address shows strong signals of being a real, human-operated wallet. Compare that with a freshly-funded bot wallet that might score 85+ with a "critical" risk level.

What We Measure

The sybil score is computed from seven behavioral indicators, each normalized through a sigmoid function and combined with carefully tuned weights:

Identity attestations carry the highest weight because verified credentials like ENS names and Gitcoin Passport scores are expensive for sybils to fake at scale. A wallet with three attestations is far less likely to be a sybil than one with zero, regardless of its transaction volume.

Transaction Time Entropy

This is one of the most interesting indicators. Bots tend to transact at regular intervals, while humans are unpredictable. We compute the Shannon entropy of the time gaps between consecutive transactions, binned into eight time ranges (under 1 minute through 7+ days). A high entropy score means varied, human-like timing. A low score means suspiciously regular patterns.

Funding Source

We also identify the first address that funded the wallet. While not directly part of the composite score, this is invaluable for cluster analysis. If hundreds of wallets all received their first ETH from the same address, that's a strong sybil signal that your application can act on.

Risk Levels

The sybil score maps to four risk levels:

How to Use It

The endpoint costs 3 Cred Units per request (or $0.03 USDC via x402 payment). Results are cached for 30 minutes.

curl -X GET "https://api.credprotocol.com/api/v2/identity/address/vitalik.eth/sybil" \
  -H "Authorization: Bearer YOUR_API_KEY"

Real-World Use Cases

Here are five scenarios where sybil detection changes the game:

1. Airdrop Protection

You're distributing tokens to early users of your protocol. Before the drop, run every eligible address through the sybil endpoint. Flag any address scoring 50+ for manual review, and automatically exclude those scoring 75+. This prevents sybil farmers from claiming hundreds of allocations while ensuring legitimate users aren't caught in the crossfire.

import requests

def is_eligible_for_airdrop(address):
    response = requests.get(
        f"https://api.credprotocol.com/api/v2/identity/address/{address}/sybil",
        headers={"Authorization": "Bearer YOUR_API_KEY"}
    )
    data = response.json()

    if data["risk_level"] == "critical":
        return False  # Auto-reject
    if data["risk_level"] == "high":
        return None   # Flag for manual review
    return True       # Eligible

2. DAO Governance

One-token-one-vote governance is vulnerable to sybil attacks where a single actor splits tokens across many wallets to amplify their influence. Before counting votes, check the sybil score of each voter. Weight votes by sybil resistance, or require a minimum score threshold to participate.

3. DeFi Lending Risk

Combine sybil detection with credit scoring to build a more complete risk picture. A borrower operating multiple wallets to circumvent lending limits will have high sybil scores on their secondary wallets. Cross-reference the funding_source_address indicator across your borrower pool to detect linked wallets.

4. Community and Allowlist Gating

Running an allowlist for a mint, beta access, or a community channel? Require applicants to have a sybil score under a threshold. This ensures your community consists of real humans without requiring KYC or centralized identity verification.

5. Grant and Retroactive Funding Distribution

When distributing grants or retroactive rewards based on on-chain contributions, sybil detection helps ensure fair allocation. An entity that contributed from 50 wallets shouldn't receive 50x the reward of someone who contributed from one.

Combining with Credit Scoring and Identity

Sybil detection is most powerful when combined with our existing APIs:

• Sybil Detection + Credit Score: A wallet with a high credit score but a high sybil score is suspicious. Legitimate high-value wallets almost always score low on sybil risk.
• Sybil Detection + Identity Attestations: The sybil endpoint already factors in attestation count, but you can use the detailed attestation data from our Identity API to understand which credentials the address holds.
• Funding Source Clustering: Pull the funding_source_address for every address in a dataset. Wallets sharing a common funder are likely controlled by the same entity.

Technical Details

Under the hood, the endpoint analyzes Ethereum mainnet transaction data via the Etherscan API. For each address, it fetches both normal transactions and ERC-20 token transfers, then computes all indicators in parallel alongside identity attestation data.

Key implementation details:

• Mainnet only for the initial release, since Ethereum has the richest transaction history
• 30-minute cache per address to balance freshness with computation cost
• 2-5 second response time for uncached requests, near-instant for cached
• ENS resolution built in, so you can pass ENS names directly

Get Started

• Read the API Documentation
• Try it in the Playground
• Create a Free Account and get 1,000 credits monthly
• Try via x402 with no account needed

Questions or feedback? Reach out on Twitter or join our Discord.