Vault Kit Security Audit

Audit Report Revisions

Audit Overview

We were tasked with performing an audit of the Euler Finance codebase and in particular their Euler Vault Kit that closely integrates with their Ethereum Vault Connector to facilitate the creation of a lending and borrowing market.

High-Level Description

The Euler Vault Kit represents a collection of modular contracts that are meant to be combined via a purpose-built proxy to create an EIP-4626 vault with lending and/or borrowing capabilities that has a high level of customization, permitting most features of the vault to be enabled, disabled, and/or gatekept.

The EVK relies on the Ethereum Vault Connector (EVC) to operate properly, integrating the sub-account authorization system of the EVC as well as ensuring most mutating calls are forcibly routed via the EVC to permit the EVK to register itself, and potentially an account, for post-interaction health / safety checks.

Proxy Model

The EVK utilizes a purpose-built proxy relay system that will append three addresses at the end of each call that provide data the vault instance can utilize, permitting the same logic to be utilized for multiple deployments without mutating the vault's bytecode (i.e. immutable variables) or storage.

We identified certain flaws in the proxy model that arise from insecure assembly practices, however, they represent latent vulnerabilities that would manifest in future updates as they would result in corruption of the memory layout of the call which presently does not result in an actively exploitable flaw.

Custom Data Types

The EVK codebase employs multiple custom data types that wrap primitive number types to expose utility functions globally.

We believe that this approach is clear, concise, and would advise the Euler Finance team to closely monitor the Solidity compiler utilized for any potential compiler-related vulnerabilities that may arise from custom types, as they are a recently released feature.

External Integrations

The EVK heavily relies on the proper operation of the EVC to conduct its security checks, as in most instances these checks are deferred until the end of a batch's execution at the EVC level. In practical terms, the health checks of the protocol as well as of an account are performed after all interactions that the user wishes to conduct with the vault have concluded.

We validated that the integration is securely performed, and did not identify any improprieties in relation to the EVC calls performed.

The system natively supports an IBalanceTracker integration as well, recording balance changes to an external contract whenever they occur for a particular vault.

In relation to this integration, we identified a potential way a loan violator may force their liquidation to fail by propagating an error from the IBalanceTracker to the vault's context.

Finally, a hook system is implemented that effectively permits access control on certain vault operations to be guarded by an external contract with arbitrary logic. As no hook was in scope of the audit, we were not able to assess whether this particular integration has been securely performed.

Lending & Borrowing Market

The EVK at its base implements a system similar to the original Euler Finance vision; a debt (DToken) and collateral (EToken) token representation for a lending & borrowing market.

The mechanisms of the lending and borrowing market were evaluated, and two flaws were identified in relation to its operation and specifically in relation to its liquidation and interest accumulator modules.

We observed a discrepancy in the former whereby toxic liquidations are permitted to occur by offering a discount on the collateral of a lending position that would otherwise be considered as solvent.

In the latter, we noted a potential misbehaviour in how interest rate updates are handled. Specifically, the conditions under which interest rate updates are reflected are two:

• The interest rate update fits within the expectable value bounds
• The fees the protocol captures as part of the accumulated interest abides by the same limitation

We do not consider the second bullet mandatory, and in reality an interest rate update that could be reflected for active borrow positions will not be due to not being able to capture protocol fees which is unsound.

Inferred Security

A significant portion of the codebase will presently operate properly due to inferred security traits that may be enforced from upstream functions, defined as documentational constraints, or inherited via mathematical guarantees.

While the Euler Finance team has introduced multiple lines of in-line documentation to attempt to elaborate on certain seemingly insecure decisions made, we advise this effort to be continued as certain seemingly insecure statements are inadequately substantiated, such as the prohibition of self-transfers, or the discardment of the RPow::rpow result.

Overview Conclusion

We advise the Euler Finance team to closely evaluate all minor-and-above findings identified in the report and promptly remediate them as well as consider all optimizational exhibits identified in the report.

Post-Audit Conclusion

The Euler Finance team iterated through all findings within the report and provided us with a revised commit hash to evaluate all exhibits on, the PR it was included in, as well as an extensive document describing the Euler Finance team's assessment of each exhibit.

We evaluated all alleviations performed by Euler Finance and have identified that certain exhibits have been partially alleviated, or require a re-visit after further elaborations were introduced by our team. We advise the Euler Finance team to revisit the following exhibits: BUL-01M, BUL-01C, BUS-01M, LNO-01M

Additionally, we have introduced context to the following exhibits which may prompt the Euler Finance team to conduct further remediative actions: BPY-02C, ESH-04C, MPD-01M, MPD-03M, MPD-01C

All other exhibits have either been properly alleviated, been safely acknowledged, or been marked as nullified after clarifications were suppled to us by the Euler Finance team.

The Euler Finance team provided follow-up alleviations and responses that are reflected in the next post-audit conclusion chapter.

Post-Audit Conclusion (0f2192ac81)

The Euler Finance team revisited all aforementioned exhibits, either applying further alleviations or supplying us with clarifications as to why the exhibits should no longer be considered open.

With regard to exhibit LNO-01M, we deliberated the liquidation mechanism we proposed with the Euler Finance team and have concluded that the original approach of the codebase is considered the most optimal when taking partial liquidations into account.

We consider all outputs of the audit report properly consumed by the Euler Finance team and no further actions are expected in relation to the audit report.

Audit Synopsis

Severity	Identified	Alleviated	Partially Alleviated	Acknowledged
	1	1	0	0
	63	54	0	9
	5	3	0	2
	2	2	0	0
	0	0	0	0

During the audit, we filtered and validated a total of 20 findings utilizing static analysis tools as well as identified a total of 51 findings during the manual review of the codebase. We strongly recommend that any minor severity or higher findings are dealt with promptly prior to the project's launch as they can introduce potential misbehaviours of the system as well as exploits.

Total Alleviations

The list below covers each segment of the audit in depth and links to the respective chapter of the report:

• 🎯 Scope
• 💻 Compilation
• 🔍 Static Analysis
• 👁️ Manual Review
• 🖋️ Code Style