We put our referral program on-chain — here's why, and how it works
Almost every referral or affiliate program is, underneath, an IOU.
You refer someone. A dashboard tells you you're owed something. And then payment happens if the company's accounting agrees, when their payout schedule comes around, on terms they can change. You're trusting the same discretionary, custodial machinery that crypto was supposed to make unnecessary.
When we built QBitFlow's referral program, that contradiction was the thing we couldn't ship past. So we didn't.
How it works
Refer someone to QBitFlow — a business that accepts payments, or a creator collecting tips on qbf.cash. When they transact, you earn 20% of our fee on every transaction they make — for six months.
And the referrer can be almost anyone: any QBitFlow user (down to a non-admin role) or any qbf.cash user holds a referral link. You don't have to run a marketplace, or even be a merchant yourself, to earn.
The part that matters: that split is enforced by the smart contract at settlement. It isn't tracked in a spreadsheet we control. It isn't queued for a monthly payout run. The moment a referred merchant's payment settles on-chain, your cut is taken in the same transaction and routed to you. Paid by code, every transaction.
There's nothing to claim, nothing to invoice, and nothing to trust about our bookkeeping. If you want to verify what you're owed, you read the chain.
One deliberate choice worth calling out: that 20% comes out of our fee, not the merchant's. Referring someone costs the person you vouched for nothing — we share our own revenue rather than skimming theirs. A referral program shouldn't make the people you bring in pay more for the privilege of being referred.
Why bother putting it on-chain
Because "trust us, we'll pay you" is exactly the thing crypto was meant to fix. A payout rail that's custodial and discretionary is just Stripe with extra steps. A referrer shouldn't have to trust our accounting any more than a merchant should have to trust that their money won't get frozen.
The whole product already works this way: funds move customer wallet → merchant wallet, directly. We never hold a cent. 1.5% flat. The referral program simply extends that same guarantee to the growth loop — your reward is enforced the same way your payments are.
One primitive, three wedges
The referral split isn't a bolt-on. It's the same on-chain authorization primitive that powers two other things:
- Subscriptions — a contract-enforced authorization with a bounded spending cap.
- Referrals — a contract-enforced cut taken at settlement.
- Agentic payments (x402) — the same authorization that lets an agent spend up to a cap you set, without ever holding your keys. The contract ships with it today; the backend is landing soon. (More on that when it's live, not before.)
One primitive, three product wedges. That's deliberate: fewer moving parts, less surface area to get wrong, and everything inherits the same on-chain guarantees.
Also in this release: cleaner subscription approvals
We moved ERC-20 approvals to Permit2. Previously, some tokens used Permit and others needed a separate approval transaction — two paths, two UX flows, two ways to confuse a user. Now it's one consistent signing flow for every token.
Try it
The contracts are open-source — readable, forkable, auditable: github.com/QBitFlow
Docs: qbitflow.app/docs
Start: qbitflow.app/get-started
If you run a marketplace or a merchant base, your referral math is now something a contract guarantees — not something we promise. That was the whole point.
Top comments (0)