Yeti Finance Contracts

Smart Contract Security Assessment

May 13, 2022

SUMMARY​

ABSTRACT​

Dedaub was commissioned to perform an audit on selected contracts from Yeti Finance’s 0xmebius/vault repository. In the past, we have audited other parts of the Yeti protocol (although not yet its entirety) and such past reports should be consulted jointly with the current.

The essence of the audited functionality is primarily the addition of UST/aUST as collateral for the Yeti protocol. (Secondarily, the audited code includes the integration of Platypus Swap.)

The audited contracts list is the following:

0xmebius/vault

** ** Commit db2c5c852c5c63a94059068fac6fbc26a2245330

contracts/src/Router.sol contracts/src/SwapFacility.sol contracts/src/integrations/aUSTVault.sol contracts/src/integrations/aUSTVaultV2.sol contracts/src/integrations/savaxVault.sol

Two auditors worked on the codebase over one week.

SETTING & CAVEATS​

Recent developments have made UST virtually worthless, so this functionality is very unlikely to be deployed as-is. However, the audit’s focus is not the specifics of UST but the general pattern, implemented in two different ways in aUSTVault and aUSTVaultV2, of accepting collateral whose staking will be finalized asynchronously. In the case of UST/aUST, depositing UST results in the minting of aUST (which is the real holding token that the Yeti Vault wants to keep long term) at a future block. The accounting of deposits/redeems/stakes for such asynchronous transactions is the main audited functionality.

In the case of the aUSTVault, the implementation works as follows:

• the client deposits UST
• the vault requests its conversion to aUST, to happen asynchronously
• the underlying token for protocol purposes is UST
  • implying that protocol fees are paid in UST
• the token the client receives upon redemption is UST
• for the client to receive UST, a swap is performed. A SwapFacility contract needs to maintain its own UST budget, to act as a buffer.

In the case of the aUSTVaultV2, the implementation works as follows:

• the client deposits UST
• the vault requests its conversion to aUST, to happen asynchronously
• the underlying token for protocol purposes is aUST
  • implying that protocol fees are paid in aUST
• the token the client receives upon redemption is aUST. This requires redefining the standard Vault functionality, which assumes that the client receives the underlying token.

The audit’s main target is security threats, i.e., what the community understanding would likely call "hacking", rather than 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, quantities returned from external protocols) is generally most effectively done through thorough testing rather than human auditing.

PROTOCOL-LEVEL CONSIDERATIONS​

The main protocol-level consideration is inherent and one that the development team may be already aware of: the asynchrony in the receipt of the holding token (aUST) can create accounting irregularities. In the case of aUSTVaultV2:

• a call to compound right after the first deposit will try to transfer aUST to the fee collection contracts, which will fail unless the contract has an aUST balance before its first transaction;
• the amount accounted for, based on a Chainlink oracle price, may be smaller than the amount of aUST that will be received at a future block, upon wrapping the supplied UST.

The second element can create broader issues, e.g.,:

• there may not be enough aUST to satisfy redeem requests
• the first redeemers may receive more aUST, based on the inflated accounting
• the contract will be misleading its users by reporting a higher underlyingPerReceipt.

Similar issues arise for aUSTVault (but perhaps to a lesser extent). The client is being issued Vault tokens based on an exchange rate r1, yet the aUST holdings of the contract may reflect a later rate r2.

For these issues to be surmountable, operation of the contracts needs to be monitored, so that the deviation of prices due to the asynchrony can stay within bounds. The contracts already export the forceBalanceUpdate functionality for bringing the balances to sync.

VULNERABILITIES & FUNCTIONAL ISSUES​

This section details issues that affect 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”, 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​

[No low severity issues]

OTHER/ADVISORY ISSUES​

This section details issues that are not thought to directly affect the functionality of the project, but we recommend considering them.

function _triggerDepositAction(uint256 amtOfUnderlying) internal override {
    	lastaUSTBalance = aUST.balanceOf(address(this));     // Dedaub: SSTORE
    	lastUSTBalance = max(lastUSTBalance, _getUSTaUST() *
               lastaUSTBalance / 1e18);  // Dedaub: 2 SLOAD, 1 SSTORE
    	lastUSTBalance += amtOfUnderlying; // Dedaub: 1 SLOAD, 1 SSTORE
    	xAnchor.depositStable(address(underlying), amtOfUnderlying);
}

function _triggerWithdrawAction(uint256 amtToReturn) internal override {
    	swapper.swapAmountOut(amtToReturn);
    	lastaUSTBalance = aUST.balanceOf(address(this));  // Dedaub: SSTORE
    	lastUSTBalance -= amtToReturn;  // Dedaub: 1 SLOAD, 1 SSTORE
    	lastUSTBalance = max(lastUSTBalance, _getUSTaUST() *
               lastaUSTBalance / 1e18);  // Dedaub: 2 SLOAD, 1 SSTORE
}

function _compound() internal returns (uint256) {
…
      	lastaUSTBalance = getTrueUnderlyingBalance();  // Dedaub: SSTORE
      	lastUSTBalance = _getUSTaUST() * lastaUSTBalance / 1e18;
         // Dedaub: SLOAD of previous SSTORE
}

address _underlying, // UST

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.