After three years as co-founder and CTO at Yield Protocol, I decided to become an advisor and consultant to other projects. Euler Finance is one of my first clients, and has taught me a great deal about what I can do for others. It has revealed a niche that no other person is working on, that few can do as well as I can, and that some clients will appreciate and pay for.

This article is many things: a barely disguised marketing product to land more clients, a technical review on the EVC, but mostly a heart-felt effort to explain what it is that I have found that I can do, that I love doing, that is useful, and that is a viable career. It is extraordinary.

An Architecture and Implementation Review

My work reviewing the EVC was not a security audit, even if it makes the EVC more secure. I guess you could call it an architecture and implementation review. My goal was to simplify the EVC, to decrease the degree of surprise from those studying the codebase, to increase the quality of the docs, to reduce attack surfaces. In doing so, aesthetics played an equal role to technical expertise. It is a bit of an art.

That review played on my natural talents, and the team at Euler seem to be happy. I feel I brought significant value for them, at a fraction of the cost of an audit.

Now that the EVC is public, I can describe the work on detail. I’ll do the same for the upcoming Euler products, as well as a couple other clients in my pipeline that can’t be disclosed yet. Maybe one day it will become an industry standard.

The original code was 1049 sloc of new code distributed over 5 contracts, already after several audits, plus 231 sloc of a library from Euler v1 that had been audited several times and seen significant production use.

The review of the EVC happened over 19 hours of work spread over 3 weeks. The resulting code was 972 sloc, with the library unchanged. 6 external functions were removed, as well as a number of internal functions. Significant clarity was achieved over the critical features in the implementation, as well as with the documentation.

Where others take pride in codebases with 100k sloc of solidity, I take pride in removing 75 lines and 6 external functions from a single contract.

The following sections describe the different features of the EVC, and how they were reviewed and refactored.

The EVC as a Flexible Router

The EVC implements a maximally flexible routing system that allows several modes of user interaction, along with call nesting through reentrancy and checks deferred. As a complex and mission-critical feature it was simplified to facilitate audits and reduce attack surfaces.

From the original implementation, we did the following changes.

• The recoverRemainingETH external function was removed.
• The callback external function functionality was merged into call.
• The impersonateInternal internal function was merged into impersonate.
• The restriction on calling the ERC1820Registry was removed.
• The restriction on using batch for callbacks was removed.
• The impersonate and callInternal functions were renamed to explicit descriptors.
• The authentication subsystem was refactored and renamed for clarity.

The resulting implementation is more compact, has less requirements, is better named, and in general is simpler.

Call Depth Tracking

The original implementation included an advanced mechanism to keep track of the exact level of nesting at each call, which would be used to detect when the execution is at the outermost level of execution and the deferred checks should be executed.

Upon careful analysis, it was possible to remove this mechanism in favour of a simple and explicit boolean variable set in the context in the outermost nesting level.

Operator Authentication

It was possible to simplify the operator authentication feature, replacing authenticateOwner and authenticateOwnerOrOperator for a single authenticateCaller function. Apart from making the code easier to understand, this also removed duplicated code which is a risk in itself.

Check Validation

The EVC implements an advanced system of flexible checks. Checks on accounts and vaults can be mandated by the caller, the controller, or EVC functions that keeps track of user and vault associations.

This system was mapped out with the areas of risk pinpointed.

• The collusion of controller and operator roles in a single account could be exploited with damages to the users that allowed the collusion to happen.
• The capacity of the controller to forgive checks in the context of liquidations is an area of risk which cannot be eliminated.
• The capacity of callers to clear deferred checks by executing them immediately was an area of concern, as it could be unexpected by those that required the checks. This could be addressed by removing the capacity.

Conclusion

A couple of months ago, when I started an advisory and consultancy career path, I had no idea about what was that I was actually doing, and in particular I didn’t know what my actual work would be.

Thanks to Euler Finance, I’ve had a glimpse of a service that I love doing, that others find useful, that I’m good at, and that others will pay for. That is much more than I could have expected.

With regards to the EVC, none of the ground-breaking features in the EVC are my ideas, I take no credit for that. However, I’m immensely proud to have steered its implementation towards a state that I find more beautiful, safer, easier to integrate with, and easier to audit.

I am incredibly grateful to the team at Euler, but in particular to two people. Michael Bentley for trusting me and hiring me even when I had such an unclear work plan, and also to Kasper Pawlowski, lead developer for the EVC, for his patience in replying to my questions and his open-mindedness to have his code criticised, sometimes refactoring it himself beyond my expectations.