Base Verify: onchain sybil resistance — and what Solana has instead

Base Verify: onchain sybil resistance so airdrops and gates hit real people, not farm wallets — and a map of what Solana builders use when they need the same outcome.

Base announced Base Verify Onchain for industrial airdrop farmers. The useful question for Solana teams is not “do we have Base’s brand?” — it is “can we enforce one real person, once, in the claim path?”

Click to zoom

Base Verify Onchain in one page

Official guide: docs.base.org — Verify Users Onchain. Demo: base/base-verify-demo.

Users prove ownership of a real account (X, Coinbase, Instagram, TikTok) without dumping credentials into your app. Your contract then enforces eligibility in the same transaction as claim / mint / vote.

Two jobs wallets alone cannot do:

• Sybil resistance — one real identity counts once across many wallets via a stable identityHash
• Policy gating — admit only users who meet a bar (e.g. active Coinbase One, X followers ≥ N) even if the wallet is thin onchain

Flow

1. Contract extends BaseVerifyConsumer and declares immutable provider + conditions (the policy).
2. App: user signs SIWE naming your contract → POST https://verify.base.dev/v1/onchain_verifications
3. API returns { identityHash, expiration, signature }
4. User submits that to your contract; consumer calls registry.verifyVerification(...) and you dedupe on identityHash

Base Sepolia (test phase)
  Chain ID:            84532
  API:                 https://verify.base.dev/v1
  SignerRegistry:      0x4f15593fbF7e3491d15080e1610E7AF8deBA1a02
  Consumer base:       BaseVerifyConsumer.sol

identityHash properties (per Base docs):
  • one-way — cannot recover the social account from the hash
  • per-contract — not correlatable across apps
  • cross-wallet — same person, different wallets → same hash for your contract
  • short-lived signature — submit within minutes of minting the verification

Error handling is part of the product UX: 404 verification_not_found → send user to https://verify.base.dev to OAuth; 400 conditions_not_satisfied → show “you don’t meet the bar,” don’t loop. Full matrix in the Base guide.

There is also an earlier / parallel path that keeps the token in your backend DB (unique on baseVerifyToken) — see the demo README. Onchain mode is the “no claim-time backend” variant.

Does Solana have a comparable?

No drop-in twin of Base Verify Onchain as a first-party L1 product wired to Coinbase + social OAuth + BaseVerifyConsumer-style registry. Solana’s identity layer is plural: several products and patterns that hit the same outcomes when composed correctly.

Comparison table

Solana options that actually ship

1. Civic Pass (gateway) — closest productized gate

Civic’s long-running Solana surface is a gateway / Pass: user completes a check (CAPTCHA, uniqueness, or other gate types depending on product config), receives an onchain Pass, and your program or client refuses actions without a valid Pass.

• React helper historically: @civic/solana-gateway-react
• Pattern: wrap claim UI so the gateway token / Pass must be present before the stake/claim instruction

Note: Civic’s public docs today heavily emphasize Civic Hub / Auth for agents. For airdrop Sybil work, treat Civic Pass as the web3 gate lineage and confirm current Pass product status in their dashboard before mainnet dependence. Outcome match: uniqueness + policy gate, not Coinbase-social identityHash.

2. World ID — strongest “personhood” bar

World ID is proof-of-personhood (Orb + ZK). Your app verifies a proof with a nullifier so the same human cannot claim twice. That is the closest philosophical match to “one real person” — biometric/personhood rather than “has a Coinbase or X account.”

Integration is usually: verify proof offchain or via a verifier, then either store a claim marker on Solana or have a program verify a wrapped proof/attestation. Check World’s current chain/verifier support for Solana before designing the onchain half — the personhood guarantee is the product; Solana is the settlement/claim rail.

3. Custom attestation program — DIY identityHash

Closest architecture clone of Base’s onchain path:

1. User completes OAuth / KYC / Passport score offchain
2. Your signer (or a trusted attester) signs:
     (wallet, identity_id_hash, policy_id, exp)
3. Program verifies ed25519/secp signature (or stores attester-written PDA)
4. Claim instruction:
     - check signature/PDA valid
     - check identity_id_hash not in claimed set
     - mark claimed + pay out

You reinvent Base’s registry + policy binding. Worth it when you need Solana-native settlement and control the trust root. Cost: key management, audit, and UX for re-auth when credentials expire.

4. Score / stamp systems (Passport-class)

Gitcoin / Human Passport-style stamps and model scores are strong as inputs to a gate (“score ≥ 20 or pass stamp X”). Enforcement is almost always: API or indexer → allowlist / attestation → Solana claim. Base has been a heavy Passport ecosystem home historically; on Solana you still use the score as an offchain oracle unless you bridge the result onchain.

5. Distribution layer ≠ identity layer

Merkle distributors and Streamflow airdrops (Streamflow programs article) solve “pay N wallets efficiently.” They do not prove one human. Farmers love clean merkle trees. Correct stack:

identity gate  →  eligibility set / nullifier / Pass
        ↓
merkle / Streamflow distributor  →  claim UX
        ↓
optional: withdraw vesting stream

6. Weak alone: wallet heuristics

Account age, tx count, SOL balance, NFT bags — farmers grind all of it. Fine as a soft filter, never as your only anti-Sybil control for real money.

What to pick on Solana

Builder sketch: Solana “identityHash” claim

// Pseudocode — pattern only
// 1) Backend after successful OAuth / Pass / World ID verify:
const identityHash = sha256(provider + ":" + stableSubjectId + ":" + appId)
const exp = now + 5 * 60
const msg = encode([wallet, identityHash, policyId, exp, action])
const sig = attester.sign(msg)

// 2) Client sends claim ix with (identityHash, exp, sig, merkle proof…)
// 3) Program:
//    - ed25519 verify attester
//    - exp > clock
//    - policyId matches this campaign
//    - identity_claimed PDA seeds = [b"id", campaign, identityHash] empty
//    - create identity_claimed + pay tokens

That is Base’s identityHash idea with your keys and your program. Audit the attester like a bridge operator.

Resources

• Base — Verify Users Onchain
• Base — Verify Social Accounts (offchain/app path)
• base/base-verify-demo
• @buildonbase announcement
• World ID docs
• Civic docs
• Streamflow programs (distribution)

Bottom line

Base Verify Onchain is a clean, first-party answer: social/exchange credential → short-lived signed verification → contract dedupe on identityHash. Solana does not ship that exact product, but it does ship the pieces for comparable outcomes — Pass-style gates, personhood proofs, attester programs, and serious airdrop distributors. Build the identity gate first; only then wire Streamflow or a merkle claim. Farmers scale wallets. They do not scale humans — if your program actually counts humans.