Apologies if the following has already been answered: Is DFINITY not considering to take KYT services from an established KYT provider to resolve this for good? Arguably, from a (legal) liability stand point, given that IC/DFINITY is (indirectly) a business leveraging BTC as a part of its product/service offering, should it not solve the KYT issue at the point of entry of BTC into its system? Maybe someone who has a law degree can chime in, as my background does not qualify in this topic at all. I sincerely hope this can be resolved as soon as possible, and I’m sure lots of teams are hard at work on this blocker. Cheers.
Based on all the comments in this thread, there are solid arguments for having and not having KYT services implemented into the design of ckBTC. While many solutions similar to ckBTC are possible on the Internet Computer, DFINITY will propose one path forward and keep an open mind as a community to iteration and optimization as the journey continues. So without further delays, the next steps to complete the ckBTC rollout with a KYT solution will start this week.
TDLR;
- DFINITY will submit a proposal to upgrade the ckBTC minter canister (mqygn-kiaaa-aaaar-qaadq-cai) in the coming days.
- The canister upgrade will remove whitelisting and make converting BTC to ckBTC available to all principals.
- The ckBTC minter canister will make calls to a newly installed KYT canister to check for “tainted” bitcoin before minting.
- With this proposal ckBTC will be fully live, and the rollout complete.
Once again, the possibilities of ckBTC are endless, which is why releasing it with its full functionality as soon as possible in a way that provides a secure user experience is crucial. Incorporating KYT checks to the ckBTC process protects users from receiving “tainted" bitcoin and ensures that their bitcoin remains exchangeable on CEXs.
Implementation of KYT Checks that will be submitted as proposal to the NNS
Issuing: KYT checks are done on all incoming bitcoin UTXOs before ckBTC is issued. More specifically, the ckBTC minter canister will be able to call a Chainanalysis KYT canister to perform KYT checks using HTTPS outcalls.
Redeeming: Outgoing BTC transactions (when ckBTC is redeemed) are checked against a hard coded OFAC (Office of Foreign Assets Control) list. In the future, DFINITY plans to submit another proposal to use the KYT canister to also check the receiving bitcoin address when converting ckBTC into BTC.
About the KYT Canister
The KYT canister is to be handed over to the NNS, which means future updates to this canister will only be possible via NNS proposals. The KYT canister will accept a Chainanalysis API key from a designated principal. Initially, this designated principal – which is able to update the API key – will be controlled by Toniq. Changing the designated principal or adding other ones will be via NNS proposals.
Toniq has a subscription with Chainalysis and will pay for these calls. The ckBTC minter canister collects transaction fees that will be used to pay the designated principal(s) (for now just the one controlled by Toniq) for the KYT service. These fees are added to the conversion fees.
Next Steps
Acceptance of the proposal that will be submitted later this week means that the ckBTC rollout is complete. The ckBTC canister will be upgraded to allow all principals to convert BTC to ckBTC. And the KYT checks will allow users to securely transact bitcoin on the Internet Computer. In the future, the KYT canister may also manage the accounting for how the API key holder will be paid in ckBTC for providing a valid and active API key.
Vision
Many in this thread have questioned the values of the DFINITY Foundation and perhaps believe that incorporating KYT services compromises the decentralization of the Internet Computer. To this point, I can only reiterate that what is being proposed now is just ONE version of ckBTC. As the ckBTC canister is an application-layer smart contract, meaning NOT integrated in the protocol, there could be multiple versions of ckBTC on the Internet Computer, each with different rules and processes with or without KYT checks. The code is open source and the steps to deploy it are documented here.
As we navigate as a community through such challenging situations, decentralization remains the number one priority. Moving forward the vision is to have multiple KYT providers and API key holders as well as multiple ckBTC variants, including non-KYT canisters controlled by the NNS. While the ckBTC canister is currently controlled by the NNS, this could change in the future, e.g., to be controlled by an SNS. However, that will require a thorough design and take time to implement. For now, control by the NNS is the most secure and also fastest way to move forward.
19 Likes
Thanks Jan. Seems like we are almost there!
Practically speaking, how will one be able to convert BTC to ckBTC? Will it be enabled in the NNS front end at the same time as the feature is rolled out or will DFINITY rely on third party front ends to do the minting?
1 Like
A wise person accepts the decisions that they have no control of; it is with that premise that a lot of developers would still keep using the IC despite the KYT decision. However the dfinity team might need to ready periodically to answer questions about tainted BTC as new concerns arise. This might be due to new comers in the ecosystem not understanding the reasoning behind the ckbtc canister implementing KYT. Like personally I have a concerning question…, what does it mean to be hard coded to OFAC? Does it mean OFAC had a list of tainted BTC that was used in the ckbtc code? Does it mean that OFAC list is updated daily, weekly, monthly, yearly or on occasion per business need?
Would this go through a voting mechanism before being accepted by the NNS?
What does the future of KYT look like in simple terms? Just for clarification does it mean that the NNS would cancel transactions of tainted BTC? Or would the ckbtc canister cancel the transactions? I’m getting a confusion on the overlap of the NNS, the ckbtc canister and the KYT canister.
Also does that system have a future of having multiple agencies for the KYT canister; in such a way that there can be more than one regulatory body. Or would that result into a different ckBtc system? On the same concern is the KYT an immutable canister or mutable; does it allow for change to be made via voting through NNS?
Great questions @JxBrian.
Yes, the ckBTC canisters are controlled by the NNS, so the only way to upgrade them is via an NNS proposal.
The NNS only controls upgrades to the ckBTC canisters. The ckBTC minter canister calls the KYT canister to screen a transaction whenever a user wants to convert BTC into ckBTC. The KYT performs the checks by using https outcalls to the chainalysis API, and returns the answer to the ckBTC minter. The ckBTC minter then proceeds to create the ckBTC for the deposited BTC.
I think it’s definitely possible that we reach a place where we have eg 3 distinct KYT providers, such that 2 out of 3 decide, but no individual entity may block a transaction. Using different compliance checks for different users will be more difficult though: since the bitcoin backing ckBTC is pooled, we can’t have different screening rules for eg users from region A vs users from region B, because user A may retrieve the bitcoin deposited by user B. If we want to go in this direction, I indeed think having multiple instances of ckBTC is the best path forward.
Yes, it can be upgraded via the NNS.
Correct. When you have ckBTC, you can ask to convert it back to BTC at a specified bitcoin address. The ckBTC minter will check if the specified address is on the OFAC sanctioned entities list, and if so, reject the call. The user can then of course try again with a non-sanctioned bitcoin address. In the future, we plan to use wallet screening from the KYT provider here, such that the hardcoded list does not need to be updated super frequently.
3 Likes
I was reading this and thought it was reasonable and something I can get behind till I read the “Toniq has a subscription with Chainalysis and will pay for these calls.”
Does this mean there will be a single point of failure with Toniq?
What if their subscription ends?
5 Likes
They are paid per request made, so they are incentivized to keep this subscription going. In case they would stop doing the work, the NNS can upgrade the canisters to use a different KYT setup.
Incentives change, we’re assuming Toniq will always be in ICP
also I don’t know what the implications of this running out are, then waiting till the NNS can upgrade the canister, no user impact?
Besides, isn’t the whole Idea of ckBTC to remove unnecessary third party risk?
Is there a reason this isn’t coming from NNS directly or even Dfinity (Not the best solution but still better than third party)?
3 Likes
So a multimillion $ foundation cannot get a chainalysis subscription 
We should rename ICP to Toniq Computer Protocol, since they’re the only “builders” building on ICP according to DFINITY.
Better yet, we can submit a proposal to the NNS to handover the development of ICP to Toniq and fund them with DFINITY treasury.
Many are confused about the development and governance process of this protocol. Its only reasonable for users to know that DFINITY has already decided they’re paying ckBTC fees to toniq for gatekeeping ckBTC canister.
4 Likes
Look guys, this is the sort of stuff that makes people question impartiality or even judgement of some decisions within the ICP community - and this spreads like wild fire outside the community
You might consider this small but is big enough to campaign for public awareness over this
You guys are smart, you know the obvious problem with this
-
Why do we now have to rely on a third party to manage a component of ckBTC?
-
(Sorry in Advance Toniq) We all know the period of non response from toniq to projects last year - if there are issues which Toniq needs to be present to solve - what then? They’re a self admitted small team unable to focus on all of their deliverables - Cronics investors are pissed that they cant deliver their promise of the game when a lot of ICP was put in by investors at PEAK bull run and now we want to add them as a layer of reliance on ckBTC, an essential chain level service
-
Toniq gets paid per Transaction - I can basically Guarantee that other builders on this eco will BID for lower payment. Not saying this is what you should do, but what makes Toniq special? Someone in Dfinity trusts them?
Isn’t trust what we’re trying to eliminate?
-
Dfinity already has control of ICP(Lets not argue semantics) - so it really doesn’t make sense why at WORST Dfinity controls the subscription?
a) It doesn’t really increase the number of parties needed to be trusted
b) You definitely can afford it
c) Dfinity is the strongest of all the stakeholders on ICP - at this point, you literally ARE ICP
d) If there are issues - you can move faster and turnaround time is quicker -
Why cant the NNS control it? is there some barriers to this?
-
What exactly is the impact if subscription runs out?
-
How long is the turnaround in case it runs out and we have to essentially DEFINE another KYT at that point, design and release?
-
What happens in the mean time to people who hold ckBTC or people who are reliant on services using ckBTC and need to mint?
I hope this gets the attention it deserves before it goes to a proposal
Hope everything I’ve mentioned is reasonable talking points
12 Likes
@Manu @Jan is any of this going to be adopted via governance proposal or is DF sticking with technical proposals?
I understand that the current ckBTC canister design was adopted before deployment; so I can see an argument for just using technical proposals.
Am I understanding your statement correctly; DF is planning to set the NNS as the KYT canister controller without requesting stakeholder approval via governance motion proposal?
Great questions. I am as equally puzzled why Toniq is involved at all in this set-up.
5 Likes
TL;DR: Thx! Also m-to-n please 
First, congrats on the KYT resolution, and fasttracking this issue. This is especially something to celebrate for startups w/ short runways remaining, in an economic downturn, who’ve bet it all on BTC@IC. Kudos to DFINITY for coming this far. Now the constructive critisim, if i may: Why Toniq (or any single corp.? Most of us know how the foundations work in Switzerland and elsewhere, thereby limiting what a foundation can and cannot touch. For example, for Polkadot, there are two entities: Web 3 Foundation in Zug, and Parity headquartered in Berlin, similar duos for all the big names out there. What’s the equivalent for DFINITY, is it Toniq, maybe it is, I just didn’t know. Within the foundation legal framework, a vetted entity or set of entities (nothing against Toniq of course) that will by default be on IC&DFINITY’s side 24x7x365, no matter what happens, in my humble opinion, should ideally have KYT 3rd party subscriptions with multiple providers. The multi-provider approach is also for technical reasons, for non-adverserial purely technical risk mitigation, for example no respectable service provider relies on just one 3rd party provider etc, Chainanalysis going down shouldn’t bring ckBTC down, there are other high uptime & credible KYT service providers out there. I believe in DFINITY, I’m certain they’ll do the best for us, we’re all on the same boat. Regards.
3 Likes
I mentioned how Dfinity can decentralise HTTP out-calls, they need an API key per node. Each API key can be held by a different party, they have yet to acknowledge that HTTP outcalls are not decentralised without this feature.
4 Likes
With all due respect, if Toniq need KYT for whatever they’re building, then they should pay all subscriptions needed for that product. This has nothing to do with Dfinity or any of the rest of us. Toniq needs should be met by Toniq. Basta.
If Dfinity have a need for an API key or subscription (regardless of whether we agree or not - I’ve left that debate) then Dfinity should pay for it and manage it. Basta.
I fail to see why Dfinity relying on Toniq to maintain this subscription is a good idea - unless it’s being implied that Toniq are somehow linked to the provision of the ckBTC canister, which I believe they are not.
This is a risk for Dfinity and anybody using the ckBTC canister or intending to support ckBTC. That risk should be covered by Dfinity and not by another third party, whether Toniq or anybody else, unless that third party is responsible for the ckBTC canister.
7 Likes
At Genesis the one part of the ecosystem I was most optimistic about, where the IC had a huge advantage out of the box, was NFTs. And Toniq had a headstart as the leader in that space within the IC. Nearly two years later, Entrepot is ranked 471 in marketplaces and the IC is not even mentioned on the home page of the dappradar NFT marketplace tracker where two dozens blockchains are listed:
https://dappradar.com/nft/marketplaces
The failure to build a thriving NFT ecosystem is for me the single greatest disappointment of the IC to date, and the biggest proof that great tech does very little good by itself.
Why give Toniq such an important responsibility, although I have no doubt about the the organisation’s sincerity of purpose? It sounds so ad hoc: someone has a subscription to a service so we will just entrust this important job to them.
3 Likes
A couple questions and points:
Why is the screening process different for BTC → ckBTC and ckBTC → BTC? Why a KYT provider for incoming but a hard-coded list for outgoing?
Was there legal research done behind the scenes to get to this design? Can you publish the research so that we the NNS voters can also make informed decisions based on the research?
The biggest concern I had as I was reading the final proposal a few comments back was the Toniq dependency. This seems strange. I understand it’s probably quite difficult to overcome the single API key and need for a subscription from a single legal entity, but can we have this discussion and try to come up with a better design?
For example, imagine a simple round-robin or random beacon-based design that chooses from a list of canisters that have legal entities with KYT provider accounts and API keys. Each entity on the IC wanting to provide these services could register with the ckBTC or KYT canister. Registration would prove an active API key with a provider. Then on each request to mint or redeem, one of these providers is selected and the fees are paid. If we had a handful of entities this would obviously remove central points of failure, and allowing anyone to create one of these KYT API provider canisters would perhaps allow us to create a market for it.
13 Likes
There is also the issue of vetting these KYT providers to make sure they’re doing what they claim - but that’s probably one for after we agree on approach
Love the idea
I think we need an answer as to why the Foundation chose Tonic. But the defeat at ICP NFT is irrelevant to the current agenda (it is the infrastructure that prevents ICP NFT from behaving like EVM).
CCC, Hatch, canistore… There were many marketplaces. What happened to those?
I don’t think the foundation loves Toniq, I think it trusts Toniq’s track record of being the best contributor to the foundation’s ecosystem from the past 2 years to today.
Giving rolls to members who can take action is also a DAO, it is not centralized.