CertiK reviewed AiEternal (AIEternal - Audit) on 27 Jul 2023: 8 findings, 0 critical; 2 acknowledged, 6 open.
Report hosted on skynet.certik.com.
Trustblock does not review code.
Statuses are the security firm’s own, from its report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 0 | 2 | 0 |
| Medium | 0 | 0 | 0 |
| Low | 6 | 0 | 0 |
If `msg.value > serviceFee_`, the excess Ether held in this contract will not be returned to the user's account. Consequently, the caller will end up paying more than what is actually required.
Addresses are not validated before assignment or external calls, potentially allowing the use of zero addresses and leading to unexpected behavior or vulnerabilities. For example, transferring tokens to a zero address can result in a permanent loss of those tokens. ```solidity=477 payable(serviceFeeReceiver_).transfer(serviceFee_); ``` - `serviceFeeReceiver_` is not zero-checked before being used.
The methods `increaseApproval` and `decreaseApproval` are unsafe. Here is the scenario: 1. Bob is allowed to transfer zero Alice's tokens. 2. Alice allows Bob to transfer 100 of here tokens via approve or `increaseApproval` method and transaction is executed successfully. 3. Alice sees that Bob is now allowed to transfer 100 of her tokens. 4. After some time, Alice uses `decreaseApproval` method to decrease by 100 the number of her tokens Bob is allowed to transfer, and transaction is executed successfully and proper Approval event was logged. 5. Alice sees that Bob is allowed to transfer 0 of her tokens. 6. Now Alice may think that once `decreaseApproval` transaction was executed successfully, then Bob didn't manage to transfer any of her tokens before the allowance was decreased, but this assumption is wrong. 7. Actually, Bob may or may not have transferred Alice's tokens before allowance was decreased, and Alice has no easy way to know for sure whether Bob transferred her tokens or not.
The `approve()` and `transferFrom()` functions could be used in an attack that allows a spender to transfer more tokens than the owner of the tokens ever wanted to allow the spender to transfer. Here is a possible attack scenario: - Alice allows Bob to transfer N of Alice's tokens (N>0) by calling approve method on Token smart contract passing Bob's address and N as method arguments. - After some time, Alice decides to change from N to M (M>0) the number of Alice's tokens Bob is allowed to transfer, so she calls approve method again, this time passing Bob's address and M as method arguments. - Bob notices Alice's second transaction before it was mined and quickly sends another transaction that calls the `transferFrom()` function to transfer N Alice's tokens somewhere. - If Bob's transaction is executed before Alice's transaction, then Bob will successfully transfer N Alice's tokens and will gain the ability to transfer another M tokens. - Before Alice noticed that something went wrong, Bob calls `transferFrom()` again, this time to transfer M Alice's tokens - So, Alice's attempt to change Bob's allowance from N to M (N>0 and M>0) made it possible for Bob to transfer N+M of Alice's tokens, while Alice never wanted to allow so many of her tokens to be transferred by Bob. ERC20 API: [An Attack Vector on Approve/TransferFrom Methods](https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/edit#heading=h.m9fhqynw2xvt)
The `SafeMath` library is used unnecessarily. With Solidity compiler versions 0.8.0 or newer, arithmetic operations will automatically revert in case of integer overflow or underflow. ```solidity=201 library SafeMath { ``` - An implementation of `SafeMath` library is found. --- ```solidity=450 using SafeMath for uint256; ``` - `SafeMath` library is used for `uint256` type in `StandardToken` contract. ```solidity=599 _approve( sender, _msgSender(), _allowances[sender][_msgSender()].sub( amount, "ERC20: transfer amount exceeds allowance" ) ); ``` - `SafeMath.sub` is called in `transferFrom` function of `StandardToken` contract. *Note: Only a sample of 2 `SafeMath` library usage in this contract (out of 10) are shown above.*
It is not recommended to use Solidity's `transfer()` and `send()` functions for transferring native tokens, since some contracts may not be able to receive the funds. Those functions forward only a fixed amount of gas (2300 specifically) and the receiving contracts may run out of gas before finishing the transfer. Also, EVM instructions' gas costs may increase in the future. Thus, some contracts that can receive now may stop working in the future due to the gas limitation. ```solidity=477 payable(serviceFeeReceiver_).transfer(serviceFee_); ``` - `StandardToken.constructor` uses `transfer()`.
| Address | Chain | Source code |
|---|---|---|
| 0x1010…fb520x1010e325e2171269b1320f6d02bb1758b861fb52 | Chain: BNB Chain | Source code: Verified source |
1,044 projects reviewed · 1,375 reports · latest May 2025
See CertiK’s auditsSomething wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.
Tell us