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" that enable users to passively increase their crypto holdings by simply selecting the desired aggressiveness of their strategy and the digital asset held. The Vesper Grow Pools represent the first product on the Vesper platform.

Vesper Token: VSP incentivizes participation, facilitates governance, and catalyzes user contribution. Users earn VSP through revenue share mechanisms by 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 is best for news and insights. serves as our primary notification channel. is where most interactions around governance, community, and development (by the team and community members) take place.

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.

Types of contracts documented here

Abstract classes or models used for creating instances.

Types of contracts not documented here

Link to Developer's Guide

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.

VSP Token

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

• Voting Rights: VSP tokens () 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

EarnVesperStrategy

constructor

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

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:

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.

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

PoolAccountantStorageV1

pool

totalDebtRatio

totalDebt

strategies

withdrawQueue

PoolAccountantStorageV2

StrategyConfig

strategy

externalDepositFee

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

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

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

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

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

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

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

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 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.

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 -

VesperStrategy

NAME

string NAME

VERSION

totalValue

Calculate total value using underlying vToken

Report total value in collateral token

isReservedToken

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

EarnVesperStrategyVSPDrip

transferToDripContract

bool transferToDripContract

constructor

Earn

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

dripToken

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:

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

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.

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 . This link is updated frequently as ongoing audits are continually returned to Vesper engineering.

VETH

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

constructor

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 },
    },
    ```

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. 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. .

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 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 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 . 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.

Flow control in Vesper V3

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

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

• The (proxied) pool contract interacts with strategies;

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

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

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

T

Mapping the block diagram to smart contracts

The Pool block represents an implementation of the VPool contract.

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

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

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

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

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

Flow of Control When a Deposit Is Made to a Pool

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

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

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

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

Flow of Control When a Withdrawal from a Pool Occurs

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

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

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

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

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

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

Flow of Control during Rebalancing

i. Only the keeper can call rebalance on strategies.

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

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

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

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

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

PoolRewardsStorage

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

pool

Vesper pool address

rewardTokens

Array of reward token addresses

isRewardToken

Reward token to valid/invalid flag mapping

periodFinish

Reward token to period ending of current reward

rewardRates

Reward token to current reward rate mapping

rewardDuration

Reward token to Duration of current reward distribution

lastUpdateTime

Reward token to Last reward drip update time stamp mapping

rewardPerTokenStored

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

userRewardPerTokenPaid

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

rewards

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

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 . 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.

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

IVesperPoolV2

An interface.

getPricePerShare

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.

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 .

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.

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

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

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

Voting & Participation

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

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 and . 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.

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

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.

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 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 , 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.

PoolRewards

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

VERSION

initialize

Called by proxy to initialize this contract.

notifyRewardAmount

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

Also updates reward rate and reward earning period.

notifyRewardAmount

addRewardToken

Add new reward token in existing rewardsToken array

claimReward

Claim earned rewards.

This function claims rewards for all tokens being rewarded

updateReward

Updated reward for given account.

claimable

Returns claimable reward amount.

getRewardTokens

Provides easy access to all rewardTokens

lastTimeRewardApplicable

Returns timestamp of last reward update

rewardForDuration

rewardPerToken

Rewards rate per pool token

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.

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.

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.

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;

Strategy

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

collateralToken

receiptToken

pool

feeCollector

swapManager

oraclePeriod

oracleRouterIdx

swapSlippage

_keepers

UpdatedFeeCollector

UpdatedSwapManager

UpdatedSwapSlippage

UpdatedOracleConfig

addKeeper

Add given address in keepers list.

keepers

Return list of keepers

migrate

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

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

removeKeeper

Remove given address from keepers list.

updateFeeCollector

Update fee collector

updateSwapManager

Update swap manager address

updateSwapSlippage

updateOracleConfig

approveToken

Approve all required tokens

setupOracles

withdraw

Withdraw collateral token from lending pool.

rebalance

Rebalance profit, loss and investment of this strategy

sweepERC20

sweep given token to feeCollector of strategy

token

Returns address of token correspond to collateral token

totalValue

Calculate total value of asset under management

Report total value in collateral token

totalValueCurrent

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

Report total value in collateral token

isReservedToken

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

PoolAccountant

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

VERSION

MAX_BPS

EarningReported

LossReported

StrategyAdded

StrategyRemoved

StrategyMigrated

UpdatedExternalDepositFee

UpdatedPoolExternalDepositFee

UpdatedStrategyDebtRatio

init

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

addStrategy

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

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

setup

OnlyPool:: Helper function for V5 upgrade

removeStrategy

Remove strategy and recalculate the pool level external deposit fee.

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

updateExternalDepositFee

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

recalculatePoolExternalDepositFee

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

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

sweepERC20

Transfer given ERC20 token to pool

updateDebtRatio

Update debt ratio.

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

updateWithdrawQueue

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

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

migrateStrategy

Migrate an existing strategy to new strategy.

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

reportEarning

Strategy calls this at regular intervals.

reportLoss

Update strategy loss.

decreaseDebt

Decrease debt of strategy; this also decreases totalDebt.

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

availableCreditLimit

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

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

excessDebt

Debt above current debt limit

getStrategies

Return the strategies array.

getWithdrawQueue

Return withdrawQueue array.

totalDebtOf

Get total debt of given strategy.

VPool

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

VERSION

MAX_BPS

ONE_YEAR

UpdatedMaximumProfitAsFee

UpdatedMinimumDepositLimit

Deposit

Withdraw

UpdatedUniversalFee

UpdatedPoolRewards

UpdatedWithdrawFee

UniversalFeePaid

constructor

initialize

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

deposit

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

depositAndClaim

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

depositWithPermit

Deposit ERC20 tokens with permit, aka gasless approval.

whitelistedWithdraw

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

Deprecated method. Keeping this method here for backward compatibility.

withdraw

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

withdrawAndClaim

Withdraw collateral and claim rewards, if any.

multiTransfer

Transfer tokens to multiple recipients

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

reportEarning

Strategy call this in regular interval. Only strategy function.

reportLoss

Report loss outside of rebalance activity.

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

sweepERC20

Transfer given ERC20 token to governor

availableCreditLimit

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

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

calculateUniversalFee

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

Earn strategies will call this during rebalance.

excessDebt

Debt above current debt limit

getStrategies

totalDebt

Get total debt of pool

totalDebtOf

Get total debt of given strategy

totalDebtRatio

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

calculateMintage

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

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

getWithdrawQueue

pricePerShare

Get price per share

Return value will be in token defined decimals.

strategy

tokensHere

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

totalValue

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

_beforeBurning

Before burning hook. withdraw amount from strategies

_calculateShares

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

_calculateUniversalFee

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

_calculateUniversalFee

migrateStrategy

Migrate existing strategy to new strategy.

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

setup

OnlyGovernor:: Helper function for V5 upgrade

updateMaximumProfitAsFee

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

updateMinimumDepositLimit

Only Governor:: Update minimum deposit limit

updateUniversalFee

Update universal fee for this pool

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

updatePoolRewards

Update pool rewards address for this pool

pause

unpause

shutdown

open

keepers

Return list of keepers

isKeeper

addKeeper

Add given address in keepers list.

removeKeeper

Remove given address from keepers list.

maintainers

Return list of maintainers

isMaintainer

addMaintainer

Add given address in maintainers list.

removeMaintainer

Remove given address from maintainers list.