DEV Community: Yinghui

Rate-Limiting Writes, Not Reads: A Referral System Redesign

Yinghui — Mon, 02 Nov 2026 08:39:25 +0000

A referral system's core write happens once, at account creation, and is immutable afterwards. The design rationale is fraud resistance: if the field could be edited, users could self-refer or arbitrage commission structures after the fact.

That rationale is sound. The implementation usually is not.

The problem with write-once

Write-once solves the fraud case and creates a silent-failure case. The referrer column is nullable because signing up without a code is legitimate - so a dropped write is indistinguishable from a deliberate opt-out.

No exception. No retry. No alert. The account is created successfully and the user never learns they are unqualified.

What the fraud model actually needs

Self-referral is a write-side abuse. The constraint that matters is who can create attribution, and how often - not whether attribution can ever be read or repaired.

Three constraints do the work:

Rate-limit attribution creation per identity document and per device fingerprint.
Require the referrer to have an active, verified account at the time of referral.
Cap commission-eligible referrals per referrer per period.

None of those require making the field permanently immutable. All of them target the abuse directly.

What an editable-with-audit model looks like

Instead of write-once, use write-once-with-a-pending-second-write:

The signup write is the canonical attribution and takes effect immediately.
A second write is allowed only within a short window (say 24 hours) and only if the first was empty.
Every write is logged with the source (query parameter, form field, support override) and immutable in the audit trail.

This closes the silent-failure case without opening the self-referral case, because the second write cannot overwrite an existing attribution.

The observability fix

The deeper problem is that the failure is invisible to engineers too. A nullable column with no companion metric means you cannot compute a referral attribution rate, so you never discover that some percentage of signups are silently failing.

The fix is small: persist the referral parameter separately from the resolved attribution. Then a mismatch between "parameter present" and "referrer stored" is a measurable, alertable event.

Why it stays broken

The discount comes out of the customer acquisition budget. The platform pays either way. A silent failure costs the platform nothing, the user a few percent, and the referrer their commission - and only the last of those has any incentive to complain.

When a failure has no owner, it has no fix. That is the actual design lesson.

Disclosure: author has a referral code. Not financial advice.

Why Referral Attribution Fails Silently (And How to Design Around It)

Yinghui — Mon, 02 Nov 2026 07:05:58 +0000

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

The backend stores a referrer field inside the signup transaction. That single write is the entire attribution. Everything downstream - fee discount, commission, reporting - reads from it.

The write competes with email verification state, KYC status, and initial balance creation. If the code arrives as 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 surface an error.

Why the bug is invisible

The field is nullable, so "no referrer" is a valid state - identical to a user who deliberately declined a code. You cannot distinguish "user opted out" from "our pipeline dropped it" after the fact.

That is the design tension in one sentence.

The UI compounds it

Most interfaces display your own outbound code prominently and record your referrer quietly. Users check the first, see a code, and conclude the relationship is active.

If a system writes something once and never again, it owes the user a verification surface for that value.

What a better design looks like

1. 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.

2. Preserve the evidence. Keep the original signup request payload long enough that support can adjudicate a rebind weeks later.

3. Rate-limit writes, not reads. The fraud concern is self-referral, a write-side problem. Making the field read-only does not solve fraud; it moves the pain to honest users.

The economics explain persistence

The discount comes from the customer acquisition budget. The platform pays either way, so a silent failure costs nothing to the platform and a few percent to the user, permanently and invisibly.

When a failure costs the platform nothing and the user invisibly, it survives for years.

If you want a code to try, mine is BBBKK (https://www.binance.com/register?ref=BBBKK) - but the verification habit matters more than the code.

Disclosure: I receive a commission if you sign up with the code above. This is not financial advice.

Wallet Basics: Custodial, Hot, and Cold - Where Each Fails

Yinghui — Mon, 02 Nov 2026 06:53:28 +0000

Wallet basics get explained with metaphors that are accurate and useless for decisions. Here is the practical version: what each type does, and where it fails.

Custodial wallets

The exchange balance. You have an account, they have the keys. Fails when the company fails, freezes, or restricts access - mitigated with 2FA, a withdrawal whitelist, and by not keeping everything there.

This is where the fee discount lives: a referral code gives roughly 20% off spot fees. Mine is BBBKK at https://www.binance.com/register?ref=BBBKK.

Software wallets (hot)

Keys on an internet-connected device. You control them, which means you can lose them. Fails through malware, phishing for the seed phrase, and device compromise.

Reasonable for spending-size amounts. Not for savings.

Hardware wallets (cold)

Keys on a dedicated device that signs without exposing the secret. Fails through a lost seed phrase, a counterfeit device, and social engineering that convinces you to type the phrase somewhere digital.

The correct choice for long-term holdings, and the one requiring the most setup discipline.

Three practical rules

Rule 1. Buy hardware wallets from the manufacturer, never from a marketplace.

Rule 2. Test recovery once with a small amount before trusting any wallet with savings. An untested backup is a rumour.

Rule 3. Never enter a seed phrase into anything with a screen that is not the device itself.

How this connects to the exchange question

People ask whether a referral code matters if they move to self-custody. The code applied to the trading you do on the venue - and if you trade at all, it applies. Mine is BBBKK: https://www.binance.com/register?ref=BBBKK.

Disclosure: I receive a commission if you sign up with the code above. This is not financial advice.

New Exchange Account: Four Settings to Enable, Two to Skip, One to Verify

Yinghui — Sun, 01 Nov 2026 10:04:09 +0000

New account holders face a wall of settings described in language that assumes you already know what they do. Short version: four things to enable before your first deposit, two to skip, one to verify within the first hour.

Enable before the first deposit

1. An authenticator-app second factor. Not SMS - SIM swap attacks are cheap, and SMS is the factor most often bypassed in practice. Hardware key support is better still.

2. A withdrawal address whitelist. Rejects any withdrawal to a pre-unapproved address at the payout layer - below where a stolen session can act. The single setting that makes a stolen login useless for moving funds.

3. An anti-phishing code, if offered. A custom word in every legitimate email. A withdrawal confirmation without it is phishing, no judgement required.

4. Withdrawal and security-change notifications. Immediately, not eventually.

Skip for now

API keys, until a specific script needs one (then: withdrawals off, IP restricted). Sub-accounts, until your structure requires them. Advanced order types, until your strategy does.

Skipping is not neglect - it is refusing to widen an attack surface you do not need.

Verify within the first hour

If you entered a referral code at signup, verify it took: profile menu → referral section → the field naming your referrer. Not your own outbound code - that is always populated.

Empty means a ticket the same day. Rebind requests are adjudicated from the raw signup session, which ages out. First hours: strong odds. Weeks: usually no.

My code is BBBKK: https://www.binance.com/register?ref=BBBKK (~20% off spot fees). The verification is the part that protects it.

First week

Make a small withdrawal to a wallet you control. It confirms your whitelist config, your exit path, and the venue's normal speed - three things you want tested before you need them under pressure.

Disclosure: commission if you sign up with the code. Not financial advice.

Why Referral Attribution Fails Silently: A Lesson in Write-Once Design

Yinghui — Sat, 31 Oct 2026 19:13:27 +0000

Every referral system I have audited has the same shape: one write, at account creation, and no way to correct it afterwards.

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.