balance

The `m_receiveAddr` is not assigned a default value during initialization which raises a concern: If a whitelist token is set up but the receiver address(`m_receiveAddr`) is not properly configured, users might inadvertently send tokens to the address(0).

Both `TopUpTron` and `TopUpV1` include a `receive()` function to collect native tokens. The concern arises if the team intends to enable native tokens to be whitelisted and uses the contracts themselves as the receiver address. In this case, the payment record may not be updated, and may need further modification on `receive()` function.

When transferring deflationary ERC20 tokens, the input amount may not be equal to the received amount due to the charged transaction fee. For example, if a user sends 100 deflationary tokens (with a 10% transaction fee),, only 90 tokens actually arrived to the contract. However, a failure to discount such fees may allow the same user to withdraw 100 tokens from the contract, which causes the contract to lose 10 tokens in such a transaction. Reference: https://thoreum-finance.medium.com/what-exploit-happened-today-for-gocerberus-and-garuda-also-for-lokum-ybear-piggy-caramelswap-3943ee23a39f ```solidity=78 bool bTransRet = erc20_token.transferFrom(msg.sender, m_receiveAddr, topup_amount); ``` - Transferring tokens by `topup_amount`. ```solidity=81 userPopupAmount[msg.sender][erc20_topup_token] += topup_amount; ``` - The `topup_amount` appears to be used for bookkeeping purposes without compensating the potential transfer fees. ```solidity=102 bool bTransRet = erc20_token.transferFrom(msg.sender, m_receiveAddr, topup_amount); ``` - Transferring tokens by `topup_amount`. ```solidity=104 userPopupAmount[msg.sender][erc20_topup_token].add(topup_amount); ``` - This function call executes the following operation. - In `SafeMath.add`, - `return a + b;` - The `topup_amount` appears to be used for bookkeeping purposes without compensating the potential transfer fees.

The return values of the `transfer()` and `transferFrom()` calls in the smart contract are not checked. Some ERC-20 tokens' transfer functions return no values, while others return a bool value, they should be handled with care. If a function returns `false` instead of reverting upon failure, an unchecked failed transfer could be mistakenly considered successful in the contract. ```solidity=58 _token.transfer(receiptAddr, withdrawAmount); ``` Non-standard ERC20 token like USDT on Ethereum mainnet, its `transfer` and `transferFrom` functions do not yield a return value. If the input token refers to USDT, any attempt to transfer USDT using these functions will result in a revert. ```solidity=78 bool bTransRet = erc20_token.transferFrom(msg.sender, m_receiveAddr, topup_amount); ```

The linked comments appear to be inconsistent with the implementation.

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

The cited address is missing a check that it is not `address(0)` while updating. - `TopUpTron::validToken` - `TopUpTron::m_receiveAddr` - `TopUpV1::validToken` - `TopUpV1::m_receiveAddr`

The payment amount in the Solana contract is subject to a restriction (`MIN_RECHARGE_AMOUNT`), which sets a minimum limit. However, this restriction does not apply to Aptos and Solidity contracts.

Both Aptos and Solana contracts are designed to emit events when users make payments, without requiring additional storage to track user payments as is done in Solidity contracts.

The linked packages in `TopUpV1` does not being used: - import "@openzeppelin/contracts-upgradeable/security/ReentrancyGuardUpgradeable.sol"; - import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol"; - import "@openzeppelin/contracts-upgradeable/utils/CountersUpgradeable.sol"; - import "@openzeppelin/contracts-upgradeable/utils/structs/EnumerableMapUpgradeable.sol";