Our new v3 front-end and back-end were designed with scalability and composability in mind, and can be divided up into multiple distinct components: Lens, Meta, Subgraph, Exporter, SDK, and Front-end.
We briefly describe each of them below:
Yearn’s lens is a group of contracts that aggregate on-chain data to make it easily consumable. The lens includes an oracle, registries, address generators, adapters, and helper contracts. Lens contracts are configurable (allowing calculations to be added/updated individually), all adapters are extendable, and all storage variables can be updated. Lens provides information scoped to any user by asset or protocol, information scoped to a specific vault or Iron Bank market, and information scoped to the entire protocol.
Important use cases for Yearn’s lens include on-chain user balances, vault balances, and TVL (all normalized to USDC via an on-chain oracle) for the entire Yearn protocol. In summary, lens serves as a simple integration point for any protocol or partner who wishes to pull Yearn data on-chain quickly.
Yearn’s metadata repo is a simple framework that allows front-end vault settings to be tweaked very quickly without requiring any code editing. Yearn team members simply need to edit a JSON file that will automatically build and deploy the updated IPFS metadata files.
Currently supported schemas and features include:
- Hide a vault from the UI
- Disable deposit/withdraw and/or zap in/out for a vault
- Indicate if a vault has an available migration to a newer version
- Override APY values
- Strategy name and description
- Vault symbol, name, or token icon override
- Underlying token symbol, name, or icon override
- Quickly configure many aspects of a vault even if you are not a programmer (still requires PR review)
- Edit configuration in one place and all integrators are updated
- Maintain control over token and vault names, icons, and symbols
The primary use case of Yearn’s subgraph is to aggregate and transform historical on-chain data and to make it easily queryable. As you can see in the image above, the subgraph is currently used to display:
- User historical earnings scoped to a vault
- Overall historical user earnings
- Vault historical earnings (shown on vault detail page)
Since the earnings of each vault are not natively integrated at the contract level we use our subgraph to track events of deposits, withdrawals, and harvests which are then aggregated so earnings can be calculated.
Yearn’s ecosystem is inherently complex which means having a subgraph that provides large amounts of accurate data is difficult. As with all aspects of the website, the code is open-source, so if you notice any problems with your earnings feel free to let us know or submit a PR to the subgraph repo below.
Yearn exporter functions as our primary API, and contains all APY and TVL calculations. It depends only on the on-chain data, and also provides tools for anyone to permissionlessly verify any measurable aspect of Yearn products. It supports exporting both realtime and historical data.
Yearn’s new SDK is the engine that powers our new v3 website, and the front-end was specifically designed around consuming data from the SDK. The SDK aggregates on-chain and off-chain data to serve front-ends and B2B integrations by fetching data from lens, exporter, subgraph, meta, and Zapper.
- V3 front-end
- B2B integrators: vault management and configuration is taken care of for the integrator. An update in the data our SDK fetches means integrators are automatically taken care of.
- Strategist dashboards
While the back-end infrastructure listed above generates the data needed, the front-end consumes it and presents it in a way that users can easily interact with it.
Our front-end code is divided in two different pieces: v3 core logic and UI layer.
The v3 core logic is meant to be easy to implement in any repo and is in charge of communicating with the SDK and other external data providers, not only by fetching data but also by making POST/WRITE requests. The core logic also models and feeds the UI with a more suitable and traditional data schema, combining all of the different pieces of data (vaults, tokens, user balances, etc).
The UI layer consumes the data directly from the core and displays it as desired in each repo. It can be broken down into five main pages, described below.
The home page contains an overview of all of your assets in your wallet, as well as all three Yearn product categories: Vaults, Labs, and Iron Bank.
The wallet view displays all assets in your wallet, their total value, and allows you to either deposit them to any vault or supply the tokens to Iron Bank if a market is available.
Our new vaults page contains a dashboard with user info regarding vault deposits, recommendations (currently displaying highest-yielding vaults), underlying token balance, dollar value, and historical earnings for any vault deposits as well as current APY. Clicking on any vault will bring up the vault detail page.
Vault Detail Page
The vault detail page is a unique URL for each vault (coming soon to labs) that displays vault TVL, APY, underlying token info, strategy descriptions, historical vault earnings, and allows users to deposit and withdraw.
One thing users will notice is that yveCRV, yvBOOST, and our yvBOOST-ETH pJar (a product launched in collaboration with pickle.finance) are no longer on our vaults page. Instead, these have all been moved to our new Labs section.
What is Labs, you ask?
Yearn’s vaults were originally created with the idea of being “up-only”, and that users could withdraw at any time. As Yearn’s strategies became more sophisticated and we searched for new ways to generate yield, we realized that many strategies are not well-suited to this specific framework.
For instance, several strategists have been working on single-sided LP strategies. Between trading fees and staking incentives, the yield on funds in AMM LPs can be quite lucrative — but there is an obvious risk of impermanent loss and/or short-term drawdowns depending on market fluctuations.
Additionally, protocols like Bancor may require a 24-hour cooldown period to unstake funds. Previously, a requirement like this would break the “withdraw any time” aspect of vaults.
In labs, we allow more flexibility, and as long as users are aware of the conditions up-front, strategies will allow lock-ups and the potential for temporary losses in pursuit of increased, long-term sustainable yield.
Similar to vaults and labs, Iron Bank shows a dashboard with relevant info, including total supplied, total borrowed, borrow limit used, and total borrow limit.
Before deposits, withdrawals, or zaps into or out of a vault we use Tenderly to simulate the transaction. This gives a lot of beneficial information to users before they even submit a transaction and commit to spending gas:
- If the simulation is successful they’ll be able to see roughly the number of tokens that will be received.
- If it’s simulated that the transaction will result in more slippage than the user’s tolerance (for zaps) then a warning will be displayed to the user with how much the actual slippage would likely be.
- If the simulated transaction fails a warning will be displayed to the user.
In order to simulate a transaction, we first need to make a call to Zapper’s API to see whether the user needs to approve the zap. If they do, then we create a Tenderly fork so we can preserve state between simulations. We then simulate the approval transaction, again using Zapper, to fetch the transaction data that needs to be simulated for the approval. After the approval simulation succeeds we then fetch the transaction data for the actual zap and execute another simulation. Finally, we’re able to see the fully simulated data about the zap, without needing the user to approve it first.
Please note that a simulation will fail if you’re trying to simulate a transaction for which you do not have enough gas. Although we have tested them extensively, simulations are complex actions, so please pass on feedback if you experience any issues or failing simulations.
Another key requirement for the new website was full mobile support, something that was sorely lacking in the past.
The website now supports displaying all information from both a full-sized and mobile screen. This includes the user dashboard, search functionality, all action buttons (deposit, withdraw, supply, borrow), APY information, and transaction modals designed specifically with mobile layouts in mind.
While we don’t currently have a native Yearn app due to some App Stores’ restrictions, we’ve committed to providing a native-like experience on mobile browsers.