TokenFi security record

The `registerLiquidityPool()` function is intended for recording tokenfi ERC20 liquidity pool information. However, the recorded information for the liquidity pool can be altered by any address since no access restrictions are applied to the `registerLiquidityPool()` function. **TokenLauncherStore.sol** ```solidity=145 function registerLiquidityPool(RegisterLiquidityPoolInput memory input) external override { liquidityPoolTokensByToken[input.tokenAddress].push(input.liquidityPoolToken); emit LiquidityPoolCreated(currentBlockLiquidityPoolCreated, input.liquidityPoolToken, input.tokenAddress); currentBlockLiquidityPoolCreated = block.number; } ``` Consequently, querying the corresponding liquidity pool for tokenfi ERC20 may yield inaccurate values in such instances. ```solidity=112 function getLiquidityPoolTokensByToken(address token) external view returns (address[] memory) { return liquidityPoolTokensByToken[token]; } ```

The `_swapFlokiByWeth()` function is designed to use Floki to buy WETH. However, the argument `amountOutMin` value is incorrect when calling `router.swapExactTokensForTokensSupportingFeeOnTransferTokens()` function to buy WETH. **IUniswapV2Router02.sol** ```solidity=24 function swapExactTokensForTokensSupportingFeeOnTransferTokens( uint amountIn, uint amountOutMin, address[] calldata path, address to, uint deadline ) external; ``` According to the `swapExactTokensForTokensSupportingFeeOnTransferTokens` function signature, the second argument `amountOutMin` denotes the minimum amount of exchanged out token assets, in this codebase, WETH. **TokenLauncherPaymentModuleV1.sol** ```solidity=149 // Calculate the required FLOKi for the expected USD amount address[] memory path = new address[](2); path[0] = router.WETH(); path[1] = address(usdToken); uint256[] memory amounts = router.getAmountsIn(usdExpected, path); path[1] = path[0]; path[0] = address(flokiToken); amounts = router.getAmountsIn(amounts[0], path); requiredFloki = (amounts[0] / 995) * 1000; // Account for FLOKI tax + buyback ``` After executing the statements from L149-L157, the items in `amounts` variable is `[Floki_in_amount, WETH_out_amount]`, so amounts[0] is the amount of Floki, not WETH. **TokenLauncherPaymentModuleV1.sol** ```solidity=165 router.swapExactTokensForTokensSupportingFeeOnTransferTokens(requiredFloki, amounts[0], path, address(this), block.timestamp); ``` When executing the statement at L165, it is incorrect that the second argument is passed in Floki amount.

According to the code logic of `_mintBatch()` function, each new minted NFT token has its own URI. However, the URIs aren't bound with the correct NFTs. **TokenFiERC721.sol** ```solidity=52 function _mintBatch( address _to, uint256 _amount, string[] memory _uris ) private { require(_uris.length == _amount, "TokenFiERC721: uris length does not match amount"); uint256 tokenId = totalSupply(); for (uint256 i = 0; i < _amount; i++) { _safeMint(_to, tokenId + i); if (bytes(_uris[i]).length > 0) { _setTokenURI(tokenId, _uris[i]); } } } ``` The local variable `tokenId` denotes the last NFT identifier and its value is unchanged in the `_mintBatch()` function scope. When executing the statement at L62, all the uris are bound with the last NFT.

**TokenLauncherERC20.sol** ```solidity=99 // if the source token is a tokenfi token, we need to add the new LP to the exchange pool if (ITokenLauncherStore(tokenLauncherStore).tokenOwner(input.liquidityPoolDetails.sourceToken) != address(0)) { if (!token.isExchangePool(lpOutput.liquidityPoolToken)) { token.addExchangePool(lpOutput.liquidityPoolToken); } if (token.isReflectionToken() && !token.isExcludedFromReflectionRewards(lpOutput.liquidityPoolToken)) { token.excludeAccount(lpOutput.liquidityPoolToken); } updateBuyBackDetails(input.buybackDetails, address(token)); } ``` The newly created LP token, designed for the TokenFiERC20 contract, is excluded from reflection only if the owner of the TokenFiERC20 contract has a non-zero address. Furthermore, when creating the TokenFiERC20 contract or updating its owner, the provided owner address can be set to zero. **TokenFiERC20.sol** ```solidity=90 if (_input.owner != address(0)) { _grantRole(DEFAULT_ADMIN_ROLE, _input.owner); } ``` **TokenLauncherStore.sol** ```solidity=45 function addToken(CreateTokenInput memory input) external override onlyRole(DEFAULT_ADMIN_ROLE) { tokensByOwnerByType[input.tokenType][input.owner].push(input.tokenAddress); tokenOwner[input.tokenAddress] = input.owner; ``` ```solidity=62 function updateTokenOwner(TokenType tokenType, address tokenAddress, address newOwner) external override { address owner = tokenOwner[tokenAddress]; require(msg.sender == owner, "TokenLauncherStore: Not owner"); require(owner != newOwner, "TokenLauncherStore: Same owner"); ``` In this scenario, if the owner of the TokenFiERC20 contract is set to the zero address by default, the liquidity pool remains unconfigured within the TokenFiERC20 contract. Consequently, the `Pair Address Reflection Exploit` issue persists (refer to FFF-01 Finding).

**TokenFiERC20.sol** ```solidity=85 tokenLauncher = msg.sender; _grantRole(DEFAULT_ADMIN_ROLE, _input.owner); _grantRole(FEE_MANAGER_ROLE, msg.sender); ``` When deploying TokenFiERC20 contract, the given token owner is granted to be `DEFAULT_ADMIN_ROLE` of that new deployed TokenFiERC20. If the owner is updated, its `DEFAULT_ADMIN_ROLE` ownership should be transferred to the new owner at the same time. The current code logic issue is that after calling `updateTokenOwner()` function, the original owner still has rights to exclude/include accounts, mint token, etc. **TokenLauncherStore.sol** ```solidity=49 function updateTokenOwner( uint8 tokenType, address tokenAddress, address newOwner ) external override { address owner = tokenOwner[tokenAddress]; require(msg.sender == owner, "TokenLauncherStore: Not owner"); require(owner != newOwner, "TokenLauncherStore: Same owner"); address[] storage tokens = _tokensByOwner[tokenType][owner]; for (uint256 i = 0; i < _tokensByOwner[tokenType][owner].length; i++) { if (_tokensByOwner[tokenType][owner][i] == tokenAddress) { _tokensByOwner[tokenType][owner][i] = _tokensByOwner[tokenType][owner][tokens.length - 1]; _tokensByOwner[tokenType][owner].pop(); break; } } _tokensByOwner[tokenType][newOwner].push(tokenAddress); tokenOwner[tokenAddress] = newOwner; emit TokenOwnerUpdated(currentBlockTokenOwnerUpdated, tokenType, owner, newOwner); currentBlockTokenOwnerUpdated = block.number; } ``` There is no code logic for transferring `DEFAULT_ADMIN_ROLE` ownership from the original to the new owner, however, the `tokenAddress` owner can be successfully updated. A similar issue also exists in the TokenFiERC721 and TokenFiERC1155 management.

The purpose of the `_mintReflection()` function is to mint RFI tokens. However, the minting operations performed via `_mintReflection()` may result in a decreased reflection rate. Consequently, assets held by users (excluding those who are excluded) become more valuable. This means that users receive rewards not only through reflect token transfer operations but also via reflect token minting operations. Furthermore, the recipient of the minted tokens gets rewards immediately after minting. **TokenFiERC20.sol** ```solidity=294 function _getRate() private view returns (uint256) { (uint256 rSupply, uint256 tSupply) = _getCurrentSupply(); return rSupply / tSupply; } function _getCurrentSupply() private view returns (uint256, uint256) { uint256 rSupply = _totalReflection.r; uint256 tSupply = _totalReflection.t; for (uint256 i = 0; i < _excluded.length; i++) { if (_rOwned[_excluded[i]] > rSupply || _tOwned[_excluded[i]] > tSupply) return (_totalReflection.r, _totalReflection.t); rSupply = rSupply - _rOwned[_excluded[i]]; tSupply = tSupply - _tOwned[_excluded[i]]; } if (rSupply < _totalReflection.r / _totalReflection.t) return (_totalReflection.r, _totalReflection.t); return (rSupply, tSupply); } ``` Let's assume that no holders are excluded, then $Rate = \frac{\_totalReflection.r}{\_totalReflection.t}$ . **TokenFiERC20.sol** ```solidity=392 function _mintReflection(address account, uint256 amount) private { _totalReflection.t = _totalReflection.t + amount; if (isExcluded(account)) { _tOwned[account] = _tOwned[account] + amount; } else { _rOwned[account] = _rOwned[account] + amount * _getRate(); } emit Transfer(address(0), account, amount); } ``` When the `_mintReflection()` function is executed along with the argument `account` that is not excluded, the $Rate = \frac{\_totalReflection.r}{\_totalReflection.t}$ becomes smaller because `_totalReflection.t` is increased and `_totalReflection.r` is unchanged. **TokenFiERC20.sol** ```solidity=152 function tokenFromReflection(uint256 rAmount) public view returns (uint256) { require(rAmount <= _totalReflection.r, "Amount must be less than total reflections"); uint256 currentRate = _getRate(); return rAmount / currentRate; } ``` After minting a reflect token, if you call the `tokenFromReflection()` function with the same `rAmount` value before minting, you will receive a larger balance value.

**TokenLauncherPaymentModuleV1.sol** ```solidity=76 flokiBurned = _processFlokiPayment(input.user, initialUsdBalance, usdExpected); ... return ProcessPaymentOutput(usdBurnShare, flokiBurned, referrerUsdShare, treasuryUsdShare); ``` **TokenLauncherPaymentModuleV1.sol** ```solidity=166 // Burn remaining FLOKI flokiToken.safeTransfer(burnAddress, flokiToken.balanceOf(address(this)) - initialFlokiBalance); ``` **TokenLauncherStore.sol** ```solidity=44 if (input.flokiBurned > 0) { _notifyFlokiBurned(input.tokenAddress, input.owner, input.usdBurned, input.flokiBurned); } ``` The variable `flokiBurned` represents the amount of Floki burned during the execution of the `_processFlokiPayment()` function. This value is intended to be returned to the caller, the `TokenLauncherERC20` contract, and ultimately included in a Floki burn notification within the `TokenLauncherStore` contract. However, it's worth noting that the variable `flokiBurned` is consistently assigned a value of zero at line 76. After the `_processFlokiPayment()` function finishes, the variable `flokiBurned` returned at line 123 is not given a value. **TokenLauncherPaymentModuleV1.sol** ```solidity=119 function _processFlokiPayment( address user, uint256 initialUsdBalance, uint256 usdAmount ) private returns (uint256 flokiBurned) { uint256 usdBasisPoints = 10000 - burnBasisPoints; // we don't need the entire usdPrice swapped (some FLOKI will be burned) uint256 usdExpected = (usdAmount * usdBasisPoints) / 10000; (uint256 requiredFloki, uint256 initialFlokiBalance, uint256 receivedFloki, uint256 initialWethBalance, uint256 flokiToBurn) = _swapFlokiByWeth( user, usdBasisPoints, usdExpected ); _swapWethByUsd(user, usdExpected, initialUsdBalance, usdBasisPoints, initialWethBalance); } ```

According to the launch code logic of the `TokenFiERC20` contract, it is essential to note that, by default, the liquidity pair address is not excluded from reflection rewards, making it to receive rewards during reflection transfers. In this case, a hacker can exploit the protocol using the reflection mechanism. **TokenFiERC20.sol** ```solidity=152 function tokenFromReflection(uint256 rAmount) public view returns (uint256) { require(rAmount <= _totalReflection.r, "Amount must be less than total reflections"); uint256 currentRate = _getRate(); return rAmount / currentRate; } ``` The RFI token balance that include rewards is calculated by $\frac{rAmount}{currentRate}$. When decreasing rate, the reflection balance will be increased. **TokenFiERC20.sol** ```solidity=132 function reflect(uint256 tAmount) external onlyReflection { address sender = _msgSender(); require(!isExcluded(sender), "Excluded addresses cannot call this function"); (uint256 rAmount, , , , ) = _getValues(tAmount, false); _rOwned[sender] = _rOwned[sender] - rAmount; _totalReflection.r = _totalReflection.r - rAmount; _totalReflection.tFee = _totalReflection.tFee + tAmount; } ``` And the aforementioned `currentRate` is determined by the $\frac{\_totalReflection.r }{\_totalReflection.t}$. If the `reflect()` function is executed with significant input, it can significantly decrease `_totalReflection.r`, thereby decreasing the rate. Reflection balance will be significantly increased. When the liquidity pair receives reflection rewards, it's crucial to recognize that the RFI token reserve in the pair is not immediately updated. This delay persists until the occurrence of the next swap, mint, burn, or sync operation (as outlined in the [UniswapV2Pair.sol](https://github.com/Uniswap/v2-core/blob/ee547b17853e71ed4e0101ccfd52e70d5acded58/contracts/UniswapV2Pair.sol#L73C99-L73C99) code). During this interim period, the RFI token balance exceeds its reserve in the liquidity pair. The attacker can uses the above exceeded RFI token assets to swap out significant assets.

```solidity=129 function updateFees(ITokenLauncherERC20.Fees memory _fees) external onlyRole(DEFAULT_ADMIN_ROLE) { uint256 maxFee = _fees.transferFee.percentage + _fees.burn.percentage + _fees.reflection.percentage + _fees.buyback.percentage; require(maxFee <= MULTIPLIER_BASIS, "TokenFiERC20: fees sum must be less than 100%"); fees = _fees; } ``` The `DEFAULT_ADMIN_ROLE` role account can update `fees.reflection.percentage` value. In this case, 1. After updating `fees.reflection.percentage` from zero to non-zero value, normal ERC20 token contract becomes reflection token contract. In this case, even though Alice holds normal token assets, the `balanceOf(Alice)` function call may return zero because `_rOwned[Alice]=0`. 3. After updating `fees.reflection.percentage` from non-zero to zero value, reflection token contract becomes normal ERC20 token contract. In this case, even though Alice holds reflection token assets, the `balanceOf(Alice)` function call may return zero because `_balances[Alice]=0`.

The modifier `supplyAvailable()` is designed to restrict the token amount in circulation. The current code logic issue is that the modifier `supplyAvailable()` cannot avoid overissuance. **TokenFiERC721.sol** ```solidity=193 modifier supplyAvailable() { require(totalSupply() < maxSupply, "TokenFiERC721: maxSupply reached"); _; } ``` When calling `adminMintBatch()` function to mint token, if `totalSupply() + amount` is greater than `maxSupply`, the `adminMintBatch()` still can be successfully executed because the modifier `supplyAvailable()` doesn't take the new minted token amount into account. Finally, the totalSupply exceeds the maxSupply. **TokenFiERC721.sol** ```solidity=73 function adminMintBatch( address _to, string[] memory _uris, uint256 _amount ) external adminMintAvailable whenNotPaused supplyAvailable onlyRole(DEFAULT_ADMIN_ROLE) { _mintBatch(_to, _amount, _uris); } ``` A similar issue also exists in `TokenFiERC1155` contract.