What's in the code?

Ingredients: Lots of reviews and testing

A few months ago, Volt went live with its integration of Morpho-Compound as a yield venue for the system. This feature was the culmination of over a month of work. A question that we asked ourselves internally was, "why did it take over a month to ship when the code for the integration is quite simple?" Smart contracts, like most software, can be rushed to meet most deadlines as long as the authors are ok with removing features, not considering security, and cutting corners on quality. These types of trade-offs where quality and security are sacrificed to ship faster are ones that Volt will never make, as we don't want our protocol to be responsible for losing people's hard-earned money. The question remains, what went into this upgrade, how was it made, who reviewed it and why did it take a month? And finally, how can we know it is as secure as possible?

There are no silver bullets in security, and writing secure software means having lots of different ways to catch bugs before they go live in your system. The main security tool Volt uses are pair-programming reviews to catch issues before they get to production. Other key tools include mainnet fork testing, upgrade simulations, and testing all system components automatically before and after an upgrade with our simulation tool.

The first thing that went into this code was reviews, 17 of them to be exact, with 8 engineers besides the author reviewing the code. These reviews happened when this software was being written with an iterative cycle of code reviews where internal and external engineers did code reviews, going line by line through the code, suggesting changes, thinking of different attack vectors, and improvements for the system. During the review process, the Morpho team caught an issue where the Morpho Deposit would not be able to be deployed if used for Eth due to the call to the function underlying() on the cToken. While this issue would not have been encountered in production due to the protocol not holding Eth, it is a great example of peer reviews catching bugs. Once the team felt confident with the current iteration and quality of the code, the solcurity checklist was reviewed to ensure the core team had questioned its own assumptions and the code was ready for additional outside review. Throughout the development process, slither was run whenever large changes were made to check and see if there were any attack vectors that were missed. Once the team felt sure that the system was in a final state, the Morpho smart-contract engineering team was engaged as part of the review process to ensure the integration correctly interacted with their smart-contract system.

Another item that went into this feature that isn't visible to the end user is the review of the entire Morpho system and their audit reports to ensure that their venue meets security standards for Volt PCV. After reviewing their entire system, our team felt very confident depositing because of Morpho Lab's strong security posture. Read the audit report here.

As the software was being written, integration, fuzz and invariant tests were written to verify the correctness of the program. A simulation framework that tested the outcome of the governance proposal allowed our team to feel incredibly confident in the state changes that would occur. This framework tests many different parts of the system both before and after an upgrade to ensure the system functions properly after the upgrade is complete and that no PCV is lost due to the upgrade.

We've already answered the question of why we didn't ship it fast, we don't just say we care about security, we actually do. Writing secure software takes time, and we would rather take longer to ship something and be safe versus rushing software out the door that handles people's hard-earned money.