Announcing ICRC7/ICRC37: A Complete NFT Implementation for the Internet Computer

Developers
1

Announcing ICRC7/ICRC37: A Complete NFT Implementation for the Internet Computer

Introduction

Hello Internet Computer Community!

We’re excited to share ORIGYN’s latest contribution to the IC ecosystem: a complete implementation of the ICRC7/ICRC37 NFT standard for the Internet Computer. After months of development and testing, ORIGYN is ready to invite the community to explore, test, and provide feedback on this comprehensive solution.

Building on Our Previous Work

As some of you may remember from our ICRC3 announcement, we’ve been working hard to create reusable components for the IC developer community. We structured our codebase to be modular and reusable, allowing developers to leverage specific components for their own projects.

Our ICRC3 transaction standard implementation was just the beginning, and now we’re expanding with this comprehensive NFT solution that leverages the same principles of reusability, standards compliance, and developer-friendly design.

What We’ve Built

This project provides a production-ready implementation of the ICRC7/ICRC37 NFT standard, consisting of three main components:

1. Core NFT Canister

  • Full implementation of the ICRC7/ICRC37 standard

  • Integrated ICRC3 transaction history

  • Certified responses for all queries

  • Fine-grained access control for NFT operations

  • Flexible storage integration options

2. Storage Canister

  • High-performance asset storage solution

  • Stable memory storage for persistence across upgrades

  • Intelligent heap caching system for frequently accessed assets

  • Certified HTTP asset serving

  • Automatic memory management

  • Optimized for minimal latency

3. Integration Tests & Example

  • Comprehensive test coverage ensuring reliability

  • Complete example for deploying an NFT collection

  • Step-by-step guide for minting and managing NFTs

  • Documentation for all available operations

Key Features and Benefits

Standards Compliance

  • Full implementation of ICRC7/ICRC37 NFT standard

  • Integration with ICRC3 for standardized transaction history

  • Forward compatibility with future ICRC standards

Performance and Reliability

  • Optimized storage solution using stable memory

  • Intelligent caching mechanisms for frequently accessed assets

  • Efficient memory management

  • Certified responses for security

Developer Experience

  • Easy-to-use API for NFT operations

  • Comprehensive documentation

  • Complete example implementation

  • Command-line tools for managing collections

Flexibility

  • Modular architecture allowing component reuse

  • Customizable metadata structure

  • Configurable collection parameters

  • Support for various NFT use cases

Why This Matters for the IC Ecosystem

The Internet Computer needs a robust, standardized approach to NFTs that developers can rely on. Our implementation aims to:

  1. Standardize NFT operations: Provide a consistent interface for wallets, marketplaces, and applications

  2. Reduce development effort: Offer a production-ready solution developers can adopt immediately

  3. Improve interoperability: Enable NFTs to work seamlessly across different applications

  4. Showcase best practices: Demonstrate efficient patterns for canister development

  5. Build community expertise: Create a shared understanding of NFT implementation approaches

Community Involvement

While this implementation is still in beta, we believe strongly in the power of community-driven development. We’ve structured our code to be as reusable as possible, making it easy for anyone to adopt and build upon.

We need your help to make this truly excellent! Please:

  • Test the implementation: Deploy your own collection using our example

  • Provide feedback: Share your thoughts on the architecture and API design

  • Suggest improvements: Identify areas where we can enhance functionality

  • Report issues: Help us identify and fix any bugs or limitations

  • Consider adoption: Try using this implementation in your own projects

  • Contribute: Add features or improvements via pull requests

Creating a robust NFT standard implementation for the Internet Computer requires community collaboration, and your input is invaluable. Together, we can build a solution that meets the needs of the entire ecosystem.

Grant Application

We’re planning to apply for a developer grant to support the ongoing development and maintenance of this project. The grant would help us:

  1. Expand documentation: Create comprehensive guides, examples, and tutorials

  2. Enhance performance: Optimize for various usage patterns and scale

  3. Add features: Implement additional functionality based on community feedback

  4. Ensure compatibility: Test with various wallets, marketplaces, and applications

  5. Provide long-term support: Maintain and update the implementation as standards evolve

Your support for our grant application would be greatly appreciated and would help ensure this project continues to serve the community’s needs.

Getting Started

The project is available on GitHub at https://github.com/ORIGYN-SA/nft.

To deploy your own NFT collection, follow these steps:

  1. Clone the repository

  2. Set up your environment variables

  3. Deploy the collection using dfx

  4. Upload assets using our command-line tools

  5. Mint your first NFTs

Detailed instructions are available in the example directory.

Next Steps & Roadmap

We’re committed to making this the gold standard for NFTs on the Internet Computer. Our roadmap includes:

Short-term

  1. Finalizing the beta: Addressing community feedback and fixing any issues

  2. Documentation improvements: Creating more examples and tutorials

Medium-term

  1. Continue work on ICRC3: Expand our ICRC3 implementation and add an indexer to facilitate transaction interactions

  2. Repository separation: Split the ledger and storage canister repositories to provide more flexibility in how the ledger can be used

  3. ICRC-97 support: Once validated by DFINITY, implement the ICRC-97 standard to ensure compatibility with Oisy and NFID, which are waiting for this standard to move forward

  4. Intregration with Claimlink : See above Origyn bought Claimlink

Conclusion

We’re incredibly excited to share this implementation with the community and look forward to seeing what you build with it. Your feedback and contributions will be essential in making this a truly exceptional solution for the Internet Computer ecosystem.

Thank you for your support, and we can’t wait to hear your thoughts!

Resources:

19 Likes
2

We are thrilled to share ORIGYN’s ICRC7/ICRC37 implementation with the community today! After months of work, it’s fantastic to release this complete NFT solution for the Internet Computer. I can’t wait to see what you’ll build with it and hear your feedback.

3 Likes
3

Hey, thank you for this,

I looked over the code,

pub struct Icrc7Token {
pub token_id: Nat, // ~8-16 bytes (depending on size)
pub token_name: String, // ~20-50 bytes typical
pub token_description: Option, // ~0-200 bytes typical
pub token_logo: Option, // ~50-100 bytes (URL)
pub token_owner: Account, // ~32 bytes (Principal) + 32 bytes (optional subaccount)
}

Per NFT: ~150-400 bytes (conservative estimate)

pub struct Approval {
pub spender: Account, // ~64 bytes
pub from: Account, // ~64 bytes
pub expires_at: Option, // ~8 bytes
pub created_at: TimestampNanos, // 8 bytes
pub memo: Option<Vec>, // ~0-64 bytes
}

  • If 10% of NFTs have 1 approval: ~20 MB
  • If each has multiple approvals: could be 100+ MB

Each transaction: ~200-500 bytes

For 1M NFTs with moderate activity:

  • Core NFT data: ~300-800 MB
  • Approvals: ~20-100 MB
  • Transaction history: ~400 MB - 2.5 GB
  • Other state: ~50 MB
  • Total: ~1-3.5 GB

I made claude analyse the total storage and it looks like once it will reach 1 mil entries, considering candid adds an overhead of 20-30% in size during upgrades it will most likely fail, (4gb heap limit, intruction limit) so why not go all the way with stable storage? (except metadata)

Why did you choose MessagePack vs cbor? I know the NFT structure is overall simple and both perform almost the same (even though CBOR handles binary data natively)

2 Likes
4

Hey,
Thanks for this.
Transaction history are stored with icrc3 in stable memory (ie : archived).
I just had some reviews issues also here, as icrc3_add_transaction is async now, due to archive calls. I’ll goes from this to a icrc3_add_transaction no-async method, and use a job thats will automaticly archive transaction after a certain time.
For nft metadata, that was something i had in mind, and my first implementation was using storage canister also for nft metadata, and stored in stable memory. And then i had some issue with icrc3 standard, as a few calls where async, or needed to have update calls instead of query calls (or composite query, but as composite query only works on same subnet…)
So i moved to store metadata on heap right now, but yeah i plan to move this part to store nft metadata on stable memory. I think approvals, and others states can stay in heap, and we should be fine that way. What do you think?
Regarding cbor, it’s on my todo list for improvement also, i already had a comment from dfinity regarding this point. I need to take to time to dig on this part.

Thanks for your review, glad community is helping here !