Reward deposits are shared by holder weight, and burn fees go straight to the burn address. Both run automatically on chain, inside the token itself. Plus gasless sends and one-tap payments.
Contract address
0x31205C42eA3e6320BEce833D167A0d3562C8176D
Metrics unavailable right now. Retries every minute.
What makes it super
A standard ERC20 moves numbers between addresses. SuperToken does that and settles rewards, burns transfer fees, verifies signatures, and calls contracts on the same transfer path.
Every deposit into the reward pool raises a single on-chain counter. Your share is your balance times how far that counter has moved since you were last settled. Settlement happens automatically whenever you send or receive, so there is nothing to claim and no keeper that can fall behind.
No database. No cron job. No hot wallet doing payouts at 3am.
Read the mathOn transfers and trades where the burn fee applies, the token contract takes a portion of the tokens and sends it straight to the burn address in the same transaction. Just like rewards, the burn runs entirely on chain.
No keeper. No scheduled burns. Every burn recorded on chain.
Liquidity pools, the treasury, and burn addresses are excluded from the denominator. If only a tenth of supply is in holders' hands, holding 1% of supply earns you 10% of every deposit.
Sign a transfer authorization in your wallet and a relayer submits it. The signature is replay-protected on chain, and the tokens move exactly as if you had sent them yourself.
Transfer-and-call lets you send tokens and trigger the receiving contract in the same transaction. The approve-then-act two-step is gone.
An optional transfer fee routes straight into the reward pool inside the same transaction. Swaps are transfers too, so trading volume becomes holder yield without any extra hook.
How rewards work
This is the Synthetix staking-rewards accumulator applied directly to a token. It costs a few storage reads per transfer and never loops over holders.
Anyone can deposit into the pool, and the transfer fee deposits on every send. The contract divides the deposit by eligible supply and adds the result to one global counter.
The next time you send or receive, the contract multiplies your balance by how far the counter moved since your last checkpoint and credits you the difference.
Credited rewards land in your balance in the same transaction. A view function shows what's pending, and a claim function exists if you want to pull without transferring.
// on every reward deposit
rewardPerToken += amount * 1e18 / eligibleSupply;
// what a holder is owed, computed on read
function earned(address a) view returns (uint256) {
return balanceOf(a)
* (rewardPerToken - checkpoint[a]) / 1e18
+ owed[a];
}
// settle both sides inside the transfer path
function _beforeTokenTransfer(address from, address to, uint256) {
_settle(from);
_settle(to);
}
// excluded addresses never count toward the denominator
if (!isExcluded[to]) eligibleSupply += amount;
if (!isExcluded[from]) eligibleSupply -= amount;Conservation
The sum of what every holder is owed never exceeds the pool balance. This is a fuzzed invariant in the test suite, not a promise.
No retroactive earning
An address added to the eligible set starts from the current counter. It cannot collect rewards from before it joined.
No owner drain
There is no rescue or withdraw function for the pool. Tokens leave it only through the reward math.
Balances never rebase
Wallet balances only change on transfers and reward settlement, so the token works in Uniswap V3 and V4 pools without special handling.
The contract
Robinhood Chain is an Arbitrum L2 with ETH gas. Use Blockscout to inspect the contract, token balances, and transfers directly on chain.
Contract address
0x31205C42eA3e6320BEce833D167A0d3562C8176D