ABSTRACT
Dedaub was commissioned to perform a security audit of the avUSD contracts from Avant. avUSD is a permissionless stablecoin that will offer users yield for participating in its ecosystem. Unlike USDC where Circle captures the yield, holders can stake their avUSD in exchange for staked avUSD, which increases in value relative to avUSD as the protocol earns yield.
BACKGROUND
avUSD is a fork of Ethena’s USDe. Ethena users mint USDe with stETH, and Ethena opens an equivalent short ETH perps position on perps exchanges. stETH yields 3-4% annualized, while short ETH perps yield 6-8%. The combined long and short position daily yield is sent to an insurance fund, and then sent to the staking contract every 8 hours. Avant plans to execute similar strategies to generate yield for users that stake their avUSD. According to Avant, the strategies will be run by their partners, starting with 0xPartners and more will be on boarded over time. The strategies will follow 0xPartners’ market neutral strategies including Ethena style cash/carry trade but others too.
SETTING & CAVEATS
This audit report mainly covers the contracts of the at-the-time private repository of the Protocol Avant USD at commit e41cf3189c622a2a9ff65d0b836d3e9b8ad40a3c.
Two auditors worked on the codebase for 3.5 days on the following contracts:
contracts//
├── AvUSDMinting.sol
├── AvUSDSilo.sol
├── AvUSD.sol
├── SingleAdminAccessControl.sol
├── StakedAvUSD.sol
├── StakedAvUSDV2.sol
└── utils/
└── TransferHelper.sol
The audit’s main target is security threats, i.e., what the community understanding would likely call “hacking”, rather than the regular use of the protocol. Functional correctness (i.e. issues in “regular use”) is a secondary consideration. Typically it can only be covered if we are provided with unambiguous (i.e. full-detail) specifications of what is the expected, correct behavior. In terms of functional correctness, we often trusted the code’s calculations and interactions, in the absence of any other specification. Functional correctness relative to low-level calculations (including units, scaling and quantities returned from external protocols) is generally most effectively done through thorough testing rather than human auditing.
PROTOCOL-LEVEL CONSIDERATIONS
Avant will deploy (through their partners) the avUSD collateral to on-chain investment strategies with the aim to generate yield
Protocol Level Consideration | Status: INFO
Avant users will be able to mint avUSD by depositing Avant-supported collateral tokens. This collateral will be deployed through Avant’s partners to on-chain investment strategies with the aim to generate yield, part of which will be distributed to users who stake their avUSD. According to Avant, the strategies will be run by their partners, starting with 0xPartners and more will be on boarded over time. The strategies will follow 0xPartners’ market neutral strategies including Ethena style cash/carry trade but others too. Even though the strategies that will be used are expected to be defensive and able to withstand crypto markets’ swifts, they are certainly not risk-free, meaning that part of the collateral that backs avUSD or of the generated yield might be lost.
Gatekeeper security analysis is based on strong assumptions
Protocol Level Consideration | Status: INFO
The protocol is using a safeguard to limit the consequences of the MINTER and REDEEMER keys getting compromised. Let’s consider the minter case, the redeemer one is similar. If the minter is allowed to mint an unlimited amount of avUSD instantaneously without sufficient collateral backing it, a compromised key would mean unlimited minting and selling, fully destroying the token’s price. As a countermeasure, a maximum limit of 100k avUSD minted per block is implemented, thus for an attack to be considered successful, it would have to be performed across several blocks. At the same time, a GATEKEEPER role is introduced. Entities granted the role have to monitor the protocol and avUSD’s market price off-chain and can disable miniting/redeeming any time an operation that deviates from market prices is detected.
The security analysis in the protocol’s README states that due to gatekeeper functionality, an adversary can mint at most $100k, plus steal the $200k collateral held in the minting contract, for a total $300k in losses.
However, this simplistic analysis assumes that the gatekeeper can not only detect the malicious behavior in a single block (which already is questionable), but also submit and execute the transaction that pauses minting. In practice, this is not easy to achieve, a financially motivated adversary could provide sufficient bribes to block proposers (or happen to propose a block himself) to prevent gatekeepers from actually executing the transaction. As a consequence, it is only realistic to assume that at least a few blocks will pass before the gatekeeper can intervene successfully.
If such a delayed response is not sufficient, the protocol should be modified to address this issue. For instance, a rolling window limit could be used, enforcing that if the limit of 100k is reached in a block, then in the following block that limit is lowered.
VULNERABILITIES & FUNCTIONAL ISSUES
This section details issues affecting the functionality of the contract. Dedaub generally categorizes issues according to the following severities, but may also take other considerations into account such as impact or difficulty in exploitation:
Issue resolution includes “dismissed” or “acknowledged” but no action taken, by the client, or “resolved”, per the auditors.
CRITICAL SEVERITY
[No critical severity issues]
HIGH SEVERITY
[No high severity issues]
MEDIUM SEVERITY
[No medium severity issues]
LOW SEVERITY
SingleAdminAccessControl allows renouncing non-admin roles
Low | Status: ACKNOWLEDGED
The SingleAdminAccessControl contract allows entities with the MINTER_ROLE, REDEEMER_ROLE, COLLATERAL_MANAGER_ROLE and GATEKEEPER_ROLE to renounce these role(s). The biggest risk associated with this decision is that if the accounts with the GATEKEEPER_ROLE get compromised, they could renounce it and essentially DOS the gatekeeper functionality.
The version of the OZ libraries used is not the latest
Low | Status: RESOLVED
The protocol uses version 4.9.2 of the OpenZeppelin libraries instead of the latest standard that is 5.0.2. There should not be any breaking changes when upgrading to 5.0.2. We summarize points of interest regarding the upgrade below:
- Minimum compiler version would have to be increased to 0.8.20
- Ownable: Added an initialOwner parameter to the constructor, making the ownership initialization explicit.
- AccessControl: Added a boolean return value to the internal _grantRole and _revokeRole functions indicating whether the role was granted or revoked.
CENTRALIZATION ISSUES
It is often desirable for DeFi protocols to assume no trust in a central authority, including the protocol’s owner. Even if the owner is reputable, users are more likely to engage with a protocol that guarantees no catastrophic failure even in the case the owner gets hacked/compromised. We list issues of this kind below. (These issues should be considered in the context of usage/deployment, as they are not uncommon. Several high-profile, high-value protocols have significant centralization threats.)
Crucial protocol actions are centralized
Centralization | Status: OPEN
Crucial protocol actions such as the minting and redeeming of avUSD and the management of the collateral that backs avUSD are centralized. Users of the protocol can consult issues P1 and P2 where we discuss the implications of these design decisions and possible pitfalls and risks that come with them.
OTHER / ADVISORY ISSUES
This section details issues that are not thought to directly affect the functionality of the project, but we recommend considering them.
Obsolete import
Advisory | Status: RESOLVED
AvUSD.sol Imports draft-ERC20Permit.sol instead of ERC20Permit.sol
Missing address(0) checks
Advisory | Status: ACKNOWLEDGED
Functions grantRole and revokeRole of the SingleAdminAccessControl contract do not enforce that account != address(0).
Compiler bugs
Advisory | Status: INFO
The code is compiled with Solidity 0.8.19. Version 0.8.19, in particular, has some known bugs, which we do not believe affect the correctness of the contracts.
DISCLAIMER
The audited contracts have been analyzed using automated techniques and extensive human inspection in accordance with state-of-the-art practices as of the date of this report. The audit makes no statements or warranties on the security of the code. On its own, it cannot be considered a sufficient assessment of the correctness of the contract. While we have conducted an analysis to the best of our ability, it is our recommendation for high-value contracts to commission several independent audits, a public bug bounty program, as well as continuous security auditing and monitoring through Dedaub Security Suite.
ABOUT DEDAUB
Dedaub offers significant security expertise combined with cutting-edge program analysis technology to secure some of the most prominent protocols in DeFi. The founders, as well as many of Dedaub’s auditors, have a strong academic research background together with a real-world hacker mentality to secure code. Protocol blockchain developers hire us for our foundational analysis tools and deep expertise in program analysis, reverse engineering, DeFi exploits, cryptography and financial mathematics.