What the phrase actually covers
"Tokenised loyalty" gets used for at least three unrelated things, which is why conversations about it tend to go nowhere. It is worth separating them before deciding anything, because they differ enormously in cost, effort and legal exposure.
- Points in a database, described as tokens. The overwhelming majority of what is marketed as tokenised loyalty. There is no blockchain involved. "Token" is a branding choice.
- A transferable on-chain balance. A fungible token, usually ERC-20, that customers earn and can move between wallets.
- An on-chain credential. A non-fungible token that proves membership or status, and unlocks something, but carries no balance and no denominated value.
These are not points on a spectrum. They are different products with different failure modes, and the gap between the first and the second is much wider than it looks.
The three architectures compared
| Property | Off-chain points | On-chain balance | On-chain credential |
|---|---|---|---|
| Customer needs a wallet | No | Yes | Yes |
| Works at the till | Yes | Awkwardly | Awkwardly |
| Balance disputes | Constant | Rare — the ledger is public | None — no balance exists |
| You can correct a mistake | Yes | Only by minting or burning | Only by reissuing |
| Portable between merchants | No | Yes, inherently | Yes, but proves nothing elsewhere |
| Becomes speculative | No | Very likely | Sometimes |
| Ongoing running cost | Support staff | Gas, monitoring, support | Nearly nil after launch |
The row that decides most of the others is portability. The moment a balance can move between people, it acquires a price, and a price brings everything else with it — expectations, complaints, screenshots of charts, and a set of legal questions that a discount voucher simply does not raise.
The one decision that determines everything
Ask a single question early, and the rest of the design follows from it:
Can a customer obtain this by paying money, and can they transfer it to someone else?
If the answer to both is no — the thing is earned rather than bought, and stays with the person who earned it, redeemable only against your own products — you have a promotional mechanism. That is a well-trodden path that thousands of retailers already run.
If the answer to either is yes, you have created something that behaves like stored value or a tradeable asset, and the questions change completely: who owes the customer, what happens on insolvency, what happens when it trades at a discount, and which regulatory perimeter you have wandered into.
Neither answer is wrong. But the second is a substantially bigger undertaking than the first, and it is very easy to arrive there by accident — usually by adding transferability to something that started as a simple points scheme.
What each one costs to run
Infrastructure is almost never the expensive part. Support is.
Off-chain points
Cheap to host and unremarkable to build. The real cost is that every customer who thinks their balance is wrong contacts someone, and that volume scales with your customer count rather than your revenue. A scheme with 20,000 members generates a support queue whether or not it generates sales.
If you are running an online shop and just want this to work, the sensible move is an existing loyalty app on your storefront platform rather than anything bespoke. On Shopify there are mature options at every price point, and the integration work is already done.
On-chain balance
Deployment is trivially cheap. Everything afterwards is not: gas for distribution, monitoring for exploits, support for people who lost keys or sent tokens to the wrong address, and — if it trades anywhere — an audience that now has opinions about the price. Budget for legal advice before launch rather than after.
On-chain credential
The cheapest of the three to keep alive, because after deployment there is nothing to operate. A capped, frozen collection with no economics attached needs no monitoring, has no balance to dispute and no market to manage. The trade-off is that it does far less: it proves status, and that is all.
Where these go wrong
- Refunds. The most under-planned mechanic in loyalty. If a customer earns on a purchase and then returns it, you need to claw back — and on-chain that means either a burn permission you probably do not have, or accepting the leakage.
- Expiry. Expiry is what keeps liabilities finite. It is also the single largest generator of angry email, and on-chain it is awkward to express at all.
- Accidental transferability. A scheme designed as closed-loop that later adds "gift your points to a friend" has quietly changed category.
- Wallet loss. With off-chain points, a support agent resets access. On-chain, there is no reset. For a credential the customer paid nothing for, that is tolerable. For a balance they believe has value, it is not.
- Chain dependency. If your programme only functions while a particular network functions, you have taken on that network's uptime as your own.
How to check what a project actually does
Marketing language is a poor guide, because all three architectures get described in the same words. To find out what something really is, look at the contract:
- Is there a contract at all? Plenty of "on-chain loyalty" has no on-chain component. If no address is published, that is the answer.
- Fungible or not? An ERC-20 is a balance. An ERC-721 or ERC-1155 is usually a credential.
- Can it move? Check whether transfers are disabled. A non-transferable token behaves very differently from a tradeable one, whatever the marketing says.
- Who can mint? If one address can create unlimited supply, the cap is a promise rather than a property.
- Is it upgradeable? Behind a proxy, today's rules are not necessarily tomorrow's.
Every entry in the record records the standard and links to the contract on a block explorer, so you can check all of the above yourself in a couple of minutes.