# ICRC-3 Draft v2 and Next Steps

**URL:** <https://forum.dfinity.org/t/icrc-3-draft-v2-and-next-steps/25132>\
**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:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![infu](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/infu/32/11321_2.png) [@infu](https://forum.dfinity.org/u/infu)\
**Post date:** [February 10, 2024, 2:31pm UTC](https://forum.dfinity.org/t/icrc-3-draft-v2-and-next-steps/25132/3 "2024-02-10T14:31:45Z")

</div>

The inner block schemas - couldn’t they be Candid as well? Just a binary we can decode later.

Usage will then be:

```auto
// Where ICRC_Transfer is a custom type
let ?transfer : ICRC_Transfer = from_candid(block.content) else Debug.trap("err");
let from = transfer.tx.from

```

Instead of using it like this:

```auto
let #Map(m) = block else Debug.trap("err");
let ?tx = Array.find(m, func (k, v) = k == "tx") else Debug.trap("err");
let #Map(txm) = tx else Debug.trap("err");
let ?from = Array.find(m, func (k, v) = k == "from") else Debug.trap("err");

```

I guess that’s not only a question for icrc-3, but in general a lot of icrc’s are getting these generic variant schemas. By now every CDK should have to\_candid and from\_candid equivalent. I think in size - they will be equal or Candid version wins. In speed - running multiple Array.find’s to get your values out, will probably be slower too and require libraries that make it usable. @claudio Makes me wonder what’s the problem with the first way of doing it having binary candid sub schemas.

---

_[View the full topic](https://forum.dfinity.org/t/icrc-3-draft-v2-and-next-steps/25132)._