Hi,

Seems like the tvl endpoint is working, but there is no mention of it in the docs.

Furthermore, what is the output format ?

I see the following for example :

{
  "25": {
     ...
  },
  "56": {
     ...
   },
  "137": {
     ...
  }
}

What do these numbers mean ?

Thanks

We used to use Pancakeswap's API at thttps://api.pancakeswap.finance/api/v1/price as a price oracle. Now we're using smart contract oracles directly. It seems like a good opportunity to stop using their inconsistent naming of mixing uppercase with capitalised or lowercase ids and move all our IDs to be uppercase.

The app/cowllector/dashboad repos might have to be updated as well.

Fill out a prettier file to make sure we all share the same code style/syntax

Right now the docs for the API are almost non-existent. If we improve our README.md at least with some clear instructions on the API structure, how to run it, how to contribute, etc, it will make it much easier for new contributors to help out.

We're launching the Mdex pools on HECO so we need to add all their APYs to the API.

This is only for BEETS token price:

Lets find uniswap LP with BEETS token and use it for price.

Right now we're not taking into account LP trading fees into the total APY. I've wanted to add it for some time, and I noticed the other day that Alpha Finance does it.

Currently, an average of a few days of the previous week's data is used for calculating the trading APR for sushi LPs. This was done towards the beginning of polygon adoption, when there were subgraph lag issues, and the trading APRs had stabilized, so it was decided showing the previous week's trading APR was fairly accurate.

Since then sushi has expanded to other chains, and we are blindly using last week's data for all chains sushi is on, regardless if there is a subgraph lag issue. The request is to investigate if there is a subgraph lag issue on each chain sushi is on, and adjust the trading APR calculation to:

1. allow customizing the days to average in the trading APR calculation per chain.
2. update to use the fresh data possible that's available on each chain.
   If there isn't a lag issue present anymore on any chains, we can globally update the days chosen for trading data to the average of the past 2 days (freshest data possible by the current query in place)

Bonus if the current query can be modified to use a trailing 48 hours of data

The harvester currently doesn't take into account its own CAKE funds while deciding where to farm.
It's easier to calculate the optimal poolId from the API because we already have functions that do most of the work.

Aura say this
https://docs.aura.finance/developers/how-to-___/calculate-aprs-from-aura-pool-yield

But beefy say this

I'm trying to run this, but getting one error.

I cloned the repo, then installed the dependancies. Am I missing something?

We are looking to make the API more reliable. One of our current pain points is that most of our price information comes from https://api.pancakeswap.finance/api/v1/price

We have constant issues with the endpoint being unreliable.

It would benefit us to get those prices directly from the Pancakeswap contracts.

Context

At our current rate, we are adding a dozen of strats per week to the system. This is making us hit the ratelimit on initialization.

A naive solution could be to group the requests, by splitting the pools in batches and waiting between them.
This approach has the problem that it relies on initialization order, or "knowing" the network rules from the application layer.

Proposed solution

Wrap the web3 object into a new object that understands the rules of each network. This object should keep track of the amount of request per minute / second and insert delays between them as needed.

The entry point for this solution would be src/utils/web3.js where the multiple clients are initialized.
we could replace: new Web3(endpoint) with new Web3(endpoint, ratelimit).

The trading APRs shown on beefy for pancake vaults tends to be much higher than what's shown shown on pancake.

Following the code it looks like the beefy backend calculates the trading Apr based on 0.25% trading fees to LP holders. but only 0.17% is actually rewarded to LP holders.

Split from Pancake docs

The code for APY on most lend/borrow strats is over estimating yields because it calculates an extra lend step that the contract does not actually perform.

Replace getStrategies & getLastHarvests with our usual Multicall.
These contracts require deployment on all chains, while they are just a 1 call function (not same as LpPriceMulticall) and thus can be replaced by general Multicall contract used everywhere else.

We need to create an endpoint that conforms to this format for the developers from CMC. It should include all the vaults that we want them to track and display:

{
    provider: 'SushiSwap',  // Project name - Sushi
    provider_logo: 'URL', // Project logo, square, less than 100*100 px
    links: [        // social media info
    {
      title: 'Twitter',
      link: 'https://twitter.com/sushiswap',
     }
  ], 
    pools: [
      {

          name: 'Pool Name 1', // Pool name if any, eg. Sushi Party, Uniswap Sushi-ETH LP
          pair: 'SUSHI-ETH'  // Pool pairs, e.g SUSHI-ETH
          pairLink: 'https://sushiswapclassic.org/farms/SUSHI-ETH%20SLP', // The URL to this pool
          logo: 'URL', //  Pool logo if any, otherwise just use Project logo
          poolRewards: ['SUSHI'], // The reward token ticker
          apr: 1.1,  // APY, 1.1 means 110%
          totalStaked: 13987213,  // Total valued lock in USD 

      },
      {
          name: 'Pool Name 2', 
          pair: 'LEND-ETH'
          pairLink: 'https://sushiswapclassic.org/farms/SUSHI-ETH%20SLP'
          logo: 'URL', 
          poolRewards: ['SUSHI'], 
          apr: 1.1,
          totalStaked: 13987213, 
      }
    ]
}

Hey team,

We've noticed that you're referencing a subgraph deployed on The Graph's hosted service in this repository. Just a heads-up: after June 12th, hosted service subgraph endpoints will no longer be available as the offering is being deprecated.

If you are the subgraph owner or maintainer, it's time to upgrade your subgraph to the network. This ensures everything keeps running smoothly and you get access to all the latest features and improvements. Here is a quick guide with all the upgrade steps.

If you're not the subgraph owner or maintainer, check Graph Explorer to see if the subgraph development team has already upgraded to the network. If you don’t find an upgraded subgraph, a friendly nudge to the subgraph development team would be greatly appreciated—it's a quick process that benefits everyone. Here's the upgrade guide with all the necessary steps for the subgraph development team.

Once the subgraph is upgraded to the network, you can create an API key and updated query URL in Subgraph Studio then update this repository to query from the new endpoint, https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>

Need more support or have more questions? Feel free to reach out to [email protected]. We're here to help!

Cheers,

Paka

for the GLP vaults, the underlying tokens should be transferred through the sGLP (staked). documentation here: https://gmxio.gitbook.io/gmx/contracts#transferring-staked-glp

the api is returning sGLP's address as the tokenAddress, so the front-end knows which token to transfer, but this has some side-effects. some integrations rely on tokenAddress to display underlying information about positions, and those integrations expect GLP as the underlying. this breaks GLP vaults on zapper, for example.

i think the api should return both addresses, and the front-end already calls this value locally as depositTokenAddress, so this could be a good field name here.

i was trying to host the api on my server after modification, confused on what to build for hosting, ii tried build folder in address book and i did see the OK response after host.

https://moonscan.io/address/0x922d641a426dcffaef11680e5358f34d97d112e1
https://moonscan.io/address/0x1DC78Acda13a8BC4408B207c9E48CDBc096D95e0

how should I handle alias in the addressbook?

I'm not exactly sure if this is something that we want to do. But having husky could make sure that all committed code shares the same style.

/vaults response updates with no reference to when it was updated behind the scenes.

Add a header to the response to recognise when the vaults data was actually refreshed.

A Beefy dev has the staking section pretty much ready on the frontend side. This section will be useful for many things, one of them is to bring the BIFI rewards pool out of the https://gov.beefy.finance subdomain and into the main app. That way we can finally decommission that subdomain.

We need an endpoint that can return 5 data points for each staking pool:

1. id: A unique ID for the pool. For example "bifi-wbnb"
2. name: Custom name for the pool.
3. tvl: Amount of the asset staked in the pool. For example in a pool with 4200 BIFI staked, this number would be 4200.
4. apy: APY that the pool currently pays out. This takes into account both the value of the staked assets and of the reward token.
5. staked: The amount of staked assets, but priced in USD. (Just need to multiply TVL * asset price)

{
  "data": [
    {
      "id": "yearn-eth",
      "name": "yearn.finance", 
      "tvl": 367025.4, 
      "apy": "20.82%", 
      "staked": 101453.46825158167
    },
    {
      "id": "bal-btcb",
      "name": "Balancer Pool",
      "tvl": 64245.17,
      "apy": "0.55%",
      "staked": 99.14566080152174
    }
  ]
}

Pretty much as soon as we can have this endpoint ready, we could have the stake section of the app live.

Context

We're trying to increase performance and decrease load of the Beefy API. We currently have different endpoints to track the value of LP tokens from different platforms. For example BUSD-BNB from pancakeswap and BUSD-BNB from streetswap, or kebab.

Problem

This causes redundancy by having to fetch multiple prices for assets that will be valued at pretty much the same price. It also means there's more files and lines of code that devs have to edit when adding pools.
Devs have to add a bunch of handlers and this type of things will only get worse:

const oracleEndpoints = {
  'bakery-lp': () => fetchLP(endpoints.bakeryLp),
  bakery: () => fetchBakery(),
  'bdollar-lp': () => fetchLP(endpoints.bdollarLp),
  coingecko: ids => fetchCoingecko(ids),
  'jetfuel-lp': () => fetchLP(endpoints.jetfuelLp),
  'monster-lp': () => fetchLP(endpoints.monsterLp),
  'narwhal-lp': () => fetchLP(endpoints.narwhalLp),
  'nyanswop-lp': () => fetchLP(endpoints.nyanswopLp),
  pancake: () => fetchPancake(),
  'pancake-lp': () => fetchLP(endpoints.pancakeLp),
  'thugs-lp': () => fetchLP(endpoints.thugsLp),
  'kebab-lp': () => fetchLP(endpoints.kebabLp),
  'sponge-lp': () => fetchLP(endpoints.spongeLp),
};

Solution

Just keeping all LP prices under a single endpoint. If we already have a BUSD-BNB LP price, we shouldn't need to add it again just because Kebab is different. We don't use the LP prices for anything mission critical so slight variations don't affect us.
The goal would be to make it as simple as possible to add and maintain new LP prices.

We are looking to make the API more reliable. One of our current pain points is our reliance on third party APIs that are sometimes out of service. For example all our Thugs price stats comes from their API at https://api.beefy.finance/thugs/tickers

It would benefit us to get those prices directly from the Streetswap contracts.

Using the endpoint /lps, one can fetch all the LP prices crosschain. Below you can find a subset of the response:

"curve-poly-atricrypto3": 1938.4656787747067

Could you please explain where the value 1938.46 comes from? I cannot derive this calculation from any value displayed on the curve website pool (https://polygon.curve.fi/atricrypto3). Thank you!

/apy api does not provide much information other than just the name of the asset and APY, but can you please add other tags like TVL, Display Name, Platform, Vault type, Asset 1 & 2 (if any) and whether deposit is paused

having these available in the endpoint will minimise traffic on your host and also simplify my analysis. Thanks

To have consistency between the Apy and Apr, the vaultApr in the apy breakdown endpoint should be returned with the vault-specific performance fee deducted.

Optionally something like vaultSimpleApr could be added to keep the underlying farm Apr exposed, however this is not needed for the UI.

There's quite a bit of code in the api repo that we no longer use. We're trying to prune as much of it to improve the api.

We had an endpoint at '/smart' that managed the SmartCake vault here The new version of CakeSmart won't require this so we can remove it.

We should also be able to remove getCakeSmartApy.js as the current smart cake vault just tracks the apy of the CakeSimple farm.

There seems to be assets that are not valid and not available in the Beefy app, e.g. FORTRESS-BNB

Can you double check to ensure these are correct?

There are a few instances in the stats API that call the compound function with just three arguments when it was meant to be called with four, forgetting to pass the default value for the third argument. Resulting in incorrect APY calculations.

For example:

• bsc/fortress/getFortressApys.js#L42
• bsc/venus/getVenusApys.js#L44
• fantom/getScreamApys.js#L48
• heco/getLendhubApys.js#L51
• matic/getAaveApys.js#L62

This cases are calling compound(apr, hpy, shareAfterPerformanceFee) instead of compound(apr, hpy, 1, shareAfterPerformanceFee), forgetting the 1 (one year for APY) as third parameter.