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

Whitelabeled protocols #10566

Open
0xngmi opened this issue Jun 8, 2024 · 0 comments
Open

Whitelabeled protocols #10566

0xngmi opened this issue Jun 8, 2024 · 0 comments

Comments

@0xngmi
Copy link
Member

0xngmi commented Jun 8, 2024

The situation with veda and ether.fi is that veda wrote the contracts, deployed and manages a yield aggregator vault, which then it whitelabeled to ether.fi which runs UI and everything else. So effectively users deposit into an etherfi vault through etherfi UI and they only know of this as an etherfi product, but actually it's a whitelabeled protocol provided by veda.

In the past we've seen something similar with Algebra, which provided Concentrated Liquidity contracts for some DEX protocols, and what we did then was just count that TVL under the DEX protocol but mark it as a fork of algebra. And another similar case is when Alchemix deposited money into yearn finance, but in that case there was an alchemix contract depositing into yearn and users took risks on both protocols, alchemix and yearn (but at the chain level TVL is only counted once!). In this case however, there's only one contract, which has 2 names, and there's no double risk, for that reason I believe that TVL should be counted only once as otherwise it would be possible to just brand the exact same protocol in multiple ways and have TVL counted multiple times.

I would be fine with counting the TVL on either end, so ideally etherfi and veda can discuss among themselves and come up with a decision there, or if that doesn't work we'll make a decision ourselves.

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

No branches or pull requests

1 participant