Rewards, referrals and payouts across four chains.
Put a human in front of the hot wallet. Trade Rewards accumulates rebates, referrals and game winnings in a single points ledger, and nothing leaves until an admin approves the withdrawal. Approved requests are then batched per chain and signed for ERC20, BEP20, TRC20 and SPL tokens plus native SOL.
Because earnings arrive from several unrelated places. A trading rebate, a multi-level referral commission and a spin-wheel prize have nothing in common except that they all become a balance someone can withdraw.
Recording every credit and debit in one ledger means there is a single answer to what a user is owed. Without that, reconciling a payout against three separate subsystems becomes guesswork the moment anything disagrees.
Because a hot wallet with automatic release is a standing invitation. Reward systems attract abuse in a way that ordinary payments do not, since the whole design is to give money away for activity, and activity can be manufactured.
Approval is the control that makes the rest tolerable. It means an exploit that inflates a balance still has to get past someone before it becomes a transfer, and the cost of that check is a delay rather than a loss.
Approved withdrawals are grouped per chain before signing, so a hundred small payouts on one network become one signing operation rather than a hundred.
That matters for fees and it matters for key exposure. Every signing operation is a moment the hot wallet is in use, and batching reduces how often that happens.
More than it looks. ERC20 on Ethereum, BEP20 on BNB Chain, TRC20 on TRON and SPL on Solana each have their own transfer semantics, and native SOL behaves differently again from the SPL tokens beside it.
Each sits behind its own adapter with the batching and approval logic shared above it, so the differences are contained rather than spread through the payout path.
By running on the same ledger as everything else. Spin-wheel results and the raffle lifecycle, which opens, draws and settles on a cron schedule, credit the ledger like any other earning rather than existing in a parallel scoring system.
Leaderboards and multi-level referral trees read from the same source, so a rank and a balance cannot disagree.
A rebate and referral platform with safe, multi-chain settlement covering ERC20, BEP20, TRC20 and SPL tokens plus native SOL.
| Earning sources | Trading rebates, multi-level referrals, gamified rewards |
|---|---|
| Ledger | Single points ledger, every credit and debit recorded |
| Release control | Admin-approved withdrawals only |
| Settlement | Batched per chain, hot-wallet signing |
| Chains | Ethereum, BNB Chain, TRON, Solana |
| Token standards | ERC20, BEP20, TRC20, SPL, plus native SOL |
| Gamification | Spin wheel and cron-driven raffle lifecycle |
| Reconciliation | Transaction hashes settled back to the ledger |
Generally not from a hot wallet. Reward systems are designed to give money away for activity, and activity can be faked, so automatic release turns any exploit directly into a loss. Requiring admin approval converts that into a delay instead, which is a far cheaper failure.
Two reasons: fees and key exposure. Grouping approved withdrawals per chain turns many signing operations into one, which cuts cost and reduces how often the hot wallet is actually in use. Each signing moment is a risk window worth minimising.
They are token standards on different chains: ERC20 on Ethereum, BEP20 on BNB Chain, TRC20 on TRON and SPL on Solana. Transfer semantics differ enough that each needs its own adapter, and native SOL behaves differently again from the SPL tokens on the same chain.
So there is a single answer to what a user is owed. Rebates, referral commissions and prize winnings arrive from unrelated subsystems, and reconciling a payout across three separate balances becomes guesswork as soon as any of them disagree.
A cross-exchange trading engine where correctness is the feature.