Could be something like for 1 BTC, 1ckBTC is generated, with 0.999ckBTC going to the user and 0.001ckBTC going to a charges collections account but still within the ckBTC circulating supply, not burnt. So still 1:1.
1 Like
Yes this is exactly how it works. 1 BTC in 1 ckBTC out, but .999975 ckBTC to the user and .000025 ckBTC to fees (assuming $0.50 fee).
4 Likes
Would this KYT apply for the ckETH minting aswell?
Based on the legal and compliance research I have done, I think you either block US citizens from using your platform, or you use KYT to ckBTC, ckETH, ckUSDC, etc. Applies to everything I think.
(not legal advice)
2 Likes
Didn’t know this, Thankyou!
1 Like
That’s a very dictatorship mentality; If it’s not this way it’s no other way.
Does it help having a European KYT provider, or Chinese KYT provider or for incorporation of
any BTC conversion there has to be an American KYT provider or business is halted!
1 Like
I apologize if I missed it, but was this problem ever solved? Is the hope still to maintain an exact 1:1, or just to get something functionally close enough?
The two problems I’m asking about are:
- What happens when ckBTC calls on tainted BTC that is labelled post-conversion?
- Given that ckBTC is liquid and will naturally be lost over time in an open system, what happens to the BTC that accumulates in the canister as a result?
Is the plan to have these disparities offset one another? Is the bad BTC tagged and sent to the bottom of the barrel?
Again, I apologize if I missed something. This thread has become quite lengthy and somewhat discombobulated.
Based on my understanding:
- You don’t KYT the ckBTC on the way out (since you did KYT on the way in). You only KYT the destination address to prevent the protocol from sending BTC to a high risk destination. The withdrawer can always just input a different address to receive their BTC. This means there will always be an exact 1:1 BTC <> ckBTC.
- This is a great question. Likely locked in the protocol forever in its current implementation due to the exact 1:1 nature of BTC <> ckBTC.
1 Like
Sorry.
I was wondering, what is the benefit of attacking a single point of failure in KYT?
If Toniq has centralized control over the keys to the ckBTC canisters, that is a big problem, but my understanding is that KYT is a function to check for tainted BTC, not a function that should be at risk of BTC being hacked from the wallet due to a vulnerability in KYT.
My conclusion remains the same for the concern that Toniq’s KYT not functioning properly could bring ckBTC to a halt, and I think the best course of action is to diversify by adding more potential new providers.
Sorry if I am wrong in my opinion. The thread has grown into a business discussion and I still don’t understand what you are talking about lol
2 Likes
thinking of a problem that hasn’t happened and finding a solution is a waste of resources and time, focus on promoting ckbtc to get more people to use it before thinking about anything else
Alternatively, it seems possible to create a CKBTC canister without KYT. dfinity understands the risk of publicizing a canister without KYT, so the creation of such a canister from an anonymous user should be welcomed.
I’d like to direct you to the OP from @Jan where he explains the proposal. There is nothing in the proposal about handing Toniq the keys to the ckBTC canister. Nor will they have access to the BTC. I know it is very confusing at this point due to the sensational responses that have thoroughly populated this forum post. Here is what Jan included in his proposal that addresses your concern…
The proposal is to hand over the KYT canister to the NNS and to designate Chainalysis as the first KYT provider. It is also to gives Toniq the ability to change and update their API key, which Chainanalysis requires to perform the work of KYT. Chainanalysis is performing the KYT work, not Toniq. Neither Toniq or Chainanalysis has access to the BTC. Toniq controls nothing more than their own API key for Chainanalysis. The NNS will control the KYT canister and the ckBTC canister.
@jan also addresses your other concern in his original post.
As @bob11 explained previously, they have a 1 year subscription for the Chainanalysis KYT service. Hence, there is no reason to believe that would fail in the next year. During that time there will likely be more KYT provider and more API key holders added to the KYT canister.
If anyone is still confused about the proposal, then I highly recommend going back to post 164 in this forum thread to read what @jan actually wrote. Then you can focus on all the posts made by @bob11 because he selectively responded to a lot of good questions that needed clarification. At that point you will be caught up without having to fuss too long with the rest of the drama that flooded this thread over the last 2 days.
2 Likes
@wpb , I truly appreciate your efforts on behalf of the community and was disturbed to see you attacked personally during the Treasury debate. I am sorry to see you now doing the same yourself, though admittedly in a much milder form.
The fundamental point is that we are in crypto mainly because of a set of principles. When those principles are compromised in the name of efficiency, my reaction is, well, what’s the difference from fiat, then?
It is worth going to extraordinary lengths to ensure a system is decentralized, publicly auditable, and transparent. To begin with, ckBTC is inadequately decentralized (too few nodes and since nodes have no enforceable contracts and no stake in the future of ICP, a big incentive to collude and steal BTC once TVL is high enough. This is bound to happen, it is only a matter of time).
Second, the mandatory addition of KYT makes the network beholden to US policies, which are opaque and often unfair. It would have been far better to add KYT as optional and keep the NNS free of US interference. Dfinity could have ensured KYT was available before the rollout in order to safeguard users without getting the NNS involved.
The reason the post about Toniq led to such an outpouring was because it was a bit like the straw that broke the camel’s back. In and of itself it may seem minor. I could get on board the fact that anyone can start a KYT of their own, even though it probably won’t pay for itself, and the more ckBTC KYT providers there are the more expensive it will be for each individual provider because queries get cheaper by volume. At least in principle it could get more decentralized over time.
It was the way in which all this was handled, and the fact that Dfinity pretends the NNS is already a functional democracy, so an NNS vote is a post-facto justification of any arbitrary decision, which stuck in my throat, because an NNS vote is currently like the last Russian election. Since everyone knows the vote is a foregone conclusion, the only way to affect anything is to change Dfinity’s mind, which is why people are getting worked up on this forum.
You have a particular perspective, which is a valid one. Please allow that the opposing view is not just a case of jumping the gun after misreading Jan Camenisch’s post, it is valid in its own right.
6 Likes
These are fair comments.
2 Likes
The moment it is opened, someone will send in 211 tainted BTC to “clean” it. Future proof design is important.
As a future improvement, I think the designated principle should add/update key only via a proposal, so that they cant just walk in and tamper with their key. Also if possible to display key expiry dates on a dashboard that would be a good thing for transparency.
2 Likes
Hey guys, I’m the Toniq CTO and co-founder, and I just wanted to comment on a few things here. Firstly, I understand where people are coming from. I’m a true believer in decentralized tech and try to push out against centralized barriers as much as I can. So lets get into it!
Let’s get ordinal, baby!
When we decided to go down the Ordinals marketplace route, we knew we wanted to use some form of wrapped BTC. At this point, ckBTC wasn’t a good solution for us; one reason was because public minting was not enabled. So at this stage, these were our options:
- Fork ckBTC (lets call it wBTC for the purpose of this post)
- Discuss with dfinity regarding timeframe of public minting for ckBTC (using ckBTC was our preference)
What’s the hold up? KY-whaT?
We then reached out to dfinity to ask when public minting would be available, and found out that the issue was a concern around KYT (hence no public minting). We left this with dfinity and we removed ckBTC from our list of options because it did not seem viable. Due to the conversation, we did some research ourselves and were informed by our legal team that we would need to perform KYT as well. What a bummer.
So wBTC was our only option, but now we had to develop a KYT step. At this stage we thought we would be building the KYT element from scratch. These were our options:
- Fork ckBTC, but develop a KYT step into the process
- Build wBTC in motoko with KYT from scratch
Good bye ckBTC, hello wBTC
Forking ckBTC meant Rust, and we are mostly a Motoko dev shop so we would need to hire additional help. Building from scratch in Motoko was a big undertaking, so we were looking at both options. We also begun speaking with different KYT providers, reviewed API spec, and worked on what would be wBTC.
At this stage we were not aware of the state of ckBTC with regards to KYT, or that being KYT provider was even an option, and there had been no communication about working with dfinity on ckBTC.
Back from the dead…?
About 3 weeks ago, Bob and I jumped on a call with members of the ckBTC team. During this meeting they shared their progress with the KYT canister and the whole process of having KYT providers. It looked like they were close to having this complete, and they had already built support for ChainAnalysis (which was one of the KYT providers that we had shortlisted for wBTC). I personally didn’t expect dfinity to be this close to having a complete solution.
Toniq as a KYT provider was used as a hypothetical of how it could work, but no commitment was made. Internally, we were still considering deploying our own wBTC due to a different issue we had with ckBTC which made it less viable for us. A few days later this forum post was created.
To be, or not to be…
Being a KYT provider for ckBTC meant we would need to use ChainAnalysis (as that’s what the KYT canister supported), we would have to sign on to an annual contract and pay an upfront cost. dfinity had not found a KYT partner at this stage and would not go live without one. We decided that we would be in a position to be a KYT provider, and communicated this to dfinity.
For us, this would mean we did not need to deal with developing and deploying our own fork, and could help to bring the OG ckBTC online for everyone to use. This was a few weeks ago, and within the last week we signed a contract with ChainAnalysis.
If we were not a KYT provider for ckBTC, or if ckBTC was to delay deployment, we would instead continue with our plans to deploy wBTC and blackhole the canister. We would plug our ChainAnalysis API key in, and we would work with other devs to integrate it with as many other projects as we could. We would ultimately be left with a fragmented ecosystem (two identical ckBTC instances, or just wBTC if no one came on board as a KYT provider).
Now, I understand some of the arguments being said, so I thought I should clarify the following:
- Are we making a profit from being a KYT provider? No - fees charged would be to cover costs incurred by ChainAnalysis.
- Why are we doing it then? Because we want an on-ICP BTC token for our marketplace, and we believe it would benefit other devs/services too
- Why don’t we deploy your own fork? We could, but we did not want to fragment the ecosystem
- Did we plot with dfinity in secret to be the sole KYT provider? Not in my opinion. We found out about some information days before it was posted here, although I think it may have already been public via other channels (public dev meetings etc). We were not considering being a KYT provider until a few weeks ago and forking was a very real possibility for us.
- Can’t we just remove our key and kill ckBTC? If we removed our API key, ckBTC would function as it does right now. No one can wrap. I believe unwrapping is still available, and transfers will still work (as they do now). ckBTC would then be waiting for someone else to get an API key, and apply to inject it. We wouldn’t be switching it off, just back to how it is right now (no public minting).
- Can’t we selectively choose how to analyse each deposit (letting bad BTC in)? No. We simply provide an API key. This key lets the KYT canister use our ChainAnalysis account to complete KYT. We have no control over the KYT process or outcome. This is like giving someone your credit card - I can’t selectively decline payments, as payments come directly from my bank. I can take my credit card back off you though.
Sorry for the long post, but I hope this helps. Happy to answer any other questions too.
On a side note, it wouldn’t be hard to create (using Threshold ECDSA) an IC service that enabled swapping between ckBTC and BTC without KYT. LP’s would be accepting the risk that they may receive tainted BTC in exchange for their clean ckBTC, but market forces may then set the price at a premium to compensate this. Users that did not want to go through the KYT process could then use this swap to exchange their BTC for ckBTC, which could then be used through the IC ecosystem. Just a thought.
13 Likes
Imagine trusting Toniq Labs again 
Theguy and whoever that wanted to become KYT provider have finally STFU after hearing that they need 5 figure upfront . Lmfao . A 5 figure upfront risk with zero profit .
My question again … So who’s willing to become provider now ? Alot of talk but no action .
Your question is 3 or 4 weeks late. Scroll up to see what other ideas have been proposed for this bs.
1 Like