Sybil protection bypass via delete then re claim + frontend/backend status code mismatch

[Sertug17]

---

Summary

Two bugs found in the sybil protection and verification flow:

Bug 1 (Critical): Delete-then-re-claim bypasses anti-sybil protection

The delete-airdrop endpoint removes a user's record from the database, but does not track the verification token afterwards. This allows a user to claim the airdrop multiple times with different wallets using the same verified social account.

Steps to reproduce:

1. Connect Wallet A → verify X account → get token abc123 → claim airdrop ✅
2. Call POST /api/delete-airdrop with Wallet A's signature → record deleted ✅
3. Connect Wallet B → verify the same X account → get the same token abc123
4. POST /api/verify-token → findUnique({ where: { baseVerifyToken: "abc123" } }) returns null (old record was deleted)
5. Upsert creates a new record with Wallet B's address and token abc123 ✅
6. User claims the airdrop again with a different wallet 🎉

Affected file: pages/api/verify-token.ts (lines 83-103) — the token uniqueness check only looks at existing records, not deleted ones.
Affected file: pages/api/delete-airdrop.ts (whole file) — deletes without tracking the token.

Impact: The core anti-sybil mechanism described in the README ("Same provider account always produces same token → Database rejects duplicate tokens → prevents multi-wallet abuse") is completely bypassable. A user can claim the airdrop N times with N different wallets using the same social account.

Suggested fix: Add a DeletedToken table (or a deleted_tokens set) that tracks tokens from deleted claims. On re-verification, check both the existing records AND the deleted-token list before allowing a new claim.

---

Bug 2 (Minor): Frontend checks for HTTP 400, backend returns HTTP 412

In pages/index.tsx, the frontend checks for response.status === 400 to show a "traits not satisfied" error message:

typescript
// pages/index.tsx (frontend)
if (response.status === 400 && errorData.message === 'verification_traits_not_satisfied') {
setVerificationError('Sorry, your X account does not have a blue checkmark...')
}

However, in pages/api/verify-token.ts, when the Base Verify API returns a 400 with verification_traits_not_satisfied, the backend maps it to HTTP 412 (Precondition Failed):

typescript
// pages/api/verify-token.ts (backend)
if (verifyResponse.status === 400) {
const errorData = JSON.parse(responseBody);
if (errorData.message === 'verification_traits_not_satisfied') {
return res.status(412).json({ // <-- 412, not 400
error: 'X account does not satisfy verification requirements.'
});
}
}

Impact: The error handling branch for "traits not satisfied" is dead code on the frontend. Users who don't meet trait requirements see a generic error message instead of the helpful "no blue checkmark" message.

Suggested fix: Change the frontend check from response.status === 400 to response.status === 412, or change the backend to return 400 instead of 412.

---

[tusar222]

Lol

[Kanhaiya911]

Repo

[osr21]

Confirming both bugs from reading the current source — this deserves attention ahead of the meme replies above. Bug 1 in particular matters beyond this repo: this is the reference demo for Base Verify, and its README explicitly advertises the anti-sybil invariant that the delete path breaks. Anyone using this as a production template inherits the bypass.

On the suggested fix for Bug 1 — a simpler invariant than a DeletedToken table

The root problem is that the schema treats the wallet record as the claim, when the deterministic verification token is the actual anti-sybil identity. Since the same social account always produces the same token, the token — not the wallet — is the correct permanent claim key.

That suggests a cleaner fix than tracking deletions:

1. Never hard-delete claim history. Make delete-airdrop a soft-delete: null out / disassociate the wallet fields but keep the row with baseVerifyToken and a claimedAt timestamp intact. The uniqueness check in verify-token.ts then works unchanged — findUnique({ where: { baseVerifyToken } }) still finds the row and rejects the re-claim.
2. This avoids the failure mode of a separate DeletedToken table: two sources of truth that every future code path must remember to check. The bypass exists precisely because one code path (delete) didn't coordinate with another (verify) — adding a second table reintroduces that same coordination burden for every future endpoint.

If hard deletion is genuinely needed (e.g. data-removal requests), the deletion should retain only a salted hash of the token in a tombstone table — but for an airdrop demo, soft-delete is simpler and preserves the invariant by construction.

On Bug 2 — recommend fixing the frontend to check 412 rather than changing the backend to 400. The backend's 412 mapping is semantically right (the precondition — trait requirements — failed) and keeps the "traits not satisfied" case distinguishable from generic 400 validation errors. Changing the backend to 400 would force the frontend to disambiguate via the error message string, which is the fragile pattern that caused this dead-code branch in the first place.

Context for the interest here: we're onboarding BasePay Mini to Base Verify for exactly this kind of claim gating, so the delete-then-reclaim pattern is one we'll need to defend against too. The takeaway we're applying: treat the deterministic token as the permanent claim key and make claim history append-only; wallets are replaceable attachments to a claim, never the claim itself.