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

feat: add karpatkey #6690

Closed
wants to merge 8 commits into from
Closed

Conversation

mariano-aguero
Copy link

@mariano-aguero mariano-aguero commented Jun 30, 2023

NOTE

  • If you would like to add a volume adapter please submit the PR here.
  • If you would like to add a liquidations adapter, please refer to this readme document for details.
  1. Once your adapter has been merged, it takes time to show on the UI. If more than 24 hours have passed, please let us know in Discord.
  2. Please enable "Allow edits by maintainers" while putting up the PR.
  3. Sorry, We no longer accept fetch adapter for new projects, we prefer the tvl to computed from blockchain data, if you have trouble with creating a the adapter, please hop onto our discord, we are happy to assist you.
  4. Please fill the form below only if the PR is for listing a new protocol else it can be ignored/replaced with reason/details about the PR
  5. For updating listing info It is a different repo, you can find your listing in this file: https://github.com/DefiLlama/defillama-server/blob/master/defi/src/protocols/data2.ts, you can edit it there and put up a PR
  6. Do not edit/push package-lock.json file as part of your changes, we use lockfileVersion 2, and most use v1 and using that messes up our CI
  7. No need to go to our discord and announce that you've created a PR, we monitor all PRs and will review it asap

Name (to be shown on DefiLlama):

karpatkey

Twitter Link:

https://twitter.com/karpatkey

List of audit links if any:
Website Link:

https://www.karpatkey.com/

Logo (High resolution, will be shown with rounded borders):

Avatar

Press kit if necessary https://drive.google.com/drive/u/1/folders/1-RaGdsneMJ1sznUkzBw2CCWlLlO_EAJB

Current TVL:

xdai: 13.13 M
ethereum: 104.93 M
total: 118.05 M

Treasury Addresses (if the protocol has treasury)
Chain:

Ethereum
Gnosis Chain (xdai)

Coingecko ID (so your TVL can appear on Coingecko, leave empty if not listed):
Coinmarketcap ID (so your TVL can appear on Coinmarketcap, leave empty if not listed):
Short Description (to be shown on DefiLlama):

We help DAOs to preserve capital through state-of-the-art risk management and trust-minimised DeFi treasury execution.

Token address and ticker if any:
Category (full list at https://defillama.com/categories) *Please choose only one:

7 - Services

Oracle used (Chainlink/Band/API3/TWAP or any other that you are using):
forkedFrom (Does your project originate from another project):

No

methodology (what is being counted as tvl, how is tvl being calculated):

karpatkey manages funds through its non-custodial platform by means of the Zodiac Roles Modifier module

Github org/user (Optional, if your code is open source, we can track activity):

https://github.com/KarpatkeyDAO

@llamatester
Copy link

The adapter at projects/karpatkey exports TVL:

ethereum                  105.07 M
xdai                      13.14 M

total                    118.20 M 

@mariano-aguero mariano-aguero changed the title Adding karpatkey feat: add karpatkey Jul 3, 2023
@g1nt0ki
Copy link
Member

g1nt0ki commented Jul 3, 2023

hi @mariano-aguero,

Sorry, I am waiting a bit for what rest of team members think, unlike other products where single protocol has control over the funds, when they are in gnosis wallets, it gets tricky.

@g1nt0ki g1nt0ki self-assigned this Jul 3, 2023
@sgzerbo
Copy link

sgzerbo commented Jul 3, 2023

Hey @g1nt0ki!

I understand the issue. Just in case, I wanted to clarify the way karpatkey manages funds. It's not that funds are simply held in a safe contract, but we deploy a contract (Zodiac's Roles Modifier module) through which the safe holding the funds grants fine-tuned granular permissions (developed here by karpatkey) to a karpatkey safe that executes transactions on behalf of the original safe. This is the principle by which our non-custodial asset management platform works, despite the funds not being deposited in a particular karpatkey contract.

@g1nt0ki
Copy link
Member

g1nt0ki commented Jul 6, 2023

@sgzerbo sorry, we cant count it as tvl (for now), I think what you have created is cool and much needed infra, but counting it as tvl opens pandora's box imo (and rest of the team agrees). when multiple modules are linked to a single gnosis safe, to whom does the tvl belong (another PR with similar issue: #6097)

This is a good metric, we will try to find a solution/workaround to show this but it will take some time :(

@sgzerbo
Copy link

sgzerbo commented Jul 6, 2023

@g1nt0ki I understand the rational :(... On the other hand I would urge you guys to find a way to show these metrics (we'll be patient :) ). Our assets under management with our infra currently amount to ~360M consisting of several DAO tresauries which represents a vote of confidence in our tech, and we only hope this number to increase. We'd be delighted to see this data reflected in defi-llama

@JKtranslator
Copy link

Hello @g1nt0ki, bumping this conversation, I would like to check with you and the team this:

In karpatkey's solution, as mentioned in a previous comment, the Avatar (a 1 of 1 Gnosis Safe controlled by the DAO) grants permission to another Gnosis Safe (controlled by karpatkey) to act on its behalf on a strict list of operations (the preset list of actions).

This transaction can be tracked on-chain, so it is possible to verify that the TVL is linked to karpatkey, even remaining non-custodial. If we provide, as a comment, in the adapter, the tx where that happens for each DAO address that karpatkey manages, would this ease the concerns about to whom the TVL belongs?

For example, in our commit, this address from ENS DAO (0x4F2083f5fBede34C2714aFfb3105539775f7FE64), granted permissions to our address (0xb423e0f6E7430fa29500c5cC9bd83D28c8BD8978).

As those funds are actively managed and invested/deposited in other protocols, it doesn't seem to be an issue to have the "double count" on it.

Is this a valid angle, or do we need to think about something else?

@karpatkey karpatkey closed this by deleting the head repository Nov 29, 2024
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.

7 participants