Skip to content
bitcoinsv.design

Search the guide

Search the guide

Growth that pays

Growing a BSV product by paying people directly: referral payouts that arrive instantly, paying for contributions, credit to try, shareable handles and payment links, and the fraud every reward attracts.

When sending a few hundred satoshis costs less than 1p and arrives as soon as the recipient's wallet accepts it, a reward can be real money paid the moment it is earned, not points redeemed later. That makes incentives more persuasive, and it makes them worth stealing.

The guide's usage life cycle holds that most people arrive through somebody they know: a friend, a shop, a colleague who pays them. Growth that pays is mostly about rewarding that person and the one they bring.

Instant referral payouts

A referral reward that lands in the referrer's wallet when it is earned, with a notification saying who it came from, is its own advertisement. The person who brought a friend in sees the result immediately.

Do

Pay the referral when the new user does the thing you value, such as their first payment, and pay it at once. A reward that arrives days later has lost most of its point.

Do

Say in the payment who it is for: "Referral reward: Anna joined using your link." A payment with no memo looks like a mistake; a memo that reports what a friend bought tells the referrer too much.

Paying for contributions

Paying people for things that make the product better: a review, a translation, a bug report, a tagged photo, an answer. Small payments make a reward of a few hundred satoshis worth sending, so contributions too small to invoice can still be paid.

Do

Pay for a contribution after you have judged it, and say what was accepted. Paying on submission rewards volume, and volume is what fake accounts produce.

Do

Publish the rate before people contribute: "50 sats for each accepted translation." A reward people can predict is one they can decide to work for.

Credit to try

Sending a new user a small amount so their first experience is holding money, then spending some of it on your product. It follows the guide's advice that a new user's first task should end with real money in their wallet.

Send it after the first action you value, not when a wallet is created or connected, and cap it to an amount you would accept losing to farming. See The risks.

Do

Send credit to try after a first action you value, never on wallet creation or connection alone.

Do

Send credit to try as a real payment to the user's wallet, not as a balance inside your app. A real payment teaches them how the wallet works; an in-app balance teaches them how your app works and leaves you holding the money.

Don't

Restrict credit to try so it can only be spent with you, then call it a gift. Either give money, or give a free trial, and name it accurately.

A is readable and stays the same for as long as the user keeps it, which makes it something they can share as easily as an email address. A payment link or request does the same for a single payment. See Paying by handle and Requesting.

Every handle shared and every payment request sent is the product being introduced to somebody new.

Do

Make the user's handle and a payment request one tap away from wherever they would want to share them, with your product's name on the landing page the recipient sees.

Do

Design the page a payment link opens for somebody without a wallet: what it is, who sent it, and the shortest route to receiving. The sender has already done your marketing.

The risks

Creating a wallet takes no and no time. That is good for onboarding, and it means one person can create a thousand recipients for your rewards in an afternoon.

Do

Tie every reward to something that costs a fake account real effort or real money: a purchase, an accepted contribution, a payment received from somebody else.

Do

Cap rewards per referrer and per period, and watch for clusters: many new users paid by the same referrer, or rewards forwarded straight to one wallet.

Don't

Pay a reward for creating a wallet or connecting one. Both are free to repeat, so the reward pays for the repetition.

Asking for an identity document stops some fraud and loses the users who came because nobody asked. The guide's privacy-minded persona, Ilse, leaves at exactly that point. If a reward needs that much protection, it is probably rewarding the wrong action.

Incentives that hold up

Paying people to grow a product

  • OK: paying for an action you would value without the reward, such as a first purchase, an accepted contribution or a friend who stays.
  • Grey area: paying for sign-ups or first opens, even with caps. It works, and it pays for a good share of accounts nobody will use.
  • Not OK: rewards that grow with how many people a user recruits beneath them, or any reward described as earnings or a return.

Open questions

  • Does an instant referral reward bring in different people from a delayed one, or only more of the same?
  • What is the smallest reward that changes behaviour? Nobody has published a test on a BSV product.
  • Can a product resist reward farming without asking anybody who they are?

Written from: /guide/designing-products/usage-life-cycle/, /guide/patterns/paying-by-handle/, /guide/how-it-works/payments/, /guide/patterns/charging-per-use/, /guide/daily-spending-wallet/first-use/, /guide/research/personas/.

Checklist

The rules on this page, in a form you can work through.

12 rules