One additional question - @peterparker will users be able to manage their cycles balances through the NNS app once the cycles ledger is released?
I can unfortunately not answer your question, @icme. I only participated in this thread as a user. I have no idea what the status, outcome, and roadmap of the cycles ledger are, nor where it will be used.
Can you address the question above about NNS access to cycle ledger?
Also:
- Does the existing get_blocks exist in the ledger so that a rosetta could at least work in read-only mode?
- What is the clean-up threshold at which time old approvals begin to be cleaned up by the ledger?
- Is the current beta of the cycle ledger set up to be pullable by dfx yet(or installed as part of the local nns deployment commands)?
I think there is currently no effort to add support in the NNS dapp; however, that’s certainly a reasonable request.
Obviously, we currently focus on getting the cycles ledger released. I suggest posting your request on the feedback board to get it prioritized! 
Regarding your other questions:
- The cycles ledger will be ICRC-3 compliant. As you can see here, there is a function called
icrc3_get_transactions, which was the proposed name at some point. The function will be renamed toicrc3_get_blocksbefore the release. - Approvals where
expires_at = Nonedo not expire, i.e., approvals are only pruned when they actually expire. - That’s a good question! The cycles ledger should be pullable but that’s not the case yet. We’ll add that item to the list of outstanding tasks.
While this is great news, I’m curious as to the mechanism you are using as even the ICP ledger clears out accounts if the collection gets too large. Have you guys cracked this or is it more of a function of with the larger stable memory size you don’t anticipate a problem emerging before you’d be able to deal with it(if it ever gets to that).
@THLO Maybe a bit of a dumb question here, but in the depositor, is the ledger_id the ICP ledger or the cycles ledger?
It is the latter. Given that the cycles ledger can now use 400 GiB of stable memory, and likely more in the future, we believe that the state size will not become a concern any time soon.
Obviously, we will closely monitor the growth of the state so that we could react if our assumption turned out to be wrong.
in the depositor, is the ledger_id the ICP ledger or the cycles ledger?
It is the cycles ledger. As you can see here, the depositor uses this canister ID to call the deposit function on the cycles ledger.
1 Like
Hey @icme - this is a good suggestion. For the initial release, we are doing everything we can to keep the Cycles Ledger simple. However, this would be a good addition to the feedback board. Care to add it? https://dx.internetcomputer.org
TY!
1 Like
If my understanding is correct then:
This would allow a user who obtained a principal through auth with II in a browser frontend, to create a canister by sending a call to the cycles ledger. (From the same frontend)
The principal should hold cycles obviously.
And this was not possible before, because the same principal would not be able to call create_canister in the management canister, since that is only possible from another canister, correct?
After some integration work, I think a transfer_from_and_send(Account, Amount, CanisterID) function would be great that would combine the icrc2 transfer from with the custom send.
I guess going the other way, deposit_and_transfer would be cool too.
2 Likes
I think that’s an interesting idea. Thanks for the suggestion!
Note that the custom send function has been renamed to withdraw.
What would deposit_and_transfer do? Note that the deposit function allows the user to specify any destination account directly.
Good point!
Thanks for the updated did!
(Nevermind…figured it out)
is there any timeline for cycles ledger to be live on mainnet?
As I wrote in January, the goal is to release the cycles ledger in Q1 2024, so there isn’t much time left.
There are still some changes required but I hope that I can provide a more precise release date soon.
I can provide some additional information already now: We will release the cycles ledger first, followed by an update to dfx with the new dfx cycles command.
The index canister will follow a bit later, depending on available resources, but hopefully not more than a few weeks later. Once everything is up and running as expected, we will hand over control to the NNS. Before this happens, the cycles ledger is considered to be in beta stage and should be used for testing only (i.e., transferring small amounts of cycles).
4 Likes
Good news! The cycles ledger is now almost ready to be deployed (we only need to merge changes to the ICRC metadata).
We are planning to launch the cycles ledger on Wednesday, March 20, 2024.
As mentioned before, the launch will start the testing phase in production. Everybody is encouraged to try it out and report any feedback here!
7 Likes
We just installed the cycles ledger to um5iw-rqaaa-aaaaq-qaaba-cai. You can find the wasm here. We will test it thoroughly over the next few weeks and invite you to do the same. Please let us know if you run into any unexpected behavior!
Important: This is still a beta. Please don’t store any significant cycle amounts. While we don’t plan to break anything, things can still go wrong. Also, we are still controllers of the canister, so we can rug you at any time 
The next dfx release will contain an opt-in way to use the cycles ledger by default. I’ll update you how to use it once it’s released.
5 Likes
Well that was quick… @mariop found a bug already with block encoding and we’ll have to reinstall the canister. I stopped the canister for now so nobody can deposit cycles anymore that they won’t be able to withdraw
On a positive note: nobody except myself has deposited cycles so far, so nobody gets rugged 
4 Likes