Suggested README.md Fix

Supported Providers

Base Verify supports verification through multiple providers, including:

- X / Twitter
- Coinbase
- Instagram
- TikTok

This repository is a demo application showing how Base Verify can be used to protect an airdrop or gated feature. The default "/api/verify-token" flow demonstrates X verification with a "verified:true" trait requirement. Builders who want to support Coinbase, Instagram, or TikTok should configure the expected provider and trait requirements in their backend before calling the Base Verify API.

«Note: This demo does not represent a live or official token claim. It is intended as an integration reference for builders.»

---

Claim Scope and Sybil Resistance

Base Verify returns deterministic verification tokens that can help prevent duplicate claims from the same verified provider account.

For example:

Wallet A verifies the same X account → receives Token: abc123
Wallet B verifies the same X account → receives Token: abc123
Database sees Token: abc123 already used → duplicate claim is blocked

This protects against the same provider account being reused across multiple wallets.

However, verification tokens are provider-scoped. A token for an X account is not the same as a token for an Instagram, TikTok, or Coinbase account. Because of this, token uniqueness alone should not be described as global “one human = one claim” protection across all providers.

Builders should clearly define their campaign claim policy:

Option A: One claim per verified provider account

Use this when each provider account is treated as a separate eligibility source.

Recommended database rule:

model VerifiedUser {
id String @id @default(cuid())
address String @unique
provider String
baseVerifyToken String @unique
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt

@@unique([provider, baseVerifyToken])
@@map("verified_users")
}

Option B: One claim per campaign participant

Use this when the campaign should allow only one claim per user, even if that user verifies multiple providers.

In this case, builders should not rely on provider-scoped token uniqueness alone. They should enforce an additional campaign-level claim rule, such as:

- Choosing one required provider for the campaign
- Storing a campaign claim record after the first successful verification
- Blocking additional claims from the same wallet
- Adding extra eligibility checks if cross-provider duplicate prevention is required

---

Why This Matters

Base Verify provides strong provider-level Sybil resistance, but the final claim policy belongs to the application.

Correct wording:

Base Verify helps prevent duplicate claims from the same verified provider account across multiple wallets.

Avoid wording like:

One verified account = one person = one global claim across every provider.

Provider-scoped tokens are powerful, but they should be documented accurately so builders do not accidentally overstate their anti-Sybil guarantees.

Review README.md and compare its current provider and claim-policy descriptions with the proposed text in this issue. Update the documentation so provider-scoped token behavior and campaign-level claim rules are described accurately, including the warning about cross-provider guarantees. Done means the README clearly distinguishes provider-level duplicate prevention from one-claim-per-participant policies.

Written by the indexing model from the issue text.