RFP: ICRC-16 Compatible Rust Cargo Component for the Internet Computer

RFP: ICRC-16 Compatible Rust Cargo Component for the Internet Computer


  • Status: Open

  • Project Type: Cooperative - Multiple workers can submit work, and the bounty is shared.

  • Time Commitment: Estimated <1 week

  • Experience Level: Beginner to Intermediate

  • Size: Possible < USD 5,000 via Grant, 60,000 Event Utility Working Group Tokens/hr.

  • Proposing Group: The Events Utility Working Group


In the rapidly emerging sector of decentralized applications, standardization of data exchange formats is crucial for interoperability and efficient communication between canisters on the DFINITY Internet Computer. The ICRC-16 EnhancedValue standard proposes a Candid-Compatible interface for a flexible, standardized exchange of unstructured data.

Our goal is to create a Rust cargo component that fully implements the ICRC-16 EnhancedValue standard, ensuring compatibility and functionality in a Rust project environment. This component should provide developers with the necessary tools to seamlessly integrate and manipulate ICRC-16 data types.

Project Deliverables

This Rust cargo component should provide:

  1. Data Types:
  • Define all necessary Rust data types corresponding to the ICRC-16 EnhancedValue Candid variants.
  1. Conversion Functions:
  • Implement helper functions that facilitate the conversion between ICRC-16 variants and native Rust types.
  1. Interface Methods:
  • Provide implementation for the interaction of these data types with the Internet Computer, including serialization and deserialization to/from Candid.
  1. Size Calculation:
  • Provide implementation for the estimation of the size of an object in bytes.

Acceptance Criteria

The deliverable must:

  • Fully support all variants outlined in the ICRC-16 standard’s Candid definition.

  • Include comprehensive documentation detailing usage and integration processes.

  • Provide a robust suite of unit tests demonstrating the correctness of the implementations and conversion functions.

  • Be published on a public repository under an open-source license (preferably MIT or similar).

  • Offer examples demonstrating practical implementations of the component in sample Rust projects.

How to Apply

Interested developers should submit an application via the Public Developer Grants process as outlined here: Introducing Public Developer Grants and should attend the Event Utility working group to share their proposal.


For any queries or clarifications, reach out on the discussion thread or comment on the issue at Rust ICRC-16 Library · Issue #32 · icdevs/ICEventsWG · GitHub.


The creation of this Rust cargo component is a step towards enhancing the ecosystem’s capability to manage and utilize unstructured data effectively, following the ICRC-16 standard. We invite capable Rust developers to contribute to this effort, paving the way for more standardized and cohesive data handling within the Internet Computer’s diverse and expanding application landscape. This component will be a key input into the rust client for ICRC-72 and a such the Event Utility WG is offering 60,000 tokens / hour spent on the item given an agreed upon estimate. We would recommend this project be granted a DFINITY public grant as well, although it my not be a full $5,000 grant.


We have already tools generating Java proxy classes from Candid IDL files. Currently we also generate Motoko types from existing Java classes. Let me investigate how we can use same libraries to generate Rust artifacts from IDL. This would simplify any future Candid integrations. Let me also see if we can use some AI to generate documentation.

1 Like

I strongly recommend using CBOR (Concise Binary Object Representation, RFC8949), as it is very mature.


Interesting initiative! Another direction towards a soft bounty/grants DAO!

I’m interested in your recommendation.

The Event Utility has one value proposition of creating a way for canisters to communicate with other canisters that are interested in its activities without that canister having to know about the other canisters and/or, in some cases(like an indexing service), those canisters needing to know the schema of the incoming message. Since inter-canister communication on the IC is generally candid unless you’re specifically trying to exclude significant portions of the ecosystem, we currently have the data payloads using standard candid, specifically, ICRC-16-defined candid.

Now of course one of those variants is #Blob and you can stick whatever you want in there, so your payload could be #Blob({CBOR}). We have specifically, and one of our WG members, Lachlan is specifically writing up some best practices around this which you can see here: Adopt CBOR as a standard binary encoding format for message payloads · Issue #9 · icdevs/ICEventsWG · GitHub.

So there will be recommendations for how to use CBOR, but generally, you need to keep in mind that if you use it you are significantly limiting the interoperability of your platform on the IC. (This may be fine in a closed loop icrc-72 implementation, but shouldn’t be the case for open internet services).

1 Like

@DunkanMcLoud is currently investigating bringing his previous component up to the latest version which would help accomplish this RFP. Thanks, DunkanMcLoud!

I have delved deeper into the topic to assess the effort required to improve the existing library: candy-rs.

Based on my analysis, adding a couple of additional types and test cases would suffice to create a type system for Rust developers. This task appears straightforward and could be completed in a few evenings, likely taking less time than going through the grant application process.

One point that remains unclear to me is the byte size estimation, which currently differs between the existing Rust and Motoko libraries. This discrepancy is highlighted in the following integration test: size.test.ts.

To achieve a more thorough implementation, I need advice and a code review from a more experienced canister developer, particularly for properly implementing byte size estimation or deciding whether to leave it as is. I am also uncertain about the specific use cases for this functionality, so I am requesting suggestions from such a developer for modelling in an additional integration test.

I am willing to work on this library without submitting an extra grant application since it is my previous project and the scope of changes seems manageable. If anyone is already working on this task, I encourage them to pay special attention to the last point mentioned.


We’d love to have you on the call Wednesday to discuss your proposal(I expect unanimous agreement). Since it is smaller, we can just do the WG tokens which may be used to seed the team allocation of a future DAO, but are pretty much just internet cool points at the moment.


This weeks agenda should be up soon.


I’ve made a mistake when claimed that byte size estimation is not ok in previous version, seems it was done right, I just forgot about it :slight_smile:
I will add a couple of test cases and hope to complete current iteration of development this week

Hi @skilesare. Just published an updated crate. Check this out, please