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

Create scrt.js #60

Merged
merged 2 commits into from
Mar 23, 2021
Merged

Create scrt.js #60

merged 2 commits into from
Mar 23, 2021

Conversation

pmuecke
Copy link
Contributor

@pmuecke pmuecke commented Mar 17, 2021

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):

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
@0xngmi
Copy link
Member

0xngmi commented Mar 17, 2021

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)?

@pmuecke
Copy link
Contributor Author

pmuecke commented Mar 17, 2021

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.

@0xngmi
Copy link
Member

0xngmi commented Mar 20, 2021

I've added a commit that removes two tokens from the calculation: uniswap's SCRT-ETH and wSCRT, the rationale for this is that:

  • We don't count tokens on pool2 as part of TVL
  • AFAIK SCRT is a native token to your blockchain, so if it gets ported to ethereum (wSCRT) and then ported back I find it hard to consider that locked value.

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.

@0xngmi
Copy link
Member

0xngmi commented Mar 23, 2021

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.

@0xngmi 0xngmi merged commit cd2048a into DefiLlama:main Mar 23, 2021
@nocanvas
Copy link
Contributor

Hey we are just discussing internally, will get back to you asap. thanks for your help

@0xngmi 0xngmi mentioned this pull request Mar 24, 2021
@0xngmi
Copy link
Member

0xngmi commented Mar 24, 2021

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.

@pmuecke
Copy link
Contributor Author

pmuecke commented Mar 24, 2021

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.

@0xngmi
Copy link
Member

0xngmi commented Mar 25, 2021

SCRT that is locked on the bridge is minted on Ethereum as WSCRT.

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:

WSCRT

The 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 LP

The 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.

will be used in future Secret Network applications as collateral

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.

@pmuecke
Copy link
Contributor Author

pmuecke commented Mar 25, 2021

Thank you for your reply, we'll discuss it internally and get back to you as soon as possible with a response.

@pmuecke
Copy link
Contributor Author

pmuecke commented Mar 25, 2021

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?

@0xngmi
Copy link
Member

0xngmi commented Mar 25, 2021

Therefore, we would like to ask you to merge the PR again.

Will do!

Would it be possible to add wSCRT as a seperate asset?

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.

Would you prefer us to add it in a seperate PR?

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?

@pmuecke
Copy link
Contributor Author

pmuecke commented Mar 25, 2021

Thanks again! We'll check #80 and add the listing data.

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