Hello, I’m building a canister for the IC using Rust as part of a grant, and I need to receive payments with the canister. As the ic-ledger-types
crate only supports transfer()
and account_balance()
, I cannot use that to verify transactions. Additionally, the ICP ledger does not depend on the ic_cdk, so I also cannot just import the IC monorepo, because I would end up with inconsistent candid
dependencies etc., which is strongly discouraged in the ic_cdk
documentation.
Thus, I have been extracting the necessary code from the IC monorepo, but it’s extremely tedious and not easy to maintain in the future. There are lots of internal constants, types, functions, etc. that I need to extract. The 30-day checkin of the grant is soon and the past few weeks have been quite stressful due to the large amount of research and pitfalls involved. The process of extracting all the code is very difficult for me, as I am completely unfamiliar with the overall project structure and design of the IC and therefore unable to properly stay on top of the complexity.
Is the ic-ledger-types
crate still being maintained? The last update seems to have been a handful of months ago. I would be happy if query_blocks()
and its related structs were added, as well as the types for notify_dfx
, so I can receive notifications for payments. Another big confusion for me is the difference between the rosetta-api/ledger.did and rosetta-api/ledger_canister/ledger.did specifications: I need to use types from both specifications (NotifyCanisterArgs and SendArgs from rosetta-api/ledger.did and TransferArgs, GetBlocksArgs, QueryBlocksResponse, etc. from the rosetta-api/ledger_canister/ledger.did), and they seem to have redundant and/or diverging specifications. Are those two completely separate canisters with different principals? It would be great if there was some more documentation regarding all of this.
I had hoped I could solve this problem on my own, but for now, my only choice is to give up the code extraction attempt, because the complexity is spiralling out of control, and I will be unable to maintain a separate copy of the code I extracted, as I don’t know when the monorepo will change those portions of the code. Thus, I will instead focus on building and using an abstraction that can be implemented with no effort once the ic-ledger-types
properly supports all the functionality I listed above. I can then revisit actual ICP ledger interactions once the utilities for that are provided.