Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

APY Finance adapter + Token Allocation #220

Merged
merged 21 commits into from
Jan 15, 2021
Merged

APY Finance adapter + Token Allocation #220

merged 21 commits into from
Jan 15, 2021

Conversation

RodrigoAD
Copy link
Member

This PR includes two new adapters:

  • token-allocations adapter. This adapter could be used for price data relying adapters, such as Defi Pulse or Synthx
  • apy-finance adapter. Calculates the Total Value Locked in APY Finance.

To not make this PR really big, Defi Pulse migration to use token-allocations adapter will be added in a separate PR.

@github-actions
Copy link
Contributor

I see that you haven't updated any CHANGELOG files. Would it make sense to do so?

@RodrigoAD RodrigoAD changed the title APY FInance adapter + Token Allocation APY Finance adapter + Token Allocation Jan 12, 2021
token-allocation/README.md Outdated Show resolved Hide resolved
Comment on lines +4 to +11
import cryptocompare from './data-providers/cryptocompare'
import nomics from './data-providers/nomics'
import coinpaprika from './data-providers/coinpaprika'
import coinmarketcap from './data-providers/coinmarketcap'
import coingecko from './data-providers/coingecko'
import coinapi from './data-providers/coinapi'
import amberdata from './data-providers/amberdata'
import kaiko from './data-providers/kaiko'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have no way of using the existing adapters instead of re-writing them here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • When we migrate the price adapters to .ts, token-allocation will be using them. Right now we can't
  • Everything under data-providers/ is exactly the same on defi-pulse, but this will use token-allocation adapter after this is merged, so all the repeated code will be removed from defi-pulse
  • Synthx could use token-allocation as well, so the repeated code will be removed there too.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the explanation! Just worried about the technical debt.

Do we have a story for this migration? I feel like we should also include some work on the CVI adapter (which isn't even merged in yet, but I think it can use the same work once it's in).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I included 2 stories yes (#176484089 and #176464064). You can include the story for CVI too so we don't forget

@boxhock boxhock self-requested a review January 15, 2021 12:44
## Input Params

- `components`: Array of the token symbols.
- `units`: Array of balances in wei of each token.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to make this optional, and default it to an array of 1s?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep ok

Comment on lines +40 to +42
"10000000000000000000",
"10000000000000000000",
"10000000000000000000"
Copy link
Contributor

@boxhock boxhock Jan 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this match with the output in this readme?
And why does units change from wei as input to "Ether" in output?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • It doesn't match you're right. Will fix it.
  • It would make sense to be the same units actually, either both 'wei' or both 'ether'. Wei I'd say makes more sense as it's more precise, but not sure.

Copy link
Contributor

@boxhock boxhock Jan 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. On the last point, also consider that "ether" would make more sense normally, if you're not explicitly aware that this adapter takes "wei".

How much precision do we usually need with an adapter like this? I'm guessing there's a reason why you picked wei to begin with 😅

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haha there are some adapters that query the units from contracts directly, so they give it in wei. But they can be converted to "ether" of course 😄

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, sounds like the easiest thing to do is just give it in wei then.


- `components`: Array of the token symbols.
- `units`: Array of balances in wei of each token.
- `currency` (optional). Currency we want the price on. `DEFAULT_CURRENCY` by default
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More of a generic question, but would it be easy to extend this adapter with a param for "endpoint"?
Say the default currently is to get the prices, could it easily be extended to say marketcap percentage?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it would be hard, and make sense to have that functionality in this adapter.

Copy link
Contributor

@boxhock boxhock left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would like some more 👀 on this, but looks good to me

@RodrigoAD RodrigoAD merged commit 5823442 into develop Jan 15, 2021
Copy link
Contributor

@krebernisak krebernisak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@RodrigoAD here are some more suggestions you can work on in the next defi-pulse PR.

return {
priceAdapter,
defaultCurrency,
makeDefaultUnits: makeDefaultUnits(defaultUnit || new Decimal(1e18).toString()),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is the default 1e18?

Even if we need an fn like this, and I think we can do without it, the config is probably not the place for it.

Comment on lines +11 to +12
units: Decimal
price?: number
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Price can be Decimal to have better precision than number, but why is units typed as Decimal. IMO it should be number or BN?

if (!index.every(isPriceSet)) throw new Error('Invalid index: price not set')
// calculate total value
return index // eslint-disable-next-line @typescript-eslint/no-non-null-assertion
.reduce((acc, i) => acc.plus(i.units.div(1e18).times(i.price!)), new Decimal(0))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should not assume every token has 18 decimal points, for example wBTC does not.

We should take decimals on input, and use 18 as a default if not set.

Comment on lines +10 to +13
type Allocations = {
components: string[]
units: string[]
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This type is a relic of defi-pulse underlying contract implementation and is inflexible. How about we change this type to something more usable like:

type TokenAllocation = {
   symbol: string
   decimals: number
   balance: string | BN
}

This type should then be moved to the token-allocations adapter and used by APY & DeFi Pulse.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep agree

import registryAbi from './IRegistry.json'
import assetAllocationAbi from './IAssetAllocation.json'

const getRegistry = (address: string, rpcUrl: string, abi: any): ethers.Contract => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function is really unnecessary :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haha ok

@@ -0,0 +1,53 @@
[
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kind of doesn't make sense to have IAssetAllocation abi in a registry folder. Let's just put all ABIs in the /src/abi folder.

The second thing is these static ABIs are really hard to identify. What is the origin and source code for these ABIs? Where can we find some more documentation for these contracts? Please document answers to these questions.

return components.map((component, i) => {
return {
asset: component,
units: new Decimal(new utils.BigNumber(units[i]).toString()),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Either Decimal or BigNumber, why both?

@boxhock boxhock deleted the apy-tvl-adapter branch June 22, 2021 11:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants