Hopefully this is a misunderstanding due to interpretation of the translation.
KYT is a feature that is checked before wrapping into ckBTC. With or without implementation, CKBTC is still 1:1 to BTC.
WBTC is issued by depositing assets with Bitgo, which is completely different.
Toniq is a KYT provider, not a key depository like Bitgo.
I can’t wait for the foundation and other members to submit their proposals, as I feel that further discussion will only add to the thread with content that is off topic.
^This is a significant problem, a lot have diminished it as “Low significance” but ckBTC is a key defi product and not being able to wrap for a period can cost significant impact to a business on ICP depending on their model
Its a highly significant issue, albeit, I understand users assets are safe hence why its mentioned as low significance
Important to note, while the canister might be back to how it is now, it wont be the same for the people depending on it . The longer this is live, the more risk to projects that become dependant on ckXXX
I’m not sure you can say this?
I’ve not been able to get what % a KYT provider would get per call to mint. We also dont know what volume you’re basing your calculation on so till these happen, this claim has no basis
Secondly, on the assumption that this is true, I don’t understand how Dfinity is releasing this with intent of others onboarding since there is no incentive for them to do so? This part is the scariest of all since it removes the hope of this heading towards a more robust system
Side Note:-
I’ve reached out to a few Defi projects and they are discussing onboarding within the team. It sure would help if @Jan would make the fees to KYT providers public
There are so many different elements to this, from my understanding it’s roughly ~$0.50c per screening, but with volume this may decrease. This would just be the KYT portion of the fee, I also believe an additional fee is taken to cover canister cycles cost which are used to fund cycles for the canister (and are not sent to KYT providers) - lets say this is another $0.50c. So if I send 1BTC from my wallet to be converted to ckBTC, I would receive 1BTC - $1 fee.
However on subsequent deposits, KYT is cheaper (possibly free) within a period of time (weeks I think). So if you were to send another 1BTC, the fee may only be 50c to cover canister costs.
The KYT canister doesn’t currently have a way to pay KYT providers yet, but I believe this will be added in future. So we are running this at a loss until the payout mechanism has been deployed. Ideally, we only want to be compensated for actual costs of KYT.
The best way forward is to continue developing the KYT canister to enable other 3rd party services as well (which may mean cheaper KYT costs), and to eventually develop a competitive fee mechanism to encourage other parties to provide this service too.
One idea is that we could set a higher fee (lets say $1 for KYT per deposit where the cost is about 50c). We (as the initial KYT provider) are compensated at the end of the month for our actual costs incurred only - we are OK to run at cost during this initial expansion phase. The rest could sit in the KYT canister to assist future KYT providers in setting up (i.e. a KYT setup fund).
In future, KYT providers can operate at a profit. This provides a duel incentive for new KYT providers - the KYT setup fund for initial setup, and the for profit aspect.
I believe you need to discuss with ChainAnalysis directly regarding fees and costs etc, arranging a demo. Although, you just need an API key (no actual dev work required), and then apply to have this injected as a KYT provider.
If dfinity were to wait for more KYT providers and delay ckBTC, this wouldn’t really affect us at Toniq. We would likely go ahead with a fork as we’ve already signed on to an annual contract at this stage, and we’re committing to getting some form of ckBTC working. But this leads to my comment about ckBTC potentially being stuck in limbo for much longer.
So additional KYT providers wouldn’t affect Toniq, but at the same time you’ve already signed a contract and will fork, instead of waiting for others to have an equal opportunity for “market share”.
This train of thought borders on extortion and it’s just leveraging your newly stated insider knowledge to your advantage.
Have you considered what will happen if the community boycotts your fork and nobody uses your WBTC? How much more material and reputational losses would you incur?
We have no advantage at this point - all the code is opensource. Anyone can fork ckBTC (which now has KYT included), sign up for a ChainAnalysis account, and have KYT compliant on-chain BTC canister. We were committed to either deploying a wBTC variant or using ckBTC for some time and either option can work for us.
We don’t want to have market-share, if someone else wants to do this then that’s awesome, I’ll support it. We just want the feature to be live so we can build and deploy defi services. I know a lot of other developers are waiting for this as well.
If we deploy a fork now, continue to build our defi services, and no one uses wBTC, then that’s how a decentralized service on the IC should be. If ckBTC then goes live later down the track and works well, than it would be super easy to switch over to it.
What’s the alternative? Delay ckBTC, don’t deploy a fork, and just wait? We want ckBTC to go live and work and be really robust in every way. If that means we have to wait months to get it right, then why would we not deploy an alternative in the mean time so we can still build and deliver defi services, and allow other teams and devs to do so too?
Maybe a dumb question here, but don’t governments make these tainted utxos public? Is there a reason we aren’t just hard coding the list? If new ones are added we make a proposal to add it?
We could set up a blacklist canister and add 21 community members/ic projects as voters in less than a day.
If we want further decentralization we can do an SNS and charge cycles to the query the blacklist to pay out to authenticators. We don’t even have to do a “sale”. We could just airdrop to validated NNS neuron holders.
Second option has an n of a month probably and the first an n of days.
As mentioned before though…there WILL be a lag and eventually flagged BYC will almost assuredly get into the utxo pool. I think we need to look at the architecture to figure out how to deal with those. That seems like a much bigger problem.
Seems like the canister needs a utxo queue where we’d be able to push flagged utxos to the back of the queue in such a way that they would likely never come out. If one does make it in then likely fees should increase until the amount is burned. Or everyone is slashed…this would make diligent enforcement a network priority.
Theguy!!! Omfg. Profit and profit and profit .sign up the api and join toniq already please . Whats stopping you ? Certainly not your hands from the constant typing .lmao
Had a meeting with Chainalaysis regarding the cost of API access. Long story short the numbers don’t add up for us. To get an idea… if the fee was 50cents per TX then we would need roughly 60 txs everyday single day for a year to just break even. Every additional API key holder would dilute the available ‘pool’ of transaction fees reduce this profitability… meaning that we need an ever larger number of txs.
So if Toniq and Saorsa Labs held keys (and a random selection design was implemented) we’d need 120 txs a day just to get to break even. This is based on initial costs however the price for API access also scales with the number of transactions sent so break-even is a moving target.
There is the option of a community crowdfunded API Key however this would have to be done every year and people would need to trust someone not to run off with the money.
I don’t think opening the ICP Ecosystem to tainted BTC is really an option TBH… most people wouldn’t want to own a stolen car, and the same is true with BTC. Institutions/ big money would also run a mile!
It’s a tricky situation… unfortunately in the short term there probably isn’t a better option. It leaves me uneasy though.
The law of large numbers favors underlying principles. 1%of 100 might be a dollar $1. But when a business is transacting $1M, then the percentage doesn’t work for them as it is about $10K. Multiply that with 365 days and you’ll see why a large business would not want to be involved in such a model.
The fact that you had to go out of your way to contact chainalysis shows how bad leadership is at toniq. The do not have all their information open and public. However they are blackmailing the ecosystem that if they are not allowed to launch ckbtc then they would go ahead and make their own fork. I don’t see a problem with that as far as they don’t drag dfinity down a hole. Dfinity has been respectful and operates like an institution with high consideration of values. So if they don’t have all their information together then they really do not understand the market of KYT in and out. This makes them incompetent for reliance in future emergency occasions. All information regarding KYT issues should be at the least be available on their website and well documented.
This isn’t wrong, to withhold info is not a sign of good faith or collaborative effort - especially for something where its considered “Not part of your profit or business scheme”
Think of Karma as a stat, Karma adds up and I’m sure the effects are felt - just my 2 cents, might help working on this
To be fair to Toniq - I never contacted them to ask. Having spoken to them on various occasions I’m sure they would have told me the cost no issue.
I dont think they are holding us hostage at all. My comments are not directed at them - just the process design. Process design/ build is mostly Dfinity’s role in this.
If it wasnt for Toniq we would be at a complete stand still. I do appreciate that!
I feel like the options are
1, Completely park ckBTC… possibility for months.
2, Go with an interim solution (Single entity API provider) BUT acknowledge that it is an INTERIM fix whilst other options are explored.
I feel like we’ve probabily got to go with option 2 and be prepared to potentially manage some flak.
