Dear WG!
Voting on ICRC-3 has been opened last week and is open only for a little longer. Can you please cast your votes so that it can be finalized and put forward to the NNS?
Please vote here:
@skilesare, @levifeldman, @benji, @sea-snake, @Maxfinity, @lastmjs
Looks good to me. Simple and it works.
In the ICRC standard is there a max size for approve transactions? For example u128::Max in rust?
Should someone be able to submit an approve transaction of this size = 115792089237316195423570985008687907853269984665640564039457584007913129639935 ?
Do you mean for the amount or for the entire transaction data? If the transaction data were larger than 2-3MB it would be unable to archive between canisters with the current data structures, but that would be huge and likely only something weāre having to deal with in NFT land. The amount is a Nat and is theoretically unbounded, but a developer should put a check in to make sure it isnāt greater than the total supply to avoid DoS(although if it is a transfer there is likely other things that would cause it fail before inclusion).
Sorry should have made that clearer. Size as in value of transaction, not size in bytes.
The reason I ask is that block 50 on ckETH is an approve transaction with the value ā115792089237316195423570985008687907853269984665640564039457584007913129639935ā
Iāve been converting Nat values to u128 in rust because I find it easier to use in rust. Candid guide seems to suggest that in rust Nat is equivalent to u128 (Candid reference | Internet Computer)
Our indexer and data canister for ckETH both hit the wall at block 50 (because we didnāt handle the case of a number > u128::max)
So just wondering if we should be handling the possibility of Nat values being > u128.
The standard uses nat for tokens amount because itās up to the Ledger to decide the precision. ckETH for instance uses u256 and therefore any client expecting u128 will have issues eventually.
Clients should be use bigunum internally or something similar to that for amounts to maximize compatibility with Ledgers.
So if I want to be evil and make rust devs have a bad day I should launch an SNS token with 255 decimal places.
But seriously, does rust have an unbounded nat data type?
Isnāt the SNS ledger written in Rust and does it support 256 bit amounts?
Itās not a massive issue. I suppose what Iām saying is the candid reference page seem to suggest Nat = u128, which isnāt the case.
From the reference page:
Corresponding Rust type
candid::Nat or u128
But seriously, does rust have an unbounded nat data type?
Natively no but there are libraries, e.g. biguint which is used by candid
The Ledger the SNS uses is the same Ledger used by ckETH and has two flavors: u64 and u256. SNSes and ckBTC use the u64 one while ckETH uses the u256 one. You can see the code that swaps between the two here.
I donāt know about the reference page but Nat is definitely unbounded.
I was poking around some ICRC1 stuff and saw this stuff about a fee_collector(I think @levi was adding a fee_collector as well as a way to update the fee on an SNS). It look like from https://github.com/dfinity/ic/blob/310743758d41e1bead72322c6a5bf8e77c4eac12/rs/rosetta-api/ledger_core/src/block.rs#L43 that these changes may actually be added to the blockchain as blocksā¦and that transfers with a fee_collector may have an extra fee_collector field in their transaction. We donāt have this defined in ICRC3 as far as I know. Do we need to add these event type blocks? Others might be changes to the minting account, initial balances, maybe some others Iām not thinking of off the top of my head.
The updated ICRC-1/-2 ledger that is used for ckBTC uses 256 bits for representing numbers to be compliant with Ethereum requirements (in Ethereum, all balances are modeled as 256-bit numbers). And when approving, you can approve an arbitrary amount, thatās why you can see numbers larger than 128 bits in size.
The max size for numbers in the new ICRC-1/-2 ledgers is, as mentioned above, 256 bits. The only reason was really compatibility for Ether and upcoming ERC-20, but in order to be compatible here, we needed to use 256 bits with all the implications. Should maybe have been communicated better.
AFAIK the fee collector has been seen as implementation specific and thus is not part of ICRC-3. Any implementation of a ledger could opt for its own way of collecting fees, thus it wasnāt put in the standard. There was some talk by @mariop some time back to have the fee collector defined as an additional extension, but we havenāt had time so far.
I guess if this is not standardized, services seeing the blocks with fees will not be able to interpret the fees and thus not be able to recompute all account balances of the ledger. For this reason, having the fee collector extension standard defined would probably make lots of sense.
This is something a ledger ideally supports in terms of creating blocks for configuration changes. The question is how much of this could go into a base standard. Potentially something to be considered for our NFT standard?
If my memory of the discussions is correct, we donāt have this for ICRC-1 for historical reasons, i.e., this not having been implemented in the first ICRC-1 ledgers and hence also not being part of the standard. New standards ideally should track configuration change in their block log, the question is whether the is ledger specific or part of a standard.
A more generic problem with the standard is how to account for custom fields that do change balances. I guess we should just forbid them unless they are put in a standard.
I agree that we should standardize the fee collector. I think most ledgers will consider having a fee collector and the fields are optional so ledgers that donāt want it can just skip the fields.
Thanks for your quick response, Mario!
I could take the fee collector on the agenda of the WG for next year and drive this forward. Should be a simple and not too big effort I guess. And until itās there, people can assume that this will be a standard way of fee accounting and can already include this semantics in their clients.
Question about ICRC-2: whatās the purpose of the spender subaccount? It isnāt explained very well in the spec and the examples given there donāt use it. I suppose it exists so that the owner can define multiple independent allowances for the same spender, to segregate amounts to be used for different purposes and each with their own expiration. Is that the reason?
Thanks - Iām looking at rebuilding the 221Bravo index canisters. Iāll add the BigUint change in as well. 
Yeahā¦it pops up because I was implementing the fee collector and replacing a silent burn of the fee and I was likeā¦what do I do here?..Do I add a transfer to the fee collector as a whole other block? Of do I just add a fee collector field at the top level? The second one is cleaner, but will it break ICRC1-compatible ledger readers that donāt know what it is?
The fee collector was implemented in the ledger before I heard about it and before my work on the snsā ability to set/change the fee-collector and other ledger parameters. In one of the meetings we spoke about it for a few minutes, If I remember correct, the way it is implemented now in the ledger is that if the fee collector changes, then the fee_collector field is put into the first block created after that change, and then until the fee collector changes again, the field is not put into further blocks.
It does break for ledger readers looking for how or where the fee-collector account(s) gets its balance from so thanks for bringing this up. If we do standardize it and ledger-readers do know about it, It becomes more complex for wallets to show account history because now, for a wallet to know where itās accountās funds came from, it has to look at every block that the ledger creates in case the fee-collector is changed to the walletās account. A change in the index canister could help with that though.
For the fact that with the ledgerās fee-collector feature implemented right now, it does break ledger-readers from knowing where funds are coming from, I think it might be best to turn off that feature for now until it can be standardized and thought through how a client will know where itās accountās funds are coming from.
The vote on the ICRC-3 token standard has been accepted by the WG.