Could be an option. We probably need to see what the real world demand is going to be. Not ideal but it would at least give some data to model.
2 Likes
Yeah definitely just one option, hoping more comes forward
@skilesare also put something forward but it was too much from my brain to understand
need it explained in low IQ words
1 Like
Now, if only we had an NNS-controlled Treasury…
3 Likes
Unfortunately no. There is a limit to the # of requests associated with a license (the limit gives you your cost per call). After you hit the limit, you are charged per call at the same price as overage charges.
So assuming a cost of $30k you might get 60k requests. But after 60k requests, you still pay $0.50 per call.
So after 60k requests to mint, you are still in the exact same scenario. $0.50 per call on top of what you have already paid.
Like I said before, there is no scenario here where we profit off of this.
2 Likes
This!
The problem is not that there is no developer who can implement a multiple agency KYT providers.
It is that it is highly expensive and no single developer has that money lying around ready to put it into a canister project.
However is some would fund the canister, at a potential profit of course then it might work.
Or if like mentioned here, there was a NNS treasury then the NNS would fund such a project as it only helps a smooth transition between developers, the customers and concerned jurisdictions on ckbtc.
Unless there is someone willing to fund this multi-KYT canister, then it would be long before we see the true potential of ckbtc.
1 Like
Im just going to say it
I cant put together fully whats going on here
Bottom one is the current solution right?
UTXOs are the bad wallets?
You know… an automated proposal that goes to update UTXOs 2weeks to 1 month might not be such a bad idea - given compliance is ok with a “Delay in update”
So wait
You have to pay X$ (assume 30k$) up front, then ALSO pay .5$ per call?
No sorry. Only if you go over the amount of requests you are allowed. The best way to think about it is you pay $0.50 per call forever. A set amount upfront, and the rest as they happen if you go over the amount you initially paid for.
Right… so you’re essentially pre-buying a minimal amount of requests - then buying Adhoc
Chainanalysis Scam revealed, someone call SEC
1 Like
@bob11 @stephenandrews I’m a bit late to this topic but I would support Toniq forking the ckBTC canister and doing their own wBTC. I think this would be a better approach for the network and would encourage other businesses to do the same. I might be in the minority but I don’t think every service like this needs to be provided by the NNS. Also, it sounds like it is a financial burden/risk that should be addressed by each provider. Just my $.02
5 Likes
Definitely something we strongly considered. The risk here is how you control the canister. If you blackhole it, then you risk something going wrong and funds being trapped inside forever, which doesn’t feel like a work-able solution to me.
If not blackhole, it would need some kind of DAO control. Even WBTC on ETH is controlled by a 20-something multisig.
The best option here is the NNS (which is why I like the Dfinity approach) but there are risks to this route as well. Anyone can put any canister under control of the NNS, but that doesn’t mean changes to your canister code will pass an NNS vote.
Creating some kind of DAO from scratch is also possible, but hard to make it secure, decentralized, and properly incentivized.
2 Likes
I do believe a DAO would be the best solution here. Its seems like we have two good options with Axon and the SNS. The IC is almost purpose-built to support this sort of thing and I think if anyone can pull it off without DF’s help it would be Toniq.
I agree that the NNS is a super appealing solution. However, I do question if this would still be the preferred approach if DF didn’t direct such an overwhelming amount of liquid VP on non-governance topics. I’m going to avoid going down all of those rabbit holes; but, I do think its important to keep this in mind. If we want to set an example for future services I think at some point we need to stop using the NNS as a crutch. Especially when we’re talking about a service that even DF admits is not considered a protocol-level service.
If we’re going to settle on an imperfect solution I think I would prefer to start with a multi-sig solution that grows into a more decentralized DAO structure rather than put this on the NNS and hope for the best in the future.
2 Likes
I see your intent. But who would be the signers that you’d be comfortable with? I feel like it would be quite a challenge to find a set of signers that everybody is happy with.
5 Likes
With Axon you can set a low quorum and add any number of signers such that those interested in participating can do so. You’d need to KYC to avoid sybils, but it is probably a decent short-term solution:
For example: Here is the BTB DAO. I’ve kyc’d the people on the list so far as significant contributors to the IC ecosystem. Right now I’m the only proposer, but the dao can vote to change that.
1 Like
Yeah I think my question is not so much technical, but really about how we’d come up with the list of people that together control ckBTC. It’s a big responsibility, and everybody would need to be comfortable that this set of signers will take good care of ckBTC.
1 Like
Before I try to respond I just want to make sure I understand the situation. Are you asking me how Toniq would choose the multi-sig participants for a Toniq wrapped BTC product, or are you asking me about choosing multi-sig participants for a product that is supposed to be considered the de facto wrapped BTC solution for the network?
All of my statements up to this point have been made with the understanding that this ckBTC canister is not a formal service provided by the protocol. If that’s no longer the case I would have to revise my statements.
2 Likes
ckBTC is far too likely to be considered/viewed as the defacto BTC considering how things have gone down so far
Ah, perhaps I misunderstood your statements.
I had a broadly used ckBTC in mind, not a toniq product. I wouldn’t say any version of ckBTC would have to be the de-facto standard, but of course its beneficial if many people use the same ckBTC (such that there is sufficient liquidity, and you don’t need to convert between ckBTC1, ckBTC2, ckBTC3 for different dapps). To achieve that, we need a controller that is broadly trusted, which is why we proposed the NNS.
1 Like
Thanks for clarifying Manu. Apologies if my intent wasn’t clear.
I agree, as a user this would be preferable. However, as an NNS stakeholder I do feel like trying to kickoff this behavior by putting ckBTC under NNS governance risks the credibility of the network. And that’s a risk I take very seriously.
I’m also confident that we would eventually observe the behavior you described if we give independent orgs enough time on the market.
1 Like