Eligibility for the refer-a-friend offer, the invite steps, the terms that bind both sides and the boundaries the desk respects.

Referral · Editorial

11Tiger referral code guide

Referral offers bind two accounts together, so the terms deserve a slower read. This page walks eligibility for the referrer, eligibility for the invitee, the invite step and the boundaries the desk refuses to blur when describing the offer.

refer-code editorial context
refer code editorial context image

Eligibility, both sides

The referrer usually needs an active account in good standing, occasionally a verified wallet, and sometimes a minimum account age. The invitee usually needs to be a new account, often tied to a fresh device or a fresh phone number. The desk reads eligibility twice — once for the referrer and once for the invitee — before resharing the offer.

Invite flow

The cleanest referral flows move the invitee through sign-up, KYC and first deposit in a stated order. The desk prefers offers whose terms state that order explicitly. When the terms are vague, the desk flags the offer instead of re-sharing it.

Boundaries

Self-referral is a hard boundary. The desk does not publish offers that allow the same account to invite itself, an account on the same device to invite the account holder, or two accounts owned by the same wallet to share a referral code. These are flags, not opinions — they are usually outlined in the partner brand's published terms.

Volume-referral is a soft boundary. Some brands allow high-volume invitations; others cap them. The desk does not reshare offers whose volume policy is buried in the footer of a separate page; it does reshare offers whose policy is on the same page as the headline terms.

Adult sending a referral invite from an unbranded smartphone at a desk
Refer Code supporting photograph

What a referral code actually does

A referral code is a string a reader enters at signup or deposit time that ties the reader's account to a referring reader's account. The referring reader typically receives a bonus when the referred reader meets a published threshold — first deposit, first contest entry, first completed contest. The desk's coverage of referral codes is the editorial anchor for the reader's side of that flow. It is not a referral-code marketplace; the desk does not list codes, does not compare codes across partner brands, and does not benefit from any referral that originates from this site.

The referral code is also the surface where the most editorial confusion happens. Partner brands publish their own codes; affiliate sites publish aggregated codes; social-media accounts publish promotional codes; each of those surfaces has a different eligibility window and a different bonus structure. The desk's order of reading is: the partner brand's own published terms first, then the desk's coverage of eligibility and terms, then the reader's own decision. Reading the desk's coverage in any other order is what causes the most eligibility-window confusion.

Editorial independence means the desk does not publish a code, does not link to a code publisher, and does not track which code the reader used. The desk's coverage of referral codes is independent of any code-aggregation surface, and the desk's recommendation is to verify the code against the partner brand's own published terms rather than against any aggregator.

A reader who has already entered a code at signup should skip ahead to the eligibility-and-terms section. The invitation-steps section is most useful for a reader who has not yet entered a code, and the privacy-and-responsible-sharing section is the section that catches the most reader-side regret.

Adult reading a published referral terms note beside a coffee cup
Refer Code supporting photograph

The invitation steps and eligibility check

The invitation-steps routine has three steps: (1) obtain the code from a verified source — the partner brand's own published site, or a referring reader who has already passed the eligibility check; (2) enter the code at signup or deposit time, depending on the partner brand's published entry surface; (3) confirm the code has been accepted by the partner brand's signup confirmation. Each step has a verification at the end, and the verification is what catches a code-entry mistake before it cascades into an eligibility-window miss.

Step 1, obtaining the code, is the step most likely to surface an illegitimate code. The desk's recommendation is to obtain the code from the partner brand's own published site, not from a search-engine result page or a social-media account. A code published by a partner brand is the only code the desk treats as verified; a code published anywhere else is treated as unverified until the reader has compared it against the partner brand's published terms.

Step 2, entering the code, has two surfaces: signup and deposit. Partner brands differ on which surface accepts the code, and the desk's coverage here does not list the differences because the differences change faster than this guide can be refreshed. The desk's recommendation is to read the partner brand's published entry-surface note before entering the code; an entered code on the wrong surface is recoverable through partner-brand support, but the recovery requires the reader to escalate.

Step 3, confirming the code has been accepted, is the step the most readers skip. The signup confirmation page shows the code and the bonus it triggered; the desk's recommendation is to capture a screenshot of that confirmation before closing the page. A captured confirmation is the audit trail that turns a missed bonus into a recoverable bonus.

Adult reviewing what referral data is shared on an unbranded smartphone
Refer Code supporting photograph

Where the referral flow gets contested

The referral flow gets contested first at step 1, when the code from a search-engine result page differs from the code on the partner brand's published site. The right response is to enter the partner brand's code, not the search-engine code. A search-engine code is most often an expired code or a code from a partner brand that no longer exists. Either case is recoverable through partner-brand support, but the recovery is faster when the entered code is from the partner brand's own published site.

The referral flow gets contested second at step 2, when the reader enters the code on the wrong surface. The right response is to escalate through the partner brand's verified support channel, with the screenshot from step 3 as evidence. An entered code on the wrong surface is recoverable when the screenshot exists; it is contested when the screenshot does not exist.

A third edge case: the reader is referred by a friend, and the friend's code is published in a chat message rather than on a partner-brand page. The right response is to ask the friend for the partner brand's published entry-surface note before entering the code. A code passed through a chat message is verified when the friend has read the partner brand's published note; it is unverified otherwise.

A final edge case: the privacy and responsible-sharing section. The reader's referral code is shareable, but the reader's account is not. The desk's recommendation is to share the code through a separate channel from any channel the reader uses to share account credentials, and to not include the reader's own account details in any referral-share message. A referral code shared with account credentials is the most common cause of a referral-code reader's account being compromised.

A shared-responsibility note: the referral-code flow also touches the partner-brand-published "share responsibly" page, which most partner brands publish in their help centre. The desk's recommendation is to read that page once, at the start of a contest cycle, and treat it as the partner brand's own published guidance. A published guidance page that disagrees with the routine is a flag, not a dealbreaker, and a reader who values the editorial line should treat the disagreement as a reason to escalate through the verified support channel rather than to skip the routine.

A note on eligible-reader identification: the partner brand's eligibility check at step 3 often distinguishes between a first-time reader and a returning reader, and the distinction is what determines whether the entered code triggers the published bonus. A first-time reader who has previously held an account under a different email or phone number is, by most partner-brand-published policies, a returning reader, and a returning reader's code-entry triggers a different bonus (or no bonus). The desk's recommendation is to verify the reader's own eligibility status before entering the code, and to escalate through the verified support channel when the partner-brand-published eligibility criteria are unclear.

A note on the post-entry observation window: most partner brands publish a short observation window — typically 7 to 30 days — during which a triggered bonus can be revoked if the referred reader cancels a deposit or completes the eligibility criteria in a way the partner brand considers outside the published terms. The desk's recommendation is to treat the observation window as part of the routine: do not treat the triggered bonus as final until the observation window has closed, and do not enter a new code on top of an unclosed observation window without first escalating through the verified support channel to confirm that the new code does not invalidate the prior bonus.

Frequently asked questions

Can I refer myself?

No. Self-referral is a hard boundary and is usually prohibited by the partner brand's own terms. A referral that allows two accounts owned by the same wallet is a flag, not an opportunity.

Are referral offers available for previously verified accounts?

Almost never. Most offers are restricted to new accounts whose owner has not previously verified a wallet. The full eligibility rules sit on the partner brand's published terms page.