Assigned: BNT-5 - ICRC-7 NFT Implementation (Rust or Motoko)


Status: Open
Project Type: Cooperative - Multiple workers can submit work, and the bounty is shared
Time Commitment: Weeks
Experience Level: Intermediate
Size: USD 7’000 in ICP (at time of distribution)


As part of the ICRC process, we aim to provide production-level implementation code to speed up adoption. This bounty concerns the ICRC-7 NFT standard which is being finalized in the working group.

The applicant is expected to have understood the current draft of ICRC-7 as well as the intentions of the working group and the design trade-offs made, implement according to the specification, and report back to the working group on a bi-weekly basis about any findings during implementation and suggestions on how the standard could be improved.

Familiarity with the fungible token standards ICRC-1, ICRC-2, and ICRC-3 is a plus.

Use Cases

NFTs on the IC.

Acceptance Criteria

  • The implementation shall fully implement the ICRC-7 draft proposal.
  • The code shall be of production quality, have good documentation and reasonable test coverage.
  • The code shall be open sourced with an MIT license.
  • The code will be considered 80% complete when the above criteria are met, and 100% complete when it passes the security audit with all problems fixed (the applicant does not bear the cost of the security audit).

How to apply?

Include links to previous relevant work.
Include a brief overview of how you will complete the task.
Post your application text in this thread.


[1] ICRC-7 Github. ICRC/ICRCs/ICRC-7 at main · dfinity/ICRC · GitHub


Hello. I would like to be assigned to work on this bounty.

Relevant experience:

Rough estimate timeline:

  1. Designing base canister with basic read methods outlined in spec 3-4d
  2. Implementing transfer method 1-2d
  3. Implementing transaction deduplication 1-3d
  4. Making sure implementation is conformant to spec and testing implementation 4-5d
1 Like

Hello. Thank you for your interest. Would you be able to participate in our next WG meeting on Tue 25th? It’d be helpful if you could better understand our goals. @ttt

I will definitely try. Can you DM me the link? I couldn’t find myself.

I’ve changed the bounty to allow proposals for a Rust or a Motoko implementation.

The event is in the general Technical Working Group calendar.

1 Like

@ttt @domwoe We agreed in the WG meeting of Apr 25 2023 to attribute this bounty to @ttt. He estimates 3 weeks to complete this implementation.

1 Like

Additionally, the HTTP interface and the transaction history are not part of this bounty, there will be a separate bounty in the future for those points.

The implementation is expected to be of production quality, including our best practices, using stable memory.

1 Like

Hey. Sorry for not updating you on my progress. I’ve published my workings here: GitHub - holykol/icrc7

There are a few todos left, I expect to complete them in a ~2-3 days:

  • stable memory
  • approvals
  • readme and CI

I am using ic-kit for auto .did generation and excellent testing harness. Thanks to it the code already has about 70% coverage and I expect that to increase in a few days

1 Like

On a side note, I will be expanding icpunks standard to match icrc7, so we will have two implementations :slight_smile:


Few questions and random notes regarding spec:

  • why does text in icrc7_metadata : (nat) -> (vec record { text; Metadata }) query; mean? What should it represent?

  • took liberty of naming fields in type Metadata = variant { Nat : nat; Int : int; Text : text; Blob : blob }, see below:

pub struct TokenMetadata {
    pub icrc7_id: TokenID,
    pub icrc7_name: String,
    pub icrc7_image: Vec<u8>,
  • Just a note: if transfer only accepted one token, the code for this and all future implementations would be simpler. Was this added because of high latency of updates?

  • If approvals can have infinite duration (when expires_at is set to None), shouldn’t there be a way to revoke approval and list existing approvals?

  • I assume approval does not expire when it is used, right? From my background: in Solana there can be only one approval for account at a time. Also after delegate used approval (e.g. transferred something), approval gets revoked.

  • Should approvals also be deduplicated? I assume yes because of memo and created_at fields

I’ve pushed support approvals, transaction deduplication and stable memory.
All that remains now is more documentation and timer for purging old transfers. Also maybe GenericError handling can be improved a bit.

The code coverage shows 82.56%, but it’s definitely higher because grcov treats structs as uncovered lines of code for some reason. Also because 99% of the tests are integrational (thanks, ic-kit!), I’m sure they can be ported with little or no effort to make sure another implementation is compatible with spec. Definitely a thing worth researching.

@domwoe @benji I think the project is pretty stable now and is ready for review. I’m looking for in-depth feedback.


Can you share the github repo? I would like to test lightic testing framework against your integration tests

1 Like

it’s icrc7/ at master · holykol/icrc7 · GitHub, as I mentioned it will require some adaption if yours is not written using ic-kit @stopak

1 Like

hey, i think the way you currently implemented icrc7_metadata it’s deviating from the standard.
(vec record { text; Metadata } means that there should be a vector of tuples that contain a text field that represents the name of the metadata and then a Metadata field that contains the actual metadata. Metadata again is of type variant { Nat : nat; Int : int; Text : text; Blob : blob };, which makes it very flexible. The metadata name fields are supposedly not part of the ICRC7 standard, afaik.

See this playground for an example implementation.

1 Like

Thanks for clarification. I’ll update it in the next commit @cryptoschindler

1 Like

Hi ttt, any new updates on your icrc7? I want to use your icrc7 in my own project.

1 Like

hey. I am currently in the process of figuring out how to remove ic-kit without sacrificing testing abilities. However, I think that the code is ready to use, since API will only have minor changes or changes at all.

1 Like

I disagree with your assessment. I opened multiple issues in your github repo. Most of them are basic errors.

1 Like

thank you, I was using the code blindly.