nestonexStart a project How do ERC20, BEP20, TRC20 and SPL actually differ when you have to pay people on all four?
ERC20 and BEP20 are near-identical, because BNB Chain copied Ethereum's execution model. TRC20 keeps the same interface on a different fee model, where bandwidth and energy replace gas. SPL is structurally different: balances live in separate token accounts rather than a mapping inside the token contract.
Because functionally they are. BNB Chain is EVM-compatible, so a BEP20 token exposes the same interface as an ERC20 one: the same transfer, the same approve and transferFrom, the same event signatures. Code written against one generally works against the other with a different RPC endpoint and chain ID.
What differs is everything around the contract. Fees are far lower, blocks are faster, and the validator set is smaller and more concentrated. Those are operational and trust differences rather than integration ones.
TRC20 keeps the familiar interface but changes how you pay for it. Instead of gas, TRON uses bandwidth and energy, resources you obtain by freezing TRX or by burning it at execution time.
That means a TRON account can hold plenty of tokens and still be unable to move them, because it has no energy. It is a failure mode with no direct equivalent on Ethereum, and one that catches payout systems the first time an account runs dry.
Addresses are formatted differently too, base58 rather than hex, so validation and display cannot be shared with the EVM path.
On EVM chains a token contract holds a mapping from address to balance. On Solana it does not. Balances live in separate token accounts, one per owner per mint, and the associated token account is derived deterministically from the two.
The practical consequence is that you may have to create the recipient's token account before you can send them anything, and creating it costs rent. A transfer to someone who has never held that token is therefore two operations, not one.
Native SOL adds another wrinkle: it is not an SPL token, so moving SOL and moving an SPL token are different code paths on the same chain.
Assuming a transfer is a transfer. Written against one chain and generalised, a payout service will work in testing and then fail in production against a recipient with no SPL token account, or a TRON account with no energy, or an EVM transfer where the nonce was reused.
None of these look alike, and none of them are caught by a shared interface. They are caught by writing an adapter per chain and being honest that the shared part is smaller than it appears.
A thin adapter per chain holding the parts that genuinely differ, and everything above it shared: batching approved payouts, signing from the hot wallet, and reconciling transaction hashes back to the ledger.
Trade Rewards settles rebates, referrals and game winnings across Ethereum, BNB Chain, TRON and Solana, covering all four standards plus native SOL. Payouts are batched per chain and released only after admin approval, so the differences stay contained in the adapter layer.
The address formats are identical, which is exactly why this goes wrong. Sending an ERC20 token to an address on BNB Chain does not move it across chains; it sends on Ethereum to an address whose owner may have no key path there. Chains are not interchangeable just because address formats are.
Because the recipient has no token account for that mint yet. On Solana balances live in per-owner token accounts rather than inside the token contract, so sending to someone who has never held that token requires creating their associated token account first, which costs rent.
Gas is bought with the chain's native currency at execution time. TRON's energy and bandwidth are resources you obtain by freezing TRX, or burn TRX to cover. An account can hold tokens and still be unable to transfer them because it has no energy, which has no direct EVM equivalent.
Per chain rather than per standard. ERC20 and BEP20 share an address derivation, so one EVM key covers both. TRON and Solana use different derivation and address formats and need their own keys and their own adapters.