Most referral programs run on things you cannot see. A cookie drops into your browser, a pixel fires somewhere, and a company's private database quietly decides who gets credit. You are told a number and asked to trust it.
The version on this site works differently, mostly because it has nowhere private to hide. There is no server keeping a secret ledger of who referred whom. The credit is a wallet address, and it travels inside the same transaction that mints the second. That changes what a referral even is here, so it is worth walking through slowly.
When you share your referral link, it carries one extra piece of information in the query string: ?ref= followed by an Ethereum-style address. The front end reads that parameter, checks that it is a valid address, and stores it. If you arrive without one, the page looks for an address it saved from a previous visit. If it finds neither, the referrer defaults to the zero address, which is the chain's way of writing "nobody."
That is the whole mechanism on the browser side. No account, no login, no tracking profile. The link is a way to hand one wallet address to the next person's mint. You can read the exact line yourself in the page source, where an invalid address is simply ignored rather than passed along.
The mint function on the contract takes three arguments: the second you want, the URL you want it to point to, and a referrer address. In the ABI it reads as mint(uint256 _second, string _url, address _referrer). When you confirm the transaction, that referrer address is not a footnote. It is a parameter, sitting alongside your chosen second, going to the contract in the same call.
This is the part that feels different from an ordinary affiliate link. The credit is not attached after the fact by some backend reconciling clicks. It is baked into the mint itself. If the referrer field says a certain address, then that is what the contract received, and there is no separate record that could disagree with it later.
Once a mint goes through with a referrer, two kinds of memory exist. The first is the running total. The contract exposes referrerEarnings(address) and referrerCount(address) as read-only views, so anyone can ask what a given address has earned and how many mints it has been credited for. You do not need to connect a wallet to read these. They answer to a plain query.
The second is the event log. Every mint emits a SecondMinted event, and its fields include the referrer address for that specific mint. So beyond the totals, there is a timestamped trail of individual credits, sitting in the same public logs the leaderboard already reads from. If you wanted to audit your own referrals one by one, the raw material is there.
The share itself is ten percent of the mint. That figure shows up in the interface next to the widget, and the split is handled by the contract when the mint is paid. I want to be careful here: I am describing the front end's stated behavior and the functions the contract exposes, not making a promise about your returns. Whether a referral earns anything at all depends on whether anyone actually mints through your link.
If you own a second, the embeddable badge on the home page builds its snippet with your address already in the query string. The generated iframe URL carries ref= set to your connected wallet, so the badge doubles as a referral link without you assembling one by hand. Put the badge on your site, and anyone who mints after clicking through is crediting you by default.
It is a small design choice, but an honest one. The thing that shows off the second you own is the same thing that passes your address along. There is no separate "referral dashboard" pretending to be more than it is.
Onchain credit is transparent, not magic. A few limits are worth naming plainly.
The link lives in the browser until the moment of minting. Someone can strip the ref= parameter, paste in a different address, or clear what the page stored. Referral attribution here rewards the address present at mint time, and that address can be changed by whoever is doing the minting. It is a convenience and a courtesy, not a lock.
None of this is financial advice or a suggestion that sharing a link will pay off. Minting a second costs a real fee on Base, transactions are irreversible, and the usual risks apply: lost keys stay lost, and phishing links are a permanent hazard whenever a wallet is involved. A referral share is a share of activity that may never happen. Treat it as a way to invite people to something you already find interesting, not as a yield.
What I do like about the design is its plainness. The credit is an address, the address is public, and the totals are readable by anyone who wants to check. When a system has nowhere to keep a private version of the truth, the version you can see is the only one there is.
→ See the clock and grab your badge · Read your second straight off Base · What happens when you mint a second
?ref= address, ignores invalid ones, and defaults the referrer to the zero address; the widget builds its embed URL with the connected wallet as ref=; the interface states a 10% referral share.mint(uint256,string,address) takes a referrer argument; referrerEarnings(address) and referrerCount(address) are read-only views; the SecondMinted event records the referrer.