Many ledgers suites have a ledger and separate index canister. Applications, such as the NNS Dapp and Dexes keep track of both a token’s ledger and index canister id (if an index canister exists for the token).
The index canister id is already part of the init args of most ICRC ledgers - why don’t they expose a index_canister_id query endpoint?
Such an endpoint would allow applications to just keep track of a single token canister id, comprising both the APIs and functionality of the ledger and index canister. An external application/agent could then dynamically pull in the ledger canister’s corresponding index canister id if it exists instead of requiring users to enter both the ledger and index canister ids for customer tokens on applications like the NNS dapp.
This would also allow developers to experiment with migrating the index canister id or merging the ledger and index canister into a single canister application, such that a ledger canister would return its own canister id from the index_canister_id endpoint, and then just expose the required index canister endpoints as well.
There’s actually a stopgap standard for that (until index canisters have been standardized), but it seems it hasn’t been picked up yet in the ledger implementation.
Good question, and great timing @icme! We have a PR that we hope to merge in the coming few days, and once the rollout of the current ICRC ledger suite release is done, we’d create a new release including support for ICRC-106. The ledger controller would need to set the index principal (in the canister upgrade argument), and then user would be able to call the new icrc106_get_index_principal endpoint on the ledger to get the canister ID of its index canister.
As @sea-snake mentioned, ICRC-106 is a stopgap standard - @bogwar can perhaps comment further on the timeline for standardizing index canisters in general (ICRC-106 only documents the current behavior of the DFINITY implementation of its ICRC ledger index canister).