PrivCaptcha.com

Giveaway and sweepstakes abuse prevention for entries and drops

One entrant taking hundreds of places in a draw or airdrop, each behind a throwaway email or wallet.

How giveaway entries get farmed

The farm loads the entry form once in a real browser and records the POST. It replays that POST with throwaway emails and wallets.

What giveaway abuse looks like in your logs
Entries outnumbering the distinct sessions that loaded the entry page.
Entries spiking seconds after the window opens, from accounts registered that hour.
Different entrant emails pointing at one delivery address or payout wallet.

How PrivCaptcha stops giveaway abuse

Four steps, with the numbers the server uses. Nothing here is configured by you.

The harness must run on your page

Once your domains are listed, a replayed POST is refused with invalid-input-origin.

One token buys one entry

Every entry issues its own challenge. The token is spent by the write that records it, and expires after 120 seconds.

First request: farm and airdrop bot

Scripted residential browser scores 20: level 2, 14 bits. Bare client, bot agent: 20+40+15+10=85, level 5, 12 shapes, 8 degrees, 5 pixels, 19 bits.

Wrong answers compound for the day

Each wrong answer adds 8, capped at 40: five failures move 20 to 60, level 4, 10 shapes, 10 degrees, 6 pixels, 17 bits.

What a giveaway abuse run costs now: 500 entries means 500 challenges, about 16,000 hashes at score 20 and a million at score 100 on the 12-to-20-bit band, none reusable.

Add PrivCaptcha to your giveaway entry form in two lines of code

Script tag, container in front of the submit button, and your existing verify call. Already on reCAPTCHA or hCaptcha? That backend code stays exactly as it is.

reCAPTCHA siteverify hCaptcha siteverify
Server SDKs
<!-- giveaway entry form -->
<script src="https://privcaptcha.com/1/api.js" async defer></script>
<div class="privcaptcha" data-sitekey="your-site-key"></div>
<!-- server side, unchanged -->
POST https://privcaptcha.com/api/v1/siteverify
Where it goes

The widget belongs on the action that increases odds: enter-now form, claim button, referral-accept step.

What the backend does

Post privcaptcha-response to /api/v1/siteverify in the write that increments the entry count. success:false must abort.

The usual mistake

Verifying once at campaign signup leaves the per-entry endpoint open. Protect each entry and each referral credit.

What this does not solve about giveaway abuse

A captcha prices an entry in time. It cannot tell you two entries are one person. Deduplicating entrants stays your job.

Common questions about giveaway abuse

How PrivCaptcha prices giveaway abuse, and what it does not do about it.

They can try, but each entry carries its own challenge and its own proof-of-work, so multiplying entries multiplies the compute rather than the odds. There is no free lane to find, because nobody is waved through.
A genuine entrant spends a couple of seconds, and the non-visual path keeps the promotion open to screen-reader and keyboard users.
Every request is challenged - there is no invisible pass to aim a script at, and no allowlist that skips the check. What changes is the form the challenge takes and what it costs. The server scores each request and picks one of five difficulty levels, so an ordinary visitor gets a couple of seconds and a client that looks automated gets tight tolerances and a heavier proof-of-work. On the non-visual path, taken by screen-reader and keyboard visitors, there is no puzzle to solve at all: the proof-of-work is the whole challenge, at a fixed 22 bits.
No. An address is used for the length of one request and never written anywhere. What we keep is an HMAC of it under a salt that is random, lives only in Redis and rotates every day, so yesterday's hashes cannot be linked to today's. The counters under that hash expire after 24 hours.

Put PrivCaptcha in front of your giveaway entry form

10,000 verifications a month are free, and the integration is the one you already have.