AL #41: Will Euler's EVC Simplify Onchain Lending?
A universal collateral layer.
It was only last week that I wrote about the first major attempt to create a lending aggregator.
Since then, Euler announced their own take on a lending infrastructure layer, this time as a free, immutable public good:
Where Starport focuses on establishing network effects around the different system participants (lenders, borrowers, liquidators), Euler's EVC focuses on developer network effects.
Why EVC exists
The raison d'être for EVC boils around collateral management.
When onchain lending protocols first emerged, they were focused on accepting different types of ERC20 tokens as collateral. To price these tokens, they used oracles. This worked well.
However, users quickly found themselves with assets that weren't easily usable as collateral. For example, if you held shares in a Yearn vault, there was likely no Chainlink oracle to price the vault (even though each vault has a clear built-in exchange rate with a numeraire asset) and therefore little support to use that as collateral in blue chip lending protocols.
The lending protocols didn't see this as an issue, allowing deposits to be used as collateral as a way to allow users to generate yield.
But then users asked for depositing NFTs, liquidity positions and many other unique asset types. New niche lending protocols were described to tackle these different cases.
This is the collateral recognition problem.
Integrators are also interested in making sure their products are usable as collateral.
The ability for an asset to be used as a collateral in a lending protocol likely leads to greater TVL (reducing the need for users to sell the asset to realize liquidity in another and also enabling recursive borrowing strategies that lead to even more TVL).
When ERC4626 emerged as a standard to unify yield-generating vaults, vault developers saw the promise of lending protocols eventually supporting ERC4626 interfaces.
This future hadn't really arrived yet (until now).
This is the collateral compatibility problem.
Finally, lending protocols themselves are also interested in safely and simply integrating several types of collateral.
However, doing so requires custom code, heavy auditing and often may lead to gas inefficient code. For example, current implementations of AAVE and Compound still iterate over all supported collateral to figure if a user’s position is underwater.
This type of logic is clearly designed to be mainly ran off chain by liquidators and only run onchain during liquidation settlement.
It would be helpful if lending protocols could more easily declare support for various types of custom collateral in a safe and gas efficient way.
This is the collateral integration problem.
EVC aims to solve all 3 issues.
EVC Dumbed Down
While I normally love searching for a simple explanation of protocols, I hate to simplify EVC.
An in-depth reading of the Whitepaper, spec and code will reveal many thoughtful details and nuances that I will only gloss over.
I think this protocol will be an exemplary entry in the protocol hall of fame alongside Maple Finance, Seaport, Sablier and other “reference” designs.
Having said that, here is the oversimplification:
EVC allows any developer of a lending type protocol to declare what is called a “controller” – effectively an API for borrowing from this contract;
Each user now is assigned 256 distinct subaccounts. Each subaccount can borrow from a single controller independently;
Furthermore, the controller may further allow lending positions to be declared as valid collateral in other controllers;
This means that lending protocols can implement their own arbitrary valuation & liquidation logic as well as general protections for operations like borrowing by defining various invariants;
Since invariants are used, operations like flashloans are easily supported, allowing a position to be temporarily “underwater” as long as a position health invariant is satisfied at the end of the interaction sequence. The EVC achieves by carefully managing transient state throughout execution;
To summarize, users can hold up to 256 different borrowing positions from one address;
Protocols can support borrowing using other lending positions as collateral and vice versa expose their own lending positions as collateral in other protocols while maintaining the relevant invariants.
Other quality of life features for users include operators (accounts that are permissioned to operate on the user's behalf – a generalization of simple spending approvals);
Finally, while easy to overlook, EVC also features a universal liquidation interface that promises to enable a broader set of liquidators (fillers) to be incentivized to risk manage each lending protocol.
Strategic Implications
While lending goliaths like AAVE and Compound likely benefit from protecting platform lock-in, EVC allows a number of smaller and more experimental lending protocols to pool their network effects and create an ecosystem that may be bigger than the sum of its parts.
EVC also supports varied collateral types, which should encourage more lending protocols to experiment with new collateral types having a gas-efficient version available to them.
EVC has some “singleton” effects analogous to Uniswap V4, supporting multicall by users and ensuring that position health checks are correctly introduced at the end of each transaction sequence.
Users benefit too through the introduction of multiple subaccounts (which is more convenient than maintaining multiple addresses), operators (accounts that are permissioned to operate on the user's behalf – a generalization of simple spending approvals).
The network effects associated with combining collateral types is supplemented by a reduced need of recruiting a unique liquidator set for each lending protocol.
In short, the point of EVC is not really to simplify the development of lending protocols.
It definitely makes collateral support simpler.
But the biggest benefit seems to be the network effects that are gained by becoming an EVC controller.
EVC vs. Starport
So how does EVC compare to the other lending base layer announced in January?
Without seeing the Starport codebase in detail, it’s hard to do anything but speculate.
Here’s my understanding so far...
Ultimately EVC and Starport act at different levels of abstraction. EVC is a collateral composability layer for lending protocols that defines some unified interfaces and benefits for users and liquidators while Starport is a modular intent-centric base for building all components of a lending protocol at a higher level.
Starport does not prescribe the use of specific collateral assets at all so a new lending protocol could actually be built on both Starport and EVC.
It would tap into EVC for building the collateral system and tap into Starport to provide an intent-centric interface for matching lenders and borrowers.
In this vein, EVC makes interaction with your lending protocol very simple and efficient for users while supporting better composability with the rest of the EVC network.
Starport instead simplifies counterparty discovery for loan agreements while offering a simple modular base and a shared custodian layer to develop a lending protocol on.
(A dedicated custodian module may need to be developed for Starport to support EVC natively.)
In terms of competing with Compound & AAVE, Starport is really better suited for building new, intent-centric lending designs while EVC is a vehicle for pooling the network effects of smaller individual lending markets.
While there is some overlap in finding liquidators and defining position health conditions, even that could be reconciled with the right design.
EVC will seed its network effect through the launch of the next iteration of Euler but they will face an important hurdle in encouraging the next 1-9 protocols to join.