Yearn

Yearn Stargate Strategy audit report

Yearn

SUMMARY

Critical 0
High 0
Medium 0
Low 2
Advisory 4
Total: 6

ABSTRACT

Dedaub was commissioned to perform a security audit of Yearn Stargate Protocol Strategy. No major issues were identified.

SETTING & CAVEATS

This audit report mainly covers the contracts of the Yearn Stargate Protocol Strategy. Two auditors worked on the contracts for 2 days.

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.

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

Unused constant

The weth constant is unused.

Missing conversion

ethToWant does not do a conversion. It is used in BaseStrategy::harvestTrigger, so it seems rational to attempt and provide an accurate estimation there.

OTHER / ADVISORY ISSUES

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

Minor gas savings

  • The require statements at the end of the constructor could check _uniV3Swapper and _curvePool to get rid of the casts and save some gas.
  • In prepareReturn, the assignment _totalAssets = estimatedTotalAssets(); after the if (_toLiquidate > _wantBalance) \{...} can be moved inside the if body to save some gas.

A more specialized call could be made

In _sellRewardsUniv3, you could call the more specialized uniV3Swapper.exactInputSingle(params); instead of the more general exactInput.

No-op if branch

In adjustPosition, the if (_amountToDeposit > 0) \{ ... } statement will always be followed.

No-op operation

In _withdrawFromLP, the min operation at the start of the function is a no-op, as the function is always called with _lpAmount = balanceOfUnstakedLPToken().

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.