Comment on page
Vesper's Modular Pool Architecture
Vesper's software architecture is based a modular, multi-pool design that enables smart contract administrators to adapt and transition strategies. This modularity not only makes it possible for running programs to switch approaches in real time in response to changing conditions in the DeFi marketplace, it also makes it possible for Vesper's team to continuously upgrade products without interruption.
This modular philosophy is present in all aspects of Vesper software development. This "Lego-like" approach not only makes it possible to swap strategies and combine product components in innumerable ways, it also separates smart-contract logic into those parts that are platform-dependent from those that are platform-agnostic. This means that the project of porting products from, say, the Ethereum blockchain to Polygon or Avalanche is readily addressable.
Moving from Ethereum and EVM-compatible blockchains to different blockchain architectures is a more complex task, but still, the modularity built into Vesper products makes this task composable, which makes the engineering easier.
Modularity is key to the Vesper idea
In many DeFi environments, yield farmers spend a lot of time and energy jumping from pool to pool, chasing new contracts that offers just a little more yield more than the previous one. When this happens, the old, now-stale pools drift into obscurity.
Nevertheless, aggregators that leverage these pools (new and old) may continue to fund pools that no longer actively produce yield. As a result, assets sit stagnant in various contracts. This phenomenon can be called 'strategy fade.' Several approaches have been developed to deal with it.
Vesper is designed to aggregate across various strategies. New and improved strategies can be deployed over time and integrated into the existing stack, while older and non-competitive alternatives are phased out.
As existing strategies become overplayed, newer, higher-yield alternatives can be gradually integrated into the existing pool with only a percentage of users’ funds being deployed in the new strategy. Eventually the new strategy can replace the original strategy altogether if it is performing better than its predecessor. This is similar to how Amazon rolls out updates to its website, surfacing them to an ever-larger percentage of users on the way to 100%.
This capability allows a “set-and-forget” experience for depositors that is sustainable over time. Instead of compulsively seeking the newest yield source, Vesper users can trust the pools to do that for them.
Each Vesper pool has three main modules: Collateral, Strategy, and Action.
The internal logic of Vesper Pools
Collateral is where funds are handled when they are deposited and withdrawn. It reflects the contract calls required to move deposits to where they will earn yield. This may be lending platforms like Maker, Aave, or Compound. The process of withdrawing funds through the collateral module can require more effort than depositing them. If the pool is taking out loans with the pooled asset (ETH for example), a partial refund of its outstanding loans may be required before a withdrawal can be executed. This may lead to rebalancing, described below.
The Strategy module deploys capital to generate yield. Depending on the pool, this module could look simple (take out a loan and deposit it somewhere else) or complicated (fractional loans for compounded interest). The strategy might only use the deposit asset deposited in full to an interest-earning DeFi protocol.
Interest accrued is goes into the Action module. The action module determines how often to claim interest, and whether to move that interest to the strategy module to be redeployed for further yield, or to take the deposit asset off the table by feeding it back to the collateral module to withdraw it.
Each Vesper pool is actually made up of two or more components — the frontend, which handles deposits and withdrawals, and the backend strategy or strategies that direct the deposits and aggregate yield.
This approach allows developers to create any number of yield-earning strategies and seamlessly combine these strategies with one another. Or, they can replace existing strategies to consistently capture high-yield opportunities as they emerge. Such strategies include lending, yield farming, liquidity-providing and trading of synthetic assets.
After making a deposit, there is no action required by the user participating in these pools to manage them. And there is no limit to how often the backend can be swapped or how many strategies can combine in one pool.
Assets can be aggregated by interfacing front pools as “gateways” for other front pools. Assets can be aggregated by interfacing frontend pools as “gateways” for other pools from across DeFi. For example, imagine we’ve created a WBTC pool which you would like to use to earn yield in DAI. In the backend, your WBTC could be routed through other pools, such as the Maker strategy to generate your yield in DAI. In this scenario, your rewarded DAI also generates additional yield until claim, using the Aave strategy. This same strategy can be replicated across other assets. That is, the same could be done for vETH and similar pool assets that are accepted as DAI collateral, as illustrated below.
Different ways to use wBTC to participate in vDAI pools
Depositors, that is, Vesper users, do not have to decide which of these approaches to use. Rather, that is taken care of by the architect of the pool strategy.
In the same way that Vesper pool strategies are swapped and combined, they can also run in parallel with one another. "Front" pools can take on any number of strategies consecutively, with a variable allocation of deposits to each pool.
This is done by queueing multiple strategies to the same pool. For example, if a pool held USDC assets valued at $40 million, it might allocate the first $10 million USDC from the USDC pool to Strategy A, the next 20 million USDC to Strategy B, and the remaining 10 million to Strategy C. The limits on strategies and order of the queue are dynamic, and can be updated as needed.
This is key to the pool architecture for two reasons. The first is better yield optimization. A pool can lend to any number of platforms at the same time, mitigating fluctuations in interest rates. When a new strategy appears, the pool can queue it to first priority with a small deposit limit, say $5 million USDC, so as to not smother the APY with an overpowering deposit.
Weighted multipart strategy
The second benefit is that incremental adoption of new strategies allows pool architects to judge their performance before deciding how much to allocate to them. Let’s say that the new strategy sustains itself at $5 million USDC. We can ladder up in $5 million USDC intervals to observe how well this strategy can handle additional TVL.
Beyond that, this architecture enables Vesper pools to faithfully take on any amount of TVL. If 100% of assets went one strategy at a time, a pool would likely be suffocating its earning potential significantly. This multi-pool approach is an important feature of Vesper pools that unlocks new ways of thinking about pool scalability.
All Vesper pool smart contracts contain a few privileged addresses including a "governor" and one or more "keepers." The governor and keeper are allowed to do some updates in pools and strategies to keep the ecosystem working.
- More sensitive and more important updates are done by the governor.
- A Vesper multisig wallet is the current governor of Vesper pools and strategies.
- Multisig is a contract where n people vote on transaction before it gets executed. The Vesper multisig has 5 signers and requires 3 yes votes for a transaction to execute.
- This governor role will be transferred to an on-chain governor at a future point.
- Daily operations or updates that keep pools healthy and need frequent operation are done by keepers.
- There is no limit on the number of keepers.
- Keepers can be added and removed anytime.
- A keeper is just an address; it can be EOA(personally owned), a bot, or even a multisig.
The governor has the capability to perform certain privileged actions, including pausing the contract's execution or even permanently disabling it. Thus it can be used an an emergency brake should that ever become necessary. The governor also has the ability to designate certain addresses as "keepers".
Keepers have the ability to adjust strategy weights and upgrade modules. They are key to Vesper's ability to upgrade pools continuously without interrupting the user experience.
This is a contract function that swaps non-native ERC20 tokens and deposits them back into the collateral module. For example, if the strategy interfaces with Compound, and receives Compound's COMP token, sweeping will liquidate the COMP and reap the profits from it. This also handles any tokens mistakenly sent to the contract.
To summarize, Vesper pools have the following attributes:
- they use a common framework;
- they may contain multiple asset management strategy modules. (But note: strategy modules are not shared across multiple pools; each pool is its own universe);
- assets in a single pool are distributed across a number of strategy modules (for example asset management modules);
- each strategy module (sometimes called a "strat") is assigned a weight;
- assets are spread across strategies according to weight.For example: if a Compound-strat weight is 60% and an Aave-strat weight is 30%, and the null strategy (asset on hand — that is, cash on hand for deposits and withdrawals) weight is 10%, then 60% of the pool's assets are sent to to the Compound protocol and 30% of the pool's assets are sent to the Aave protocol and 10% are held in reserve;
- Assets are moved between strategies without depositor intervention. This is a key value of Vesper: "hands off" asset management. The Vesper team monitors the DeFi environment continuously and makes regular "course corrections" to the strategies.
- In the event of an emergency, assets are withdrawn from strategies by keepers; the contract's execution may be paused, resumed, or disabled by the governor.