Hey everyone, love the conversation that has been happening so far. I’m extremely involved in this and want to give my perspective:
At Toniq we’ve been building Bioniq for the past month. Bioniq is a BTC ordinals marketplace built on the Internet Computer. We’re building Bioniq as a native BTC application, meaning we won’t have ICP NFTs or ICP tokens available on the marketplace at all. ckBTC will be the native currency of the marketplace, and you will only be able to view/transact BTC ordinal NFTs on the marketplace. We are making fantastic progress, and if you haven’t seen the crazy traction around BTC ordinals, we’re really excited about the potential for Bioniq to bring a lot of positive attention to the Internet Computer.
In order for Bioniq to work we need a ckBTC solution, so I’ve been discussing with Dfinity over the past few weeks to try to come up with a workable solution that can be implemented quickly without sacrificing decentralization/security.
Over the past few weeks I’ve spent 20 hours on calls with Toniq AML legal counsel (Goodwin), compliance case management providers (Unit 21, Hummingbird, ComplyAdvantage), and KYT providers (Elliptic/Chainalysis) to try to come up with the best solution. The best solution in my mind (1) maintains decentralization as much as possible, (2) mitigates risk for all parties involved, and (3) is actionable and allows us to move quickly to a solution.
Just so everyone understands what I’m referring to, let me add a few definitions here:
KYT provider: a centralized service (like Chainalysis or Elliptic) to screen wallets/UTXOs for risky crypto assets. This can be called directly from a canister with an API key as the only centralized point.
KYT: know your transaction. Simply an API call to a KYT provider that returns a risk score associated with a particular UTXO or BTC wallet address.
Importantly, KYT has nothing to do with KYC. Users won’t have to provide any personally identifying information to interact with the ckBTC minter. In fact, the entire process (using a KYT setup) is still almost completely decentralized. There can be many KYT providers (decentralizing the KYT process) and these can be switched out as needed (further decentralizing the KYT process). The KYT piece is really isolated to the management and rotation of an API key.
So my final thoughts:
First, we absolutely need KYT as part of the ckBTC process in order to mitigate risks for everyone involved. Whether you are a dApp wanting to provide a frontend interface to wrap BTC to ckBTC, or you are a user that is interacting with the ckBTC canister, or you are part of the NNS that will be governing the ckBTC minter canister, adding KYT reduces risks for everyone involved.
Second, there aren’t really any additional risks by implementing KYT. You can always just get a new API key, new KYT provider, etc. These can even be added over time to further decentralize the KYT process. So we reduce risks for dApps, users, and the NNS by implementing KYT, and we don’t add any additional risks by adding KYT. The KYT process will be built to minimize the reliance on any single KYT API key or KYT provider.
Finally, on top of the ckBTC KYT process (which is absolutely needed) it is likely that Toniq will need to implement a KYT solution on our own frontend. Both pieces are needed based on the legal/AML/compliance conversations I’ve been having.
If you have questions, you can reply here, or DM me on Twitter (@BobBodily), or you can grab a time on my calendar here: Calendly - Robert Bodily. Thanks everyone.