Replies: 2 comments 1 reply
-
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Beta Was this translation helpful? Give feedback.
-
|
I need help with this platform |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
A lot of projects ask us to use their closed API to get their TVL. I would rather avoid that, mostly because that's much less transparent than an open-source script that computes the TVL from on-chain calls.
This might not seem like it matters that much, but transparency is one of the core tenets of defillama and one of the things I spend most of my time working on. Here are the reasons for it:
Verifiability and reproducibility
It's important for our metrics to be verifiable and reproducible, meaning that anyone should be able to check how our TVLs are calculated, what's included as part of them, and then be able to reproduce the data that we display on our website. For this reason, we keep our whole stack open source, making it possible to reproduce everything.
With API-based adapters that's just not possible since they are completely opaque, making it completely impossible to check how the TVL is calculated.
Furthermore, one of the non-obvious consequences of that is that any changes to the API are not tracked, whereas changes to our scripts are tracked through git. The result of that is that verifying historical TVL values obtained through an API requires a lot of work.
This is because a lot of the tools you would use to verify the current TVL (checking the tokens locked on a contract or calling a contract function through etherscan) don't allow you to make queries at older blockheights, requiring you to write a script for it instead. This makes verification impossible for a large part of the population, and for the other part it makes it heavily work-intensive.
Fairness
One of the main things that defillama must provide are fair comparisons between protocols. It would be a failure on our side if for one protocol we count assets on a staking contract and for another protocol we don't include them, since then we would be favoring a protocol over another. However, there's a lot of things to consider when choosing what to include as TVL so we are bound to make mistakes, transparency acts as a safeguard that allows other people to keep us in check.
By making it possible to easily check how other TVLs are calculated, people can verify whether we count TVL for other projects in a similar way to the one we are using for them, and if we don't or if we include something for another project that we are excluding for them, they can raise the issue publicly.
If adapters rely on a closed API it's much harder and more time-intensive to check what is being included (especially since that may change through time, eg: in the past an API might include something as TVL that is not included anymore, and while checking current TVL is somewhat doable, crosschecking historical TVL against a number is very time intensive, a sisyphean task when you take into account that we host almost 300 projects), so it would be much harder or straight up impossible to run these comparisons against other protocols.
Breaking
APIs break a lot. The very few adapters we have that use APIs do regularly break and then I have to scramble to fix since otherwise data gets stale and we miss updates, which is quite important, since usually APIs don't provide historical values, so if it takes me 2 days to fix that adapter then there will be a 2-day gap in our data.
On top of that, it's impossible for me to fix APIs since I don't have access to their code, so all I can do is just ping the team to let them know that their API is broken or try to rewrite their adapter to avoid using their API.
No control over changes
Even if we verify that the numbers reported by an API are correct at the time we integrate it, we have no control over such API so it's possible for it to change and start reporting something different. An example of this would be the case of sovryn, where initially the API only included basic TVL stuff like liquidity on their pairs, resulting in a TVL of ~50M, but then they changed their API to also include staked tokens, which pumped the TVL to almost 2bn.
This generated quite a lot of drama on twitter (especially since sovryn claimed that their TVL had surpassed uniswap's) and casted a doubt on the fairness of our metrics, as it turned out that the "staked tokens" were more like unvested tokens that hadn't been issued yet, so they were counting part of their FDV as TVL.
This is a bit of an extreme example, but it highlights a real problem with APIs. Even if changes are not like the one above, if suddenly something is added to the TVL through the API, it can lead to a jump on the TVL that is not real since TVL hasn't actually increased, it just that something that previously wasn't counted has been added.
Historical data
This only applies to chains where it's possible to query values at previous blockheights (EVM chains and Terra fit here but Solana doesn't), but usually APIs only provide the most current value, which is a problem since:
Instead, with on-chain adapters we can run them at old blockheights and get the TVL at different points in time, allowing us to fill our charts.
Snowball effect
Above I listed the fundamental reasons why we avoid this kind of adapters, but another secondary reason why we avoid them is that accepting API-based adapters creates a snowball effect where other people ask us to also accept their API adapters.
This mainly manifests in other people asking us why we won't merge their API adapter when we have merged other API adapters, thus accusing us of favoring some projects over others.
As you can imagine, this just grows bigger, as the more projects we merge with an API the less reasons we have to reject other API adapters, creating a negative feedback loop that forces us to either merge even more API adapters or reject them and look like dicks.
Exceptions
Beta Was this translation helpful? Give feedback.
All reactions