Why a crypto exchange loyalty program fails to retain traders
A crypto exchange loyalty program usually breaks not on bonus mechanics but on the accrual model. Points are attached to a single event in the transaction log — "trade executed" — instead of an aggregate of trading activity for the settlement period.
As soon as a trader starts working with partial fills, canceling orders, moving positions between subaccounts, or trading multiple instruments at once, the same turnover is either counted twice or not counted at all.
The discrepancy accumulates quietly: an active trader sees a rewards balance that does not match their real turnover. They read this not as a bug but as unfair rules — and trader retention collapses faster than with no bonuses at all.
Then support gets involved: every discrepancy has to be investigated manually, transaction history reconciled, and the balance corrected directly in the database.
Hence two related metrics.
Support load grows proportionally to turnover, because every request requires manual reconciliation, and churn of active accounts — proportionally to the number of such explanations: it is not the one who trades little who leaves, but the one who trades a lot and does not see a reward for it.
A separate reason why this cannot be cured by adjusting the balance: a recalculation not tied to the settlement period and not protected against reprocessing the same event returns manual adjustments on the next pass through the log. We explain how this is closed.
What the new loyalty system delivers: measurable effects
The loyalty program stops being a separate table with points and becomes part of the user's balance.
Accrual, write-off, and level change trigger at the moment of the trade, not during the next nightly recalculation, so the status in the personal account matches the actual volume of operations.
Rewards are calculated in real time
Rules — trading volume over a window, retaining funds on the account, number of referred accounts — are checked per event and immediately change the multiplier. The delay between an operation and accrual shrinks from hours to seconds, and disputed accruals become fewer.
Share of active accounts and repeat deposits
Predictable mechanics bring the user back more often: they see how much is left until the next level. The share of accounts with operations per month grows, and repeat deposits stop depending on manual campaigns — scenarios are tied to behavior, not the calendar.
Support is offloaded
Requests like "it wasn't credited" and "why did the level change" are closed by a transparent history: every accrual has a link to the event and the rule that triggered. First-line load drops, and dispute resolution takes minutes.
The effect of the loyalty system is measurable: growth of exchange turnover, share of active accounts, frequency of repeat deposits, and volume of support requests are visible in cohort reporting.
External sources like Chainalysis help reconcile activity with on-chain data so metrics do not diverge from reality.
Options for building the program: points, levels, subscriptions
The choice of mechanics is determined not by personal account design, but by which event accrual is calculated from and how quickly the exchange liability grows.
A points system accrues for actions, a partial fee rebate is tied to actual turnover, and tiered subscriptions — to balance retention and trading volume for the settlement period.
Therefore the model is selected for the client profile: share of high-turnover traders, average deposit lifetime, sensitivity to fee size.
Limitations surface at the interface with accounting. If levels are recalculated retroactively, and points and fee rebate accrue for the same trade, double reward appears — visible only in reconciliation. Therefore the accrual model is fixed in the rules and run on historical data before launch.
| Mechanics | When it fits | Limitations |
|---|---|---|
| Points system | Need to incentivize specific actions: onboarding, referrals, tasks | Points depreciate without a clear exchange scale; liability volume is hard to forecast |
| Partial fee rebate | Clients are sensitive to trade cost and trade frequently | Directly cuts revenue; without a tie to real turnover encourages volume padding |
| Tiered subscriptions | There is a core of clients willing to maintain balance for status | Require level recalculation per period and correct handling of balance drawdown |
| Mixed model: points plus levels | Need both to attract new and retain active | Complexity of rules and reconciliations grows; without a single accrual ledger discrepancies are inevitable |
The practical criterion is one: mechanics must be calculated from data the exchange already stores and allow manual verification of any accrual.
Implementation stages: from data audit to launch
The project is split into stages because the cost of an accrual error is incommensurate with a week spent on reconciliation: a wrong multiplier spreads across hundreds of thousands of events and is rolled back manually. The order of work is built so each next step relies on data verified at the previous one.
- Data audit. Inventory of events: trades, deposits, withdrawals, staking, referral links, cancellations, and reversals. We check log retention depth and completeness of identifiers by which an event is linked to a participant.
- Accrual scheme. Levels, multipliers by product, transition thresholds, points lifetime, behavior on trade reversal. We describe declaratively so changing a threshold does not require code changes.
- Integration setup. Subscription to the event stream via Kafka, write is idempotent by event identifier — repeated delivery does not cause double accruals. The delay between the event and points crediting becomes a measurable parameter.
- Calculation verification. Run on historical data for several months and reconcile with reference exports for each product. Target discrepancy is zero; everything that does not match is investigated to root cause, not to a tolerance threshold.
- Controlled launch. First shadow mode, where calculation runs in parallel with manual without crediting points, then a limited user group and gradual enablement across the entire base with pointwise rule disabling.
- Handover. Documentation on the scheme, discrepancy monitoring dashboard, incident handling procedure, and access to configuration — changing thresholds no longer requires us.
What we hand over: schemes, policies, procedures
The loyalty program project does not end at launch: then the client's team changes coefficients, resolves disputed accruals, and answers users.
Therefore we assemble a set of artifacts by which the program can be run and developed without us, and hand it over not as an archive but as a walkthrough with those who will work on it.
- Architecture scheme: how accrual and points accounting services are connected, where transaction history is stored, which events come from outside and which are generated internally.
- Accrual procedure: formulas for levels and partial trading fee rebate, calculation periods, rounding rules, per-participant limits, and procedure for retroactive adjustments when conditions change.
- Access policies: roles — support, analyst, risk officer, developer — and what each is allowed to read and change, environment separation, procedure for granting and revoking rights.
- Incident documentation: classification of failures (double accrual, balance discrepancy, stuck points withdrawal), procedure for stopping accruals, rollback and compensation scenarios.
- Support service instructions: response wording, escalation tree, what can be promised to the user immediately and what only after a risk officer decision.
- Reporting procedure: which metrics we capture — share of active participants, accrual volume, transitions between levels — and how we reconcile them with accounting.
Acceptance runs on a test environment: the client's team independently runs a coefficient change and resolution of a typical incident so that after handover there is no "it works, but unclear why".
Case study: returning churned traders and growing activity
Before the project, the loyalty program relied on nightly batch recalculation: rewards across the entire base were calculated for several hours, and the discrepancy between a trader's balance and the transaction log surfaced only upon complaint.
The share of active accounts held around one third of registered, and support monthly handled hundreds of identical requests about uncredited points.
| Metric | Before | After |
|---|---|---|
| Share of active accounts per month | 31% | 54% |
| Reward recalculation across the entire base | 6 hours | 11 minutes |
| Support requests about accruals | 380 per month | 45 per month |
| Balance reconciliation with transaction log | manually, upon complaints | daily, automatically |
What was reworked in calculation
The reward path was analyzed from trade to crediting: trading events enter the queue, accrual is calculated incrementally, and each record gets an idempotent key — reprocessing does not double the balance.
Reward withdrawal was moved to the Polygon network, where the fee does not eat small amounts: rewards began to be used rather than accumulated to an inconvenient minimum.
Accrual history was exposed in the personal account, and support got access to the log by operation identifier. This removed the main reason for churn: a trader who did not understand where the balance figure came from simply stopped trading. In the reward-receiving segment, churn decreased more noticeably than across the base as a whole.
How does a points system differ from tiered subscriptions?
A points system and tiered subscriptions differ not by screen design but by where user state is stored.
In the first case, the mechanics accumulates accruals in the balance: points are composed of a dozen sources — trading turnover, referred users, asset retention, participation in promotions.
In the second, state is a status with an expiration date, recalculated over a rolling window by one aggregate.
Hence the difference in calculation predictability.
A points system is multiplicative: editing a coefficient or adding a new accrual source changes the total for everyone who already accumulated points, so idempotent event processing, deduplication, and a separate recalculation layer are needed — otherwise the balance diverges from transaction history.
A tiered subscription is discrete: the transition between levels is calculated by a threshold over a window, the result is reproducible, and it is explained to the user in one line.
Support cost follows from the same. Points generate a stream of requests "credited less than expected": to resolve each, an engineer needs an accrual log with the source and coefficient for each event.
Subscriptions produce a spike of requests at the period boundary and on status downgrade, but resolution comes down to checking one aggregate. An error in a threshold costs more than an error in a coefficient: it affects the entire level at once.
User segments react differently. Active traders count points and are sensitive to multipliers, large holders hold the asset for status and barely notice pointwise accruals, and newcomers get lost in multi-layer arithmetic.
Therefore the choice of mechanics — points system or subscriptions — is determined by which behavior needs reinforcement, not by which model is "more correct".
In practice, comparison of models rarely ends with one winning: more often a hybrid is assembled, where levels from window aggregates set status and unlock privileges, while points live inside the level as a consumable resource for exchange for fees and limits.
Thresholds, windows, and coefficients are moved to configuration so mechanics can be changed without a release, and the accrual log is written from the very beginning — restoring it retroactively is impossible.
Technical concerns: accrual, anti-fraud, withdrawals
Before the start, the same topics usually come up: accruals when one trader has several accounts, transferring already accrued points, protection against wash trading, and reward reporting. Below are direct answers.
A trader has several accounts — do you count each separately?
We link accruals to the client identifier, not the account number: all trading accounts of one trader are summed into one balance. You cannot bypass limits by splitting accounts, and the reward remains understandable to the trader himself.
Are points accrued under the old mechanics transferred?
Accrual and write-off go through a separate log: each operation has an identifier and source. We load past history by reconciling with the current balance, and until it matches, new rules are not enabled — points do not disappear or duplicate.
How do you cut off wash trading and padding?
Anti-fraud works on rules: we calculate the share of volume where both sides of a trade are one client, catch activity spikes right after accrual, and match linked accounts by payment data.
Suspicious operations go to quarantine, so a good-faith trader does not lose a reward because of a false positive.
What will be included in reward reporting?
Accruals, write-offs, and balance per each client linked to the source operation, separately — triggered anti-fraud rules and frozen points. The export is provided as a table and reconciled with the program balance: a discrepancy is visible before a support request.
Let's discuss the task: we'll come back with an estimate and work plan
To come back with a project estimate, not a range "from and to", we need context: how the loyalty mechanics are currently structured, which systems it affects, and what constraints apply.
These inputs are enough to assemble the scope of work, order of stages, and control points — we analyze them and formulate ourselves what to do and in what sequence.
What helps to start faster:
- description of the current mechanics: levels, accrual and write-off of points, their lifetime, anti-fraud rules;
- list of systems with which the crypto exchange loyalty program needs to be integrated, and owners responsible for their side;
- access: test environment, accounts with minimum required rights, sandbox for accrual and withdrawal operations;
- expected volumes: active users and operations per day — the storage and caching scheme depends on them;
- constraints on launch timelines, regulator requirements, and reporting form before it.
In response you get a document you can make a decision by: scope of work by blocks, order of stages with dependencies, list of accesses and roles, testing plan, and control points where the result is visible before final acceptance.
Describe the task in free form — we'll come back with an estimate and work plan, and discuss controversial points separately.