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.
Supported Providers
Base Verify supports verification through multiple providers, including:
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:
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.