For the ledger, make sure you wrap the record with a variant (Init to deploy). This is an example deploy argument:
dfx deploy ledger --argument "(variant {Init = record {minting_account = record { owner = principal \"$MINTERID\" };transfer_fee = 0;token_symbol = \"ckBTC\";token_name = \"Token ckBTC\";metadata = vec {};initial_balances = vec {};archive_options = record {num_blocks_to_archive = 10_000;trigger_threshold = 20_000;cycles_for_archive_creation = opt 4_000_000_000_000;controller_id = principal \"$PRINCIPAL\";};}})"
obviously the env variables have to be present for the above to work.
The above also assumes you downloaded the dids and wasm using the latest blessed replica hash (1612a202d030faa496e1694eed98be4179fca856 at the time of writing). You can find the latest one here.
The following commands offer a way to download the dids and wasms for this release, IC_VERSION can be replaced by the hash of a different blessed replica version:
In NNS-dapp for local development purpose and for the time being (until we automate things), I’ve got a script to download the wasms and one to deploy locally. It’s inherited from the work of my colleague Léo (). So if it can help here:
Correct, users cannot yet convert BTC into ckBTC (see ckBTC and KYT Compliance for more context). However, your project can already support ckBTC transactions, just like eg openchat and dscvr already support tipping in ckBTC.
@Manu whom do I talk to if i want to use this feature? does dfinity provide customer support? it acts like a web2 company with icp token as its security
ckBTC consists of some NNS-controlled canister smart contracts, so you can just start using it without asking anybody :). If you run into technical problems, I think this forum thread is a great place to ask questions.
But few builders in my dms telling me that DFINITY is providing 24/7 direct customer support outside dev forums. This is the worst Security I have ever bought.
I followed the discussion on KYT - and you can see my thoughts on that from my comment… but are we now saying that this is “context” because it plays a part in deciding when to allow others to mint ckBTC?
Personally, I don’t think this should be a blocker, for the same reason that I don’t think the protocol should get involved in implementing KYT… but you can refer to my comment in the relevant thread to pick that up. It’s out of context here
First, to install this Chainalysis KYT canister without any principals that can set API keys. This will let everybody review the Chainalysis KYT canister code.
Second, a proposal sets an initial list of principals that can provide API keys. This proposal will contain Toniq’s principal. Anybody else that is willing to obtain a chainalysis subscription and perform the role of providing API keys can submit a proposal similar to this to add their own principal (and feel free to ask for help here).
Third, a proposal to upgrade the ckBTC minter to use this KYT canister and enable BTC → ckBTC conversions. This proposal will also reduce the required confirmations from 72 to 12.
We will share the proposals here and I hope everybody takes the time to vote!