Every referral system I have audited has the same shape: one write, at account creation, and no way to correct it afterwards.
That shape is not an accident. It is what you get when you design for fraud resistance first and user experience second, and it produces a failure mode that engineers rarely think about, because it never throws an exception.
The write
When a new account is created, the backend stores a referrer field. That single write is the entire attribution. Everything downstream - fee discount, commission calculation, reporting - reads from it.
The write happens inside the signup transaction, so it competes with everything else in that transaction: email verification state, KYC status, initial balance. If the referral code arrives from a query parameter, it also competes with session state, redirects, and whatever the frontend did to the form before submitting.
Any of those can drop it. None of them surface an error.
Why the bug is invisible
From the system's point of view, nothing failed. No exception, no retry, no alert. The referral field is nullable, so "no referrer" is a perfectly valid state - the same state as a user who deliberately signed up without a code.
That is the core design tension: you cannot distinguish "user declined the discount" from "our pipeline dropped the discount" after the fact.
The UI makes it worse
Most exchanges show your own outbound referral code prominently, and record your referrer quietly. Users check the first one, see a code, and conclude their relationship is active. It is not. Your outbound code says nothing about who referred you.
If a system writes something once and never again, it owes the user a verification surface for that value. A read-only "referred by" line on the profile is not a nice-to-have; it is the difference between a recoverable mistake and an invisible one.
What a better design looks like
Three changes would remove most of this failure class:
- Echo the value back immediately. After signup, show "You were referred by X". If the value is empty and the user arrived via a referral link, warn them.
- Preserve the evidence. Keep the original signup request payload long enough that support can adjudicate a rebind request weeks later.
- Rate-limit writes, not reads. The fraud concern is self-referral, which is a write-side problem. Making the field read-only does not solve fraud; it moves the pain to honest users.
The economics explain why it stays broken
A referral code on Binance gives around 20% off spot trading fees. The money comes from the customer acquisition budget - the exchange pays either way. So a silent failure costs the platform nothing and costs the user a few percent, permanently and invisibly.
That is the tell. When a failure costs the platform nothing and a few percent to the user, it survives for years.
If you want a code to try, mine is BBBKK (https://www.binance.com/register?ref=BBBKK) - but the habit that matters is the verification step, not the code.
Disclosure: I receive a commission if you sign up with the code above. This is not financial advice.
Top comments (0)