It’s been a hugely successful week from an audit perspective, and many issues were found by a quality set of experts.
Let’s look at the findings and value we’ve got from the contest!
How Findings are Submitted
Wardens (reviewers) were briefed to find issues and assign them as high-a-risk as possible to claim a bigger share of the prize pool.
Many eyes are looking at the same code, and thus we saw the same issues reported several times. (That creates the appearance of a higher number of issues vs actual number of original issues.)
Issues can be raised as a bug, security risk or gas optimization. Security risks are listed as high, medium or low severity as chosen by the warden. (Not necessarily accurate.)
It’s then up to the Sponsor (Us) to go through that list, and tag each issue as Acknowledged, Disputed or Duplicate.
Example responses to a finding could be that it’s:
- an intentional way of operation
- acknowledged but left, e.g a minor gas optimisation
- a disputed issue, or disputed severity
- acknowledged security risk, and will be fixed
- a duplicate from another wardens entry
Proof of Concept and Mitigation Steps
What is particularly helpful about the interactive element of the contest is that findings are often reported along with a PoC of the bug, and a recommended way to fix it.
This saves a lot of time on our end.
We’ve been working our way through the list, and fixing the easy ones. Most are simple changes required.
In total, we had 164 issues raised from the Wardens for us to look into. (That includes all duplicates.)
This is actually fantastic for us. The worst outcome would have been that 0 issues were found, or some risks remained hidden going into launch.
Breakdown into Categories:
- Gas Optimization — 44
- Low Risk — 63
- Med Risk — 26
- High Risk — 26
Again we want to stress, many are duplicate reports but are still valuable as some contain another method of resolving to consider.
The high risks issues are mostly around potential arbitrage and slippage of accepting and withdrawing to different tokens. E.g USDC / DAI / USDT.
There is a reason there are separate Yearn DAI and Yearn USDC vaults, or why many platforms only allow the deposit of DAI.
This presents us with some decisions to make this weekend. We could simply limit the type of deposits allowed in the stable vault, or we could raise a withdrawal fee to stop arbitrage opportunities, or we could press on with a technical fix to preserve the intended user experience.
Some issues we already knew about, such as the Harvests getting frontrun. And others we don’t agree with and will dispute.
Overall, it’s been such a great experience to be under the microscope that we are grateful for.
As we wrote at the time, the original schedule for a guarded launch on Sunday 19th was subject to the outcome of the C4 Audit.
With the number of issues raised, we’ll instead be crunching all weekend to resolve them and ensure the vaults are safe to use. We’ll have a better idea on Sunday of what’s left to do, but we won’t be skipping any steps to rush a guarded launch.
We’ll communicate on a newly proposed guarded launch date as soon as possible.
The remainder of the proposed schedule for Full Launch is still on track. After this thorough review, we aren’t anticipating new issues being found in the upcoming Haechi Audit on the 28th of September.
Code 423n4 is a new concept for Smart Contract security. The prize pools are relatively high compared to a traditional audit and without a big budget to throw around, we had some reservations if it would be worth the spend.
Thankfully, we are exceptionally happy with the outcome. While most Audits provide 1 or 2 engineers, we’ve had 13 specialists pick apart the code base, and lend us their area of expertise. It’s like having a ton of audits packed into one week.
There were also a lot of useful bonus findings that greatly improve UX for our users on aggregate, and that’s something a traditional audit wouldn’t have delivered.
We’ve always spoken about the necessity of peer reviews, especially before launching an entirely new code base. This has been a vindication of our tough decision to delay launch in August whilst we waited.
We want to give a resounding recommendation to the DeFi community of the team and Wardens over at Code 423n4 for the job done and value added.
After these issues are resolved, we can confidently move towards launch.
Thanks for everyone’s patience while we waited for this peer review. It’s been a hugely successful outcome that we can take a lot of assurance from going forward.
We’ll use this weeks Ya Herd? as an opportunity to talk again about the outcome and answer community questions.
Let’s then focus on these resolutions asap, launching the vaults and then shifting gear to catapult yAxis to the next level.