Waitlist Fraud: Move Queue Logic to the Server or Lose the Queue

A waitlist with a referral reward is a game with a prize. That's not cynical; it's what happens when you attach value to a countable action. As soon as the prize is worth anything, some people will try to win it cheaply.

Founders usually respond by adding checks: a disposable-domain blocklist here, a captcha there. Those help at the edges, and none of them fix the real weakness.

The weakness is location. Any queue logic that runs in the visitor's browser is both wrong and editable, so move all of it to the server. Do that and the three common attacks mostly reduce to a rate-limiting problem, which is a solved one.

Three attacks account for most of it

Each has a different fix, and founders tend to defend only against the first.

Self-referral farming. A subscriber opens their own referral link in a private window, signs up with a throwaway address, and repeats. No technical skill required, which is why it's the one that actually happens.

List flooding. Someone scripts large numbers of signups against your page. Your count looks great and your list is worthless. If you pay per contact anywhere downstream, it's also expensive.

Position squatting. Someone opens the network tab, sees that position is sent by the browser, and asks to be number one. This one is purely an implementation mistake.

The first and third are only possible because a decision that belongs to the server was handed to the browser.

Nothing about the queue may be computed in the browser

This is the whole defense; everything else is refinement.

Position, duplicate detection, referral credit and plan limits all need the full subscriber list for a page. A browser has exactly one row: its own submission. Logic placed there works from a sample of one, which makes it wrong before it's even insecure.

The security consequence follows: code on the visitor's machine is code the visitor can edit. A position computed in the browser is a position the visitor chooses.

In practice, the signup handler should accept an email, a page ID and an optional referral code, and nothing else. If your request body contains a position, a referral count or a status, the queue is already compromised.

Once that holds, flooding becomes a rate-limiting problem. Qubed allows at most five signups per minute and thirty per hour from one IP address, and adds a hidden honeypot field that catches simple bots.

Make self-referral impossible, not just checked

The tempting fix is a comparison: reject if the referrer matches the new subscriber. That works until someone refactors the handler and drops the check.

The structural version comes from ordering. Resolve the referrer before creating the new subscriber. The referrer must already exist; the new row doesn't yet. No sequence of operations lets a row refer itself, so there's no check to forget.

Scope referral codes to the page they belong to, for the same reason. An unscoped lookup lets a code from any list on the platform count against yours.

Enforce uniqueness in the database, not just in code. A unique constraint on page and email rejects duplicates even when two requests arrive at once, where an application check has a race window.

Keep the queue reversible, or fraud becomes permanent

If a referral overwrites the referrer's stored position, the original join order is gone. You can never undo a fraudulent referral, change the boost, or rebuild what the queue should have been.

Store join order as its own value and derive the effective position from it: join order minus referrals times the boost, never below one. A bad referral becomes a subtraction you can reverse. It also makes the boost a setting rather than a permanent commitment, which matters because the boost size is a judgment call.

Watch two signals, and don't auto-ban

Two patterns catch most of what gets past the architecture: a burst of signups from one network in a short window, and a referrer whose count jumps in a step rather than a curve.

Neither should trigger an automatic ban. A false positive costs you a real subscriber and starts a support conversation with an accusation. Flag, look, then act by hand.

Start on a referral waitlist that already does this. Every Qubed page works out positions, duplicates and referral credit on the server, rate-limits signups per network, scopes referral codes to your page and stores join order separately so your queue stays reversible. That's true for every template on every plan, from the crypto & Web3 style (where airdrop farming makes this especially relevant, see Neon Wallet) to the plainest minimal page. Planning a token or NFT launch? Read the Web3 waitlist guide.

Architecture is the only defense that doesn't have to be remembered.