Multi-Chain and Cross-Chain Deployments

Vesper has been engineered to make its contracts easy to port Ethereum and Ethereum-like blockchains such as Optimism/Base, and eventually to newer protocols that are not modeled on the Ethereum Virtual Machine (EVM).

Vesper Pools on Optimism and Base

The fees to use the Ethereum Network are high. High fees affect all users, but they particularly exclude a large portion of the world, people of modest means, from participating in DeFi at all. One of Vesper's stated principles is to be inclusive in crypto, bringing the benefits of financial freedom and financial inclusion to as many people as possible.

With that in mind, Vesper has deployed the VSP token and a selection of Grow pools on the Optimism and Base Networks as a first step towards making Vesper more accessible to broader communities. These pools will route through protocols like Aave to earn the greatest sustainable yield presented on those platforms.

For Vesper depositors, choosing which network to participate on is as simple as selecting from the pull-down on the Vesper App. Note, however, that in order to use Vesper pools on Optimism (or any other network), you must have assets on that platform.

Optimism and Base are Layer 2 networks that work directly with Ethereum Mainnet. These Layer 2s process transactions separately but regularly submit their data back to Ethereum for security. Vesper's smart contracts that are deployed to them are very similar, if not identical, to those deployed to Ethereum. Both Optimism and Base use optimistic rollups, which means they bundle multiple transactions together before sending them to Ethereum Mainnet, making transactions faster and cheaper for users.

Yield Sources For the Same Pools Differ on Each Blockchain

Note that even though Vesper pools on Layer 2's leverage the same smart contract code as their counterpart pools on the Ethereum mainnet, the yield sources, and thus returns, will likely be different.

VSP Rewards May Differ on Each Blockchain

Some Vesper Grow pools offer participants rewards for participation in the form of VSP tokens. The VSP yield is in addition to the base asset. That is, if, for example, a USDC pool has VSP rewards, it yields both USDC and VSP. The rewards on other blockchains do not always follow the same schedule as rewards for the corresponding Grow Pools on Ethereum. Rewards are subject to periodic adjustment. To see the current reward for any pool on either blockchain, use the Vesper app.

Vesper's Grow Pools allow you to easily grow your holdings by routing your deposits through DeFi's leading yield sources. Deposit one coin, earn more of that coin. Aggressive and conservative strategies are available.

Vesper pools rebalance their loans algorithmically along parameters specified by each pool. Conservative and Aggressive pools are differentiated by the criteria used to take additional loans (when sufficient capital is deposited or the underlying asset appreciates) and partially refund outstanding loans (when capital is removed or the underlying asset depreciates). As the names imply, “conservative” pools are less risky than “aggressive” pools.

Universal Fee

The Universal Fee charges a 2% annual fee on the assets deposited (principal) at the time of rebalance. If this fee is greater than 50% of the yield earned, then the fee will only equate to 50% of the yield earned.

Earning Rate

The earning rate, also known as 'yield' or 'APY', is the sum of two components:

• the underlying yield accrued by pool assets as they are routed to other DeFi per the pool strategy; and,

• the VSP reward, or “boost” (if any) assigned as part of VSP token reward distribution.

The Grow Pool underlying yield is auto-compounded in the deposited asset. That is, the DAI Grow Pool yield is returned in the form of DAI. The "spot" earning rate is calculated as the last 72 hours’ performance annualized and compounded, while the "average" reflects the last 30 days, annualized and compounded.

Sweeping: This is a contract function that swaps non-native ERC20 tokens and deposits them back into the Grow Pool. 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 in to form of the pool's deposited asset. This also handles any tokens mistakenly sent to the contract.

Available Vesper Grow Pools

Because the family of Vesper pools is continuously growing and changing, for an accurate list of currently available pools you should consult the Vesper App.

Through strategies, Vesper Pools interface with a number of different protocols and perform a handful of different interactions at those protocols. Each Vesper strategy represents some combination of interactions across various DeFi platforms. These platforms include, but are not limited to, MakerDAO, Aave, Compound, and Yearn. Vesper users do not select strategies, rather, they select pools. The pool's internal logic determines which strategies it employs.

Each strategy is differentiated by, among other things:

• Deposit asset (that is, the token you can deposit into the pool, such as ETH, wBTC, etc.)

• Contract risk level

• Susceptibility to realized losses

Categories of Strategies

At a minimum, in every pool TVL is deposited or swapped into a protocol. Beyond that, the position may be used as collateral or staked for additional yield. These strategies include:

<Platform> Deposit

This is the most basic strategy of simply depositing a particular protocol.

<Platform> LP

Unlike a straight deposit, pool TVL is converted into the platform’s pertinent liquidity provision (LP) token.

<Platform> to <Platform>

After depositing to a platform, the output of that deposit is then deposited to another platform.

<Platform> Leverage

Pool TVL is deposited to a platform where it is used as collateral to borrow the same token, to redeposit over and over, “leveraging” up the assets contributed to the platform versus the strategy’s initial deposit.

<Platform> Borrow

Deposits to a platform are utilized as collateral to borrow a different token. That token is then routed through the corresponding Vesper pool for that token where it is routed through that pool’s strategies.

Vesper Proxy

A representative mapping of strategies to protocols appears below. Keep in mind that the available strategies on any platform are subject to change and are regularly updated.

Strategies are classed as medium-risk or higher-risk. The risk level reflects the level of safety with regards to the underlying contract interactions. Medium-risk strategies have fewer interactions with safer, audited platforms. (These strategies are considered 'medium' rather than 'low' risk because nothing within the cryptocurrency or DeFi category is truly low-risk.) Higher-risk alternatives may reflect a higher number or more complex interactions as well as exposure to unaudited contracts.

Pools are classed as Conservative or Aggressive depending on their likelihood of realizing losses. This primarily refers to the susceptibility of outstanding loans to liquidation. Conservative pools employ strategies which use higher collateral ratios on loans to better protect against 'black swan' events that can jeopardize the loan.

The following terms outline the participants in the Vesper ecosystem and the roles that they play.

Founders

The team that originally created the Vesper platform. They are compensated with a portion of the originally minted VSP tokens.

Developers

Developers are Vesper community members who contribute strategies to the Vesper platform. They are compensated with a percentage of the fees generated within the strategies they author.

VSP Holders

Members of the Vesper community that hold or lock VSP (for esVSP) tokens will be able to cast votes on proposals and receive a share of Vesper revenue (if they lock their VSP tokens).

Pool Participants

Pool participants are Vesper's core users, making them a critical part of the community from Day 1. They often hold VSP tokens, but regardless they have an important voice in the community that is expressed through both their capital allocations and their participation in community conversations.

Multisig Keyholders

At inception, Vesper pool parameters and contract upgrades are managed by multisig keyholders, whose members include the founding team and external partners. Multisig keyholders execute the decisions made by the VSP community.

The initial composition of the Vesper multisig includes founding team members, and will quickly expand to include external partners. You can learn more about Vesper's decentralization roadmap in the section on the Decentralization Plan.

Cybersecurity auditors

Before new strategies are deployed to the Vesper platform, they will need to undergo extensive security audits by professional penetration testing firms. There auditors will be paid with Vesper reserve funds, and will ensure that new contracts are held to the highest levels of scrutiny before users interact with them.

‌Liquidity Providers

Liquidity Providers assist the Vesper community by providing two-sided liquidity to a VSP pair on the Uniswap platform.

‌Ecosystem Partners

iYield provides a clear picture of your financial health by combining crypto and fiat assets. It tracks your net worth, savings rate, and DeFi yields while factoring in assets, debts, income, and expenses. Track your Vesper positions easily here.

Black Swan Event

One of the primary risks faced by Vesper pools is a 'black swan' event, where a pool's underlying asset sees a rapid flash crash. In extreme cases, the debtor will not be able to modify their loan fast enough to avoid liquidation. This is a broader risk that affects DeFi lending protocols as a whole.

A partial liquidation is enforced by the lending protocol. Some lenders charge fees on the capital liquidated. This would reflect a financial loss to pool participants.

Exploits

Another primary risk faced by Vesper pools is if a protocol that Vesper routes funds through is exploited. While exploits in DeFi seem to have decreased over time, they still do occur. While Vesper is careful both in the project's own audited codebase, along with the selection of other protocols that funds are routed through, both Vesper and/or other protocols being exploited and having a negative financial impact on user deposits is possible.

Assessing Risk

Vesper pools rebalance their loans algorithmically along parameters specified by each pool. Users are able to view the strategies and weighting being used inside the Vesper dApp to assess the risk they are comfortable taking when making their pool selections.

Stable Coin Depeg

Stable coins have the potential of a depegging risk (when the coin no longer is valued at the price it is supposed to represent). While stable coin pools have historically been a safer product in DeFi, a depegging event could cause user losses.

Negative Yield

In rare instances, a Vesper pool can produce negative yield for a user. These periods of negative yield are usually temporary. This can occur due to borrowing costs exceeding yield on a loan, or rebalancing interest without having a yield harvest on the lent asset. There is a risk that a Vesper pool depositor can earn negative yield in a pool for a loss of capital.

APY Estimation

Estimated APY’s in the Vesper dApp are calculated automatically and algorithmically. Calculating APYs in DeFi is notoriously difficult, and it is possible that the APY being displayed differs from the actual APY being earned. The Vesper team to the best of its ability tries to display an accurate APY. There is a risk however that the APY being displayed is inaccurate at times.

Additional Risk

There are likely additional risks associated with using Vesper Finance that are not listed here.

Features reflecting the cryptocurrency category's accepted standard and that enable proper interoperability between our platform and others.

• Non-Custodial: Assets are deposited to and deployed automatically via smart contracts. Users always maintain 100% ownership of their funds and can retrieve them at any time.

• Trustless: Assets are algorithmically deployed through the specifications laid out by Vesper pool strategy smart contracts.

• Permissionless: No signup, whitelisting, account verification, or otherwise is required to participate in the Vesper ecosystem.

• Censorship Resistant: Users can always interact with the smart contracts directly, which fundamentally cannot be taken down or tampered with.

• Open Source: Any developer is welcome to build with Vesper. In fact, it's highly encouraged and heavily incentivized.

• Fraud Resistant: The qualities listed above position Vesper's ecosystem to minimize the risk of fraudulent activity typically associated with bordered, custodial, trusted, permissioned, closed source, and censored platforms.

• Simple, Easy-to-use: Vesper's user interface was designed to be as seamless as possible. One-click deposit and withdrawals plus mechanisms for portfolio tracking and miscellaneous Vesper metrics.

• On Ethereum, 'Layer 2 Positive': The Vesper ecosystem is deployed on the base ('Layer 1') Ethereum blockchain, where it can interact with existing DeFi protocols for yield farming. Layer 2 solutions are under active consideration as potential ways to improve the efficiency of the platform.

DeFi Primitives

Features representing the mechanics of the DeFi products offered as part of Vesper.

• Grow Pools: Grow Pools collect a particular asset (ETH, WBTC, USDC, others) via user deposits and deploy the capital to other DeFi platforms as outlined by the Grow pool's active strategies. Yield accrued by these strategies are used to buy back more of the deposit asset, which is delivered to pool participants.

• esVSP: Token holders can deposit VSP to the esVSP contract. Revenue generated across all Vesper products is used to buyback VSP from the open market. These tokens are delivered to esVSP holders, where holders earn VSP interest proportionate to the size of their deposit.

All Tokens

Features reflecting all tokens in the Vesper ecosystem, including the VSP governance token and the various tokenized pool shares.

• ERC20 Standard: Industry standard for tokens on Ethereum, this enables tokens in the ecosystem to interact with the existing global DeFi ecosystem (Ex: tradeable on Uniswap).

• ERC-721: Used for esVSP, the ERC-721 standard represents ownership of non-fungible tokens, that is, where each token is unique.

• EIP-712: All tokens support EIP-712 for sharing data via message signing. This is an important component of gas-less approvals.

• EIP-2612 (Gas-less Approvals): All tokens leverage EIP-2612, which enables gas-less approvals, with the help of EIP-712. Users can send tokens to any contracts after signing an approval message, rather than having to broadcast a transaction.

• Multi-Transfer: Inspired by Metronome, all tokens feature a mass pay functionality that enables batched payments in a single transaction.

VSP Token

Features of the VSP token that make it the best token to govern the Vesper ecosystem:

• Voting Rights: VSP tokens (esVSP) correspond to the voting weight in the Vesper ecosystem, which includes deployment of reserves and approval of new strategies.

• Delegation: Forked from Compound, holders can delegate their VSP voting weight to other accounts.

• Holistic View: Vesper is a single-token ecosystem, with every product (new and future) interfacing with VSP. VSP grants voting rights that span the entire Vesper umbrella and revenue generated by all products are used to buy back VSP off the open market.

• Time-Locked Mintage: The Administrative "mint" function is locked for the first twelve months. This prohibits a supply expansion beyond 10 million until a point in the future where ownership has fully transitioned to the community of VSP holders, where they can decide for themselves whether or not to extend emissions.

Pool Share Token

Features specific to the various tokenized pool shares that add value + functionality beyond the immediate purpose of tokenized stake.

• "Lego Brick" Modularity: Vesper pool shares are designed as a modular asset that can be plugged into other DeFi platforms. Vesper participants maintain liquid ownership of pool shares and can use them for other functionalities while retaining said ownership. For example:

  • Collateral: Vesper pool shares can be applied as collateral to create synthetic assets or to be posted as collateral to take out a loan. This is similar to how yCRV is backed by Grow pool shares (yUSDC + yDAI + yTUSD + yUSDT).

Backend Maintenance

Features representing the underlying mechanics that ensure Vesper operates as smoothly and securely as possible.

• Sweeping: This is a contract function that swaps non-native ERC20 tokens and deposits them back into the Grow Pool. 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.

• Rebalancing: Pool assets are redistributed (or rebalanced) on activity. This includes, for example, realizing yield and swapping to deposit asset or adjusting strategy positions on entry to or exit from the pool.

Pool Strategies

Features that guide Vesper Grow Pools to be profitable, secure, and sustainable.

• Risk Scoring: Every Vesper Grow Pool has a conservative/aggressive score that reflects the overall risk of the strategies employed by the pool including the security of third-party protocols interacted with, number of contract interactions, and collateralization ratios on loans (if applicable).

• Modular: Grow Pool strategies can be modified to integrate additional or alternative actions as well as swapped altogether for better strategies. No action is required on the user's end and funds transition to updated strategies automatically.

• Upgradeable: As new and better strategies are proposed within the confines of a pool's defined risk framework, those strategies can be employed without moving funds.

• Multi-Pool: Pool assets can be deployed across n strategies, with any chose percentage allocated to a strategy (e.g. Allocating 90% of your pool to a Conservative strategy, and 10% to an Aggressive strategy.)

  • Upgrades: Upgrades utilize the multi-pool feature to execute a rolling transition from an old strategy to a new one. (Ex: Start with 1%/99% new/old, then 5%/95%, etc. up the staircase until 100%/0%.)

  • Developer Strategies: A pool can support an unlimited number of strategies. Therefore, developers may spread funds across n pools as a way of testing their strategy.

Web3 UI

Features pertaining to the Vesper frontend to enable a more seamless experience for users.

• Multi-lingual Support: Like our pool strategies, website content is modular, and users can interact with Vesper in their native language. As more translations are compiled, they can similarly be added alongside available translations.

Participation Rewards

Features that guide how VSP token rewards are allocated to participants.

• Merkle Tree Reward: ZK-Rollups and Merkle trees are employed for distributing VSP to recipients. This enables more sophisticated approaches to VSP distribution (weighted averages, for example) and also eliminates much of the gas burden typically associated with claiming rewards.

Vesper provides a platform for easy-to-use Decentralized Finance (DeFi) products.

Vesper's DeFi products deliver ease-of-use in achieving your crypto-finance objectives. The Vesper token (VSP) is the core economic engine that facilitates the building and expansion of Vesper’s capabilities and its community.

The Vesper project rests on three pillars:

Vesper Products: At launch, Vesper offers a variety of interest-yielding "Grow Pools" that enable users to passively increase their crypto holdings by simply selecting the desired aggressiveness of their strategy and the digital asset held. The Vesper Grow Pools represent the first product on the Vesper platform. More will be developed and presented over time.

Vesper Token: VSP incentivizes participation, facilitates governance (by locking up for esVSP), and catalyzes user contribution. Users earn VSP through pool participation and, later, participating in Vesper's continuous improvement.

Vesper Community: Vesper is building a user community that sustains and grows the product portfolio, facilitates progressive decentralization, and enables users to build new products while earning a share of that product's fees.

Medium is best for news and insights. Twitter serves as our primary notification channel. Discord is where most interactions around governance, community, and development (by the team and community members) takes place.

Vesper Pools combine tokens of the same kind from many depositors to generate yields for its participants. Assets in Vesper pools are used to borrow, lend, and farm yield across various DeFi projects. Each pool has its own deposit asset type, yield asset type, deployment approach (employing one or more "strategies"), and risk level.

Users select the pool or pools that let them employ the asset or assets they wish to use and which fits their risk tolerance.

Certain pools also generate rewards for participants in the form of VSP, Vesper's native token.

Using Vesper Pools

Vesper pools are designed for accessibility. Connect your wallet (for example, MetaMask) with any of the available deposit assets, and make your deposit through the Vesper web interface (that is, the Vesper App).

When you deposit, you’ll receive a vToken that represents your weight in the pool. For example, deposit ETH and get vETH.

To exit the pool, simply use the Vesper App and the withdraw function in the 'manage' section of pool you're participating in, and you will receive the underlying asset. The app is designed to be self-documenting, and many users find that it answers basically all of their questions about using Vesper products. Below, a representative view of the Vesper App.

Types of Vesper Pools

• Vesper Grow : Grow Pools collect a particular asset (ETH, WBTC, USDC, others) via user deposits and deploy the capital to other DeFi platforms as outlined by the Grow pool's active strategies. Yield accrued by these strategies are used to buy back more of the deposited asset, which is delivered to pool participants.

Because the family of Vesper pools is continuously changing, for an accurate list of currently available pools you should consult the Vesper App.

Understanding vTokens

As explained above, each vToken functions as a claim ticket representing your share of the assets in the pool. While your funds are in the pool, you are free to move your tokenized stake to other wallets you control.

The calculation of the correspondence between the deposited token and the vToken differs according to the type of pool.

In the case of Grow Pools, as the pool accrues yield and purchases more of its asset, that tokenized stake will grant more of the underlying asset. Say, for example that you deposit one DAI into the Vesper Grow DAI pool, for which you receive one vDAI token in exchange. Let's say that over the course of a year, that pool's earning rate is 10%. At the end of that year, your 1 vDAI token would now be worth 1.1 DAI.

Note that when you deposit your crypto into a pool, your the amount of the vTOKEN you receive depends on whatever the current rate of the vToken is. The pool started at a ratio 1:1 and the vToken increases overtime. So unless you deposit on day 0 of the pool, you are going to receive less than one 1 vDAI per 1 DAI. That vDAI will continue to appreciate in value as explained above.

The situation for Earn Pools is different, since the yield is not automatically re-deployed in the original collateral pool, but rather "dripped" to a separate pool denominated in the yield token. So at the end of the year your 1 vDAI token would be worth your original deposit of 1 DAI while your yield was paid out in a different asset.

Fees

During Vesper's first year of operation, there were two types of fees associated with Vesper pools: withdrawal fees and platform fees. These fees were allocated to the Vesper Treasury and to the pool's architect.

As of April, 2022, these fees are being phased out in favor of a Universal Fee. The Universal Fee will charge a 2% annual fee on the assets deposited (principal) at the time of rebalance. If this fee is greater than 50% of the yield earned, then the fee will only equate to 50% of the yield earned. The fee is assessed as part of the rebalancing process, as explained below.

VSP Rewards

In addition to their crypto yield, certain activities additionally generate VSP rewards, such as locking up your VSP tokens for esVSP to earn revenue share.

Understanding Earning Rates (Yield)

In Vesper pools that offer VSP rewards, depositors accrue yield in two denominations: The original asset they deposited, and VSP (from the rewards account).

In the illustration below, these two types of yield are listed in the “Earning Rate” field. For example, if you look at the FEI pool, and click on the value in the “Earning Rate” column you will see a pop up like the one shown here. In this example the 6.67% value represents the total APY on your deposit. It comprises 4.45% yield in FEI, and 2.29% represents the APY on your deposited asset, denominated in VSP.

The field labeled "My Deposits" shows your current balance in the pool, including any yield that has already accrued.

To withdraw your deposited cryptocurrency from the pool (incurring the withdrawal fee) you click on “Withdraw;” to claim your VSP rewards, click on “Claim.” You can claim these rewards at any time.

Note that the displayed APY is after the performance fee has been subtracted

Rebalancing

Rebalancing is the process by which yield is allocated to pools.

It works as follows:

• Each pool has a 'high water' and 'low water' percentage that correlates to the collateral requirements enforced by the lending platform. Whenever users interact with the pool, or the pool claims yield, it determines the current collateralization ratio and compares it to the high and low water ratios.

• TheRebalanceFriction administrative parameter protects the pools from excessive rebalance calls.

• Any member of the public, user or not, may call the rebalance function every RebalanceFriction number of seconds. When the rebalance function is called, if the assets are in 'high water', more loans are taken out. If the pool is at 'low water', some of the loan are returned to partially close out the loan.

• This rebalance function also claims interest, and swaps interest to collateral tokens on a decentralized exchange.

Rebalance Mechanics

The initial conservative pools use 250% and 275% collateralization benchmarks as the boundaries for low water and high water variables, respectively.

When the collateral on outstanding loans is greater than 275% at time of call, additional loans are taken out to bring the collateral ratio back down. If outstanding loans are less than 250% collateralized, then the loans will be partially repaid to bump the ratio up into a healthy midpoint between low water and high water.

All strategies additionally rebalance as per the strategy module to realize yield and allocate as dictated by the pool (to compound in Vesper Grow and convert in Vesper Earn). The frequency of each strategy depends on network congestion and the TVL in the pool.

In order to reduce gas burden, more expensive strategies and smaller pools rebalance less frequency than large pools/cheap strategies. All pool strategies target a minimum rebalance frequency of once per week.

Deeper Dive: Rebalance Frequency

Rebalance frequency is not static. Because this operation requires a significant amount of gas, we have logic built into the process which is aware of the current gas rates and adjusts the rebalance timing accordingly to optimize for transaction costs. The amount of time between rebalances can be impacted on the scale of days if gas remains above the threshold. Once gas returns to lower levels, the rebalance operation will execute. After a rebalance, it’s not a simply a “dump” of all claimable rewards, but they will come in slowly every block going forward (for Earn pools).

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 Optimism or base 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.

Fighting 'Strategy Fade'

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.

Modularity Enables Sustainability

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.

The Logical Structure of Vesper Pools

Each Vesper pool has three main modules: Collateral, Strategy, and Action.

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.

The Modular Multi-Pool Approach

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.

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.

Multi-Pool Under the Hood

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.

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.

Governors and Keepers

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.

Sweeping

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.

Summary of Vesper Multi-Pool Architecture

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.

Universal Fee

The Universal Fee charges a 2% annual fee on the assets deposited (principal) at the time of rebalance. If this fee is greater than 50% of the yield earned, then the fee will only equate to 50% of the yield earned.

Yield Mechanics

For community pools, a 5% share of both of these fees goes to the developer who authored the strategy. This is paid in the pool’s asset.

Incentives

Any user may trigger a Rebalance-Collateral operation, to address pool-wide systemic risk and generate additional stablecoin yield. If collateral price falls below Low Water, this operation will prevent liquidation. If collateral price rises above High Water, this operation will generate additional DAI, which, in turn, generates more yield for the entire pool. Users have the incentive to use this to earn maximum yield and avoid liquidation.

Any user may trigger a Rebalance-Earned operation. This operation swaps earned stablecoin interest for underlying collateral (e.g. DAI to ETH), and adds this collateral to the pool's holdings. Users have the incentive to not call the operation, as the longer the collateral stays in there, the more yield it earns. Balancing that, they have the incentive to call the operation prior to withdrawal, to maximize the amount of collateral in pool, to maximize their share of collateral withdrawn.

Treasury Income

[Ed. note: This section is under revision per the Nov. 15, 2021, community vote to revise the treasury income model to be more focused on the long term growth of Vesper.]

Community Growth Engine

The Vesper project and community are tied together by the VSP token.

At launch, 10,000,000 VSP tokens will be minted, and allocated almost entirely to community-focused efforts. In the short term, 3,400,000 of these funds will be allocated to product and liquidity provisioning incentives.

In the long term, the community reserves (3,600,000 tokens) combines with community-defined level of VSP revenue from the VSP vault. These VSP tokens will be held in a community vault, to be used to create a continuous cycle of bootstrapping new products with VSP incentives, which in turn benefits the VSP token, which generates funds to bootstrap yet more products.

This strategy involves MakerDAO. This strategy operates as follows:

1. The pooled asset is deposited to a Maker vault as collateral;

2. DAI loans are taken out against the collateral;

3. DAI is deposited, where it generates yield;

4. The yield is withdrawn and either

   • Swapped on the open market back for the deposit asset, or

   • Redeposited for compounding returns

This strategy is medium-risk. It can be deployed as either aggressive or conservative, depending on the low-water and high-water collateralization benchmarks. Conservative pools use a low water mark of 250% and high water mark of 275%.

With esVSP comes the transition to on-chain governance. This new model uses a modified version of Compound Governance’s code, with Tally.xyz as the user interface. In order to participate, users will need to lock VSP for esVSP, with voting power determined by the number of esVSP a user has. Holders of esVSP will then be able to make decisions, propose, and vote upon changes to the Vesper protocol on a weighted basis.

Once locked, the boosted amount is calculated based on the number of VSP tokens a user has locked, and the duration of the locking. The maximum boost is 4x, and represents voting weight. Voting power is based on the boosted amount.

Note that initial functionality will be limited and expanded over time.

Background

Vote-escrow tokenomics have been a game-changer in the DeFi space since their inception. Standout platforms such as Curve have underscored their potential by enabling users to lock their tokens for a share of the revenue. For years now, it's been a proven mechanism to drive growth, boost TVL, and cultivate a thriving community.

However, this model presents challenges, primarily the liquidity constraints due to the non-transferable nature of the locked tokens. Vesper's esVSP offers an evolved approach. Drawing from the foundational principles of the vote-escrow model, esVSP is designed to address these challenges and ensure a more robust system that benefits users of the Vesper ecosystem.

Key features include:

• Rewarding long-term users with a share of the revenue

• Liquid positions where users can trade their locked esVSP on the open market as an ERC-721 token

• Early exit with fees directed to the Vesper DAO Treasury

The concept of an early unlock fee is not new within DeFi, acting as a safety net to encourage users to stay in the ecosystem. With Vesper, this early unlock fee is the penalty you would pay if you decide to unlock your VSP before the end of your chosen lock-up period. The initial penalty starts at 50%, and decreases linearly over time until the lock expires when it becomes 0%. Any penalty fees collected in this way go back to the Vesper DAO Treasury.

How does it work?

To determine the penalty involved in an early unlock, you can use the following formula:

User’s Locked Balance * Remaining Time * Maximum Penalty / Total Lock Duration

Example

Let’s say you locked your VSP for 1 year, but after 6 months, you decided to withdraw them early.

Given the penalty decreases linearly from 50% to 0% over the course of the lock duration (1 year in this case), at the halfway point (6 months), your penalty would be 25%.

If you had locked 100 VSP, you’d pay 25 VSP as a penalty for unlocking them early.

How To Unlock

2. Click “Manage” on the position you wish to unlock

3. At the top of the popup, select “Unlock” - Here you will see how many days you have left until you get a penalty free unlock

4. If you do not want to wait, enter in the amount you want to unlock - Make sure you are comfortable with the early unlock penalty fee

5. Confirm the translation

In order to start earning rewards such as revenue share, users will first need to lock their VSP tokens. The revenue each esVSP holder earns will be influenced by their respective weights. These weights are dependent on the amount of VSP they’ve locked and the duration of the lock, which can be between 1 week to 2 years (730 days), with a maximum multiplier of 4x.

How does it work?

To calculate your esVSP, you can use the following formula:

1. Boost: MaxBoost * Lockup Duration / Max Lockup

2. Boosted Balance: Balance * Boost

3. Total esVSP Balance: VSP Balance + Boost Balance

Example

Suppose a user decides to lock their 1000 VSP tokens for a period of 2 years (730 days). Using the formulas above:

Boost: 4 * 730 / 730 = 4

Boosted Balance: 1000 * 4 = 4000

Total esVSP Balance: 1000 + 4000 = 5000 esVSP

How To Lock

1. Visit https://app.vesper.finance/eth/locked-vsp and connect you wallet

2. Select “Lock”

3. Use the slider to choose your lock amount and then click “Next”

4. Choose your lockup duration

5. Select “Lock VSP” and confirm the transaction

The founding team will always provide the community answers to these basic questions for every material decision the team makes:

• What decision has been made?

• Why was that decision made?

• Who is impacted by the decision?

• When is the decision going into effect?

• How can the community provide feedback and voice their opinion?

Founding Principles

As with other projects in the DeFi space, Vesper's governance will emerge from community collaboration and participation. We begin the project with a few simple governance principles:

• Any and all material changes to Vesper products and VSP should be proposed in public, with code, with appropriate time for community feedback.

• We believe that a responsible yield farming network can remain in the founding team's hands for the initial phase only, until power can be transferred to the community. Our roadmap for progressive decentralization outlines our strategy for transitioning to fully autonomous and decentralized decision-making.

• We believe a successful governance system should minimize the time and cost necessary for a person or entity to participate in governance. We will explore gas-efficient methods of voting like Layer 2 scaling solutions to reduce costs associated with voting.

Every pool has metadata associated with it that is stored in JSON format in the Vesper repository. This information is used, for example, by the Vesper app. By consulting this file you can get a helpful overview of all Vesper pools, controllers and supported tokens.

Most of the fields should be self-explanatory, but a few of the fields in the pool descriptions are some worth a bit of elaboration. Consider the example below, for the vDAI Vesper Grow pool. Start with looking at the values of the 'name' field (vDAI) and the 'asset' field (DAI). These values tell us that Internally to the pool, calculations are done in units of the vDAI claim token, and that to participate in this pool, the user deposits DAI.

The 'chainID' field tells us whether the pool is deployed to the Ethereum mainnet, (chainID = 1) or another chain such as Base (chainID = 8453) or Optimism (chainID = 10).

The 'risklevel' field denotes the perceived risk associated with this pool. These values are used, among other things, to indicate whether a pool is labeled as 'conservative' or 'aggressive' in the Vesper App.

The 'stage' field indicates where the pool is in its lifecycle. Possible values include 'beta' for pools under development, 'orbit' for riskier pools offered under Vesper Orbit, 'back' for pools that only service other pools, 'prod' for pools in production under the Vesper brand, and 'retired' for pools that are no longer supported.

The 'type' field values include 'grow,' 'earn' and 'governance'. This list will grow as new kinds of Vesper products are developed.

// Some code  
{
      "name": "vDAI",
      "poolName": "vDAI Pool",
      "address": "0xcA0c34A3F35520B9490C1d58b35A19AB64014D80",
      "asset": "DAI",
      "birthblock": 11594191,
      "chainId": 1,
      "riskLevel": 3,
      "stage": "prod",
      "symbol": "vDAI",
      "decimals": 18,
      "logoURI": "https://raw.githubusercontent.com/vesperfi/metadata/master/src/logos/vdai.svg",
      "type": "grow"
    },

All esVSP tokens are eligible to participate in Vesper governance votes. VSP holders can acquire esVSP by locking their tokens.

Within Vesper, token-locking users will receive esVSP, enabling them to vote on various pool parameters through Vesper Improvement Proposals (VIPs). This includes many different decisions such as strategy proposals, asset inclusions, protocol-specific matters, and more.

Signal Voting

Signal voting through Snapshot is a casual process, with the outcome being executed in good faith of the sentiment of voters. Initially, only whitelisted "core" addresses are permitted to create snapshot proposals.

Snapshot requires a block number to poll balances, which will be estimated at three hours prior to the start of the vote. Snapshot votes run for 72 hours in length.

Votes require at least 30,000 esVSP voting in favor with majority approval to meet quorum and pass. This quorum requirement may increase over time as esVSP supply increases and holders become more accustomed to voting.

*VSP holders may still vote on Snapshot with VSP if they wish.

Proposal Introduction (Off-Chain)

Proposal Creation (On-Chain)

Following the forum discussion, the proposal can be introduced on-chain. Alternatively, users have the option to initiate the proposal on-chain at the same time as the forum discussion. However, this on-chain proposal creation needs to occur at least 7 days prior to the beginning of the voting period. The on-chain proposal will remain in the 'proposal stage' for 1 week.

Voting Phase

The voting will begin after a votingDelay() of 7 days. During the votingPeriod() of 3 days, proposals will be in an ACTIVE state, and users will be able to cast their votes FOR or AGAINST. A snapshot of voting power will be taken and will no longer be able to be delegated or transferred.

For a proposal to be successful, at least 4% of the total voting power must participate in the vote, determined by the quorum function. In order to achieve the required 4% quorum for a proposal, the total voting power is calculated by adding the VSP supply to the esVSP boost supply, then subtracting the VSP balance locked in the esVSP contract to avoid double counting. If a proposal passes, it will change to a SUCCEEDED state. If not it is marked as DEFEATED.

TimeLock

A SUCCEEDED proposal can be queued and will be executed after the minDelay() of 2 days. The validation and execution of the proposal is performed by the timelock executor. A successfully executed proposal state is EXECUTED. If a queued proposal has not been executed before expiration, then the proposal state is CANCELLED.

Overview

VSP is the platform’s governance token, which gives token-holders the ability to participate in on-chain votes on new pool strategies and other platform decisions. This section addresses how members of the Vesper community might use their tokens in this manner.

Governance Phases & Rationale

‌Vesper Governance is derived from the Compound governance module, a tried-and-true framework that has become familiar to the DeFi community. From Day 1, the founding team will begin relinquishing control over Vesper operations through phases of progressive decentralization, and will strive for the highest standards of communication and transparency.

Transitioning to Community Governance

Many DeFi projects have experienced early 'growing pains' when initiating community governance. We hope to mitigate this friction with an iterative transition to community governance.

1. For the first 2-6 months, ownership functionalities will be retained by the team’s multisig in order to upgrade strategies, introduce new pools, allocate VSP rewards, and so on.

2. After 2-6 months, governance responsibilities will be transferred in full to holders of vVSP in the vVSP vault.

3. At the end of that 2-6 month period, the Founding Team will stake 1,000,000 VSP from the community reserve to the vault. This will mint vVSP 'receipt tokens' as a 'governance bootstrap' to ensure quorum and good governance principles are met. The voting power of those tokens will be initially delegated to the Founding Team's multisig. As the 1,000,000 VSP that created these voting tokens are unstaked, they will be deposited back into the vault for the benefit of the other vVSP holders.

4. Over the course of one year after the governance module is launched, vVSP delegated to the Founding Team will be forfeited quarterly, so that 100% of the control will be in the hands of the community at the end of this one-year period.

We expect the community’s voting power to exceed that of the team by Month Six.

The revenue generated by the reserve fund is 'community property' and is sent back to the other vVSP holders. The flow of assets will be very visible/auditable to the community.

Votes can only be cast by vVSP token-holders. The vote passage/approval requirements are as follows:

Voting & Participation

Participants can engage with the Vesper community by proposing, developing and assisting Vesper Improvement Proposals [VIPs], casting votes on VIPs, and sharing their opinion in our community chats. (See "The Voting Process.")

Treasury Management

2,950,000 VSP is dedicated as DAO reserves. Most of this VSP likely stays in the primary wallet and deployed on voting for the likes of reward extensions and VSP boosts for new pools.

But beyond that, there are many, smaller expenditures required to facilitate further growth of Vesper. There are two "satellite wallets" represented as OpComms and Community Marketing. Each wallet is a 2-of-n multisig with a modest allowance (2,000-4,000 VSP) to be utilized as needed per the discretion of signers.

OpComms is designated for misc. one-off purchases and expenditures. This includes audit payments, bug bounties, freelance work, and so on. The CM wallet is utilized for community engagement, contests and campaigns, content bounties, and so on.

These types of siloed wallets enable a more efficient ecosystem that doesn't require a vote on every single spend and maintains security of the overall treasury by fragmenting allowances to different groups and categories.

Today, wallet signers comprise of team members, Vesper community members, and external reputable faces in DeFi. Ultimately, more and more weight will shift away from the team and towards the community.

Some assets will earn higher APY if deposited straight to a lending platforms ( such as Aave or Compound) rather than being first deposited to Maker for a DAI loan.

This more straightforward strategy has only two parts:

1. Deposit 100% of the pool asset straight to Aave or Compound (wherever yield is highest)

2. Claim and redeposit the yield as it is accrued

This is a medium-risk, conservative strategy; the contracts it interacts with are well audited, and the collateralization ratios are conservative.

It could be used as a launchpad for more aggressive strategies, by using the deposits to Aave/Compound as collateral for loans which are then deployed in other interest-yielding platforms.

Types of contracts documented here

Abstract classes or models used for creating instances.

Types of contracts not documented here

Link to Developer's Guide

The following pages document the various contracts that are used to implement Vesper pools. For a conceptual overview of how these contracts work together, along with Vesper strategy contracts, see the Vesper Developer's Guide.

Flow control in Vesper V3

The diagram below illustrates how various contracts interact in the V3 framework. To a first approximation,

• Users or external (non-Vesper) contracts interact with pools;

• The (proxied) pool contract interacts with strategies;

• Pool rewards and pool accountant contract are logically just parts of the pool contract;

• Strategies are deployed target protocols (for example, Compound, Aave);

• Keepers, which may be bots or persons, regulate the system.

T

Mapping the block diagram to smart contracts

The Pool block represents an implementation of the VPool contract.

Pool rewards is a module for calculating and storing any VSP rewards associated with the pool. It is implemented with the PoolRewards and PoolRewardsStorage contracts.

The Pool Accountant keeps track of the strategies used by the pool. It is implemented by the PoolAccountant and PoolAccountantStorage contracts.

Strategy represents one or more strategy contract for deploying assets to generate yield.

With regard to the illustration above, let’s assume this Vesper pool is vDAI pool. That means a user will deposit DAI and receive a vDAI claim ticket in return, the amount of which is based on the value of the pricePerShare variable at the time the deposit is made.

The Target Protocol block represents the protocol to which the pool's assets have been sent, such as, for instance, Curve, Compound or Yearn.

Flow of Control When a Deposit Is Made to a Pool

Here's what happens when a user makes a deposit to a pool. The steps below are labeled to correspond to the pathways in the illustration above.

1. The user initiates deposit of DAI in the vDAI pool.

2. If the PoolRewards contract exists, the pool sends an update to to the PoolRewards contract, notifying it that the user is depositing in the pool.

3. The pool issues shares of vDAI, also known as claim tokens, to the user. These claim tokens go to the user's wallet.

Flow of Control When a Withdrawal from a Pool Occurs

Here's what happens when a user makes a withdrawal from a pool. The steps below are labeled to correspond to the pathways in the illustration above.

a. The user initiates withdrawal of DAI. To do this, the user must hold vDAI in their wallet. This vDAI is now transferred to the pool.

b. If the PoolRewards contract exists, then the pool sends an update that the user is withdrawing from the pool, and any rewards due to the user are calculated.

c. The pool maintains a local reserve of DAI in order to cover withdrawals. If the pool's reserve holds sufficient funds to cover the withdrawal, it burns the user's share of vDAI, and transfers to the user an equivalent amount of DAI. Otherwise, if the local reserve does not have sufficient DAI on hand, the pool initiates withdrawal from one or more of its strategies.

d. Since strategies do not hold any collateral, (DAI in this case), it withdraws DAI from its target protocol.

If the pool employs more than one strategy, the Pool Accountant maintains a list that determines the order in which strategies will be asked for funds to complete a withdrawal.

Flow of Control during Rebalancing

i. Only the keeper can call rebalance on strategies.

ii. Strategies gather data to generate profit/loss and payback statements. In the case of profit and/or payback, each strategy will withdraw funds from its target protocol, given it has deposited funds previously.

iii. The Strategy sends profit/loss and payback statements to the pool.

iv. The Pool passes this information to the PoolAccountant, which is responsible for doing all bookkeeping.

v. The PoolAccountant sends the final standing of the strategy back to the pool and the pool decides whether to give more funds to the strategy or take back from the strategy.

vi. If the strategy has received funds from the pool, it deposits these new funds in the target protocol; otherwise it must withdraw from the target protocol to give funds back to the pool.

The architectural framework of Vesper Pool smart contracts has evolved over time. Each iteration of the framework is denoted by a version number. (These version numbers are sometimes incorporated into different implementations of the same smart contract — for example PoolStorageV1, PoolStorageV2, PoolStorageV3 . The table below lists attributes of the framework versions.

Vesper's modular architecture allows for upgrading of pools from one framework version to another. At any time contracts of different framework levels may coexist in the Vesper ecosystem, but over time they all tend to be upgraded to the most current version.

A Schematic Overview of flow control in Vesper V3

The diagram below illustrates how various contracts interact in the V3 framework. The description that follows gives a high-level overview of these processes work. More detailed explanations will be forthcoming soon.

The Vesper Pool System Architecture

Components of the pool system architecture include:

The Pool block represents an implementation of the VPool contract.

Pool rewards is a module for calculating and storing any VSP rewards associated with the pool.

The Pool Accountant keeps track of the strategies used by the pool.

Strategy represents one or more strategy contract for deploying assets to generate yield.

Following Assets from Deposit to Withdrawal

Let’s assume this vesper pool is vDAI pool meaning user will deposit DAI and receive vDAI in return based on pricePerShare at the time of deposit

The Target Protocol block represents the protocol to which the pool's assets have been sent, such as, for instance, Curve, Compound or Yearn.

Deposit:

1. The user initiates deposit of DAI in the vDAI pool.

2. If the PoolRewards contract exists, the pool sends an update to to the PoolRewards contract, notifying it that the user is depositing in the pool.

3. The pool issues shares of vDAI, also known as claim tokens, to the user. These claim tokens go to the user's wallet.

Withdrawal:

a. The user initiates withdrawal of DAI. To do this, the user must hold vDAI in their wallet.

b. If the PoolRewards contract exists, then the pool sends an update that the user is withdrawing from the pool, and rewards are calculated.

c. The pool maintains a local reserve of DAI in order to cover withdrawals. If the pool's reserve holds sufficient funds to cover the withdrawal, it burns the user's share of vDAI, and transfers to the user an equivalent amount of DAI. Otherwise, if the local reserve does not have sufficient DAI on hand, the pool initiates withdrawal from one or more strategies.

d. A strategy does not hold any collateral, (DAI in this case), so it withdraws DAI from target protocol.

Rebalance:

i. Only the keeper can call rebalance on strategies.

ii. Strategies gather data to generate profit/loss and payback statements. In case of profit and/or payback, strategy will withdraw funds from target protocol, given it has deposited funds previously.

iii. The Strategy sends profit/loss and payback statements to the pool.

iv. The Pool passes this information to the PoolAccountant, which is responsible for doing all bookkeeping.

v. The PoolAccountant sends the final standing of the strategy back to the pool and the pool decides whether to give more funds to the strategy or take back from the strategy.

vi. If the strategy has received funds from the pool, it deposits these new funds in the target protocol; otherwise it must withdraw from the target protocol to give funds back to the pool.

Token Standards

Vesper pools supports ERC20 and EIP2612 permit standards.

This document is intended for developers who wish to programmatically route crypto assets from other protocols to and from Vesper pools and strategies. It is a companion to the Vesper Contracts API Reference, which documents API end points for Vesper pools and Vesper strategies.

This Developer's Guide is not a guide to developing, testing, deploying or updating Vesper pools or strategies. As such it does not explain the programs (generally written in JavaScript) that are used by pool-operations to perform these functions. Also, it does not explain the inner workings of every strategy. Rather, it explains the overall architecture in which Vesper pools and strategies interact, and to give a conceptual overview of the role of each contract in the system. The purpose of this documentation is to enable developers of other protocols, DAOs, wallets, and other entities the opportunity to use Vesper, with confidence, for enhanced product offerings and treasury management options. For a complete understanding, of course, you should read the code itself in the Vesper repository. Think of this guide as your road map to what you'll find there.

The discussion that follows assumes that you've read Vesper's Modular Pool Architecture, which explains pool and strategy architecture in abstract terms. Below, we will go into more concrete detail to explain how this architecture is implemented in Vesper's smart contracts.

Categories of Vesper Smart Contracts

Vesper smart contracts, written in the Solidity programming language, are organized in the Vesper code repository in directories described in the next sections. The Vesper Contracts API Reference only documents contracts that reside in the Pool directory, along with a few key contracts in the Strategy directory, since those are the only ones that other (that is, external to Vesper) protocols would interact with. The types of Vesper smart contracts which exist in the repository but are not included in the Reference are described briefly below.

Dependencies

Wherever it is practical to do so, Vesper uses smart contracts from OpenZeppelin to implement common DeFi functionality. Contracts from OpenZeppelin are in the 'dependencies' directory.

Interfaces

Interfaces are pure abstract contracts that contain external functions that contain only declarations — that is, no statements. Implementations of other contracts inherit from them. The Interfaces directory includes Vesper interfaces from which pools and strategies are derived. Examples include IVesperPool.sol, IStrategy.sol, and IEarnDrip.sol.

Pool

This directory includes all the contracts that are instantiated when a Vesper pool is deployed. Each of these contracts is described in the Vesper API Reference.

Strategies

This directory includes all the strategy contracts employed by Vesper pools to generate yield. The contracts in this directory include both general purpose contracts like Strategy.sol and VesperStrategy.sol that are inherited by all strategy contracts, and contracts that implement specific strategies on specific platforms — for example the aave subdirectory includes the contracts AaveCore.sol, AaveLeverageStrategy.sol, AaveStrategy.sol, and so forth.

Test

This directory includes interfaces and contracts that are used to implement various tests.

Upgraders

This directory includes contracts that are used to upgrade pools and their related contracts.

Utils

This directory that contains contracts used to do things like interfacing with external exchanges.

Various Contracts at the Top Level of the 'Contracts' Directory

Contracts including Errors.sol, the abstract contracts FlashLoanHelper.sol, Governable.sol and Pausable.sol are implemented by all pools to provide common functionality.

Understanding Proxied Pools

We have seen that Vesper pools are engineered for upgrading. Not only can pool logic be changed to fix any errors or to improve performance, but also the strategies used by pools can be changed or modified at any time. This is accomplished using proxies, as explained below.

The idea behind proxies is separating the logic parts of a pool from its state. Consider the illustration below. Imagine that we were going to implement a Vesper Grow pool for the 'Cool' token. The vCool pool would be created as an instance of Strategy.sol. When deployed, it would create two new contracts: the Logic Layer Contract, or llc, which contains the pool's logic, and the Storage Layer Contract, or SLC, which contains the pool's state. Thereafter, the storage layer contract effectively is the pool, from the point of view of other contracts that interact with it. In other words, if you were writing a contract on a protocol external to Vesper and wanted to invoke, say, the withdraw method of the vCool contract, you would access it at address A1, not A0.

Note that in the illustration below, the arrows from the vCool pool only point in one direction. This indicates that the pool contract spawns the SLC and LLC, but those contracts, once created, have no interaction with the pool contract.

The storage layer contract, in turn, contains a pointer to the address of the logic layer contract. The logic layer actually contains the code that implements the function that was invoked.

Given this architecture, the process of upgrading a pool is simply a matter of deploying a new LLC, and then changing pointer in the SLC to point to the new LLC instead of the original one.

To understand how the Vesper software ecosystem works, you need to have a general understanding not just of the smart contracts that implement pools and strategies and related functionality, but of the supporting infrastructure for creating, managing and deploying those contracts.

The processes and software tools that provide this infrastructure fall under the heading of 'pool operations' ('pool ops') or 'development operations' ('dev-ops).

This Guide is not intended to explain Vesper pool ops or dev ops. Its aim is simply to point you in the right direction for you to study the appropriate code on your own. In particular, the "deploy' and 'deployments' directories in the top level of the Vesper repository for any given framework level contain the JavaScript programs and JSON files used to deploy pools and pass them the initial values of their key parameters, as in the codes snippet below.

You will also find in the repository directories for tests, helpers, tasks, and so on. Once you have a conceptual understanding of pools, strategies, proxies and upgrading, studying the code in these directories should give you a sound understanding of Vesper software engineering.

In addition to the yields generated by the pools, users can also earn the native VSP token. Users earn VSP tokens in two ways: participating in Vesper pools, or locking VSP. These are described below.

VSP is dripped to users (a little is issued to them every block), and held by the smart contract until the user withdraws from the pool, which triggers the contract to deliver the VSP to their address.

Earning VSP: Vesper Pools

Each Vesper pool is assigned an amount of VSP tokens, and these are distributed to participants proportionate to the size of their stake in the pool. New pools are incentivized after launch.

These VSP tokens are an extra reward on top of the passive real yield the pool generates.

Earning VSP: Locking VSP for esVSP

By locking your VSP, you'll receive esVSP. Much like how depositing ETH yields vETH, locking VSP tokens gives you esVSP (ERC-721).

After withdrawal and yield fees are collected in the pool (ETH, BTC, USDC, etc.), they go to the Treasury Box and are used to buy back VSP on the open market. This VSP is delivered to esVSP participants and can be claimed in the dashboard.

Vesper Launch Details

Supply Dynamics

At launch, Vesper will have a total supply of 10,000,000 VSP:

• 6.5M VSP (65%) goes to the community, which includes 2.55M for the Incentivized Launch Pools, 1M to incentivize liquidity providers, and 2.95M to the Vesper Reserves.

• 3.5M VSP (35%) is for Vesper team, advisors, and strategic partners, which is subject to vesting over twelve months.

The initial policy is to keep the supply at 10 million. Twelve months following public launch (after open beta), the community may vote on whether to burn the admin keys and fix the supply at 10 million forever, or, assign minting ability to a DAO for future management. It is up to the community to decide whether limiting future minting benefits the overall Vesper project. For the first 12 months, any amount of VSP beyond 10 million is locked.

Beta Program

Before the official Vesper launch, there will be a brief beta program where users can deposit funds and participate in the initial Vesper pools. There is no active VSP drip during the beta (as there is after), but average balances across the entire period will be recorded and beta users will receive VSP proportionate to their deposited assets after the conclusion of beta.

450,000 VSP is allocated as beta rewards to be distributed to early users of Vesper's open beta. These rewards will be delivered as a multi-send airdrop to each beta participant's wallet on launch day. No further actions are required for beta participants to be eligible.

Token Emissions

Please note that these emissions are not finalized, and may be subject to change at the discretion of the community. (For more on Vesper’s governance, refer to the documentation’s chapter on Vesper’s decentralization plan.)

• Launch Pools (2,550,000 VSP)

  • 450,000 allocation to pre-launch Beta participants, airdropped at launch

  • 2,100,000 over twelve months, heavily weighted towards the first three months

• Reserves (2,950,000 VSP)

  • Reserves for ecosystem growth and developer/community incentives, as determined by VSP voters

  • NOTE: A small amount of reserves have been leveraged to further boost rewards on Grow Pools.

• Liquidity Providers (1,000,000 VSP)

  • Incentivization for LPs on Uniswap, SushiSwap, 1inch and Loopring (with SushiSwap retaining majority)

  • 1,000,000 distribution over 12 months, heavily weighted towards the first month (and more acutely — the first weeks)

• Team and Advisors (2,500,000 VSP)

  • 208,333 (1/12) unlocked at launch

  • 2,291,667 (11/12) vested with streaming unlock (constant drip each block) for eleven months following launch

• Strategic Partners (1,000,000 VSP)

  • 83,333 (1/12) unlocked at launch

  • 916,667 (11/12) vested with streaming unlock (constant drip each block) for eleven months following launch

Emissions Breakdown

SushiSwap LP rewards for the first month were distributed via Geyser (gysr.io). Months 2-12 are distributed through a merkle claims process at Pure Finance for liquidity providers who deposit their LP tokens to SushiSwap Onsen (thus receiving $SUSHI rewards as well).

Uniswap LP rewards are distributed via Geyser for the full twelve month duration following the schedule below. You can interact with the Uniswap Geyser here.

1inch LP rewards are distributed through 1inch multi-farming support for those who deposit to 1inch VSP-1inch LP farming. They receive VSP in the same manner as they received 1INCH initially, and 1inch team also has the opportunity to extend their supplied 1inch rewards as well.

Loopring LP rewards are handled through Loopring directly. VSP is rewarded to market makers on the orderbook exchange and follows a formula that multiplies the volume of a user’s buy/sell orders by time-spent within 2% of the market price. You can learn more about Loopring’s orderbook liquidity mining in the post here.

Additionally, users can earn LRC when they trade across the VSP-ETH AMM. A VSP/DAI orderbook will be included soon as well.

Note that the sum of SushiSwap and Uniswap LP rewards is 1,000,000. The additional 107,800 VSP across 1inch and Loopring was funded out of the reserves allocation.

Team, Advisor, and Partner tokens are held in a Sablier contract. Recipients can interface with the contract to claim VSP as frequently or as seldom as they prefer. They receive 1/n of their total VSP allocation over the entire n blocks of their vesting period.

Below outlines VSP emissions. Several assumptions are made:

• All tokens are claimed as soon as they are available.

• No additional VSP is granted from reserves.

• Existing reserve holdings are not counted towards emissions.

Vesper launched on 2/17/2021

UPDATED 8/16/2021 (VIP-10: Emissions Upgrade)

From 8/13/21 - 8/16/21, vVSP holders voted unanimously in favor of an overhaul to VSP emissions to platform participants.

VIP-10 outlines a new system for emissions that utilizes two global VSP allocations: one for all Vesper Pool participants and one for all liquidity providers. Each Vesper pool earns a portion of the global allocations depending on TVL, and each market receives a share based on the volume traded. These metrics are polled each month and weights are updated accordingly for the coming month.

This approach enables Vesper to continue to incentivize usage of new products without necessitating additional emissions beyond what is currently accounted for and agreed upon.

VSP Allocation for Vesper Pools

Each pool is assigned a number of "points" to reflect their weight in the global emissions. The points breakdown is as follows:

• #1 highest TVL pool: 5 points

• 2-3: 4 points

• 4-5: 3 points

• 6-8: 2 points

• 9+: 1 point

New pools will automatically be allocated 3 points for the first month after launch and 2 points for the second month, and are absorbed into the above methodology starting their third month.

VSP Allocation for Vesper Liquidity Providers

Each market is assigned a number of "points" to reflect their trading volume versus other exchanges.

• SushiSwap: 5 points

• #1 highest volume (excluding SushiSwap on ETH Layer 1): 3 points

• 2-3: 2 points

• 4+: 1 point

New markets start with 2 point allocation in their two months, and are absorbed into the above methodology starting their third month.

NOTE: Uniswap v2 LP rewards are immutable through Month 12. Uniswap will be absorbed into this mechanism starting Month 13.

Updated Emissions Breakdown

NOTE: See deprecated emissions for total VSP emissions (which remain unchanged). If emissions exceed DAO reserves, vVSP holders can vote to mint more VSP to the reserves at any point in time after Month 12.

Deprecated Emissions (replaced Month 7: 8/16/2021)

NOTE (7/16): Further months emissions are largely a placeholder while ongoing discussion of tokenomics/revenue V2 take shape. *vLINK pool rewards began on April 29th (middle of "month 3"). vLINK rewards breakdown is as follows:

• Month 1 (First thirty days starting Apr 29): 40,000 VSP

• Month 2: 15,000 VSP

• Month 3: 20,000 VSP

**Error in Geyser deployment duplicated VSP rewards for liquidity providers to Uniswap through the duration of month three. Rewards were prorated slightly in month four in response.

PoolRewards

Distributes VSP rewards based on the user's Vesper pool balance and the supply of rewards available to that pool.

VERSION

initialize

Called by proxy to initialize this contract.

notifyRewardAmount

Notify that reward is added. Only authorized caller can call this function.

Also updates reward rate and reward earning period.

notifyRewardAmount

addRewardToken

Add new reward token in existing rewardsToken array

claimReward

Claim earned rewards.

This function claims rewards for all tokens being rewarded

updateReward

Updated reward for given account.

claimable

Returns claimable reward amount.

getRewardTokens

Provides easy access to all rewardTokens

lastTimeRewardApplicable

Returns timestamp of last reward update

rewardForDuration

rewardPerToken

Rewards rate per pool token

VETH

This contract handles ETH incoming to the contract address. It inherits from VPOOL.

constructor

receive

Handle incoming ETH to the contract address.

withdrawETH

Burns tokens/shares and returns the ETH value, after fee, of those.

withdrawETHAndClaim

Burns tokens/shares and returns the ETH value and claim rewards if any

deposit

Receives ETH and grants new tokens/shares to the sender depending on the value of pool's share.

depositAndClaim

Deposit ETH and claim rewards if any

This is an abstract contract. Every pool has one associated PoolAccountant that is an implementation of this contract. The each pool's associated PoolAccoutStorage contract is used to store values used by the Pool Accountant. The current version of the abstract class inherits from its predecessor, going back to PoolAccountantStorageV1.

PoolAccountantStorageV1

pool

totalDebtRatio

totalDebt

strategies

withdrawQueue

PoolAccountantStorageV2

StrategyConfig

strategy

externalDepositFee

PoolAccountant

This contract is the "accountant" for Vesper pools which keeps records of strategies. Each deployed pool has one associated accountant.

VERSION

MAX_BPS

EarningReported

LossReported

StrategyAdded

StrategyRemoved

StrategyMigrated

UpdatedExternalDepositFee

UpdatedPoolExternalDepositFee

UpdatedStrategyDebtRatio

init

This init function meant to be called after proxy deployment. DO NOT CALL it with proxy deploy; only after the proxy has been successfully deployed.

addStrategy

Add strategy. Once a strategy is added it can call rebalance and borrow funds from the pool and invest those funds in a provider/lender.

Recalculate pool level external deposit fee after all state variables are updated.

setup

OnlyPool:: Helper function for V5 upgrade

removeStrategy

Remove strategy and recalculate the pool level external deposit fee.

Revoke and remove strategy from the strategy array. Update withdraw queue. Withdraw queue order should not change after remove. Strategy can be removed only after it has paid all debt. Use he migratestrategy function if debt is not paid and you want to upgrade the strategy.

updateExternalDepositFee

Update external deposit fee of the strategy and recalculate the pool level external deposit fee.

recalculatePoolExternalDepositFee

Recalculate the pool external deposit fee. It is calculated using debtRatio and the external deposit fee of each strategy.

Whenever debtRatio changes, recalculation is required. DebtRatio changes if a strategy reports loss, in which case an off-chain application can watch for it and take action accordingly. This function is 'gas heavy', so we do not want to call it during reportLoss.

sweepERC20

Transfer given ERC20 token to pool

updateDebtRatio

Update debt ratio.

A strategy is retired when its debtRatio is 0. As debtRatio impacts pool level external deposit fee, it must be recalculated after updating debtRatio.

updateWithdrawQueue

Update withdraw queue. Withdraw queue is a list of strategies in the order in which funds should be withdrawn.

Pool always keeps some buffer amount to satisfy withdrawal requests. Any withdrawal request higher than what is in the buffer will cause withdrawal from the withdraw queue. So withdrawQueue[0] will be the first strategy where withdrawal request will be sent.

migrateStrategy

Migrate an existing strategy to new strategy.

Migrating strategy aka old and new strategy should be of same type. New strategy will replace old strategy in strategy mapping, strategies array, withdraw queue.

reportEarning

Strategy calls this at regular intervals.

reportLoss

Update strategy loss.

decreaseDebt

Decrease debt of strategy; this also decreases totalDebt.

In case of withdraw from strategy, pool will decrease debt by the amount withdrawn

availableCreditLimit

Get available credit limit of strategy. This is the amount strategy can borrow from the pool.

Available credit limit is calculated based on current debt of pool and strategy and the current debt limit of pool and strategy. credit available = min(pool's debt limit, strategy's debt limit, max debt per rebalance). When any strategy does not pay back its outstanding debt, this impacts the credit line of other strategies if totalDebt of pool >= debtLimit of pool

excessDebt

Debt above current debt limit

getStrategies

Return the strategies array.

getWithdrawQueue

Return withdrawQueue array.

totalDebtOf

Get total debt of given strategy.

PoolRewardsStorage

This contract keeps track of addresses used by the PoolRewards contract to compute and distribute vVSP "rewards".

pool

Vesper pool address

rewardTokens

Array of reward token addresses

isRewardToken

Reward token to valid/invalid flag mapping

periodFinish

Reward token to period ending of current reward

rewardRates

Reward token to current reward rate mapping

rewardDuration

Reward token to Duration of current reward distribution

lastUpdateTime

Reward token to Last reward drip update time stamp mapping

rewardPerTokenStored

Reward token to Reward per token mapping. Calculated and stored at last drip update

userRewardPerTokenPaid

Reward token => User => Reward per token stored at last reward update

rewards

RewardToken => User => Rewards earned till last reward update

IVesperPoolV2

An interface.

getPricePerShare

function getPricePerShare() external view returns (uint256)

VesperEarnDrip

This contract handles the "drip" of the yield asset in Vesper Earn pools. It inherits from PoolRewards.

DripRewardPaid

event DripRewardPaid(address user, address rewardToken, uint256 reward)

GrowTokenUpdated

event GrowTokenUpdated(address oldGrowToken, address newGrowToken)

growToken

address growToken

receive

receive() external payable

claimable

function claimable(address _account) external view returns (address[] _rewardTokens, uint256[] _claimableAmounts)

Returns claimable reward amount.

In case of growToken it will return the actual underlying value

notifyRewardAmount

function notifyRewardAmount(address _rewardToken, uint256 _rewardAmount, uint256 _rewardDuration) external

Notify that reward is added. Also updates reward rate and reward earning period.

updateGrowToken

function updateGrowToken(address _newGrowToken) external

Defines which rewardToken is a growToken

growToken is used to check whether to call withdraw from Grow Pool or not

_calculateRewardInDripToken

function _calculateRewardInDripToken(address _rewardToken, uint256 _reward) private view returns (uint256)

The rewardToken AKA growToken is a Vesper Grow Pool which can be V2 or V3 pool. V2 and V3 pools have different signatures to read price per share.

Earn

An abstract contract that inherits from Strategy. All Vesper Earn pools are implementations of the Earn contract.

dripToken

address dripToken

dripPeriod

uint256 dripPeriod

totalEarned

Accounting total stable coin earned after fee. This amount is not reported to the pool.

uint256 totalEarned

DripPeriodUpdated

event DripPeriodUpdated(uint256 oldDripPeriod, uint256 newDripPeriod)

updateDripPeriod

function updateDripPeriod(uint256 _dripPeriod) external

Update update period of distribution of earning done in one rebalance

_dripPeriod in seconds

approveGrowToken

function approveGrowToken() external

Approves EarnDrip' Grow token to spend dripToken

Strategy

This is an abstract contract that implements key functionality for all strategies. For example, the AaveLeverageStrategy contract inherits from Strategy and AaveCore.

collateralToken

contract IERC20 collateralToken

receiptToken

address receiptToken

pool

address pool

feeCollector

address feeCollector

swapManager

contract ISwapManager swapManager

oraclePeriod

uint256 oraclePeriod

oracleRouterIdx

uint256 oracleRouterIdx

swapSlippage

uint256 swapSlippage

_keepers

struct EnumerableSet.AddressSet _keepers

UpdatedFeeCollector

event UpdatedFeeCollector(address previousFeeCollector, address newFeeCollector)

UpdatedSwapManager

event UpdatedSwapManager(address previousSwapManager, address newSwapManager)

UpdatedSwapSlippage

event UpdatedSwapSlippage(uint256 oldSwapSlippage, uint256 newSwapSlippage)

UpdatedOracleConfig

event UpdatedOracleConfig(uint256 oldPeriod, uint256 newPeriod, uint256 oldRouterIdx, uint256 newRouterIdx)

addKeeper

function addKeeper(address _keeperAddress) external

Add given address in keepers list.

keepers

function keepers() external view returns (address[])

Return list of keepers

migrate

function migrate(address _newStrategy) external virtual

Migrate all asset and vault ownership,if any, to new strategy

_beforeMigration hook can be implemented in child strategy to do extra steps.

removeKeeper

function removeKeeper(address _keeperAddress) external

Remove given address from keepers list.

updateFeeCollector

function updateFeeCollector(address _feeCollector) external

Update fee collector

updateSwapManager

function updateSwapManager(address _swapManager) external

Update swap manager address

updateSwapSlippage

function updateSwapSlippage(uint256 _newSwapSlippage) external

updateOracleConfig

function updateOracleConfig(uint256 _newPeriod, uint256 _newRouterIdx) external

approveToken

function approveToken() external

Approve all required tokens

setupOracles

function setupOracles() external

withdraw

function withdraw(uint256 _amount) external

Withdraw collateral token from lending pool.

rebalance

function rebalance() external virtual

Rebalance profit, loss and investment of this strategy

sweepERC20

function sweepERC20(address _fromToken) external

sweep given token to feeCollector of strategy

token

function token() external view returns (address)

Returns address of token correspond to collateral token

totalValue

function totalValue() public view virtual returns (uint256 _value)

Calculate total value of asset under management

Report total value in collateral token

totalValueCurrent

function totalValueCurrent() external virtual returns (uint256)

Calculate total value of asset under management (in real-time)

Report total value in collateral token

isReservedToken

function isReservedToken(address _token) public view virtual returns (bool)

Check whether given token is reserved or not. Reserved tokens are not allowed to sweep.

Vesper Improvement Proposals (VIPs) can be submitted at [GitHub Link].

VIP-000: Title

A VIP number, like VIP-001, will be assigned and the proposal author should give it a short, descriptive title.

Summary

In easy-to-understand language, describe the purpose of your proposal and what it intends to achieve for the Vesper network.

Abstract

Briefly describe what the proposed change will do.

Expectations

Detail the expectations and assumptions behind the VIP's proposed contract. This is the qualitative and quantitative rationale behind the contract's strategy.

Specification

In detailed, technical language, describe the inner workings of your proposed contract.

Test Cases

Describe how other implementations or back-tests of this contract performed.

VesperStrategy

NAME

VERSION

totalValue

Calculate total value using underlying vToken

Report total value in collateral token

isReservedToken

Check whether given token is reserved or not. Reserved tokens are not allowed to sweep.

EarnVesperStrategy

constructor

Overview

The Vesper team encourages community-created content and merchandise. To assist this and help ensure consistency and quality, the team provides guidelines, a color palette, typeface, and images for the community's use.

Color Palette

Logo Treatment

Images

Vesper Logos

Vesper Token

Typeface

The current version of PoolStorage inherits from its predecessor which in turn inherits from its predecessor going back to the original implementation, PoolStorageV1.

PoolStorageV1

token

Collateral token address

poolAccountant

PoolAccountant address

poolRewards

PoolRewards contract address

PoolStorageV2

PoolStorageV3

universalFee

Universal fee of this pool. Default to 2%

maxProfitAsFee

Maximum percentage of profit that can be counted as universal fee. Default to 50%

minDepositLimit

Minimum deposit limit.

Do not set it to 0 as deposit() is checking if amount >= limit

EarnVesperStrategyVSPDrip

transferToDripContract

bool transferToDripContract

constructor

constructor(address _pool, address _swapManager, address _receiptToken, address _dripToken, address _vsp, string _name) public

Vesper adheres to rigorous security practices that includes independent audits on every user facing smart contract (pools, rewards) and every yield strategy. There are well over 50 audits covering the entire span of Vesper engineering.

All Vesper audits can be found on our github audit directory. This link is updated frequently as ongoing audits are continually returned to Vesper engineering.

What is Vesper?

Vesper is a platform of DeFi products designed for ease-of-use, longevity, and scale. It is a comprehensive ecosystem governed by the VSP token.

Vesper Grow

What are Vesper Grow Pools? Vesper Grow Pools are algorithmic DeFi lending strategies. They pool capital from a group of users and deploy it to generate interest across various DeFi protocols. Accrued interest is used to buy back the pool's deposit asset (which may be ETH, BTC, USDC, or something else), and award it as interest to participants.

How do I interact with Grow Pools? All you have to do is choose the pool you are interested in and deposit your asset. One transaction, and the pool does the rest. Similarly, you can withdraw your funds and claim your interest with one transaction.

What Grow Pools are available today? As of the launch there are three pools: ETH, BTC, and USDC. We will frequently offer trial pools to the community before they go prime-time on the Vesper website.

Has the code been audited?

Yes. The code has undergone two independent audits by Coinspect and Certik. See the Audits and Due Diligence section for more details.

What is the benefit to depositing my funds in an Grow Pool? Grow Pools deploy your assets into DeFi lending strategies. You can choose a pool based on your risk tolerance and desired token. This reduces a process that typically comprises more than a dozen fee-extracting transactions, hours of research, and constant monitoring down to a one-time deposit and withdrawal. Additionally, Grow pool participants farm VSP tokens, further rewarding users with even greater passive returns, catalyzing participation, and forming the basis for progressively decentralized governance.

What happens to my funds after I deposit them in a Grow pool?

Deposits are pooled and deployed through the strategy outlined by the particular Grow pool. See the Strategies page for more information on what that strategy may look like.

Is there any risk associated with Vesper Grow pools?

Grow pools that interface with loans are at risk in the event of a so-called black swan event, such as when a pool asset sees a flash crash in a short amount of time. In this event, the pool's outstanding debt position may become under-collateralized, leaving the lender insolvent, and the pooled funds may be hit with a liquidation fee, which could translate into a loss to the participant.

Each token supported offers a pool that pursues conservative and aggressive strategies. Conservative pools use higher collateralization ratios and are therefore less vulnerable to such a risk – but not completely immune.

Additionally, Grow pool strategies are only as safe as the platforms they interact with. Medium-risk pools only interact with blue-chip DeFi protocols like Maker, Aave, and Compound, but high-risk pools may interface with newer and less established alternatives.

What are the fees?

There is a 2% universal fee which is taken from yield earned. See more information on the universal fee.

Where do the fees go?

The platform fee and withdrawal fee are both taken in the form of pool shares, and delivered to the Treasury Box. They continue to earn yield as any pool share would, until they are converted to VSP tokens by selling them on the open market via an AMM like Uniswap or SushiSwap. These VSP go to esVSP holders.

VSP Token

What is the VSP token?

VSP is the governance token that serves as the basis for the Vesper ecosystem. VSP holders can vote on proposals, and additionally deposit their tokens to passively accumulate more VSP.

How do I earn VSP tokens?

There are three ways to earn VSP tokens:

• Participating in Vesper pools. Each pool is assigned an amount of VSP tokens that are distributed to participants proportionate to size of stake. Initial Grow pools are incentivized for three months after launch.

• Providing liquidity. Liquidity Providers to the VSP-ETH Uniswap pair are incentivized with VSP similarly to the Grow pools. The trading pair is incentivized for one year after launch.

• Staking your VSP. Users can deposit their tokens to the VSP treasury pool. A small percentage of withdrawals are allocated to the treasury box, and those funds are used to buy back VSP and award to pool depositors.

How will I receive my VSP tokens?

VSP tokens are 'dripped' to pool participants, and held by the smart contract until they broadcast a transaction to exit the pool, whereupon the VSP is delivered to their address.

Governance

Who makes decisions about what happens with Vesper?

Initially, the founding team will govern the project. This is a hard decision to make, but seeing how other tokens have had widespread difficulties with community governance on Day One, the safest route seems to be keeping Vesper under our wing immediately after launch. As the Vesper ecosystem matures, governance will soon be turned completely over to the community. See the Decentralization Plan and Roadmap page to learn more.

Who governs the Treasury Box?

Just like other Vesper pools, the Treasury Box has an algorithmically-enforced strategy. At launch, the multisig signers from the Vesper team have jurisdiction to make changes to the treasury strategy. As Vesper transitions to community governance, changes to the strategy are proposed and deployed in the same manner as any of the Vesper pools.

Can I propose new products or strategies to be added to Vesper?

New products and strategies can be proposed by any holder with 1% of the issued esVSP supply. You can hold these VSP tokens yourself, have other VSP holders delegate tokens to table your proposal, or a combination of both.

On day 1, before any meaningful portion of the supply has been issued, proposals will be initiated by the Vesper team. We are eager to transition to community governance, at which point VSP community members will be able to create a formal proposal for a new strategy, product, or change to the ecosystem. The sky's the limit to how many assets and strategies can be deployed, and we are excited to see what the community comes up with.

How do I vote? All VSP/esVSP holders are eligible to vote. Users can acquire esVSP tokens by locking their VSP. All Vesper Improvement Proposals (VIPs) that are backed esVSP will be voted upon by the the community of esVSP holders. You can learn more about the voting process in the Voting and Participation section.

Medium-Risk/High-Risk – Refers to the security of the Vesper Grow Pool strategies. Medium-risk strategies have less steps and fewer asset conversions. Additionally, medium-risk strategies only interact with audited and highly secure third party contracts. Alternatively, high-risk strategies are more complex in terms of the underlying contract calls and may interact with unaudited protocols, such as Yearn vaults. (There is no 'low-risk' designation because we believe that labeling anything as low-risk in crypto is disingenuous.)

Conservative/Aggressive – Refers to how prone a Vesper Pool strategy is to realizing losses due to partial liquidation. Conservative pools adhere to higher collateralization ratios than aggressive pools, and as such are better protected in the event that the pool's deposit asset sees a rapid loss in value (thus putting the outstanding loan underwater and in danger of liquidation).

Low Water/High Water – Vesper Pools that deposit assets to MakerDAO in order to withdraw DAI loans adhere to low-and-high water collateralization targets. If the ratio of collateral to the outstanding DAI loan falls below "low water", the loan will be partially refunded to increase the ratio. If the ratio is above the high water benchmark, additional DAI will be taken out to shift the ratio below "high water".

Black Swan Event – Extenuating circumstance where a drastic "flash crash" in the price of an asset causes financial products interfacing with the asset to breakdown. In the world of cryptocurrency, this looks like a substantial crash in Ethereum, BTC, or other collateral asset that leads to mass liquidations. The danger is compounded with low scalability making it difficult or impossible for debtors to service their loans in order to avoid liquidation. Vesper's additional low/high water mechanism further insulates Grow Pools from the detriments of a potential Black Swan.

Rebalance-Collateral – Any user may trigger this operation to address pool-wide systemic risk and generate additional stablecoin yield. If collateral price falls below Low Water, this operation will prevent liquidation. If collateral price rises above High Water, this operation will generate additional DAI, which, in turn, generates more yield for the entire pool. Users have the incentive to use this to earn maximum yield and avoid liquidation.

Rebalance-Earned – Any user may trigger this operation to swap earned stablecoin interest for underlying collateral (e.g. DAI to ETH), and add the purchased collateral (e.g. ETH) to the total pool holdings. Users have the incentive to not call the operation, to maximize stablecoin deployed earning yield. Users have the incentive to call this operation prior to withdrawal, to maximize amount of collateral in pool, to maximize share of collateral withdrawn.

Developer's Fee – The 5% share of the fees taken by pools (as withdrawal fees and platform fees) that is allocated to the author of the strategy.

Treasury Box – Fees taken from Vesper products (pools or otherwise) are taken as tokenized shares. The treasury box converts these tokenized shares back to the underlying assets then swaps the assets for VSP on Uniswap, where 95% of it is given to stakers and 5% to strategy developers.

Reserves – 2,950,000 VSP of the 10,000,000 total supply is allocated to Vesper's DAO holdings. These reserves can be deployed only with the democratic approval of VSP holders. Reserves are designed to extend incentives to holding and liquidity pools beyond initial allocations and introduce incentives to new products as they are released.

Earning Rate – Earning Rate reflects two figures: the underlying yield accrued by pool assets as they are routed to other DeFi platforms per the pool strategy and the VSP "boost" assigned as part of VSP token distribution. The "spot" earning rate is calculated as last 24-hours performance annualized and compounded, while "average" reflects the past 30-days annualized and compounded.

VPool

All Vesper pools are implementations of VPOOL. This contract performs the core functions for all Vesper pools, including deposits, withdrawals, fee calculation

VERSION

string VERSION

MAX_BPS

uint256 MAX_BPS

ONE_YEAR

uint256 ONE_YEAR

UpdatedMaximumProfitAsFee

event UpdatedMaximumProfitAsFee(uint256 oldMaxProfitAsFee, uint256 newMaxProfitAsFee)

UpdatedMinimumDepositLimit

event UpdatedMinimumDepositLimit(uint256 oldDepositLimit, uint256 newDepositLimit)

Deposit

event Deposit(address owner, uint256 shares, uint256 amount)

Withdraw

event Withdraw(address owner, uint256 shares, uint256 amount)

UpdatedUniversalFee

event UpdatedUniversalFee(uint256 oldUniversalFee, uint256 newUniversalFee)

UpdatedPoolRewards

event UpdatedPoolRewards(address previousPoolRewards, address newPoolRewards)

UpdatedWithdrawFee

event UpdatedWithdrawFee(uint256 previousWithdrawFee, uint256 newWithdrawFee)

UniversalFeePaid

event UniversalFeePaid(uint256 strategyDebt, uint256 profit, uint256 fee)

constructor

constructor(string _name, string _symbol, address _token) public

initialize

function initialize(string _name, string _symbol, address _token, address _poolAccountant) public

Equivalent to a constructor for the proxy. It can be called only once per proxy.

deposit

function deposit(uint256 _amount) external

Deposit ERC20 tokens and receive pool shares depending on the current share price.

depositAndClaim

function depositAndClaim(uint256 _amount) external

Deposit ERC20 tokens and claim rewards, if there are any.

depositWithPermit

function depositWithPermit(uint256 _amount, uint256 _deadline, uint8 _v, bytes32 _r, bytes32 _s) external

Deposit ERC20 tokens with permit, aka gasless approval.

whitelistedWithdraw

function whitelistedWithdraw(uint256 _shares) external

Withdraw collateral based on given shares and the current share price. Burn remaining shares and return collateral. Claim rewards if there are any

Deprecated method. Keeping this method here for backward compatibility.

withdraw

function withdraw(uint256 _shares) external

Withdraw collateral based on given shares and the current share price. Burn remaining shares and return collateral.

withdrawAndClaim

function withdrawAndClaim(uint256 _shares) external

Withdraw collateral and claim rewards, if any.

multiTransfer

function multiTransfer(address[] _recipients, uint256[] _amounts) external returns (bool)

Transfer tokens to multiple recipients

Address array and amount array are 1:1 and are in order.

reportEarning

function reportEarning(uint256 _profit, uint256 _loss, uint256 _payback) external

Strategy call this in regular interval. Only strategy function.

reportLoss

function reportLoss(uint256 _loss) external

Report loss outside of rebalance activity.

Some strategies pay deposit fee thus realizing loss at deposit. For example: Curve's 3pool has some slippage due to deposit of one asset in 3pool. Strategy may want report this loss instead of waiting for next rebalance.

sweepERC20

function sweepERC20(address _fromToken) external

Transfer given ERC20 token to governor

availableCreditLimit

function availableCreditLimit(address _strategy) external view returns (uint256)

Get available credit limit of strategy. This is the amount strategy can borrow from pool

Available credit limit is calculated based on current debt of pool and strategy, current debt limit of pool and strategy. credit available = min(pool's debt limit, strategy's debt limit, max debt per rebalance) when some strategy do not pay back outstanding debt, this impact credit line of other strategy if totalDebt of pool >= debtLimit of pool

calculateUniversalFee

function calculateUniversalFee(uint256 _profit) external view returns (uint256 _fee)

Calculate universal fee for calling strategy. This is only strategy function.

Earn strategies will call this during rebalance.

excessDebt

function excessDebt(address _strategy) external view returns (uint256)

Debt above current debt limit

getStrategies

function getStrategies() external view returns (address[])

totalDebt

function totalDebt() external view returns (uint256)

Get total debt of pool

totalDebtOf

function totalDebtOf(address _strategy) external view returns (uint256)

Get total debt of given strategy

totalDebtRatio

function totalDebtRatio() external view returns (uint256)

Get total debt ratio. Total debt ratio helps us keep buffer in pool

calculateMintage

function calculateMintage(uint256 _amount) public view returns (uint256 _shares)

Calculate how much shares user will get for given amount. Also return externalDepositFee if any.

Amount should be >= minimum deposit limit which default to 1

getWithdrawQueue

function getWithdrawQueue() public view returns (address[])

pricePerShare

function pricePerShare() public view returns (uint256)

Get price per share

Return value will be in token defined decimals.

strategy

function strategy(address _strategy) public view returns (bool _active, uint256 _interestFee, uint256 _debtRate, uint256 _lastRebalance, uint256 _totalDebt, uint256 _totalLoss, uint256 _totalProfit, uint256 _debtRatio, uint256 _externalDepositFee)

tokensHere

function tokensHere() public view returns (uint256)

Returns the token stored in the pool. It will be in token defined decimals.

totalValue

function totalValue() public view returns (uint256)

Returns sum of token locked in other contracts and token stored in the pool. It will be in token defined decimals.

_beforeBurning

function _beforeBurning(uint256 _share) private returns (uint256 _actualWithdrawn, bool _isPartial)

Before burning hook. withdraw amount from strategies

_calculateShares

function _calculateShares(uint256 _amount) private view returns (uint256)

Calculate shares to mint/burn based on the current share price and given amount.

_calculateUniversalFee

function _calculateUniversalFee(address _strategy, uint256 _profit) private view returns (uint256 _fee)

Calculate universal fee based on strategy's TVL, profit earned and duration between rebalance and now.

_calculateUniversalFee

function _calculateUniversalFee(uint256 _lastRebalance, uint256 _totalDebt, uint256 _profit) private view returns (uint256 _fee)

migrateStrategy

function migrateStrategy(address _old, address _new) external

Migrate existing strategy to new strategy.

Migrating strategy aka old and new strategy should be of same type.

setup

function setup() external

OnlyGovernor:: Helper function for V5 upgrade

updateMaximumProfitAsFee

function updateMaximumProfitAsFee(uint256 _newMaxProfitAsFee) external

Only Governor:: Update maximum profit that can be used as universal fee

updateMinimumDepositLimit

function updateMinimumDepositLimit(uint256 _newLimit) external

Only Governor:: Update minimum deposit limit

updateUniversalFee

function updateUniversalFee(uint256 _newUniversalFee) external

Update universal fee for this pool

Format: 1500 = 15% fee, 100 = 1%

updatePoolRewards

function updatePoolRewards(address _newPoolRewards) external

Update pool rewards address for this pool

pause

function pause() external

unpause

function unpause() external

shutdown

function shutdown() external

open

function open() external

keepers

function keepers() external view returns (address[])

Return list of keepers

isKeeper

function isKeeper(address _address) external view returns (bool)

addKeeper

function addKeeper(address _keeperAddress) external

Add given address in keepers list.

removeKeeper

function removeKeeper(address _keeperAddress) external

Remove given address from keepers list.

maintainers

function maintainers() external view returns (address[])

Return list of maintainers

isMaintainer

function isMaintainer(address _address) external view returns (bool)

addMaintainer

function addMaintainer(address _maintainerAddress) external

Add given address in maintainers list.

removeMaintainer

function removeMaintainer(address _maintainerAddress) external