Designing a referral system that can't be gamed by throwaway accounts

I just deployed a referral system for Adsyte, my free directory for indie projects, and the design choice behind it is worth sharing because the pattern can be applied to any growth loop that offers token rewards. The conventional approach, although simple, has an inherent vulnerability. The basic implementation involves granting tokens to the recruiter the moment someone signs up via their unique link.

This seems straightforward, but it harbors an exploit. Signing up is free and OAuth facilitates the creation of throwaway accounts, enabling anyone to self-refer through multiple Discord accounts and reap free reward tokens without contributing even a single genuine user to the platform.

I took a different route instead. The payoff only triggers when the recruit publishes their first listing, not when they sign up. This single adjustment closes the loop: A fake account is devoid of cost, but a genuine listing necessitates a real project with a valid URL. Publishing a listing involves passing duplicate-URL detection and hCaptcha, making it significantly harder to fabricate than to counterfeit a signup.

Consequently, each token dispensed corresponds to a listing the directory has actually gained, which is the metric that truly matters, not the number of signups.

Implementation specifics include deriving the referral code as an HMAC of the user's ID, deterministically rather than storing it as a random token, eliminating the need for extra generation or leakage. The code resides in a cookie set on the landing page ( ?ref=CODE ), read once at the OAuth callback, and tied to the account via a Redis SETNX to ensure it can only be set once, excluding self-referral outright.

The payout mechanism also utilizes SETNX on a per-recruit key to prevent double-firing (retries, race conditions) from resulting in double-payments. A daily cap per recruiter prevents a single compromised or bot-driven account from depleting the reward pool in one go. None of these measures are groundbreaking; it's the standard "pay for the outcome, not the action" principle.

However, I've rarely seen it applied to referral systems as extensively as it should be. Most implementations I've encountered reward signups because it's the simplest event to hook into, followed by bolt-on fraud detection after abuse becomes apparent. Rewarding the outcome that actually costs the abuser something negates the need for a fraud detection layer altogether.

I'm curious how others have approached this, particularly the daily cap number. I settled on 10 for a starting point.