Imagine your smart contract stops working at 1000 holders, each transaction exhausts the gas limit — this is the reality of naive reflection implementations. Not long ago, a client came with a contract where the excluded array reached 500 addresses: any operation would exceed the gas limit. With over 5 years in blockchain development, we have implemented dozens of tokens with an O(1) algorithm that works regardless of holder count. We develop such tokens turnkey, including audit and gas optimization. Let's break down the mechanics, typical mistakes, and protective measures. Get a consultation from an engineer for your project.
How does a reflection token save gas?
The mechanism is based on two types of balances: rBalance (reflection balance) and tBalance (token balance). Holders store rBalance, which automatically grows with each transaction. Instead of redistributing tokens, the contract changes the conversion rate rBalance → tBalance by decreasing rTotal by the fee amount. This increases rate = rTotal / tTotal for all others. More details in Solidity (Solidity).
Full listing of ReflectionToken contract
```solidity contract ReflectionToken is IERC20, Ownable { uint256 private constant MAX = ~uint256(0);uint256 private _tTotal; uint256 private _rTotal; uint256 private _tFeeTotal; uint256 public taxFee = 5; uint256 public liquidityFee = 3; uint256 public burnFee = 2; mapping(address => uint256) private _rOwned; mapping(address => uint256) private _tOwned; mapping(address => bool) private _isExcluded; constructor(uint256 totalSupply) { _tTotal = totalSupply * 10**18; _rTotal = (MAX - (MAX % _tTotal)); _rOwned[msg.sender] = _rTotal; } function _getRate() private view returns (uint256) { (uint256 rSupply, uint256 tSupply) = _getCurrentSupply(); return rSupply / tSupply; } function _getCurrentSupply() private view returns (uint256, uint256) { uint256 rSupply = _rTotal; uint256 tSupply = _tTotal; for (uint256 i = 0; i < _excluded.length; i++) { if (_rOwned[_excluded[i]] > rSupply || _tOwned[_excluded[i]] > tSupply) return (_rTotal, _tTotal); rSupply -= _rOwned[_excluded[i]]; tSupply -= _tOwned[_excluded[i]]; } if (rSupply < _rTotal / _tTotal) return (_rTotal, _tTotal); return (rSupply, tSupply); } function balanceOf(address account) public view returns (uint256) { if (_isExcluded[account]) return _tOwned[account]; return tokenFromReflection(_rOwned[account]); } function tokenFromReflection(uint256 rAmount) public view returns (uint256) { require(rAmount <= _rTotal, "Amount too large"); return rAmount / _getRate(); } function _transferStandard(address sender, address recipient, uint256 tAmount) private { (uint256 rAmount, uint256 rTransferAmount, uint256 rFee, uint256 tTransferAmount, uint256 tFee, uint256 tLiquidity, uint256 tBurn) = _getValues(tAmount); _rOwned[sender] -= rAmount; _rOwned[recipient] += rTransferAmount; _reflectFee(rFee, tFee); _takeLiquidity(tLiquidity); _burn(sender, tBurn); emit Transfer(sender, recipient, tTransferAmount); } function _reflectFee(uint256 rFee, uint256 tFee) private { _rTotal -= rFee; _tFeeTotal += tFee; } }
</details> Naive iteration over all holders consumes 50 times more gas than O(1) reflection. At 10,000 holders, one transaction can cost 5 million gas, while O(1) costs only 100 thousand. The O(1) implementation is more efficient than naive iteration in terms of gas, as confirmed by the table below. ### Why are excluded pool addresses critical? Liquidity pool addresses (Uniswap pair, PancakeSwap pair) must be excluded from reflection. If the pool participates in reflection, its token balance constantly grows, disrupting the token/ETH ratio in the pool and creating arbitrage opportunities. This is a classic mistake in early reflection tokens. We include this point in every audit checklist. ```solidity function excludeFromReward(address account) public onlyOwner { require(!_isExcluded[account], "Already excluded"); if (_rOwned[account] > 0) { _tOwned[account] = tokenFromReflection(_rOwned[account]); } _isExcluded[account] = true; _excluded.push(account); } Comparison of O(1) and naive implementation: How much better?
| Parameter | Naive implementation (iteration) | O(1) via reflection |
|---|---|---|
| Transaction complexity | O(N) | O(1) |
| Gas at 10,000 holders | ~5,000,000 gas | ~100,000 gas |
| Scalability | Drops at >500 holders | Unlimited |
| Risk of gas limit exceeded | High | None |
O(1) implementation consumes 50 times less gas and is independent of holder count. Savings on transaction fees reach 90%. Order development of a reflection token — we will prepare a detailed plan in 7–14 days.
How to test a reflection token before deployment?
We use static analysis with Slither to identify code vulnerabilities, symbolic execution with Mythril to find error paths, and fuzzing with Echidna to verify correct distribution under random parameters. We also run integration tests on a mainnet fork to check gas limits and correctness of excluded addresses.
Vulnerabilities in reflection tokens and their prevention
- Iteration over excluded: the
_getCurrentSupply()function iterates over the excluded array. If the array is large — gas limit exceeded. We limit array length and allow only owner to add. - Precision loss: with a huge number of transactions,
_rTotalcan become too small,_getRate()returns 0. InvariantrTotal > tTotal * minRateis checked in tests. - Anti-whale measures: we add
maxTransactionAmount(1% of supply) andmaxWalletToken(2%).
uint256 public maxTxAmount = _tTotal / 100; uint256 public maxWalletToken = _tTotal / 50; function _transfer(address from, address to, uint256 amount) internal { require(amount <= maxTxAmount, "Exceeds max tx"); if (!_isExcluded[to]) { require(balanceOf(to) + amount <= maxWalletToken, "Exceeds max wallet"); } // ... } Typical fees and their purpose
| Fee type | Typical tax | Purpose |
|---|---|---|
| Reflection | 2–5% | Reward holders |
| Liquidity | 2–3% | Automatic pool top-up |
| Burn | 0–2% | Supply deflation |
Total fee should not exceed 8%, otherwise the token becomes economically dysfunctional.
How to implement a reflection token in 5 steps?
- Analytics and design: specification of mechanics (tax, liquidity, burn, anti-whale).
- Contract development in Solidity 0.8.x using Foundry or Hardhat.
- Testing: unit tests, fuzzing with Echidna, integration tests on mainnet fork to verify correct distribution and gas limits.
- Audit: static analysis with Slither + symbolic execution with Mythril according to a 30+ point checklist.
- Documentation and deployment support: help with liquidity pool selection and excluded address configuration.
What is included in turnkey reflection token development
- Specification of mechanics (tax, liquidity, burn, anti-whale) with parameter justification.
- Source code of the contract in Solidity 0.8.x with comments.
- Set of unit tests and tests on mainnet fork.
- Audit report with vulnerability analysis (Slither, Mythril, Echidna).
- Deployment instructions and configuration of excluded pool addresses.
- Support for 1 month after deployment.
Auto-liquidity mechanism: why is it needed?
Accumulated liquidityFee is periodically converted into LP tokens via a DEX. The inSwapAndLiquify flag prevents recursive calls. The mechanism maintains liquidity without team intervention, automatically adding pairs to decentralized exchanges.
We guarantee that the contract will pass checks for known vulnerabilities (reentrancy, flash loan attacks, precision loss). Get a consultation from an engineer for your project. Contact us for an assessment.