# ICRC-3 Draft v2 and Next Steps **URL:** \ **Category:** Developers\ **Created:** [November 29, 2023, 10:15am UTC](https://forum.dfinity.org/t/icrc-3-draft-v2-and-next-steps/25132 "2023-11-29T10:15:39Z")\ **Posts on this page:** 20\ **Page:** 4
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [March 15, 2024, 11:25pm UTC](https://forum.dfinity.org/t/icrc-3-draft-v2-and-next-steps/25132/64 "2024-03-15T23:25:55Z")
Blah…found one implementation detail. In the past, I could dedupe on the tx part of the Value map. Now that the type is moving out of the TX it isn’t as easy. Of course, I can inject it…or in the case of icrc1 and icrc2 put both the type and the op in the block. ---
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [March 15, 2024, 11:27pm UTC](https://forum.dfinity.org/t/icrc-3-draft-v2-and-next-steps/25132/65 "2024-03-15T23:27:42Z")
Shouldn’t this be 2approve? > ---
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [March 15, 2024, 11:28pm UTC](https://forum.dfinity.org/t/icrc-3-draft-v2-and-next-steps/25132/66 "2024-03-15T23:28:22Z")
Would there be anything precluding us from putting both the type at the top and op in the tx? ---
**Author:** ![mariop](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/mariop/32/5114_2.png) [@mariop](https://forum.dfinity.org/u/mariop)\ **Post date:** [March 18, 2024, 10:44am UTC](https://forum.dfinity.org/t/icrc-3-draft-v2-and-next-steps/25132/67 "2024-03-18T10:44:42Z")
I’ve received a lot of feedback during the weekend (thanks!). I’m going to discard the motion proposal I was writing and make some adjustments to the ICRC-3 draft based on that feedback. SpecificallyL 1. fix typos 2. Change the name of the field `type` to something that is not a keyword in most languages, e.g. `btype` (we have `phash` so…) 3. Explain what happens if both `btype` and `tx.op` are defined (`btype` has priority) 4. Explain what the endpoint `icrc2_supported_block_types` returns in the default (ICRC-1 and ICRC-2) case when the Ledger doesn’t support `btype` yet. There are two options: a) the Ledger returns nothing or b) the Ledger returns `1burn`, `1mint`, `2xfer` and `2approve` even if the `btypes` are not set yet in the blocks. I think b) is better because it allows to compose the default behavior with other standards. Stay tuned 🙂 . ---
**Author:** ![Saumay-Agrawal](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/saumay-agrawal/32/14928_2.png) [@Saumay-Agrawal](https://forum.dfinity.org/u/Saumay-Agrawal)\ **Post date:** [March 18, 2024, 11:00am UTC](https://forum.dfinity.org/t/icrc-3-draft-v2-and-next-steps/25132/68 "2024-03-18T11:00:57Z")
Hey Austin, can you please share when and where you would be having these conversations? Would love to be part of it. ---
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [March 18, 2024, 2:20pm UTC](https://forum.dfinity.org/t/icrc-3-draft-v2-and-next-steps/25132/69 "2024-03-18T14:20:18Z")
Yes…I will announce it on the forum…likely we’ll do a new WG focused around these ideas. ---
**Author:** ![mariop](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/mariop/32/5114_2.png) [@mariop](https://forum.dfinity.org/u/mariop)\ **Post date:** [March 18, 2024, 3:53pm UTC](https://forum.dfinity.org/t/icrc-3-draft-v2-and-next-steps/25132/70 "2024-03-18T15:53:21Z")
I’ve pushed a new version of the draft and replaced `type` with `btype`. You can find the preview [here](https://github.com/dfinity/ICRC-1/blob/1467044471b7ba5853e50b88c183fa2209f6c395/standards/ICRC-3/README.md). Once again I’ll wait a couple of days for comments. ---
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [March 18, 2024, 4:24pm UTC](https://forum.dfinity.org/t/icrc-3-draft-v2-and-next-steps/25132/71 "2024-03-18T16:24:43Z")
> If both are specified then `tx.op` should be ignored and `btype` should be used. Can we be specific about what ‘ignored’ here means? Is it ignored when calculating the hash? Or just when calculating the state of a canister from Genesis? I’d prefer letting it be included in the hash calc if present as including it makes deduplication much easier and removing it when calculating hashes would likely be an expensive operation. ---
**Author:** ![mariop](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/mariop/32/5114_2.png) [@mariop](https://forum.dfinity.org/u/mariop)\ **Post date:** [March 18, 2024, 5:43pm UTC](https://forum.dfinity.org/t/icrc-3-draft-v2-and-next-steps/25132/72 "2024-03-18T17:43:53Z")
> [@skilesare](#): > > Can we be specific about what ‘ignored’ here means? Is it ignored when calculating the hash? Or just when calculating the state of a canister from Genesis? > > I’d prefer letting it be included in the hash calc if present as including it makes deduplication much easier and removing it when calculating hashes would likely be an expensive operation. I changed it to say that if both are set then `btype` defines the type of the block. Both should still be used for the hash. ---
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [March 18, 2024, 8:11pm UTC](https://forum.dfinity.org/t/icrc-3-draft-v2-and-next-steps/25132/73 "2024-03-18T20:11:13Z")
> 1. the `btype` field MUST be > 2. `"2xfer"` if the Ledger supports ICRC-2 > 3. `"1xfer"` if the Ledger doesn’t support ICRC-2 Hmmm…this is confusing to me. And a bit complex from a library perspective. Ideally, an ICRC1 library should exist without having to have any information about what ICRC2 is. The ICRC2 library is like an add-on. Is there any reason why icrc1\_transfer can’t use 1xfer and icrc2\_transfer\_from use 2xfer? Theoretically, we shouldn’t have a 1xfer with a spender right? Should they be defined as different blocks with separate schemas? If my ICRC1 library has to know if it is in ICRC2 mode it kind of creates a circular dependency. ---
**Author:** ![kayicp](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/kayicp/32/36679_2.png) [@kayicp](https://forum.dfinity.org/u/kayicp)\ **Post date:** [March 19, 2024, 5:38am UTC](https://forum.dfinity.org/t/icrc-3-draft-v2-and-next-steps/25132/74 "2024-03-19T05:38:40Z")
> [@skilesare](#): > > Is there any reason why icrc1\_transfer can’t use 1xfer and icrc2\_transfer\_from use 2xfer? I was thinking the same thing. One `btype` for each method. icrc1\_transfer: `1xfer`, icrc2\_transfer\_from: `2xfer`. ---
**Author:** ![mariop](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/mariop/32/5114_2.png) [@mariop](https://forum.dfinity.org/u/mariop)\ **Post date:** [March 19, 2024, 12:51pm UTC](https://forum.dfinity.org/t/icrc-3-draft-v2-and-next-steps/25132/75 "2024-03-19T12:51:23Z")
Good point, I’ll change the draft. By the way, today’s working group is going to be again about ICRC-3 and the latest updates. If you are interested in the standard then join us! ---
**Author:** ![mariop](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/mariop/32/5114_2.png) [@mariop](https://forum.dfinity.org/u/mariop)\ **Post date:** [March 19, 2024, 4:36pm UTC](https://forum.dfinity.org/t/icrc-3-draft-v2-and-next-steps/25132/76 "2024-03-19T16:36:28Z")
@skilesare @kayicp I’ve made the change. The spec now reads: > 1. the `btype` field MUST be > 1. `"2xfer"` for `icrc2_transfer_from` blocks > 2. `"1xfer"` for `icrc1_transfer` blocks I’ve decided to keep one section for both blocks because they contain the same fields minus the `spender`. ---
**Author:** ![mariop](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/mariop/32/5114_2.png) [@mariop](https://forum.dfinity.org/u/mariop)\ **Post date:** [March 19, 2024, 5:25pm UTC](https://forum.dfinity.org/t/icrc-3-draft-v2-and-next-steps/25132/77 "2024-03-19T17:25:01Z")
I got no more comments. I’ll let the draft up for a couple more days and then I’ll make the NNS motion proposal. ---
**Author:** ![mariop](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/mariop/32/5114_2.png) [@mariop](https://forum.dfinity.org/u/mariop)\ **Post date:** [March 25, 2024, 4:41pm UTC](https://forum.dfinity.org/t/icrc-3-draft-v2-and-next-steps/25132/78 "2024-03-25T16:41:56Z")
Hi, the [motion proposal for ICRC-3 is live](https://dashboard.internetcomputer.org/proposal/128824) and to be voted by the NNS. Thanks everyone who helped with the standard. ---
**Author:** ![Roman](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/roman/32/6307_2.png) [@Roman](https://forum.dfinity.org/u/Roman)\ **Post date:** [March 25, 2024, 4:47pm UTC](https://forum.dfinity.org/t/icrc-3-draft-v2-and-next-steps/25132/79 "2024-03-25T16:47:33Z")
Marvelous ! Congratulations to you all for this hard and patient work ! ---
**Author:** ![gatsby\_esp](https://avatars.discourse-cdn.com/v4/letter/g/e95f7d/32.png) [@gatsby\_esp](https://forum.dfinity.org/u/gatsby_esp)\ **Post date:** [March 25, 2024, 6:23pm UTC](https://forum.dfinity.org/t/icrc-3-draft-v2-and-next-steps/25132/80 "2024-03-25T18:23:07Z")
Rosetta is dependant on ICRC 3 right? How long until rosetta? Got an update? ---
**Author:** ![mariop](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/mariop/32/5114_2.png) [@mariop](https://forum.dfinity.org/u/mariop)\ **Post date:** [March 25, 2024, 6:54pm UTC](https://forum.dfinity.org/t/icrc-3-draft-v2-and-next-steps/25132/81 "2024-03-25T18:54:20Z")
Rosetta is not dependent on ICRC-3 and it’s using the interface for fetching blocks that the existing canisters provide ([get\_blocks](https://dashboard.internetcomputer.org/canister/mxzaz-hqaaa-aaaar-qaada-cai#get_blocks) to be specific). This allowed us to develop Rosetta without having to wait for the standard to be voted. Rosetta is currently feature complete and we just did the security review. The team is now addressing the findings and then we can release it. The plan is to eventually move Rosetta to use ICRC-3 to fetch the blocks but that doesn’t block the release of Rosetta. ---
**Author:** ![dieter.sommer](https://avatars.discourse-cdn.com/v4/letter/d/b487fb/32.png) [@dieter.sommer](https://forum.dfinity.org/u/dieter.sommer)\ **Post date:** [March 26, 2024, 1:27pm UTC](https://forum.dfinity.org/t/icrc-3-draft-v2-and-next-steps/25132/82 "2024-03-26T13:27:01Z")
Awesome, hope this gets adopted! ---
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [April 12, 2024, 5:53pm UTC](https://forum.dfinity.org/t/icrc-3-draft-v2-and-next-steps/25132/83 "2024-04-12T17:53:33Z")
Does anyone have any thoughts on how one should write a motoko float into an ICRC3 transaction log? Is there a quick and dirty function to get the components of a float so it can all be put back together again? If so we can do a map of those components. The options I’m seeing are outputting text with #exact, but I’m not sure how to put the bbs back in the box with that. Can we not get the sign, exp, and Mantissa exposed to motoko? Can Prim do it? [Previous page](https://forum.dfinity.org/t/icrc-3-draft-v2-and-next-steps/25132.md?page=3)