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)
Description
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.
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
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.
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
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.
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.
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.