This repository hosts standards for creating and interacting with RMRK.app NFTs.
There are two types of standards: entities and interactions. Entities are definitions for how a collection or NFT should be declared while being minted, so that tools can recognize them as valid. Interactions are interactions between the off-chain world and the RMRK protocol, between those NFTs, and between different users and NFTs.
The standards currently cover the following basic interactions:
- MINT creates a new collection
- MINTNFT creates a new NFT inside an existing collection
- CONSUME burns an NFT
- CHANGEISSUER changes the owner of the collection, affecting who can issue NFTs
- SEND, BUY are transactional
- LIST is used to list an NFT as for-sale on-chain
- MIGRATE (starting with 1.0.0) allows a collection issuer to migrate a collection and its child NFTs to a new standard
Inspect each standard folder to see the specifics about these interactions and how to integrate them.
A collection of NFTs is an entity. An NFT inside a collection is an entity as well.
RMRK standards versions will be tagged as a release. Each release will contain all previous major and minor versions so that an implementer checking out the latest release can decide which ones to support alongside the latest.
A released version is never worked on again - all changes must happen via RIPs and will apply to the next version only. It is up to the implementing library / UI to see previous versions as invalid or demand a migration from an old version to a new version of an NFT (this will usually involve a CONSUME of an earlier NFT and a MINTNFT into a newer version of the collection) or a MIGRATE interaction. To be kept up to date on version changes, please Watch this repo or subscribe to Dot Leap or NFT Review.
- n/a
To contribute, please create a new RIP (RMRK Improvement Proposal) as per this template.
Interested in implementing these standards? Check out the Implementer's Guide.
The following is a list of implementations of these standards:
- RMRK.app Tools (TypeScript) (IN DEVELOPMENT)
The RMRK standards will always support the very minimum of functionality needed to interact with NFTs. However, some projects may want or need more logic, or more specific integration. Let's say for example that someone is building a CryptoKitties game in which cats can "breed" to produce an offspring with some random on-chain attributes adding special uniqueness to the new cat token. The game devs would:
- integrate with an implementation of RMRK
- wrap RMRK functionality in their own library
- define their own game's rules
- MINT and do other interactions as per RMRK standards, but reacting to their custom rules
As an example, let's assume that we have a user who owns Cat A and Cat B and wants to breed them to get Cat C. Let's assume that breeding requires 100 blocks of time, and that a breeding results in an egg, this egg needs to incubate for 100 blocks, and then the user needs to manually hatch it.
To implement this, the CryptoKitties game devs would:
- add a BREED and a HATCH interaction on top of the RMRK standards they already inherit through an implementation.
- once BREED is called by a user, the starting block is logged (e.g. X).
- at block X+100, the user can call HATCH and the egg hatches. The block hash is used as a seed for the random attributes of the new NFT.
- a new NFT is created and assigned to the breeder.
- given that the NFT is minted according to RMRK standards, it will be automatically compatible with any tools and UIs that follow the standard as well.
Note: A tricky part is step 4 - minting and assigning a new NFT to the breeder. This would require a new entity type given that only an issuer is allowed to mint new NFTs, but then the new entity is not automatically compatible with wallets and UIs following RMRK, given that they're not familiar with the CryptoKitties standard. This introduces a barrier to market entry for the CryptoKitties devs. A better alternative is skipping user-initiated hatching and hatching programmatically from CryptoKitties game devs' end, but this introduces a reliance on their service for the continuation of the game.
This is an active area of research which we hope to have ironed out soon - ideally with an action-triggered MINT addition to the standard.