The audit makes no statements or warranties about utility of the code, safety of the code, suitability of the business model, investment advice, endorsement of the platform or its products, regulatory regime for the business model, or any other statements about fitness of the contracts to purpose, or their bug free status. The audit documentation is for discussion purposes only. The information presented in this report is confidential and privileged. If you are reading this report, you agree to keep it confidential, not to copy, disclose or disseminate without the agreement of the Client. If you are not the intended recipient(s) of this document, please note that any disclosure, copying or dissemination of its content is strictly forbidden.
A group of auditors are involved in the work on the audit. The security engineers check the provided source code independently of each other in accordance with the methodology described below:
- Project documentation review.
- General code review.
- Reverse research and study of the project architecture on the source code alone.
- Build an independent view of the project's architecture.
- Identifying logical flaws.
- Manual code check for vulnerabilities listed on the Contractor's internal checklist. The Contractor's checklist is constantly updated based on the analysis of hacks, research, and audit of the clients' codes.
- Code check with the use of static analyzers (i.e Slither, Mythril, etc).
Eliminate typical vulnerabilities (e.g. reentrancy, gas limit, flash loan attacks etc.).
- Detailed study of the project documentation.
- Examination of contracts tests.
- Examination of comments in code.
- Comparison of the desired model obtained during the study with the reversed view obtained during the blind audit.
- Exploits PoC development with the use of such programs as Brownie and Hardhat.
Detect inconsistencies with the desired model.
- Cross check: each auditor reviews the reports of the others.
- Discussion of the issues found by the auditors.
- Issuance of an interim audit report.
- Double-check all the found issues to make sure they are relevant and the determined threat level is correct.
- Provide the Client with an interim report.
- The Client either fixes the issues or provides comments on the issues found by the auditors. Feedback from the Customer must be received on every issue/bug so that the Contractor can assign them a status (either "fixed" or "acknowledged").
- Upon completion of the bug fixing, the auditors double-check each fix and assign it a specific status, providing a proof link to the fix.
- A re-audited report is issued.
- Verify the fixed code version with all the recommendations and its statuses.
- Provide the Client with a re-audited report.
- The Customer deploys the re-audited source code on the mainnet.
- The Contractor verifies the deployed code with the re-audited version and checks them for compliance.
- If the versions of the code match, the Contractor issues a public audit report.
- Conduct the final check of the code deployed on the mainnet.
- Provide the Customer with a public audit report.
All vulnerabilities discovered during the audit are classified based on their potential severity and have the following classification:
| Severity | Description |
|---|---|
| Critical | Bugs leading to assets theft, fund access locking, or any other loss of funds. |
| High | Bugs that can trigger a contract failure. Further recovery is possible only by manual modification of the contract state or replacement. |
| Medium | Bugs that can break the intended contract logic or expose it to DoS attacks, but do not cause direct loss funds. |
| Low | Bugs that do not have a significant immediate impact and could be easily fixed. |
Based on the feedback received from the Customer regarding the list of findings discovered by the Contractor, they are assigned the following statuses:
| Status | Description |
|---|---|
| Fixed | Recommended fixes have been made to the project code and no longer affect its security. |
| Acknowledged | The Customer is aware of the finding. Recommendations for the finding are planned to be resolved in the future. |
The StataToken is an EIP-4626 generic token vault/wrapper intended to be used with Aave v3 aTokens. More precisely, this is the second version of stata tokens.
The implementation is separated into two ERC20 extensions and one actual "merger" contract stitching functionality together:
ERC20AaveLMis an abstract contract implementing the forwarding of liquidity mining.ERC4626StataTokenis an abstract contract implementing the EIP-4626 methods for an underlying aToken.StataTokenV2is the main contract inheritingERC20AaveLMandERC4626StataToken, while also addingPausability,Rescuability,Permitand the actual initialization.
| Title | Description |
|---|---|
| Client | Aave DAO (Code Developed by BGD Labs) |
| Project name | StataTokenV2 |
| Timeline | 25.09.2024-03.12.2024 |
| Number of Auditors | 3 |
| Date | Commit Hash | Note |
|---|---|---|
| 25.09.2024 | f02fcb2d6ac2e08aa6bf6a8a0d38f6786cc1809a | Commit for the audit |
| 07.11.2024 | c2f6db7984a2129831eca288bab2431434ed4d7c | Commit for the re-audit |
| 03.12.2024 | 665b480ab89a62b0b3b9dbab21479292b3142772 | Commit with updates |
The audit covered the following files:
| Severity | # of Findings |
|---|---|
| CRITICAL | 0 |
| HIGH | 0 |
| MEDIUM | 0 |
| LOW | 5 |
Aave StataToken combines an ERC4626 vault with a reward distribution system. Therefore, in this audit, we paid special attention to attacks on ERC-4626 vaults and errors in rewards distribution.
Key vectors examined for the ERC-4626 contract ERC4626StataToken:
- We checked for rounding errors in either direction during minting and burning of assets. Everything is implemented correctly since the functions
_convertToShares()and_convertToAssets()use the appropriateMath.Rounding. - An inflation attack via the influence of the AToken balance on the contract is impossible since the exchange rate does not depend on it.
- We also verified the correct inheritance of the OpenZeppelin ERC-4626 contract. The functions
maxMint(),maxWithdraw(),maxDeposit(), andmaxRedeem()have been overridden considering that the Aave pool might be inactive, paused, frozen, or have a supply cap. The_withdraw()and_deposit()functions are also correctly overridden, except for minor potential discrepancies between the AToken balance and the underlying asset.
Key vectors tested for rewards distribution in ERC20AaveLM:
- Users cannot steal another user's rewards; they must be either the registered claimer or the
msg.sender(who owns the rewards). - If there are not enough rewards in the
StataTokenV2contract, the user can claim part of the rewards, and the remaining amount is stored in theunclaimedRewardsvariable. Once theStataTokenV2contract is replenished with rewards, the user can easily claim the remaining rewards. - We verified the correctness of tracking integral indices when initializing a new reward token, as well as during transfers, minting, and burning of shares. The tracking works correctly, with checkpoints occurring before any operations.
- Failure to accrue rewards to users due to delayed registration of a reward token. This issue exists.
- There is no possibility of a yield-stealing attack (mint and burn shares via flashloan within a single block). If a reward token is not registered and an attacker registers it in the same block as a flashloan, they still cannot steal previously unregistered rewards, as reward distribution is measured from the time of registration. This is also impossible for an already registered token, as user index checkpoints are made before any operation.
- Sending a "poisonous" token instead of a reward token to various user functions does not lead to issues, as there are checks to ensure the token is registered by the admin.
- We also verified that users can receive their pending rewards after their shares are burned.
We also went through our detailed checklist, covering other aspects such as business logic, common ERC20 issues, interactions with external contracts, integer overflows, reentrancy attacks, access control, and other potential issues.
No significant vulnerabilities were found.
Key notes and recommendations:
- The rewards array only has a push method and lacks a pop method. Although reward addresses can only be added by the admin in the
INCENTIVES_CONTROLLERcontract, there is a low probability of a DoS whenStataTokenV2._update()is triggered if the admin adds too many reward tokens to the contract. - Until an existing reward token is registered, rewards will accumulate but not be distributed to users. The admin can forcibly withdraw these rewards, but users may be demotivated by the possibility of missing out on a portion of their rewards.
- In case of an emergency, contracts can be paused, and a rescue guardian can transfer tokens (except ATokens backed by shares) and ETH from the contract.
Not found.
Not found.
Not found.
Fixed in https://github.com/bgd-labs/aave-v3-origin/commit/c2f6db7984a2129831eca288bab2431434ed4d7c
In ERC20AaveLMUpgradeable._registerRewardToken(), lastUpdatedIndex is cast to uint240.
However, its type is uint248.
We recommend casting it to uint248.
Fixed in https://github.com/bgd-labs/aave-v3-origin/commit/c2f6db7984a2129831eca288bab2431434ed4d7c
In ERC4626StataTokenUpgradeable.maxDeposit(), when calculating the return value, >= should be used instead of >.
Currently, if currentSupply is greater than supplyCap, zero is returned. However, if these values are equal, the result is still zero.
We recommend using >= instead of >.
Fixed in https://github.com/bgd-labs/aave-v3-origin/commit/c2f6db7984a2129831eca288bab2431434ed4d7c
- In the
_startIndexmapping, the address is nameduserinstead ofreward.
- In the comments of the
ERC20AaveLMUpgradeable._getPendingRewards()function, it states that the return value is in WAD, but it is actually in asset decimals.
https://github.com/aave-dao/aave-v3-origin/blob/f02fcb2d6ac2e08aa6bf6a8a0d38f6786cc1809a/src/contracts/extensions/static-a-token/ERC20AaveLMUpgradeable.sol#L198-L202 https://github.com/aave-dao/aave-v3-origin/blob/f02fcb2d6ac2e08aa6bf6a8a0d38f6786cc1809a/src/contracts/extensions/static-a-token/ERC20AaveLMUpgradeable.sol#L219
- In the
IERC20AaveLMinterface, the comments indicate that rewardsIndexOnLastInteraction and unclaimedRewards are in RAYs, but they are actually in asset decimals.
- In the README file, it is stated that anyone can rescue funds using the PermissionlessRescuable contract. However, the code uses the Rescuable contract with the onlyRescueGuardian modifier, meaning that only a designated rescue guardian can perform rescue operations.
We recommend correcting the typos.
Fixed in https://github.com/bgd-labs/aave-v3-origin/commit/c2f6db7984a2129831eca288bab2431434ed4d7c
In the constructor of ERC20AaveLMUpgradeable, there is no check to ensure that INCENTIVES_CONTROLLER is not set to the zero address. This could lead to a situation where the admin mistakenly assigns it to the zero address, rendering the contract unusable after initialization.
We recommend adding a check to ensure that INCENTIVES_CONTROLLER is not set to the zero address.
Fixed in https://github.com/bgd-labs/aave-v3-origin/commit/c2f6db7984a2129831eca288bab2431434ed4d7c
Regular users may encounter difficulties when attempting to deposit their entire AToken balance.
The deposit functions in ERC4626StataTokenUpgradeable transfer an exact amount of ATokens from the user, as specified in the assets argument:
function _deposit(
address caller,
address receiver,
uint256 assets,
...
)
...
SafeERC20.safeTransferFrom(
$._aToken,
caller,
address(this),
assets
);
...
However, since ATokens are rebaseable, by the time the transaction is in the mempool, the user's AToken balance might increase, leaving some dust in the user's wallet after the transfer.
We recommend providing the user with the option to transfer the entire available amount at the time of the transaction's execution.
Addressed here https://github.com/bgd-labs/aave-v3-origin/pull/36/commits/7fe3a08e94fd86e4e2dfb28ccb3832c7452f7cad
MixBytes is a team of blockchain developers, auditors and analysts keen on decentralized systems. We build opensource solutions, smart contracts and blockchain protocols, perform security audits, work on benchmarking and software testing solutions, do research and tech consultancy.