Double opt-in is usually argued for on deliverability grounds — protect your sender reputation, keep bounces down, stay out of spam folders. All true, all secondary.
The first-order reason is that without it you do not know your denominator, and every number you compute afterwards is a fraction of an unknown.
Four things that are not a person
A public form on the internet collects these whether you want them or not.
Ordinary bots. Scripts that fill any form they find, because forms are where injection attempts and spam links go. These arrive within hours of a page being indexed and they never stop.
Disposable addresses. Ten-minute mailboxes, used by people who want whatever is behind the form without the consequences. Sometimes that is a fair trade for them and it still means the address will not exist next week.
Plus-addressing and dots. you+1@gmail.com, you+2@gmail.com, y.o.u@gmail.com all deliver to
one inbox. Not malicious by default. Extremely malicious once a referral mechanic rewards volume.
Typos. gmial.com, hotmial.com, and addresses that are simply wrong. Nobody is trying anything;
the address just does not exist.
The first three grow when there is something to gain. The moment a queue position becomes a reward, you have published an incentive to manufacture signups, and somebody will take it up quickly.
What verification actually fixes
Not "the list is now clean". It is not.
What it fixes is that you now have two numbers instead of one: signups, and verified signups. The ratio between them is a measurement, and it is one of the more informative ones on the whole dashboard because it is mostly a statement about your traffic.
A verification rate around 80% is unremarkable. Around 50% and something is wrong with where your traffic is coming from. Below that and you are largely counting things that are not people.
Watch it per source. One channel with a verification rate half the others is telling you something specific about that channel, and the blended number hides it completely.
The controls, and what each one is for
Osokoro ships four. They are not interchangeable and it is worth knowing which failure each addresses.
Email verification. Confirms the address exists and its owner clicked. Catches typos, disposable addresses whose window has closed, and every bot that does not read mail. Free on every plan, including the free one — a product that let you build strategy on an unverified count would be selling you a worse number than you started with.
CAPTCHA. Stops the cheap automation at the door, before it reaches your database or your send quota. On Starter ($10/mo) and up.
Disposable-domain blocking. Refuses known throwaway providers at submission. Cheaper than verifying and then discarding, and it also declines to send mail to an address that was never going to receive it.
Referral-abuse detection. The one specific to the incentive. Looks for the patterns that appear when position-jumping is worth gaming — rings, bursts, addresses that are variations on each other.
Only verified signups should move the queue
If an unverified address advances somebody's position, you have built a machine for manufacturing positions. The people gaming it will discover that before you do.
This is the single most consequential line of configuration on a referral waitlist and it is frequently the default in the wrong direction, because rewarding on signup produces a nicer-looking graph.
What it costs you
Verification loses you real people. Some fraction never open the email, never find it in spam, or sign up on a phone and never return to a mail client. Those people were interested and you have dropped them.
You cannot have both. What you can do is make the loss small:
- Send immediately. Verification rate falls off a cliff with delay.
- Say what the email will look like on the confirmation screen, including who it is from.
- Make the subject line unmistakably yours, not "Confirm your email".
- Let people re-request it without signing up again.
And then accept a real cost in exchange for a real number, rather than pretending the tradeoff is not there.
The related trap that has nothing to do with email
Since this is the article developers will find: when you eventually export or analyse this list, check how many rows you actually got.
PostgREST caps a query at 1,000 rows by default. A select written to mean "give me everything"
silently returns the first thousand — no error, no warning, a file that downloads and opens and looks
correct. It truncated a CSV export and the validation analytics in this codebase before anybody
noticed, and it is exactly the failure that leaves your verification-rate arithmetic quietly wrong.
Osokoro's own export streams by keyset for that reason, and the public API at GET /api/v1/signups
uses keyset pagination with a maximum page size of 500 rather than an offset. If you are doing this
yourself, page explicitly and count what came back.
The summary
Verification is not hygiene. It is the difference between a number and a number you can divide by. Turn it on before the referral mechanic, reward only verified signups, watch the rate per source rather than blended, and check your row counts when you export.