At a glance

• The problem. belo was paying for sign-ups, and a sign-up came back as nothing.
• What belo did. Split every reward into two missions, and paid only once both were done.
• What it cost the product team. No app release, no wallet, no engineering time.

What is belo?

belo is a fintech app in Latin America that lets people hold, send, and spend both local currency and stablecoins from a single balance. Users pay with a card, settle bills, send money abroad, and swap between currencies.

The company operates mainly in Argentina, where it serves more than three million people. In April 2026 it raised a Series A led by Tether.

The Challenge

belo had run referral programs before, and they had the problem every sign-up bounty has. Someone created an account, collected the reward, and never came back. The team wanted to spend the same budget on people who became users.

The second problem was the product. belo is a consumer finance app, not a crypto protocol. People sign in with an email. They do not connect a wallet, approve transactions, or pay network fees, and nobody at belo wanted to start asking them to.

The reward had to land in accounts belonging to people who had never heard the word wallet, and it had to do it without a single app release.

So the program had to:

• Pay for activation, not registration.
• Stay invisible. Nothing new to learn, no extra steps.
• Stay off the roadmap. No app release, no engineering team pulled away.
• Let belo decide where the money lands, separately from how the user was tracked.

The Solution

Instead of building a rewards system inside a product with no wallets, belo used Fuul as the layer between the data it already collects and the money that goes out. belo set the rules. Fuul ran them.

• Identity. People are identified by email. belo's existing invite codes stayed where they were.
• Activity. Events come from belo's own systems, through the API. Nothing changed inside the app.
• Destination. belo tells Fuul which account receives each reward, and can change it whenever it needs to.
• Payout. USDT on Arbitrum, claimed automatically on the user's behalf, every day.

Two missions before anyone gets paid

Mission 1, money in. The invited friend deposits $100 or more, in pesos, dollars, or crypto. It is the first real money into the account.

Mission 2, money doing something. They pay with the card, settle a bill, send a transfer, or swap currencies. Any of these count, because any of them mean the account is alive.

The invited friend earns half the reward for the first and half for the second. The person who invited them is paid once both are done.

A deposit alone can be someone parking funds. A payment alone can be someone passing money through. Together they describe a customer.

The same logic handles fraud. Every belo user passes identity verification, and someone unverified cannot transact at all. No transaction, no mission, so referring yourself pays nothing.

Results

The program has run in production since June 2026.

• belo shipped no app changes to run it. The whole program sits on data the team was already producing.
• Every scheduled payout run has gone out since automatic claiming was turned on, without a failed payment.
• A referral that stops at sign-up costs nothing. The reward leaves the budget only after both missions.
• Self-referral pays nothing, because belo's identity checks make it impossible to complete a mission without being verified.

Conclusion

belo set out to stop paying for registrations. The two missions are what made that possible: the reward only leaves the budget once someone deposits and then spends, which is the same moment belo would call a customer activated.

The rest of the story is what did not change. Rewards settle in USDT on a public network, and the people earning them still sign in with an email and never touch a wallet.

A company does not have to become a crypto product to pay rewards onchain. It only has to describe what its users do and say where the money should go.