Thank you for the response @manu. I’ll try to do my best to answer. Please know that I have no experience with finance or running a business so this is just me trying to come up with an approach that seems reasonable.
I agree this is the case and I think there are many projects that would love to benefit from this level of security and exposure. However, since DF is just another contributor (granted, the largest) it is my opinion that their products should have to work with the same tools as other organizations that contribute to the network’s development and growth.
I was actually thinking of something more along the lines of a DAO that governs all of the DFINITY’s future non-protocol products and not just ckBTC. Re: value of the token, I do think there is value in being allowed to more directly influence DFINITY’s development plans and roadmap. I think there are many devoted followers, both developers and users who wholeheartedly believe in DF’s vision and would be willing to participate in a DF SNS decentralization sale.
Alternatively, is it not possible to have an SNS whose governance tokens are bit more controlled so that DF can choose who to distribute them to? Perhaps they could be divided proportionally amongst the DF executives and their employees and used purely for governance without any implied monetary value.
I don’t believe either of these would be ideal at this time so I won’t try to justify them.
To piggy-back off of this - the ckBTC canister is on an application subnet (one of the new fiduciary subnets), and NOT on an application subnet. This means that the application pays cycles just like any other canister and is not at the “protocol” level.
DFINITY will be doing the majority of the work here, so it’s not THAT hard for a developer to take the code, strip out the KYT, and spin up a nice UX/DevX in front of it.
That being said, I don’t believe that the the ckBTC canister should be managed by the NNS. It should be a DAO of it’s own (maybe SNS), with investors that dictate the direction of the KYT portion and other features.
Tagging @dymayday@JxBrian@Jonathan@Maxfinity@bitbruce and a few others. This is a huge opportunity for the community, at little development cost (although you will be taking on large regulatory risks).
In fact, I’m 95% sure at this very moment @spnrapp or some other projects are doing this exact thing, so you won’t have to wait long for a no-KYT ckBTC canister.
Technically anybody can put things under NNS control. It’s just a question whether people would want to vote on proposals for that canister.
Interesting idea. I’ll think a bit more about it. I don’t think we can have a fully baked idea very soon, but perhaps it is a good option to start with ckBTC under NNS control, and eventually move it into something like this.
That’s a fair point. It is technically possible for anyone to set the NNS as their canister’s controller. The difficult part would be convincing the parties with the most liquid VP to care about their technical proposals.
I don’t have much to add, but wanted to say that I both like and am eager to see where the thread between @Manu and @LightningLad91 goes. I appreciate the honest discussion of trade offs about the canister governance.
We had some discussions at ETHDenver about dropping an SNG (SNS governance) to every neuron at some date based on VP. Maybe also to ICP holders? To claim you need to submit your principal which we can use to rebuild the ledger in an ICRC3 style with principal/subaccount.
Then, orgs and citizens that feel it is a violation of their local laws to approve SNS tokens can divest their tokens to other users that want the SNS voting power.
Whether ckBTC goes under this governance is another discussion.
What if the ckBTC were itself the governance token?
Owners could then democratize their own KYT by voting on the providers they want to adhere to or those they want to give the boot. This will give them leverage over abusive KYT orgs and even enable them to label what is dirty and what is clean on a case-by-case basis themselves. Or they could construct their own crowdsourced listing and ignore KYT orgs entirely.
This way the KYT is internally controlled, managed by the parties who care most about BTC, and immune to hostile takeovers.
I fully agree with @Zane and the others on this matter, the default ckBTC canister should be kept non-KYT in order to maintain it a neutral token that doesn’t pander to any specific government. Then developers concerned with US regulations should build their “usBTC” version, those concerned with regulations coming from China should build their “chBTC” version and so on.
I want to echo and extend @LightningLad91 's point that application level canisters should not be managed by the NNS.
I don’t believe the NNS should be making decisions about application level things.
It undermines the neutrality of the platform and discourages third parties from developing applications.
It increases the legal risk to NNS participants.
If we vote to not implement KYT. Then by virtue of having 8 year locked neurons I am forced to be part of a joint enterprise that could be accused of facilitating money laundering and sanctions evasion. Given what happened to Alexey Pertsev this is a very serious matter.
If we vote to implement KYT we have shown that we have the willingness and ability to intervene in application level things. We will come under more and more pressure from authorities and other actors to act to freeze assets under our control including both ckBTC and IPC. We open ourselves up to personal liability for both action. (holders of frozen assets could sue the NNS) and inaction (owners of stolen assets could sue if we fail to stop hacked funds moving).
I am comfortable voting on protocol level stuff but I absolutely do not want to be responsible for application level stuff like ckBTC.
I would therefore prefer either
The option as suggested by @skilesare where Control of ckBTC and other application level things to be passed to separate SNS (s). The tokens controlling these applications should be airdropped to NNS participants / all IPC holders with no enforced lockup so that we have the opportunity to divest ourselves of liability and responsibility and not be forced to participate.
The code for KYT implemented but the ckBTC canister shut down and it left to the community to launch different kinds of ckBTC and the freemarket to decide.
I’ll say this about the SNS and what the DFINITY team has pulled off: A few weeks ago, trying to do something like this would have been hard. With the SNS tooling, it looks like it might be fairly easy now. That is good engineering and a real accomplishment!
These issue are stressful and a pain to deal with, but they are worth solving and figuring out how to deal with successfully, powerful tech is a great problem to have.
I do not think it makes sense for Dfinity to cede control at this moment to the ck SNS holders.
Realistically, even if there are new SNS tokens Dfinity will just hold a majority of them. So it’s not going to help getting Dfinity out of any legal troubles that arise.
They are not going to cede control of the ck canisters to the community to avoid legal troubles unless they perceive that risk to be large enough.
To the extent Dfinity wants to build a trusted application, I think it makes total sense for it to be NNS controlled.
To the extent Dfinity wants to cede control only then does it make sense to spin it out. It is clear it does not want to cede control of the ck canisters at this moment in time.
@dfisher the recommendation to separate ckBTC from the NNS wasn’t intended to take away control from DFINITY or protect them. If anything it would make it easier for DFINITY to make their case without others accusing the network of being centralized.
It’s about keeping NNS stakeholders from being responsible for the governance of applications that aren’t part of the protocol.
Disclaimer (since it has been counting in the debate) : I precise that I am not an US citizen.
There is no contradiction about describing the CkBTC as a twin of the BTC. « Twin » does not mean similar (similar meaning « perfectly analogous ») or a fortiori identical.
In my humble opinion. If users want a no censurable BTC, they can directly use BTC. We can not ask CkBTC to be the BTC on the IC. We can’t evaluate the CkBTC through the same BTC’s criteria and ideals. The purpose is different : by using it, we want to get some capabilities we don’t have with BTC. But BTC does not have head office to sue, ICP, through Dfinity, has one, so we must be more cautious. At least for now. We can’t just want the plus without the minus here.
With CkBTC, as it is designed by Dfinity which is currently nuclear (some folks would say « a point of failure ») for the IC , we will eventually have to comply with regulation more than if we were on BTC, and clearly the regulation will sooner than later harmonize. So Dfinity’s CkBTC must be compliant with the regulators to avoid any systemic risk for IC. The BTC on IC is currently Dfinity’s one, but BTC on IC does not have to be Dfinity’s BTC : they proposed one, and can’t challenge regulation with it or with any feature, and I would be terrify that they want to or that they don’t evaluate the risk of breaking the lawS. But anybody can implement their own BTC version, compliant or not compliant, and everybody will make their choice. But with this one, in my opinion, we can’t take a chance. Still, CkBTC is definitely not the last word for BTC on IC, it is the first, but the Dfinity’s one, and they have to be irreproachable, for them and for us, because at the end of the day, metaverse or not, cyberspace or not, we live in the real space with laws governing the real people in real countries, and they’ll be always here.
To me, want a neutral CkBTC whereas the CkBTC is by design not neutral (not to be neutral is not always a bad thing and can be necessary), is a contradiction that misplaces its function and more globally the achievements which remain to be accomplished on the IC.
I don’t think DFINITY has any desire to shut down the ckBTC canister as too much time and money was spent promoting ckBTC on different IC platforms. I think the most we can do is push for DFINITY to keep ckBTC neutral and let other developers spin new versions that cater to the whims of each government as necessary. This would not only make it fair to every IC user in the world but by leaving it up to the market to decide the winner will also possibly lead to more innovations due to competition between the different versions.
From my perspective, the fact that the IC allows for on-chain computing, end-to-end, makes it by far the most decentralized blockchain protocol in the world. No other blockchain can claim such a degree of decentralized function.
Roll-ups and oracles are intrinsically centralized functions that enable all the other major blockchain players to do business, That’s no secret, and there is no complaint about this from the worldwide blockchain community.
Therefore, I don’t see ckBTC compliance with KYT as a legitimate accusation that the IC will become more centralized, or even viewed as more centralized by future developers or companies that will choose the IC as their blockchain platform of choice.
Dfinity is responsible for the progressive development of ckBTC - let them develop it as they see fit. And (not “but”) let another developer create their own version of non-KYT compliant ckBTC.
First, I would like to comment on the discussion process so far.
Introducing KYT may not be the best But it is understandable that the risk is that the state action will spoil the BTC integration してthat has been achieved for a long time.
Whichever path NNS choose, I respect.
But either way, DFINITY must understand that no matter what measures it takes, it is inevitable that it will face similar problems like this one. (The safest and best measure is to blank CKBTC )
The public mint of ckBTC is still closed and cutting off ICP’s possibilities…do we have to debate for days with the same uncertainty during ETH integration?
I would like to see ICP grow first and foremost. No state will care about ICP now.
I’ve briefly looked at some KYT providers, haven’t come across any that provides a pricing page, which is a bit concerning at least for me. As an alternative, if the BTC is purchased by credit-card from a non-DEX (prefer to not call it CEX), would that BTC not be KYC’d by the selling entity, i.e.Coinbase and the like? And if so, would it be technically possible, and also vetted by DFINITY, to allow those sorts of pre-KYT’d BTC be whitelisted/allowed as an interim solution to not have founders like myself get stuck with a ckBTC based project? Cheers.
)