Do ckBTC transactions show up as tvl for ICP?

[Agnostic]

The amount of ckBTC is gradually increasing on ICP. I wonder if any of this information is being picked up as tvl for ICP. It would be nice to have ckbtc txs show up on third party analytics sites as part of ICP tvl.

On X, someone said this:

O.aye

Is this correct?

Others have posted about this like @bob11 :

@bob11

Yeah this is interesting. I do like this idea. Increases TVL numbers and is accurate, in that there are many assets being controlled by the Internet Computer Protocol that should count as TVL.

The implementation here feels a bit complex, but I would like this information to show TVL growth of cross-chain assets on ICP.

In fact, this is probably my top number to watch with the Chain Fusion thesis. I think this is the number we care about most. Chain Fusion success = total TVL of all cross chain assets on ICP. So this number should be tracked and should be used to determine success of all chain fusion initiatives.

And @marc0olo

@marc0olo

First, I was only thinking about exposing the TVL of BTC secured through ICP via Chain Fusion only. But this discussion should be broader as Chain Fusion can be used to secure different assets across multiple chains.

For that reason I think it would be great to define a standard how we can allow developers to let their Canisters verifiably expose the TVL they hold.

But was any of this implemented yet?

[marc0olo]

@Agnostic

Is this correct?

not sure what he meant with his post. I responded on X and made clear that the amount of ckBTC is the minimum amount of BTC secured via ICP and that it could be more.

@Agnostic

But was any of this implemented yet?

somehow nobody really stepped up yet to work on this. and even if we have it, it would most likely “just” be a standardized way of doing it (e.g. clear rules about derivation paths). ultimately a developer cannot be “forced” to expose the amount of BTC/ETH/… their canister really controls.

sidenote: there is currently an active grant in that regard to research and evaluate different options to expose TVL of canisters

[Lorimer]

@marc0olo

amount of BTC secured via ICP

Hey @marc0olo, given what’s been happening recently regarding exploits in third party dapps built using chain fusion, it may be worth clarifying what’s meant by ‘secured via ICP’.

Confusion or lack of clarity here can lead to videos like this (click to expand)

$ICP - DEX HACKED (again??)

Standard to expose verifiable TVL of assets secured by ICP (Chain Fusion)

I think it would be worth fleshing out what it means for chain fusion assets to be secured by ICP, and what guarantees that provides users, and what guarantees it doesn’t. TVL (total value locked) is a different concept as far as I understand. Messaging and clarity is important here. The IC cannot really account for what less experienced or less methodical devs build on top of ICP using chain fusion.

[marc0olo]

@Lorimer

it may be worth clarifying what’s meant by ‘secured via ICP’.

with “secured via ICP” I mean that the native tokens (BTC, ETH, …) are held in accounts that are “ultimately” secured through ICP by utilizing threshold signatures.

however, the derived key material is of course depending on the master key which is unique for each canister and controlled by the canister. and it is very important to understand that the controller of a canister has ultimate control over all the derived keys because the controller could potentially update the canister code anytime. so even if the code in the present is secure, that might not be the case after an update.

the controller of a canister could be a single user, multiple users, a multisig setup, another canister, an SNS or the NNS. a canister can also be blackholed (no controllers) if that is desired, but making that decision should be taken carefully.

when taking the ckBTCminter as an example, the controller of the BTC that are “secured by ICP” (via the canister accessing threshold signature APIs) is the NNS. so nobody can easily “just upgrade” the canister code. typically DFINITY proposes updates to that canister and these need to be accepted by the NNS.

it is also very important to understand that ckBTC is “just” an ICRC-1/2/3 ledger on ICP which is controlled by the ckBTCminter canister. the native BTC are always controlled by the ckBTCminter canister in this case.

now, while it is a clear difference whether canisters are using threshold signature APIs directly to control assets on other chains natively or whether canisters control deposited funds of ckBTC on behalf of users - the problem is the same:

• if the canister code that accesses threshold signing APIs or controls ckBTC on behalf of users has security flaws, the funds are at risk!

some people might not care too much about this, while others do. ultimately it is a decision of the enduser whether they want to trust the team (and code) behind a project or not.

projects should ideally:

• set up a multisig setup to control their canisters
• aim to get their code audited / peer reviewed
  • publish the audit(s)
• provide instructions for reproducible builds (if the source code is public)
• make their canister upgrade history transparent

… especially if they deal with financial assets.

this in turn is not feasible for every project and requires additional effort and expenses. IMO the bare minimum we could expect is a solid multisig setup for the controller.

[marc0olo]

@Lorimer

Confusion or lack of clarity here can lead to videos like this (click to expand)

yeah … seem to be lot’s of misunderstandings on that. only navigated through it quickly.

[Lorimer]

Do you think it could be worth making it easier for users to see when services they’re using do not conform to these standards?

This would help the IC avoid reputational damage. I suspect there will be many more hacks ahead. Not because the IC is insecure, but because you can’t control what people build and use on top of the IC. The protocol and/or dashboard can help people make more informed decisions though.

I think it would also be worth including a disclaimer like this in promotional material that describes the IC and/or chain fusion as immune to hacks.

[frozenapple]

@marc0olo

sidenote: there is currently an active grant in that regard to research and evaluate different options to expose TVL of canisters

Hi there. Yes, we will start working on this soon and might circle back to this thread in a couple weeks (I’m glad it’s relevant!)

[marc0olo]

@Lorimer

Do you think it could be worth making it easier for users to see when services they’re using do not conform to these standards?

sure, I am absolutely advocating for this in different threads and independent discussions. I think we will get there over time, actually we have to IMO