This value in Context is non-optional, so when instantiating the SDK it has to be passed in - https://github.com/yearn/yearn-sdk/blob/master/src/context.ts#L65

Instead it should be 'true' by default, and the allow list should not be used unless the user explicitly sets disableAllowlist to false

src/cache.ts

Spinoff this PR comment #251 (comment)

In summary, we would like to have this rule enabled "@typescript-eslint/camelcase": "off"

However, in order to achieve that we need to serialize the JSON keys (snake_case) to camelCase

A possible solution is using a library such as https://github.com/typestack/class-transformer, but we could also have a go at implementing something similar ourselves.

src/interfaces/earnings.ts

When running the simulation.mjs, it looks like the gas estimation is using the tenderly API which results in the following error.

(node:42563) UnhandledPromiseRejectionWarning: Error: cannot estimate gas; transaction may fail or may require manual gas limit (error={"reason":"processing response error","code":"SERVER_ERROR","body":"{\"jsonrpc\":\"2.0\",\"id\":52,\"error\":{\"code\":32606,\"message\":\"error simulating transaction\",\"data\":\"handle rpc request: EstimateGas: call simulate api: prepare transaction state: max fee per gas less than block base fee: address 0x4F76fF660dc5e37b098De28E6ec32978E4b5bEb6, maxFeePerGas: 1 baseFee: 1000000000: invalid transaction simulation\"}}","error":{"code":32606,"data":"handle rpc request: EstimateGas: call simulate api: prepare transaction state: max fee per gas less than block base fee: address 0x4F76fF660dc5e37b098De28E6ec32978E4b5bEb6, maxFeePerGas: 1 baseFee: 1000000000: invalid transaction simulation"},"requestBody":"{\"method\":\"eth_estimateGas\",\"params\":[{\"gasPrice\":\"0x1\",\"value\":\"0x0\",\"from\":\"0x4f76ff660dc5e37b098de28e6ec32978e4b5beb6\",\"to\":\"0xe14d13d8b3b85af791b2aadd661cdbd5e6097db1\",\"data\":\"0x095ea7b3000000000000000000000000d6b88257e91e4e4d4e990b3a858c849ef2dfde8c00000000000000000000000000000000000000000000000cd2707ac84a77b4a7\"}],\"id\":52,\"jsonrpc\":\"2.0\"}","requestMethod":"POST","url":"https://rpc.tenderly.co/fork/8af6f512-dd4b-4f8a-abef-c492bd4a18b9"}, tx={"from":"0x4F76fF660dc5e37b098De28E6ec32978E4b5bEb6","to":{},"data":"0x095ea7b3000000000000000000000000d6b88257e91e4e4d4e990b3a858c849ef2dfde8c00000000000000000000000000000000000000000000000cd2707ac84a77b4a7","value":"0","gasLimit":{},"gasPrice":{"type":"BigNumber","hex":"0x01"},"type":0,"nonce":{},"chainId":{}}, code=UNPREDICTABLE_GAS_LIMIT, version=abstract-signer/5.4.1)
    at Logger.makeError (/Users/kunaljain/Code/OpenSource/yearn-sdk/node_modules/@ethersproject/logger/lib/index.js:187:21)
    at Logger.throwError (/Users/kunaljain/Code/OpenSource/yearn-sdk/node_modules/@ethersproject/logger/lib/index.js:196:20)
    at /Users/kunaljain/Code/OpenSource/yearn-sdk/node_modules/@ethersproject/abstract-signer/lib/index.js:365:47
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
    at async Promise.all (index 4)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:42563) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:42563) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

https://github.com/yearn/yearn-sdk/blob/master/src/interfaces/strategy.ts#L52

We should always use fetchMetadataFromApi for all chains. If that fails then fallback to fetchMetadataFromChain

Functionality to cover:

• simulations
• deposits
• withdrawals
• earnings calculations
• iron bank interactions
• the vaults interface

The apollo cache never gets invalidated thus serving old content when the subgraph has been updated.

Elevator Pitch
In order for the FE to be able to handle specific errors that come from simulation we have to start forwarding a bit more information about, where the error happened and what type of error happened. The idea is to catch the most common errors thrown by each of the points of contacts of the simulation endpoint and throw a specific error code for each and a default error message for the ones that we are not catching.

We are already catching what is throwing which error on https://github.com/yearn/yearn-sdk/blob/master/src/types/custom/simulation.ts#L3 so it's just the suggested structure to those type of errors

Definition of Done

• Throw errors with error_type, error_code and message from the simulation endpoint

Design Approach
The idea is to have the errors thrown by the SDK to have the following structure:

{
  error_code: string, // The specific error code that happened
  error_type: string, // Where the error originated from (zapper, contracts, tenderly, sdk own error, etc)
  message: string // Default message to show to the user in case it is not being handled
  data: any, // metadata that might come with the error
}

Also the SDK should export error types for each type of error, like ZapperError, this would allow us to also type which error_codes are accepted. (See https://medium.com/geekculture/how-to-strongly-type-try-catch-blocks-in-typescript-4681aff406b9 for more information about how to strong type errors from exceptions)

Just as an example for

And ZapperError would look like

 class CustomError extends Error {
  constructor(message, error_code) {
    super(message);
    this.error_code = error_code;
  }
}

class ZapperError extends CustomError {
  constructor(message, error_code) {
    super(message, error_code);
    this.error_type = 'zapper';
  }
}

Additional Context
This has to be done as part of yearn/yearn-finance-v3#440

At the moment a lot of the addresses of contracts from https://github.com/yearn/yearn-lens are hardcoded into the sdk. E.g. https://github.com/yearn/yearn-sdk/blob/master/src/services/oracle.ts#L51. These should instead be fetched from the addresses provider contract.

These should be fetched and cached for a period of time, so if they are updated on chain then the sdk will receive the correct values.

Not all id will be present as they need to be added, it'd be helpful to gather a list of these and in the meantime fallback to the hardcoded addresses already present in the SDK

Mainnet:
https://etherscan.io/address/0x9be19ee7bc4099d62737a7255f5c227fbcd6db93
Fantom:
https://ftmscan.com/address/0xac5A9E4135A3A26497F3890bFb602b06Ee592B61
Arbitrum
https://arbiscan.io/address/0xcad10033c86b0c1ed6bfccaa2ff6779938558e9f

E.g. addressById("ORACLE") returns the oracle address

It seems getNormalizedValueUsdc method is good for what yearn watch wants, it would be great if it supported batch calls (multicall), since potentially we will be calling this with all the want tokens we support which is a lot of promises and calls to web3 provider

src/services/allowlist.ts

Trying to fetch yvBoost dynamic data returns undefined

const [yvBoostVaultDynamic] = await yearn.vaults.getDynamic([YVBOOST]);

VaultDynamic[] is expected.

Fetching all data (static + dynamic) does return the expected response:

const [yvBoostVault] = await yearn.vaults.get([YVBOOST]);

Remove the if statements from this block of code - https://github.com/yearn/yearn-sdk/blob/master/src/interfaces/token.ts#L67-L79

Use a switch instead, as will be easier to add future chains

LensService https://github.com/yearn/yearn-sdk/blob/master/src/services/lens.ts relies upon a contract that doesn't exist. It's functionality does not work, so should eventually be removed. First, it should be marked as deprecated, and it's functionality in the sdk (accessing adapters) being replaced by moving those adapters to a more suitable place, perhaps on the Yearn object

PR #220 removed the ContextValue property of disableAllowlist.

This change is backwards incompatible. This change was neither documented nor is there an explanation for people using <=1.0.30 on how to correctly change their code.

I discovered this after a dependency upgrade brought in the latest @yfi/sdk v1.1.1 and our build immediately failed with a TypeScript error referencing this property.

What is the correct way to change code that previously relied on disableAllowlist? Does just removing the use of property fix it, or is additional work required?

• Clone the yearn exporter repo - https://github.com/yearn/yearn-exporter
• Checkout the branch feat/brownie_bridge
• Make sure these environment variables are set:

export WEB3_PROVIDER=...
export EXPLORER=...
export FTM_WEB3_PROVIDER=...
export FTM_EXPLORER=...

• run make bb-up
• wait for the bridge to finish starting up
• curl -X POST -H 'Content-Type: application/json' http://localhost:4004/v2/1/prices?type=json -d '["0x0bc529c00c6401aef6d220be8c6ea1667f6ad93e"]'

This endpoint fetches prices from yearn-exporter, it will eventually be hosted somewhere but it can be run locally for now for testing purposes. In this example we fetch the price just for YFI, but an array of tokens can be passed in.

A new service should be added to the SDK that fetches prices for all yearn tokens, caches the response for 3 minutes, and provides a function to fetch all prices, and one for individual prices. All yearn tokens can be found from the registry adapter's assetsTokensAddresses function - https://etherscan.io/address/0x240315db938d44bb124ae619f5fd0269a02d1271#readContract

src/interfaces/vault.ts

the token.mjs example is failing with an outofgas exception.

I've tracked the issue down to the following helper contract: https://etherscan.io/address/0x855ffe28019106d089bc018df18838f8d241c402#readContract

tokensAddresses() is called with about 70 tokens as tokensAddresses parameters, which is causing the out of gas exception.

After a bit of testing, the following is the minimal set of tokenAddresses I found that will cause an out of gas exception:

accountAddress: 0xFEB4acf3df3cDEA7399794D0869ef76A6EfAff52

tokenAddresses:
[0x3F1B0278A9ee595635B61817630cC19DE792f506,0x9c2C8910F113181783c249d8F6Aa41b51Cde0f0c,0x8818a9bb44Fbf33502bE7c15c500d0C783B73067]

Not sure if this counts as a yearn-lens issue

Elevator Pitch:

This seems to only happen when user has deposits on yvBoost vault (lab).\

This comes directly from SDK from vaults.summaryOf().holdings

In the next example user doesnt have any vaults deposits and still we get $32k of holdings. Also price calculation seems off since shows $32k but the real value of user's yvBoost position is $81k

Vaults view

Labs view

Hot to reproduce:

Go to dev website > settings > enable dev mode > Enter thi address 0xb6725c748d2C69673784652bE63Efba5CC20AF72

Customer Value:

[Who is this for? -- Persona or group of people whom will derive value from the scenario]
[What benefits will be achieved or business metrics improved? ]

Design Approach:

[Free text / diagram / whiteboard picture/ whatever that clearly shows your approach/considerations to build the task list / Existing code patterns in production code base that you will base your work off of]

Agreed upon Acceptance Criteria (definition of Done):

[Bulleted list describing the exit criteria and desired end state. Should be clear how success is determined and measured]

• Criteria #1

Refactoring Impact:

[Call out any refactoring that may be required as a side effect of the work]

Dependencies:

[Key/major people or technology dependencies to call out]

Assumptions:

[Call out any assumptions being made when estimating the tasks to complete the work]

Threat Modeling:

[What are possible attack vectors? Detail what kind of attacks could happen, and steps being taken to protect against them.]

Design Changes:

[ Design changes identified during the course of engineering that are contrary to the initial design should be identified in this section, and approved again by the team ]

Estimation/Estimated Completion date:

[95% confidence]

Design review:

[Two people needed for signoff]

Do not signoff unless 1) agreed the tasks and design approach will achieve acceptance and 2) the work can be completed by 1 person within the SLA. Design reviewers should consider simpler approaches to achieve goals.

<Person/date>

<Person/date>

https://github.com/yearn/yearn-sdk/blob/master/src/interfaces/earnings.ts#L33

Should mark this function as deprecated since we're not able to accurately calculate protocol earnings from the subgraph. This function will be removed in a future version of the SDK

https://github.com/yearn/yearn-sdk/blob/master/src/interfaces/earnings.ts#L260

The arbitrum subgraph has been deployed with timestamps for VaultDayData that are in formats like: 1642723200000000

They should be normalized to ms timestamps i.e. 1641948793000, so we should correct it when necessary, if the timestamp's length is too long

Does this package have rate limiting functionality?

src/interfaces/strategy.ts

Hi, awesome sdk

Is there a way to remove this console log or handle the error appropriately? It happens on sdk initialization

SdkError: HTTP to https://raw.githack.com/trustwallet/assets/master/blockchains/ethereum/tokenlist.json request failed (status 429 Too Many Requests)

console log is coming from here

When instantiating the yearn sdk and passing in a JsonRpcProvider to a remote node, the sdk is still attempting to connect to a node at localhost:8545.

src/interfaces/token.ts

• Use Curve's APR formula for all Curve vaults, based on base APR and boost data from the Curve gauges and pools.
• This will be a significant improvement, and will especially useful for new vaults (instead of showing N/A)
• For calculations, see here: https://docs.google.com/spreadsheets/d/1lJKrH8uP19AsVBMjMbHdBX9xbzDdYXtXpeUzvaSHXRs/edit#gid=340252882