# Introduction 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:** Vesper offers a variety of interest-yielding "[Grow Pools](/vesper-pools-and-strategies/vesper-grow)" 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](/vesper-pools-and-strategies/vesper-grow) represent the first product on the Vesper platform. **Vesper Token:** VSP incentivizes participation, facilitates governance, and catalyzes user contribution. Users earn VSP through revenue share mechanisms by [locking](/community-participation/governance/locking) VSP for esVSP. **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](https://medium.com/vesperfinance/) is best for news and insights. [Twitter](https://twitter.com/vesperfi) serves as our primary notification channel. [Discord](https://discord.com/invite/Pm8UDaazsK) is where most interactions around governance, community, and development (by the team and community members) take place. # Vesper Features *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 can be 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. It is also currently deployed on multiple Layer 2's, such as Base and Optimism. ### 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](/community-participation/governance)) 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 Participants 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](/community-participation/governance/locking)) 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](/community-participation/governance-1). ### 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. # Vesper's Modular Pool Architecture Vesper's software architecture is based a modular, multi-pool design that enables smart contract administrators to adapt and transition strategies. This modularity not only makes it possible for running programs to switch approaches in real time in response to changing conditions in the DeFi marketplace, it also makes it possible for Vesper's team to continuously upgrade products without interruption. This modular philosophy is present in all aspects of Vesper software development. This "Lego-like" approach not only makes it possible to swap strategies and combine product components in innumerable ways, but it also separates smart-contract logic into those parts that are platform-dependent from those that are platform-agnostic. This means that 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. ![Modularity is key to the Vesper idea](/files/bWt2zmRNYJLP8KNAn7hN) ## 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 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. ### 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 queuing multiple strategies to the same pool. For example, if a pool held USDC assets valued at $40 million, it might allocate the first $10 million USDC from the USDC pool to Strategy A, the next 20 million USDC to Strategy B, and the remaining 10 million to Strategy C. The limits on strategies and order of the queue are dynamic and can be updated as needed. This is key to the pool architecture for two reasons. The first is better yield optimization. A pool can lend to any number of platforms at the same time, mitigating fluctuations in interest rates. When a new strategy appears, the pool can queue it to first priority with a small deposit limit, say $5 million USDC, so as to not smother the APY with an overpowering deposit. ![Weighted multipart strategy](/files/YVRbTy10BGtlbWqIZa3I) 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 as 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. # Multi-Chain and Cross-Chain Deployments ## 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](https://app.aave.com/markets) 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. # Overview of Vesper Pools {% hint style="info" %} **Important:** Although contracts are accessible to all, you should not send assets directly to any Vesper contract address. Instead, you should always use the [Vesper App.](broken://pages/EP3etUmoUDo3WVeockJk) This is because, as explained in [Vesper's Modular Architecture,](broken://pages/FqyayuQnKybh8NKStkJT) Vesper pools (and other contracts) are designed to be upgradeable at any time. Sending funds directly to a contract may result in a total loss of user funds. {% endhint %} 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 that fit their risk tolerance. ### **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. ![A typical view of the Vesper App](/files/MHZif0M5aeu52WC1bbVi) ### 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. ### 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. ### 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 were 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)** Vesper pool depositors accrue yield in the original asset they deposited. 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”. Note that the displayed APY is after the performance fee has been subtracted. ### Rebalancing Rebalancing is the process by which pool strategies are adjusted and yield is compounded back into the underlying asset. For lending and farming strategies, rebalancing typically means harvesting rewards, swapping them into the deposit asset, and redeploying them to generate additional yield. For borrow-based strategies, it ensures that collateral ratios remain within safe parameters by either reducing or increasing loan exposure as needed. Rebalancing is handled by designated keepers. It occurs on a scheduled basis, roughly every two days on Base and Optimism, and every ten days on Ethereum mainnet, or in response to market conditions when required, particularly in borrow strategies. # Vesper Grow Pools {% hint style="info" %} **Important:** Although contracts are accessible to all, you should not send assets directly to any Vesper contract address. Instead, you should always use the [Vesper App.](broken://pages/EP3etUmoUDo3WVeockJk) This is because, as explained in [Vesper's Modular Architecture,](broken://pages/FqyayuQnKybh8NKStkJT) Vesper pools (and other contracts) are designed to be upgradeable at any time. Sending funds directly to a contract may result in a total loss of user funds. {% endhint %} 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 underlying yield accrued by pool assets as they are routed to other DeFi per the pool strategy. 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. # Overview of Vesper Strategies 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, 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: #### \ Deposit This is the most basic strategy of simply depositing a particular protocol. #### \ LP Unlike a straight deposit, pool TVL is converted into the platform’s pertinent liquidity provision (LP) token. #### \ to \ After depositing to a platform, the output of that deposit is then deposited to another 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. #### \ 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 this may not represent the full picture in the future.
PlatformDepositLPPlatformLeverageBorrow
Compound V3truefalsefalsetruetrue
Aave V3truefalsefalsetruetrue
Curvefalsetruetruefalsefalse
Convex for Curvefalsefalsetruefalsefalse
Convex for Fraxfalsefalsetruefalsefalse
Yearntruefalsefalsefalsefalse
Stargatefalsetruefalsefalsefalse
Sommelier Financetruefalsefalsefalsetrue
Morphotruefalsefalsefalsetrue
FraxLendtruefalsefalsefalsetrue
Euler V2truefalsefalsefalsefalse
ExtraFinancetruefalsefalsefalsefalse
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 that use higher collateral ratios on loans to better protect against 'black swan' events that can jeopardize the loan. # Direct-to-Lending-Platform Some assets will earn higher APY if deposited straight to a lending platforms (such as Aave or Compound). 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.\
# Discussion of Risk **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. # VSP Token: Supply, Issuance, & Rewards 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](https://app.vesper.finance/eth/locked-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 (Revenue Share) By locking your VSP, you'll receive esVSP (ERC-721). After withdrawal and yield fees are collected in the pool (ETH, BTC, USDC, etc.), they go to the treasury, and a portion of this revenue is used for VSP buybacks on the open market. These bought-back VSP tokens are delivered to esVSP participants and can be claimed in the [dashboard](https://app.vesper.finance/eth/locked-vsp). Following a period in which buybacks were paused in favor of treasury emissions, governance has [approved](https://snapshot.box/#/s:vsp.eth/proposal/0xa973f424dcf050ee8d4c2e36d7e094c43d10068c85348944363ee1d43af6f070) a restart of the buyback program. This includes: * A target of $3,000/month in VSP buybacks, distributed to esVSP holders. * A plan to gradually increase buybacks toward the previous policy level of up to 40% of total revenue. ***Note:** Actual month-over-month buyback amounts may vary at the discretion of Operations in alignment with the* [*strategic liquidity initiatives*](https://snapshot.box/#/s:vsp.eth/proposal/0xf66d151e28f48d7539f34dd139d25762c3165baac1a18fe7a8b21ac1584824ce)*.* * Begin reducing monthly VSP emissions from 20,000/mo, with an end target of 0/mo. To view the current and historical VSP distribution to esVSP holders, please visit Vesper on [DeFiLlama](https://defillama.com/protocol/fees/vesper) for all the details. *** ## Vesper Launch Details ## Supply Dynamics Vesper launched with a total supply of **10,000,000 VSP**: * **6.5M VSP (65%) went to the community**, which included 2.55M for the Incentivized Launch Pools, 1M to incentivized liquidity providers, and 2.95M to the Vesper Reserves. * 3.5M VSP (35%) was for the Vesper team, advisors, and strategic partners, which was subject to vesting over twelve months. ![](/files/-MTgXbTxg-KW_aKTm75W) ## Token Emissions * **Launch Pools (2,550,000 VSP)** * 450,000 was allocated to pre-launch Beta participants, and airdropped at launch * 2,100,000 was distributed over twelve months, heavily weighted toward the first three months * **Reserves (2,950,000 VSP)** * Allocated for ecosystem growth and developer/community incentives, as determined by VSP voters * A small portion of reserves was later leveraged to further boost rewards on Grow Pools * **Liquidity Providers (1,000,000 VSP)** * This was used as incentives for LPs on Uniswap, SushiSwap, 1inch, and Loopring (with SushiSwap receiving the majority) * Distributed over twelve months, heavily weighted toward the first month (and especially the first weeks) * **Team and Advisors (2,500,000 VSP)** * 208,333 (1/12) was unlocked at launch * 2,291,667 (11/12) was vested with a streaming unlock (constant drip each block) over the following eleven months * **Strategic Partners (1,000,000 VSP)** * 83,333 (1/12) was unlocked at launch * 916,667 (11/12) was vested with a streaming unlock over the following eleven months Team, Advisor, and Partner tokens were held in a Sablier contract. Recipients could interface with the contract to claim VSP as frequently or as seldom as they preferred. They received 1/n of their total VSP allocation across the n blocks of their vesting period. Vesper officially launched on **February 17, 2021**. *** ### **UPDATED 8/18/2024 (**[VSP Buybacks + Emissions Update](https://snapshot.box/#/s:vsp.eth/proposal/0xa973f424dcf050ee8d4c2e36d7e094c43d10068c85348944363ee1d43af6f070)**)** From 8/15/24 - 8/18/24, VSP/esVSP holders voted to restart VSP buybacks for esVSP lockers and set intentions for future buybacks and emissions policy. This proposal: * Reintroduces the buyback mechanism as a **supplement** to VSP emissions with a fixed **$3,000 USD per month** buyback target, delivered to esVSP holders. * Seeks to **gradually increase** buybacks beyond $3,000/month to a maximum of **40% of total revenue**. * Begins reducing monthly VSP emissions from **20,000 VSP/month**, with the end target of **0 VSP/month**. # Revenue Model ## Universal Fee Vesper uses a simple, transparent fee structure designed to ensure you never earn negative returns on your deposits. *\*APY shown on the Vesper app is calculated after all fees have been applied.* #### How It Works Vesper charges a **2% annual fee** on your deposited principal, collected from your earned yield at each rebalance. However, this fee is capped. If 2% of your principal exceeds half of what you've earned, only 50% of your yield is taken instead. #### Why This Model? The universal fee eliminates that possibility while remaining straightforward to understand. * **No withdrawal fees** means you can withdraw anytime without penalty. * **No deposit fees** enable your full deposit to go to work immediately. * **Fees come only from yield,** so your principal is never touched. #### Fee Calculation At each rebalance, the fee is calculated as: ``` Fee = 2% * (blocks since last rebalance / blocks per year) * TVL ``` If this amount exceeds 50% of the yield earned, the fee is reduced to 50% of the yield instead. ## 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. # Governance 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.* # Introduction ## 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 # Locking 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 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 # Unlocking 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** 1. Visit and connect your wallet 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 # Decentralization Plan {% hint style="info" %} *At launch, Vesper network governance relies on a strong social contract between the founding team and stakeholders. Over time, the Vesper platform will mature to become entirely community-driven. This means that Vesper stakeholders will eventually be in total control of the future of the product ecosystem. From Day 1, the long-term objective is to develop a robust decentralized community of which the founding Vesper team only accounts for a small minority of the decision-making authority.* *Across all phases of decentralization, we have a firm commitment to engaging with VSP holders and community members on all major changes and updates.* {% endhint %} ## 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:** | **Action** | **Threshold** | | ------------------------ | -------------------------------------------------------------------------------------- | | Bring a proposal to vote | Submitters must have the delegation of at least 1% of the outstanding vVSP supply. | | Voting - Reach Quorum | 4% of the outstanding vVSP supply must vote ‘Yes’ on the proposal. | | Voting - Vote Passes | A minimum of 50%+1 of votes cast with a minimum of 4% of vVSP supply as ‘YES’ votes . | ## **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](/community-participation/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](https://gnosis-safe.io/app/#/safes/0x44f978c4a5f58DeC14c9CbB7B67123aDCf6f69A3/balances) and [Community Marketing](https://gnosis-safe.io/app/#/safes/0xDDa9AB13Ef3eB0521Ad18f91c1d101646346D37E/balances). 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. # The Voting Process ### 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. There are two types of votes: on-chain and signal. VIPs can be introduced as a signal or on-chain vote. Initially, most voting will comprise of signal voting through [Snapshot](https://snapshot.org/#/vsp.eth). Over time, more and more votes will be executed on-chain with executable code, ultimately relinquishing all administrative responsibilities and controls directly to the esVSP holders. ### 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. Voting weight on Snapshot is determined by a user's esVSP balance. esVSP represents a user's locked VSP tokens plus a boost multiplier based on their lock duration. The longer a user locks their VSP (up to 2 years maximum), the higher their voting power will be, with a maximum multiplier of 4x. [More here](/community-participation/governance/locking). 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) Proposals begin by being published on the [Vesper forums](https://gov.vesper.finance/) to encourage community discussion and feedback, enable a deeper understanding of the proposal, and prepare users for the upcoming voting period. A proposer must hold at least 25,000 esVSP to create a proposal on-chain, and any proposals that go directly on-chain without having been posted on Vesper forums for at least 7 days before voting begins will be vetoed. ### 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. The *`propose`* function in the [VesperGovernor contract](https://etherscan.io/address/0xF14441a8c1859aDdF0675312F8799eEF092C0e38) can be called by a proposer who has at least 25,000 esVSP tokens (as defined by *`proposalThreshold()`*). For more details or to interact with the governance contract, visit the Vesper DAO governance page on [tally.xyz](https://www.tally.xyz/gov/vesper-dao). Once a proposal is created, it will transition to a **PENDING** state until the voting begins. ### 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**.
# Governance Principles 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. # Vesper Developer's Guide Preliminary draft. Update coming soon. ## # Introduction 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,](/vesper-developers/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](/vesper-pools-and-strategies/vespers-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](https://www.openzeppelin.com/) 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. {% hint style="info" %} Note that although OpenZeppelin offers contracts to implement proxies, Vesper uses its own implementation of this concept not OpenZeppelin's. {% endhint %} 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.

Proxied pools separate a pool's state from its logic

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.

The Address of the pool is the address of the storage layer contract

# Vesper Framework Levels Preliminary draft 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. | Version | Main features | | :-----: | :-------------------------------------------------------------: | | V1 | Each pool associated with 1 strategy | | V2 | Pools can have multiple strategies | | V3 | Withdrawal function is separated from claiming rewards function | | V4 | Includes gas savings on user interactions | | V5 | Fee structure changed to universal platform fee | 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. ![Vesper pool and strategy interactions](/files/zX0n8MpJbzmO0YLF7eAm) ## 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. # Overview of Flow Control ### 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. ![Vesper pool and strategy interactions](/files/zX0n8MpJbzmO0YLF7eAm) 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. # Vesper Pool Metadata Every pool has metadata associated with it that is stored in [JSON format in the Vesper repository. ](https://github.com/vesperfi/metadata/blob/master/src/vesper-metadata.json)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" }, ``` # Pool and Strategy Creation and Deployment 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. ```` // Some code Deployment will be done via custom `hardhat task deploy-pool` which behind the scene uses deploy scripts created using `hardhat-deploy` ### Usage * Help ```bash npx hardhat help deploy-pool ``` * Deploy Vesper pool 1. Add pool configuration in `./helper/mainnet/poolConfig.js` file. - Some default config for setup and rewards are already defined at top of file, override them as needed. - Replace mainnet in `./helper/mainnet/poolConfig.js` with arbitrum/avalanche/polygon as needed. Example configuration for `VDAI` ```js VDAI: { contractName: 'VPool', poolParams: ['vDAI Pool', 'vDAI', Address.DAI], setup: { ...setup }, rewards: { ...rewards }, }, ``` ```` # Vesper Contracts API Reference Types of contracts documented here Abstract classes or models used for creating instances. Types of contracts not documented here Link to Developer's Guide # Pool Contracts 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. # PoolAccountant ## PoolAccountant This contract is the "accountant" for Vesper pools which keeps records of strategies. Each deployed pool has one associated accountant. ### VERSION ```solidity string VERSION ``` ### MAX\_BPS ```solidity uint256 MAX_BPS ``` ### EarningReported ```solidity event EarningReported(address strategy, uint256 profit, uint256 loss, uint256 payback, uint256 strategyDebt, uint256 poolDebt, uint256 creditLine) ``` ### LossReported ```solidity event LossReported(address strategy, uint256 loss) ``` ### StrategyAdded ```solidity event StrategyAdded(address strategy, uint256 debtRatio, uint256 externalDepositFee) ``` ### StrategyRemoved ```solidity event StrategyRemoved(address strategy) ``` ### StrategyMigrated ```solidity event StrategyMigrated(address oldStrategy, address newStrategy) ``` ### UpdatedExternalDepositFee ```solidity event UpdatedExternalDepositFee(address strategy, uint256 oldFee, uint256 newFee) ``` ### UpdatedPoolExternalDepositFee ```solidity event UpdatedPoolExternalDepositFee(uint256 oldFee, uint256 newFee) ``` ### UpdatedStrategyDebtRatio ```solidity event UpdatedStrategyDebtRatio(address strategy, uint256 oldDebtRatio, uint256 newDebtRatio) ``` ### init ```solidity function init(address _pool) public ``` *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.* | Name | Type | Description | | ------ | ------- | ---------------------------- | | \_pool | address | Address of Vesper pool proxy | ### addStrategy ```solidity function addStrategy(address _strategy, uint256 _debtRatio, uint256 _externalDepositFee) public ``` 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.* | Name | Type | Description | | -------------------- | ------- | ------------------------------------- | | \_strategy | address | Strategy address | | \_debtRatio | uint256 | Pool fund allocation to this strategy | | \_externalDepositFee | uint256 | External deposit fee of strategy | ### setup ```solidity function setup() external ``` OnlyPool:: Helper function for V5 upgrade ### removeStrategy ```solidity function removeStrategy(uint256 _index) external ``` 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 ```solidity function updateExternalDepositFee(address _strategy, uint256 _externalDepositFee) external ``` Update external deposit fee of the strategy and recalculate the pool level external deposit fee. | Name | Type | Description | | -------------------- | ------- | ---------------------------------------------------------------- | | \_strategy | address | Strategy address for which external deposit fee is being updated | | \_externalDepositFee | uint256 | New external deposit fee | ### recalculatePoolExternalDepositFee ```solidity function recalculatePoolExternalDepositFee() external ``` 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 ```solidity function sweepERC20(address _fromToken) external virtual ``` *Transfer given ERC20 token to pool* | Name | Type | Description | | ----------- | ------- | ---------------------- | | \_fromToken | address | Token address to sweep | ### updateDebtRatio ```solidity function updateDebtRatio(address _strategy, uint256 _debtRatio) external ``` 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.* | Name | Type | Description | | ----------- | ------- | ------------------------------------------------------ | | \_strategy | address | Strategy address for which debt ratio is being updated | | \_debtRatio | uint256 | New debt ratio | ### updateWithdrawQueue ```solidity function updateWithdrawQueue(address[] _withdrawQueue) external ``` 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.* | Name | Type | Description | | --------------- | ---------- | ------------------------- | | \_withdrawQueue | address\[] | Ordered list of strategy. | ### migrateStrategy ```solidity function migrateStrategy(address _old, address _new) external ``` 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.* | Name | Type | Description | | ----- | ------- | ---------------------------------- | | \_old | address | Address of strategy being migrated | | \_new | address | Address of new strategy | ### reportEarning ```solidity function reportEarning(address _strategy, uint256 _profit, uint256 _loss, uint256 _payback) external returns (uint256 _actualPayback, uint256 _creditLine) ``` *Strategy calls this at regular intervals.* | Name | Type | Description | | ---------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | \_strategy | address | | | \_profit | uint256 | yield generated by strategy. Strategy get performance fee on this amount | | \_loss | uint256 | Reduce debt ,also reduce debtRatio, increase loss in record. | | \_payback | uint256 | strategy willing to payback outstanding above debtLimit. no performance fee on this amount. when governance has reduced debtRatio of strategy, strategy will report profit and payback amount separately. | ### reportLoss ```solidity function reportLoss(address _strategy, uint256 _loss) external ``` Update strategy loss. | Name | Type | Description | | ---------- | ------- | ------------------------- | | \_strategy | address | Strategy which incur loss | | \_loss | uint256 | Loss of strategy | ### decreaseDebt ```solidity function decreaseDebt(address _strategy, uint256 _decreaseBy) external ``` Decrease debt of strategy; this also decreases totalDebt. *In case of withdraw from strategy, pool will decrease debt by the amount withdrawn* | Name | Type | Description | | ------------ | ------- | ----------------------------------------------- | | \_strategy | address | Strategy Address | | \_decreaseBy | uint256 | Amount by which strategy debt will be decreased | ### availableCreditLimit ```solidity function availableCreditLimit(address _strategy) external view returns (uint256) ``` 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* | Name | Type | Description | | ---------- | ------- | ---------------- | | \_strategy | address | Strategy address | ### excessDebt ```solidity function excessDebt(address _strategy) external view returns (uint256) ``` Debt above current debt limit | Name | Type | Description | | ---------- | ------- | ------------------- | | \_strategy | address | Address of strategy | ### getStrategies ```solidity function getStrategies() external view returns (address[]) ``` Return the strategies array. ### getWithdrawQueue ```solidity function getWithdrawQueue() external view returns (address[]) ``` Return withdrawQueue array. ### totalDebtOf ```solidity function totalDebtOf(address _strategy) external view returns (uint256) ``` Get total debt of given strategy. | Name | Type | Description | | ---------- | ------- | ---------------- | | \_strategy | address | Strategy address | # PoolAccountantStorage 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 ```solidity address pool ``` ### totalDebtRatio ```solidity uint256 totalDebtRatio ``` ### totalDebt ```solidity uint256 totalDebt ``` ### strategies ```solidity address[] strategies ``` ### withdrawQueue ```solidity address[] withdrawQueue ``` ## PoolAccountantStorageV2 ### StrategyConfig ```solidity struct StrategyConfig { bool active; uint256 interestFee; uint256 debtRate; uint256 lastRebalance; uint256 totalDebt; uint256 totalLoss; uint256 totalProfit; uint256 debtRatio; uint256 externalDepositFee; } ``` ### strategy ```solidity mapping(address => struct PoolAccountantStorageV2.StrategyConfig) strategy ``` ### externalDepositFee ```solidity uint256 externalDepositFee ``` # PoolRewards ## PoolRewards Distributes VSP rewards based on the user's Vesper pool balance and the supply of rewards available to that pool. ### VERSION ```solidity string VERSION ``` ### initialize ```solidity function initialize(address _pool, address[] _rewardTokens) public ``` *Called by proxy to initialize this contract.* | Name | Type | Description | | -------------- | ---------- | ------------------------------- | | \_pool | address | Vesper pool address | | \_rewardTokens | address\[] | Array of reward token addresses | ### notifyRewardAmount ```solidity function notifyRewardAmount(address[] _rewardTokens, uint256[] _rewardAmounts, uint256[] _rewardDurations) external virtual ``` Notify that reward is added. Only authorized caller can call this function. *Also updates reward rate and reward earning period.* | Name | Type | Description | | ----------------- | ---------- | ------------------------------------------------------------ | | \_rewardTokens | address\[] | Tokens being rewarded | | \_rewardAmounts | uint256\[] | Rewards amount for token on same index in rewardTokens array | | \_rewardDurations | uint256\[] | Duration for which reward will be distributed | ### notifyRewardAmount ```solidity function notifyRewardAmount(address _rewardToken, uint256 _rewardAmount, uint256 _rewardDuration) external virtual ``` ### addRewardToken ```solidity function addRewardToken(address _newRewardToken) external ``` Add new reward token in existing rewardsToken array ### claimReward ```solidity function claimReward(address _account) external virtual ``` Claim earned rewards. *This function claims rewards for all tokens being rewarded* ### updateReward ```solidity function updateReward(address _account) external ``` Updated reward for given account. ### claimable ```solidity function claimable(address _account) external view virtual returns (address[] _rewardTokens, uint256[] _claimableAmounts) ``` Returns claimable reward amount. | Name | Type | Description | | ------------------ | ---------- | ---------------------------------------------------------- | | \_rewardTokens | address\[] | Array of tokens being rewarded | | \_claimableAmounts | uint256\[] | Array of claimable for token on same index in rewardTokens | ### getRewardTokens ```solidity function getRewardTokens() external view returns (address[]) ``` Provides easy access to all rewardTokens ### lastTimeRewardApplicable ```solidity function lastTimeRewardApplicable(address _rewardToken) public view returns (uint256) ``` Returns timestamp of last reward update ### rewardForDuration ```solidity function rewardForDuration() external view returns (address[] _rewardTokens, uint256[] _rewardForDuration) ``` #### rewardPerToken ```solidity function rewardPerToken() external view returns (address[] _rewardTokens, uint256[] _rewardPerTokenRate) ``` Rewards rate per pool token | Name | Type | Description | | -------------------- | ---------- | ------------------------------------------------------------- | | \_rewardTokens | address\[] | Array of tokens being rewarded | | \_rewardPerTokenRate | uint256\[] | Array of Rewards rate for token on same index in rewardTokens | # PoolRewardsStorage ## PoolRewardsStorage This contract keeps track of addresses used by the PoolRewards contract to compute and distribute vVSP "rewards". ### pool ```solidity address pool ``` Vesper pool address ### rewardTokens ```solidity address[] rewardTokens ``` Array of reward token addresses ### isRewardToken ```solidity mapping(address => bool) isRewardToken ``` Reward token to valid/invalid flag mapping ### periodFinish ```solidity mapping(address => uint256) periodFinish ``` Reward token to period ending of current reward ### rewardRates ```solidity mapping(address => uint256) rewardRates ``` Reward token to current reward rate mapping ### rewardDuration ```solidity mapping(address => uint256) rewardDuration ``` Reward token to Duration of current reward distribution ### lastUpdateTime ```solidity mapping(address => uint256) lastUpdateTime ``` Reward token to Last reward drip update time stamp mapping ### rewardPerTokenStored ```solidity mapping(address => uint256) rewardPerTokenStored ``` Reward token to Reward per token mapping. Calculated and stored at last drip update ### userRewardPerTokenPaid ```solidity mapping(address => mapping(address => uint256)) userRewardPerTokenPaid ``` Reward token => User => Reward per token stored at last reward update ### rewards ```solidity mapping(address => mapping(address => uint256)) rewards ``` RewardToken => User => Rewards earned till last reward update ##
NameTypeDescription
_rewardTokensaddress[]Array of tokens being rewarded
_rewardPerTokenRateuint256[]Array of Rewards rate for token on same index in rewardTokens
# PoolStorage 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 ```solidity contract IERC20 token ``` Collateral token address ### poolAccountant ```solidity address poolAccountant ``` PoolAccountant address ### poolRewards ```solidity address poolRewards ``` PoolRewards contract address ## PoolStorageV2 ## PoolStorageV3 ### universalFee ```solidity uint256 universalFee ``` Universal fee of this pool. Default to 2% ### maxProfitAsFee ```solidity uint256 maxProfitAsFee ``` Maximum percentage of profit that can be counted as universal fee. Default to 50% ### minDepositLimit ```solidity uint256 minDepositLimit ``` Minimum deposit limit. *Do not set it to 0 as deposit() is checking if amount >= limit* # VETH ## VETH This contract handles ETH incoming to the contract address. It inherits from VPOOL. ### constructor ```solidity constructor(string _name, string _symbol, address _token) public ``` ### receive ```solidity receive() external payable ``` *Handle incoming ETH to the contract address.* ### withdrawETH ```solidity function withdrawETH(uint256 _shares) external ``` *Burns tokens/shares and returns the ETH value, after fee, of those.* ### withdrawETHAndClaim ```solidity function withdrawETHAndClaim(uint256 _shares) external ``` *Burns tokens/shares and returns the ETH value and claim rewards if any* ### deposit ```solidity function deposit() public payable ``` *Receives ETH and grants new tokens/shares to the sender depending on the value of pool's share.* ### depositAndClaim ```solidity function depositAndClaim() external payable ``` *Deposit ETH and claim rewards if any* # VPOOL ## VPool All Vesper pools are implementations of VPOOL. This contract performs the core functions for all Vesper pools, including deposits, withdrawals, fee calculation ### VERSION ```solidity string VERSION ``` ### MAX\_BPS ```solidity uint256 MAX_BPS ``` ### ONE\_YEAR ```solidity uint256 ONE_YEAR ``` ### UpdatedMaximumProfitAsFee ```solidity event UpdatedMaximumProfitAsFee(uint256 oldMaxProfitAsFee, uint256 newMaxProfitAsFee) ``` ### UpdatedMinimumDepositLimit ```solidity event UpdatedMinimumDepositLimit(uint256 oldDepositLimit, uint256 newDepositLimit) ``` ### Deposit ```solidity event Deposit(address owner, uint256 shares, uint256 amount) ``` ### Withdraw ```solidity event Withdraw(address owner, uint256 shares, uint256 amount) ``` ### UpdatedUniversalFee ```solidity event UpdatedUniversalFee(uint256 oldUniversalFee, uint256 newUniversalFee) ``` ### UpdatedPoolRewards ```solidity event UpdatedPoolRewards(address previousPoolRewards, address newPoolRewards) ``` ### UpdatedWithdrawFee ```solidity event UpdatedWithdrawFee(uint256 previousWithdrawFee, uint256 newWithdrawFee) ``` ### UniversalFeePaid ```solidity event UniversalFeePaid(uint256 strategyDebt, uint256 profit, uint256 fee) ``` ### constructor ```solidity constructor(string _name, string _symbol, address _token) public ``` ### initialize ```solidity 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 ```solidity function deposit(uint256 _amount) external ``` Deposit ERC20 tokens and receive pool shares depending on the current share price. | Name | Type | Description | | -------- | ------- | ------------------- | | \_amount | uint256 | ERC20 token amount. | ### depositAndClaim ```solidity function depositAndClaim(uint256 _amount) external ``` Deposit ERC20 tokens and claim rewards, if there are any. | Name | Type | Description | | -------- | ------- | ------------------- | | \_amount | uint256 | ERC20 token amount. | ### depositWithPermit ```solidity function depositWithPermit(uint256 _amount, uint256 _deadline, uint8 _v, bytes32 _r, bytes32 _s) external ``` Deposit ERC20 tokens with permit, aka gasless approval. | Name | Type | Description | | ---------- | ------- | --------------------------------------- | | \_amount | uint256 | ERC20 token amount. | | \_deadline | uint256 | The time at which signature will expire | | \_v | uint8 | The recovery byte of the signature | | \_r | bytes32 | Half of the ECDSA signature pair | | \_s | bytes32 | Half of the ECDSA signature pair | ### whitelistedWithdraw ```solidity 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.* | Name | Type | Description | | -------- | ------- | --------------------------------------- | | \_shares | uint256 | Pool shares. It will be in 18 decimals. | ### withdraw ```solidity function withdraw(uint256 _shares) external ``` Withdraw collateral based on given shares and the current share price. Burn remaining shares and return collateral. | Name | Type | Description | | -------- | ------- | --------------------------------------- | | \_shares | uint256 | Pool shares. It will be in 18 decimals. | ### withdrawAndClaim ```solidity function withdrawAndClaim(uint256 _shares) external ``` Withdraw collateral and claim rewards, if any. | Name | Type | Description | | -------- | ------- | --------------------------------------- | | \_shares | uint256 | Pool shares. It will be in 18 decimals. | ### multiTransfer ```solidity 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.* | Name | Type | Description | | ------------ | ---------- | ---------------------------- | | \_recipients | address\[] | array of recipient addresses | | \_amounts | uint256\[] | array of token amounts | | Name | Type | Description | | ---- | ---- | ----------- | | \[0] | bool | true/false | ### reportEarning ```solidity function reportEarning(uint256 _profit, uint256 _loss, uint256 _payback) external ``` Strategy call this in regular interval. Only strategy function. | Name | Type | Description | | --------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | \_profit | uint256 | yield generated by strategy. Strategy get performance fee on this amount | | \_loss | uint256 | Reduce debt ,also reduce debtRatio, increase loss in record. | | \_payback | uint256 | strategy willing to payback outstanding above debtLimit. no performance fee on this amount. when governance has reduced debtRatio of strategy, strategy will report profit and payback amount separately. | ### reportLoss ```solidity 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.* | Name | Type | Description | | ------ | ------- | --------------------------------- | | \_loss | uint256 | Loss that strategy want to report | ### sweepERC20 ```solidity function sweepERC20(address _fromToken) external ``` *Transfer given ERC20 token to governor* | Name | Type | Description | | ----------- | ------- | ---------------------- | | \_fromToken | address | Token address to sweep | ### availableCreditLimit ```solidity 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* | Name | Type | Description | | ---------- | ------- | ---------------- | | \_strategy | address | Strategy address | ### calculateUniversalFee ```solidity 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 ```solidity function excessDebt(address _strategy) external view returns (uint256) ``` Debt above current debt limit | Name | Type | Description | | ---------- | ------- | ------------------- | | \_strategy | address | Address of strategy | ### getStrategies ```solidity function getStrategies() external view returns (address[]) ``` ### totalDebt ```solidity function totalDebt() external view returns (uint256) ``` Get total debt of pool ### totalDebtOf ```solidity function totalDebtOf(address _strategy) external view returns (uint256) ``` Get total debt of given strategy | Name | Type | Description | | ---------- | ------- | ---------------- | | \_strategy | address | Strategy address | ### totalDebtRatio ```solidity function totalDebtRatio() external view returns (uint256) ``` Get total debt ratio. Total debt ratio helps us keep buffer in pool ### calculateMintage ```solidity 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* | Name | Type | Description | | -------- | ------- | ----------------- | | \_amount | uint256 | Collateral amount | | Name | Type | Description | | -------- | ------- | ---------------------------------- | | \_shares | uint256 | Amount of share that user will get | ### getWithdrawQueue ```solidity function getWithdrawQueue() public view returns (address[]) ``` ### pricePerShare ```solidity function pricePerShare() public view returns (uint256) ``` Get price per share *Return value will be in token defined decimals.* ### strategy ```solidity 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 ```solidity function tokensHere() public view returns (uint256) ``` *Returns the token stored in the pool. It will be in token defined decimals.* ### totalValue ```solidity 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 ```solidity function _beforeBurning(uint256 _share) private returns (uint256 _actualWithdrawn, bool _isPartial) ``` *Before burning hook. withdraw amount from strategies* ### \_calculateShares ```solidity function _calculateShares(uint256 _amount) private view returns (uint256) ``` *Calculate shares to mint/burn based on the current share price and given amount.* | Name | Type | Description | | -------- | ------- | ------------------------------------------------------- | | \_amount | uint256 | Collateral amount in collateral token defined decimals. | | Name | Type | Description | | ---- | ------- | -------------------------- | | \[0] | uint256 | share amount in 18 decimal | ### \_calculateUniversalFee ```solidity 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 ```solidity function _calculateUniversalFee(uint256 _lastRebalance, uint256 _totalDebt, uint256 _profit) private view returns (uint256 _fee) ``` ### migrateStrategy ```solidity 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.* | Name | Type | Description | | ----- | ------- | ---------------------------------- | | \_old | address | Address of strategy being migrated | | \_new | address | Address of new strategy | ### setup ```solidity function setup() external ``` OnlyGovernor:: Helper function for V5 upgrade ### updateMaximumProfitAsFee ```solidity function updateMaximumProfitAsFee(uint256 _newMaxProfitAsFee) external ``` Only Governor:: Update maximum profit that can be used as universal fee | Name | Type | Description | | ------------------- | ------- | --------------------- | | \_newMaxProfitAsFee | uint256 | New max profit as fee | ### updateMinimumDepositLimit ```solidity function updateMinimumDepositLimit(uint256 _newLimit) external ``` Only Governor:: Update minimum deposit limit | Name | Type | Description | | ---------- | ------- | ------------------------- | | \_newLimit | uint256 | New minimum deposit limit | ### updateUniversalFee ```solidity function updateUniversalFee(uint256 _newUniversalFee) external ``` Update universal fee for this pool *Format: 1500 = 15% fee, 100 = 1%* | Name | Type | Description | | ----------------- | ------- | ----------------- | | \_newUniversalFee | uint256 | new universal fee | ### updatePoolRewards ```solidity function updatePoolRewards(address _newPoolRewards) external ``` Update pool rewards address for this pool | Name | Type | Description | | ---------------- | ------- | ------------------------ | | \_newPoolRewards | address | new pool rewards address | ### pause ```solidity function pause() external ``` ### unpause ```solidity function unpause() external ``` ### shutdown ```solidity function shutdown() external ``` ### open ```solidity function open() external ``` ### keepers ```solidity function keepers() external view returns (address[]) ``` Return list of keepers ### isKeeper ```solidity function isKeeper(address _address) external view returns (bool) ``` ### addKeeper ```solidity function addKeeper(address _keeperAddress) external ``` Add given address in keepers list. | Name | Type | Description | | --------------- | ------- | ---------------------- | | \_keeperAddress | address | keeper address to add. | ### removeKeeper ```solidity function removeKeeper(address _keeperAddress) external ``` Remove given address from keepers list. | Name | Type | Description | | --------------- | ------- | ------------------------- | | \_keeperAddress | address | keeper address to remove. | ### maintainers ```solidity function maintainers() external view returns (address[]) ``` Return list of maintainers ### isMaintainer ```solidity function isMaintainer(address _address) external view returns (bool) ``` ### addMaintainer ```solidity function addMaintainer(address _maintainerAddress) external ``` Add given address in maintainers list. | Name | Type | Description | | ------------------- | ------- | -------------------------- | | \_maintainerAddress | address | maintainer address to add. | ### removeMaintainer ```solidity function removeMaintainer(address _maintainerAddress) external ``` Remove given address from maintainers list. | Name | Type | Description | | ------------------- | ------- | ----------------------------- | | \_maintainerAddress | address | maintainer address to remove. | # VesperEarnDrip ## IVesperPoolV2 An interface. ### getPricePerShare ```solidity 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 ```solidity event DripRewardPaid(address user, address rewardToken, uint256 reward) ``` ### GrowTokenUpdated ```solidity event GrowTokenUpdated(address oldGrowToken, address newGrowToken) ``` ### growToken ```solidity address growToken ``` ### receive ```solidity receive() external payable ``` ### claimable ```solidity 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* | Name | Type | Description | | ------------------ | ---------- | ---------------------------------------------------------- | | \_rewardTokens | address\[] | Array of tokens being rewarded | | \_claimableAmounts | uint256\[] | Array of claimable for token on same index in rewardTokens | ### notifyRewardAmount ```solidity function notifyRewardAmount(address _rewardToken, uint256 _rewardAmount, uint256 _rewardDuration) external ``` *Notify that reward is added. Also updates reward rate and reward earning period.* ### updateGrowToken ```solidity 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 ```solidity 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.* # Strategy Contracts # Earn ## Earn An abstract contract that inherits from Strategy. All Vesper Earn pools are implementations of the Earn contract. ### dripToken ```solidity address dripToken ``` ### dripPeriod ```solidity uint256 dripPeriod ``` ### totalEarned Accounting total stable coin earned after fee. This amount is not reported to the pool. ```solidity uint256 totalEarned ``` ### DripPeriodUpdated ```solidity event DripPeriodUpdated(uint256 oldDripPeriod, uint256 newDripPeriod) ``` ### updateDripPeriod ```solidity function updateDripPeriod(uint256 _dripPeriod) external ``` Update update period of distribution of earning done in one rebalance \_*dripPeriod in seconds* ### approveGrowToken ```solidity function approveGrowToken() external ``` *Approves EarnDrip' Grow token to spend dripToken* # Strategy ## Strategy This is an abstract contract that implements key functionality for all strategies. For example, the AaveLeverageStrategy contract inherits from Strategy and AaveCore. ### collateralToken ```solidity contract IERC20 collateralToken ``` ### receiptToken ```solidity address receiptToken ``` ### pool ```solidity address pool ``` ### feeCollector ```solidity address feeCollector ``` ### swapManager ```solidity contract ISwapManager swapManager ``` ### oraclePeriod ```solidity uint256 oraclePeriod ``` ### oracleRouterIdx ```solidity uint256 oracleRouterIdx ``` ### swapSlippage ```solidity uint256 swapSlippage ``` ### \_keepers ```solidity struct EnumerableSet.AddressSet _keepers ``` ### UpdatedFeeCollector ```solidity event UpdatedFeeCollector(address previousFeeCollector, address newFeeCollector) ``` ### UpdatedSwapManager ```solidity event UpdatedSwapManager(address previousSwapManager, address newSwapManager) ``` ### UpdatedSwapSlippage ```solidity event UpdatedSwapSlippage(uint256 oldSwapSlippage, uint256 newSwapSlippage) ``` ### UpdatedOracleConfig ```solidity event UpdatedOracleConfig(uint256 oldPeriod, uint256 newPeriod, uint256 oldRouterIdx, uint256 newRouterIdx) ``` ### addKeeper ```solidity function addKeeper(address _keeperAddress) external ``` Add given address in keepers list. | Name | Type | Description | | --------------- | ------- | ---------------------- | | \_keeperAddress | address | keeper address to add. | ### keepers ```solidity function keepers() external view returns (address[]) ``` Return list of keepers ### migrate ```solidity 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.* | Name | Type | Description | | ------------- | ------- | ----------------------- | | \_newStrategy | address | Address of new strategy | ### removeKeeper ```solidity function removeKeeper(address _keeperAddress) external ``` Remove given address from keepers list. | Name | Type | Description | | --------------- | ------- | ------------------------- | | \_keeperAddress | address | keeper address to remove. | ### updateFeeCollector ```solidity function updateFeeCollector(address _feeCollector) external ``` Update fee collector | Name | Type | Description | | -------------- | ------- | --------------------- | | \_feeCollector | address | fee collector address | ### updateSwapManager ```solidity function updateSwapManager(address _swapManager) external ``` Update swap manager address | Name | Type | Description | | ------------- | ------- | -------------------- | | \_swapManager | address | swap manager address | ### updateSwapSlippage ```solidity function updateSwapSlippage(uint256 _newSwapSlippage) external ``` ### updateOracleConfig ```solidity function updateOracleConfig(uint256 _newPeriod, uint256 _newRouterIdx) external ``` ### approveToken ```solidity function approveToken() external ``` *Approve all required tokens* ### setupOracles ```solidity function setupOracles() external ``` ### withdraw ```solidity function withdraw(uint256 _amount) external ``` *Withdraw collateral token from lending pool.* | Name | Type | Description | | -------- | ------- | -------------------------- | | \_amount | uint256 | Amount of collateral token | ### rebalance ```solidity function rebalance() external virtual ``` *Rebalance profit, loss and investment of this strategy* ### sweepERC20 ```solidity function sweepERC20(address _fromToken) external ``` *sweep given token to feeCollector of strategy* | Name | Type | Description | | ----------- | ------- | ---------------------- | | \_fromToken | address | token address to sweep | ### token ```solidity function token() external view returns (address) ``` Returns address of token correspond to collateral token ### totalValue ```solidity function totalValue() public view virtual returns (uint256 _value) ``` Calculate total value of asset under management *Report total value in collateral token* ### totalValueCurrent ```solidity function totalValueCurrent() external virtual returns (uint256) ``` Calculate total value of asset under management (in real-time) *Report total value in collateral token* ### isReservedToken ```solidity function isReservedToken(address _token) public view virtual returns (bool) ``` Check whether given token is reserved or not. Reserved tokens are not allowed to sweep. # VesperStrategy ## VesperStrategy ### NAME ```solidity string NAME ``` ### VERSION ```solidity string VERSION ``` ### totalValue ```solidity function totalValue() public view returns (uint256 _totalValue) ``` Calculate total value using underlying vToken *Report total value in collateral token* ### isReservedToken ```solidity function isReservedToken(address _token) public view returns (bool) ``` Check whether given token is reserved or not. Reserved tokens are not allowed to sweep. # EarnVesperStrategy ## EarnVesperStrategy ### constructor ```solidity constructor(address _pool, address _swapManager, address _receiptToken, address _dripToken, address _vsp, string _name) public ``` # EarnVesperStrategyVSPDrip ## EarnVesperStrategyVSPDrip ### transferToDripContract ```solidity bool transferToDripContract ``` ### constructor ```solidity constructor(address _pool, address _swapManager, address _receiptToken, address _dripToken, address _vsp, string _name) public ``` # JavaScript Library # Vesper Improvement Proposal Template 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. # Brand Guidelines & Assets ## 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. For creative inspiration, the team encourages people to visit #vespernaut-meme-station-alpha on [the official Vesper Discord](https://discord.com/invite/Pm8UDaazsK). ## Color Palette ![](/files/-MXIP_18UVjlBkyheymW) ## Logo Treatment ![Logo on white background](/files/-MXICPg8KfWEi1Fk7mwm) ![Logo on navy background (#160e3a)](/files/-MXIC-WRADOQPZPd5p9t) ![Logo on cobalt blue background (#4138ac)](/files/-MXIC9UivGuWC10Fj0GK) ## Images ### Vesper Logos ![](/files/-MXOHdljVyvbH4RK2kEP) {% file src="/files/-MXOIEi\_KZaJZ5Pg8IqG" %} Vesper Logo (PNG) {% endfile %} {% file src="/files/-MXOIR\_XF8rJ8-UdW1Bm" %} Vesper Logo (SVG) {% endfile %} ![](/files/-MXOIv_33M4_P1nLCFec) {% file src="/files/-MXOJ1L-SPcLcRF6Ka5o" %} Vesper Logo Reversed (PNG) {% endfile %} {% file src="/files/-MXOJ8\_3fpDm4gqv3F2H" %} Vesper Logo Reversed (SVG) {% endfile %} ### Vesper Token ![](/files/-MXOJlTMMrSPNA7GOtY2) {% file src="/files/-MXOJsiUXNJRYcd5sXp4" %} Vesper Token (PNG) {% endfile %} {% file src="/files/-MXOJxBvitged-p06u8h" %} Vesper Token (SVG) {% endfile %} ## Typeface The Vesper copy typeface is [inter](https://fonts.google.com/specimen/Inter#standard-styles), which is available under the [SIL Open Font License](https://scripts.sil.org/cms/scripts/page.php?site_id=nrsi\&id=OFL). {% file src="/files/-MXOKMzu2jnbqfijvbRk" %} Inter Font Family (ZIP) {% endfile %} ![](/files/-MXITnbe7D01pFhynG9W) # Quarterly Reports This page offers downloadable PDFs of Vesper Finance's quarterly reports. {% file src="/files/rySe1KfHk9UqWLKEwiIq" %} Q3 2022 {% endfile %} {% file src="/files/4wer92rmn6QIByhBybmK" %} Q2 2022 {% endfile %} {% file src="/files/1klbzII8fkqaG0XSCDUB" %} Q1 2022 {% endfile %} {% file src="/files/1NdaH7TL38JDlUcUh4t5" %} Q4 2021 {% endfile %} {% file src="/files/okuVtDQryYOuceDcf7Gc" %} Q3 2021 {% endfile %} # Smart Contract Audits 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](https://github.com/vesperfi/doc/tree/main/audit/v3%2B). This link is updated frequently as ongoing audits are continually returned to Vesper engineering. # FAQ ## **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](broken://pages/-MG_Lga7DSoznys3P5rd) 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](/vesper-pools-and-strategies/strategies) 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](/vsp-economics/revenue-model#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](/community-participation/governance-1) 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](/community-participation/governance/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](/community-participation/the-voting-process) section. # Glossary of Terms **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). **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. **Rebalance-Collateral** – The process by which Vesper pools are adjusted to maintain health and compound yield back into the deposit asset. Rebalancing is carried out automatically by designated keepers. For lending and farming strategies, this typically involves harvesting rewards, swapping them into the deposit asset, and redeploying them. For borrow-based strategies, it can involve adjusting loan positions to keep collateral ratios within safe thresholds. **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 the underlying yield accrued by pool assets as they are routed to other DeFi platforms per the pool strategy. The **"spot"** earning rate is calculated as last 24-hours performance annualized and compounded, while **"average"** reflects the past 30-days annualized and compounded.