I am working on an ICRC-1 token indexer for my team’s project Bitcorn Block Explorer which has the ultimate goal of indexing all ICPI tokens to display top holders and more. I recently ran into an issue with the archive canister of the BITCORN token. I am raising this concern because I believe it effects ALL ICRC-1 standard tokens.
Here is the problem: When I call the method get_transactions(4000, 1) from the BITCORN archive canister from any source (ic dashboard, icscan, candid, motoko) the length of the result is 1000. The expected length is obviously 1. This problem continues further than just index 4000 as index 4001 and index 4002 give 1000 transactions back as a result as well.
Similar issues:
ICPumper canister ID: cuvds-maaaa-aaaak-afkyq-cai
ICPumper archive canister ID: ijpyk-dqaaa-aaaak-aflbq-cai
get_transactions(1000, 1) gives an array of 996 transactions
CATDOG canister ID: tmt5q-3qaaa-aaaak-afjrq-cai
CATDOG archive canister ID: ey5tr-3iaaa-aaaak-afkpa-cai
get_transactions(31000, 1) gives an array of 1000 transactions
Windoge98 canister ID: rh2pm-ryaaa-aaaan-qeniq-cai
Windoge98 archive canister ID: e3o6i-daaaa-aaaan-qeo2a-cai
get_transactions(80000, 1) gives an array of 999 transactions
I will be researching this further on my end to discover more issues and potential causes. I will report any findings to this thread.
I’m having a few problems myself with the NatLabs type ICRC canister used by several projects. I think the EXE canister has been upgraded and doesn’t have this issue anymore?
… however I think there is a flaw in these canisters because they have a pre-minting account. This means that the first transactions on the ledgers are transfers and not mints. I don’t think that this adheres to the ICRC-1 standard (I’ll get a 2nd opinion on that!)
It’s not a problem with ICRC-1 standard tokens. The interface to fetch blocks and transactions is not standard to begin with. There is a proposal called ICRC-3 for a standard get_blocks but not for get_transactions.
The bug is in the implementation of the Archive canister. I’ve checked ckBTC and Dragginz archive canisters but they don’t have this issue. Then I noticed that the interface of the canisters with the issue is different from the interface of the SNS/ckBTC canisters developed at DFINITY, e.g. the archives above canisters have an append_transactions endpoint instead of the append_blocks endpoint of DFINITY’s canisters. My guess is that ICPumper, CATDOG and Windoge98 are using their own Ledger and Archive. I suggest to contact their teams and let them know about the issue so that they can upgrade the canisters and fix the bug.
The ICRC-1 standard doesn’t say anything about the initial state of the Ledger . Pre-minted tokens are perfectly valid and ICRC-1 is not concerned with them. The Ledger should still return the blocks resulting from minting at init time as ICRC-3 doesn’t really care how those blocks were created.
I think the main question is - should you be able to mint tokens which don’t show on the ledger? I’m not fussed if they are pre-minted or the ledger starts at 0. I do think however token creation should be recorded. You shouldn’t be able to transfer something that hasn’t been ‘minted’?
. Pre-minted tokens are perfectly valid and ICRC-1 is not concerned with them. The Ledger should still return the blocks resulting from minting at init time as ICRC-3 doesn’t really care how those blocks were created.