-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
Create scrt.js #60
Create scrt.js #60
Conversation
Why are you creating this pull request? Add Secret Network TVL adapter Twitter Link: https://twitter.com/SecretNetwork List of audit if any: Website Link: https://scrt.network/ Contact Email: info@secret.foundation Expected TVL: 82,781,198 Chain: Secret Network Coingecko ID (so your TVL can appear on Coingecko): secret Description/bio (to be shown on DefiLlama): Secret is the native coin of the Secret Network, a decentralized network for private / secure computation. Nodes on the network (known as secret nodes) can perform generalizable computations over encrypted data, which allows smart contracts (known as secret contracts) to use private and sensitive data as inputs. Our focus is on computational privacy, not just transactional privacy. Token address and ticker if any: SCRT
Thanks for submitting! I've noticed that all the tokens on the api endpoint come from ethereum. Do you happen to know how can we fetch those amounts using a web3 script (this would allow us to also get historical data on the TVL of the network)? |
That functionality is on our radar and we'll be updating to include it once the polkadot and BSC bridges are live in the near future. |
I've added a commit that removes two tokens from the calculation: uniswap's SCRT-ETH and wSCRT, the rationale for this is that:
With that being said, I'm not familiar with the exact details of SCRT, so if the uni tokens are being used in some way inside your chain (apart from just receiving rewards from a LP incentives) or I made some some wrong assumptions along the way feel free to let me know and I'll be happy to include it back. The same applies to wSCRT, if there's something I missed there let me know. In case you agree with these changes let me know and I'll merge this PR. Otherwise I'm happy to discuss, I'll also try to reply to everything quickly so that having a discussion doesn't mean that the listing of your project will be delayed. To be fully transparent, some of the projects on our site include pool2 inside their TVL, such as alchemix. The reason for this is that either we merged those PRs when we hadn't already decided against it or that we made a mistake. In those cases, we've chosen not to change the adapter after the fact in order to avoid "fake" sudden decreases of TVL, which could hurt these projects. In any case, we are working on moving all the adapters to be web3 based so that we can get historical TVLs and then replace the adapters with ones that exclude pool2 from them, but in the meanwhile we are trying to avoid adding any pool2-included tvls. |
I'll assume the lack of response means agreement with my previous message and merge this PR. If that's not true just let me know and I'll revert. |
Hey we are just discussing internally, will get back to you asap. thanks for your help |
Understood, I've reverted the PR for now as, if we list it in it's current state and then make changes to it later, the TVL graph will look jumpy and won't reflect real TVL changes. |
SCRT that is locked on the bridge is minted on Ethereum as WSCRT. The direction of the bridge operation is from Secret Network to Ethereum. Therefore it is TVL locked on Ethereum through Secret Network’s bridge. UNI LPs on the other hand (like any other ERC20 that is bridged, and therefore locked) are minted as SNIP20s on the Secret Network and are traded (for example on SecretSwap), sent privately on the Secret Network, and also will be used in future Secret Network applications as collateral. We therefore believe that both WSCRT and UNI LPs (similarly to any other ERC20) contribute to the proper TVL. |
Thanks for clarifying this, I thought it was the other way around. Regarding these assets, allow me to explain the multiple problems I see with them: WSCRTThe first problem here is the direction of locking, as generally we consider assets that go into your protocol as TVL, not assets that your protocol generates and are locked in some other protocol. I believe that a good analogy for this would be the following case: If YFI or a y-token gets locked in CREAM or Compound, would we consider that as part of yearn's TVL? I believe that the general consensus is that no, as that would be part of CREAM's TVL only. Isn't the case of wSCRT similar? Here we have an asset generated by the Secret Network that ends up being locked in Ethereum (and protocols within it, such as Uniswap). If we are currently not counting this for other protocols, doing it in the case of SCRT might lead to unfair TVL comparisons. Another problem is that this is the main asset of the protocol, which makes this similar to a multichain token migration, if not the same. For example let's take the case of BNB, you could argue that it is a native asset of Binance Chain, there's some supply on Ethereum and there exists a bridge which allows users to move these from one chain to the other. Should we consider all the BNB on Ethereum to be part of Binance Chain's TVL? The consensus seems to be that we shouldn't. You could also argue that BNB was originally built on Ethereum, so it's not the same, but there are lots of other cases of multi-chain assets where this is not the case and in none of those people would consider TVL part of the supply just because it has been issued on another chain. Finally, there's also the case of double counting, as we would be counting wSCRT both on the SCRT ported to Ethereum and the one on uniswap LP tokens. I don't see this as a big deal given that for protocols that deposit money on other protocols we are already counting that as TVL of both protocols, so if the only problem was this one I wouldn't have a problem merging the PR, however, this is also something that must be considered. I'm aware that there's an argument to be made if you consider the bridge as a standalone identity and say that, as a project on itself, it has money locked on both Ethereum and the Secret Network. However, you could argue the same thing about any bridges and we would end up with the same problems as presented above. Furthermore, I believe that the bridge is so closely interlinked with the network that they are inseparable. UNI LPThe pool2 tokens have been a big problem for us. Initially we didn't enforce any rule there so for some projects we listed staked pool2 tokens as TVL and for some other we didn't. It's pretty clear to see how this can lead to unfair comparisons so we decided to enforce a no-pool2-counted rule, meaning that for projects that have pool2 tokens locked in their contracts these won't be considered into the TVL. As mentioned before, there's some projects for which we do consider these, but these are mostly mistakes which we plan to fix once we finish the next version of our backend, which will make it easy to get repopulate historical TVLs. In any case, if we don't consider LP tokens locked inside some other protocols' contracts I don't see a compelling argument for considering them in this case, given that ported tokens would be less "locked" than tokens explicitly locked in contracts. The collateral exception was meant to avoid disfavoring projects such as bao finance, for which LP tokens are the backbone of the protocol and the TVL is composed of them. With that being said we have never applied this exception thus far.
Personally I believe that we can only base the TVL on the current status of the project. If we were to accept counting pool2 tokens on this case based on this possible future, then we would also need to go to the projects for which we've previously denied pool2 tokens and tell them that, if they tell us that they have plans for using them as collateral, we will accept them as part of TVL. Otherwise the treatment we give to the multiple projects wouldn't be the same. |
Thank you for your reply, we'll discuss it internally and get back to you as soon as possible with a response. |
Thank you again for your well structured comment, we talked about it and can follow your thoughts. Therefore, we would like to ask you to merge the PR again. Would it be possible to add wSCRT as a seperate asset? Would you prefer us to add it in a seperate PR? |
Will do!
Sure, I don't see a problem with it if we consider it as a sort of dapp of the secret network. Which name where you planning to use for it? Also, to be fully transparent, if in the future this is brought up as an example of differential treatment by a project wanting to just list part of it's token supply as TVL we might need to reevaluate this, but for now it's good.
I've gone ahead and written an adapter for it in #80. Could you verify that it's correct and fill the other listing data? |
Thanks again! We'll check #80 and add the listing data. |
Why are you creating this pull request?
Add Secret Network TVL adapter
Twitter Link:
https://twitter.com/SecretNetwork
List of audit if any:
Website Link:
https://scrt.network/
Contact Email:
info@secret.foundation
Expected TVL:
82,781,198
Chain:
Secret Network
Coingecko ID (so your TVL can appear on Coingecko): (https://api.coingecko.com/api/v3/coins/list)
secret
Coinmarketcap ID (so your TVL can appear on Coinmarketcap): (https://api.coinmarketcap.com/data-api/v3/map/all?listing_status=active,inactive,untracked&start=1&limit=10000)
secret
Description/bio (to be shown on DefiLlama):
Secret is the native coin of the Secret Network, a decentralized network for private / secure computation. Nodes on the network (known as secret nodes) can perform generalizable computations over encrypted data, which allows smart contracts (known as secret contracts) to use private and sensitive data as inputs. Our focus is on computational privacy, not just transactional privacy.
Token address and ticker if any:
SCRT
Category (Yield/Dexes/Lending/Minting):