# Dawn of the NFT Legos

This post will document some examples of what becomes possible with RMRK - a set of NFT 2.0 legos that, when put together, allow you to compose a cross-chain cross-media cross-collection compatible system of advanced but backwards compatible NFTs.

## NFT Legos

The following few sections document the various _legos_ we developed as part of RMRK 2.0. Later on, we will go into a combination of these legos to see what their combinations make possible.

### Nested NFTs

**NFTs that can own and equip other NFTs.**

Think in-game characters and their inventories, or house deed NFTs containing an album (another NFT) of photographs of the previous construction project.

NFTs can be minted and equipped into other NFTs which can then gain new functionality based on which NFTs they "own". This can also be abstracted into user-made collections, where a basket of NFTs can be for sale rather than listing them all one by one.

Nested NFTs also have the ability to _equip_ other NFTs, for which there are designated slots. Some of these NFTs can also be non-transferable, effectively becoming "soulbound" to _another_ NFT.

With RMRK, any NFT can contain any other NFT, no strings attached, no special configuration needed.

More detailed info about this lego [here](https://docs.rmrk.app/lego1-nested) and [here](https://docs.rmrk.app/lego25-equippable).

### On-chain emotes

**On-chain reactions to NFTs - anyone's NFTs.**

Reactions are emotes, something you'd expect to see on a social website like 👍 🔥 ❤️ etc. We support the whole set of unicode emotes, and these can be rendered by any UI implementing the RMRK standard, making the social activity of reacting on someone's NFT visible across the whole ecosystem.

On chain emotes allow for interesting mechanics of price discovery where popular NFTs evoke a lot of emotion and are therefore presented as more relatively valuable than their peers.

Emotes can also be very interesting ways of categorization with "emojilists" where users can curate their NFTs based on some emotes they marked them with, and then share these lists.

More info [here](https://docs.rmrk.app/lego3-emote).

### Conditional Rendering

**Change output based on some on-chain or off-chain value.**

Conditional rendering is the ability of a certain NFT to display different visuals depending on certain conditions, like flipping an artwork upside down if it has enough 🙃 emotes on it.

If some value exists on-chain, the NFT can react to it by changing its look or functionality. If a switch is flipped in the NFT itself (see Custom Fields below), this can also invoke a different render.

Conditional rendering is defined with special rules on the NFT itself, and is currently [jsonlogic](https://jsonlogic.com/) but algorithmic modifications are being explored (boxed eval).

More info [here](https://docs.rmrk.app/lego4-conditional-rendering).

### Multi-resource NFTs

**An NFT can have multiple resources (outputs) defined on it, of same or different type.**

Multiple images, coupled with a 3D model, and maybe a PDF instruction manual. In the case of identical resource types, the user can define which resource is default and can switch this value at will by interacting with the NFT.

As an example, an audio book NFT can be minted with three resources: an audio file, a PDF, and a high resolution cover. The loading of each resource would depend on the context it is loaded in, so if you load the book into Audible, it plays. If you load it into [Singular](https://singular.rmrk.app), it opens the built-in PDF reader. If you load it into Opensea to sell it, the high-res cover is shown on the search results and collection pages.

This is also the way to make gaming accessories multi-game. A single skin cannot easily be ported to another game because of difference in engines, rigging. With multi resource NFTs, this becomes trivial - a single NFT can have two different files, each loaded in its own context on demand.

More info [here](https://docs.rmrk.app/lego2-multi-resource).

### NFT DAOs

**Collective pushing of an NFT's buttons.**

NFTs are now interactive and can emit actions, send items, equip them, change state, and more. Some of these NFTs might be unique and [too expensive](https://twitter.com/RmrkApp/status/1463614397826449413) for individuals to hold in their entirety.

Each NFT will be breakable into a number of fungible tokens where these tokens can be used to issue DAO-like commands to the NFT, e.g. the community can vote to EQUIP an item.

To break an NFT into fungible tokens, the owner must stake some [$RMRK tokens](https://kanaria.rmrk.app/tokens). This prevents fungible token spam.

## Examples

Now let's look at some examples of what becomes possible when we put these new **NFT legos** together.

### The Multi-resource NFT

A multi-resource NFT is one that has multiple resources equally applicable to it.

An NFT can be a video game that contains JS code that executes when it's loaded in the browser, a high resolution image of the game as cover art, and a PDF manual of how to play the game. If you load this NFT in Opensea, their UI will know to load the high-res image to represent the NFT. If you load it on RMRK's Playground, the marketplace for NFT-based games, the game can also be played. In both cases, the PDF will come attached as a separate resource on the NFT.

An NFT that is a 3D model can have the actual model file, a high res image of it, and a thumbnail. A SERP page will load the thumbnail, a listing page will show the high res photo, or the model if it can support rendering them, and with the RMRK plugin, a tool like 3Ds Max or Maya or Blender can load the model file directly from the UI.

This is especially useful for metaverse applications as described [in the Skybreach post](https://url.rmrk.app/meta) where an avatar can have a 3D version, a cover version, and a 2D pixel version of itself, making itself compatible with different universes at the same time without relying on the centralized provider which is creating the "metaverse".

Note that multi resource NFTs are not nested NFTs - alternative resources are part of one NFT, but that NFT can still contain _other_ NFTs (nested NFTs) each of which can itself have multiple resources and its own children.

### NFT Custom Fields

The NFTs in RMRK2.0 also have mutable fields on the NFTs themselves that owners and/or issuers of the collection can set.

The NFT will inherit the mutable fields of its collection, but each NFT instance can individually override them.

By using custom fields, an NFT can alter its functionality or artwork. As an example, a background image can be equipped onto another NFT to change the background. Supposing that this background image NFT has a `season` flag, if we switch it to `winter` from `summer`, the parent NFT can now find itself in a snowy environment.

This field can be switched by whoever is defined as allowed to be doing this: the collection issuer, the NFT owner, or someone else entirely.

### Resource Adding

With multi-resources, there is sometimes a need to add a resource, like a different rendering style, long after the NFT's original minting.

The issuer of a collection can create an alternative resource for an NFT in that collection, and then suggest it to the owner on-chain. The owner has to accept this new resource, thereby preventing the issuer from rug-pulling their art. The owner cannot add new resources to fake the appeal of their NFT willy nilly.

This is useful for adding utility to NFTs after the fact, making an existing game's assets compatible with new upcoming games, and adding value to them in perpetuity, allowing for a global supercharged creator economy.

### The Multi-resource NFT: Priority Switch

A multi-resource NFT can, for example, have several images. A Vorpal Blade NFT can have a beautiful stylized drawing or a realistic render.



The user can change the priority of the display by choosing which of these is the default. This way, the user picks between two different displays of the same NFT with a switch, and all UIs implementing the standards easily render this, across the board, in any app.

One example where this is in use is in Kanaria's secondary art. If you visit the [bird catalogue](https://kanaria.rmrk.app), you will notice some birds are very different to others. This is because they have multiple artworks attached, and any user can scroll through these alternative renderings of the same NFT.


An additional use case of Multi Resource NFTs is being able to back-up the asset of the NFT on various platforms. These days many NFT projects pick a centralized server to host you artwork, and when the server goes down they can "rug-pull" your art. Things like this can happen:


However, if NFT assets are instead stored on multiple immutable media platforms at once, like Arweave, Crust, Filecoin, and IPFS, through 4 resources, you end up with redundancy that protects your art indefinitely.

**It is absolutely essential to have redundancy built-in to the core layer of the NFTs**, and not to force users to use a certain storage solution. This is the only way to remove risk of failure - by exponentially reducing the probability of all the platforms that host an asset to go down.

### Conditional Rendering: Reactive Painting

RMRK 2.0 NFTs use [jsonlogic](https://jsonlogic.com/) to add conditions into the NFTs that are non-turing-complete, **but require no smart contracts**.

A user draws a digital painting of a moon. This painting has two resources: an image where it's just a moon, and an image where it's a moonbase on a moon.

The NFT has a logic block like this one:

...
    "logic": [
        {
            ">": ["emotes.🚀", 50],
            "priority": [1, 0] // change prio based on condition == true
        },
...

To the RMRK system, this means "if people have collectively EMOTEd more than 50 🚀 to this painting, switch priority to [1, 0] instead of whatever it is now".

Assuming the moonbase is in the `resources` list at index `1`, and the plain moon at `0`, the NFT will display the moonbase by default for as long as the number of rocket emoji on it is above 50.


### Nested NFTs

In RMRK 2.0, the `owner` of an NFT can be an Account on the chain, or it can be another NFT's ID. This means the system supports implied NFT nesting.

In order to mint a bundle of NFTs to sell them all at once, all a user has to do is mint an NFT and send them all to this one. There's no special class or flag to activate.

_Note that the user will still have to define the price of each child separately but in a single UI. This is to prevent a royalties distribution issue which is outside the scope of this post._

The NFTs do not have to be of the same type. Wanting to sell an NFT bundle called "Genesis #1s", thus minting an NFT that will contain Kanaria #1, SubstraPunk #1, and Chelobrick #1, as the first three instances of the first three NFT projects on RMRK, this is fine.

### Nested NFTs + Composite Rendering

Let's explain RMRK's special `BASE` entity.

With RMRK 2.0, we can compose multi-element characters out of stackable SVG or PNG fragments (or other media soon - music and video experiments are underway).

An NFT can contain or own other NFTs, as explained above. But this can have more depth than in the above use case.

We can define a `BASE` for the NFT, which defines parts and slots. A `BASE` looks like this:

{
    "type": "svg",
    "id": "some-base-id",
    "parts": [
        {
            "bg": {
                "type": "fixed",
                "z": 0,
                "src": "ipfs://ipfs/hash"
            },
            // ...
            "wing_1_back": {
                "type": "fixed",
                "z": 1,
                "src": "ipfs://ipfs/hash"
            },
            "wing_1_front": {
                "type": "fixed",
                "z": 3,
                "src": "ipfs://ipfs/hash2"
            },
            "wing_1_slot": {
                "type": "slot",
                "collections": ["id-of-genesis-legendaries", "id-of-genesis-rares", "id-of-genesis-epics", ...],
                "z": 2
            }
        }
    ]
}

This is an SVG type base, which implies it's used to create a composite NFT.

There are fixed parts, like `bg`, which define the image background at a certain `z` index (`0` means behind everything - the higher the number, the more "above" everything else something is).

But notice the three parts at the bottom: two fixed, and one slot. Put together, these mean: "The wing is composed of a front and a back, and slot in between. The slot can `EQUIP` items from the following collections".

An NFT can use this base by referencing it as a resource:

// ...
    "resources": [
        {
            "base": "ipfs://ipfs-hash-of-base"
        },

Now let's assume an NFT in the collection `id-of-genesis-epics`, which is whitelisted in this base, has the following resources set:

// ...
    "resources": [
        {
            {
                "metadata": "hash-of-metadata-containing-guest-bird-art",
                "slot": "some-base-id.wing_1_slot"
            },
            {
                "metadata": "hash-of-metadata-guest-bird-art-with-jetpack"
            }        
        }
    ]

You'll notice it has two resources, each pointing to a static hash. But one also has a `slot` property that identifies which base and which slot in that base this resource is for.

This makes the NFT *equippable* into the base's slot of the same name.

If the owner of this NFT sends it into the NFT that uses the required base, then the owner of that NFT can issue an `EQUIP` command targeting the child NFT ID and the slot name.

Once equipped, the RMRK renderer will show the SVGs stacked, as defined by their Z index, composing a layered image. This is what makes [Kanaria](https://kanaria.rmrk.app) birds possible.


### Fractional NFTs: NFTs as DAOs

An NFT that is expensive may be out of reach for many people, but they might want to own a part of it.

NFTs in RMRK can be fractionalized into *fungible tokens*, so that the holders of these tokens can not only own a piece of an NFT, but also govern its functions (as a Decentralized Autonomous Organization, or DAO).

To fractionalize an NFT, its owner needs to *stake* (lock up) a certain amount of [$RMRK tokens](https://singular.rmrk.app/tokens). This prevents fungible token spam.

Once the tokens are distributed, the holders can issue collective commands. For example, issuing a default resource priority change is now a semi-plutocratic function of the majority tokenholders.

### The Billboard

The video version of this concept can be seen on Youtube by clicking the image below.

[](https://url.rmrk.app/videobb)

Assume [we have a metaverse](https://url.rmrk.app/meta) with plots of land represented as NFTs.

Assume Bob buys three plots of land.


Assume Bob then finds an NFT on the [Singular market](https://singular.rmrk.app) which is a billboard with two resources: a 3D render, and a 2D high-res version shown on the marketplace.

Bob sends this billboard to the middle land NFT, the land NFT now has this billboard NFT as its child.

Because the Land NFT's primary resource is a `BASE` that has a `structure` slot, and the billboard has a resource matching that base and slot, Bob can tell the land to `EQUIP` the billboard. The billboard appears in the metaverse.


Assume that people who enter the game immediately spawn next to this billboard, so corporations take notice that this billboard is getting a lot of views.

They contact Bob for ad placement. Bob decides to fractionalize this billboard instead of selling ad space outright, and sells the tokens to the community (see Fractional NFTs, above).

It is now up to the corporations to:

- mint the advertisement in the dimensions of the billboard
- send the advertisement to the billboard
- bribe the token holders to pick their ad, and not their competition's


Putting RMRK 2.0 art lego primitives together in such a way allows for community-governed virtual real estate management, an incredibly powerful metaverse concept.

### Mixed Reality

RMRK 2.0 NFTs can be anything, including location-specific entities. Thus, they can overlay on top of the real world based on geo-tagging or even some AR markers.

In the not-so-distant future, we imagine we'll be able to wear AR glasses or lenses that can wipe real-world ads from our view around us. The billboards that currently pester you will be whitespace. Eye-based ad blockers.

But what if we could NFT-ize this whitespace and rent it out to the corporations whose products we're actually interested in, or to ad providers who share profit with us, like Brave?

With an NFT scenario like the Billboard example above, this becomes directly translatable into the real world - along with, for example, plutocratic governance over the massive ads in Times Square. What if the people - everyone - could share in this parallel visual economy?

What if we could hijack our visual surroundings back from the ad corporations and replace the content with what we all collectively agree on, at the same time sharing profits?

### Collaborative 🎶 Compositions

A user can mint an NFT with a BASE which has slots defined for musical notes.

Others can mint notes and send them into this NFT. The empty composition can be DAOified, and the composition can be plutocratically composed of multiple tones to result in a community-built decentralized song that is then tradable and playable as an NFT.

It is then possible to apply royalties to this song's purchases and plays, allowing for the communty to share their creativity's profits among one another.

### Character Progression Systems

The nested NFT concept with equip mechanics lends itself perfectly to games. A character can be an NFT, this NFT can own a backpack NFT, and this NFT can own item NFTs, like potions, food, weapons. Armor from the backpack can be EQUIPped, and curses can be NFTs minted directly onto the character's buff slots, and get "burned" when un-equipped (i.e. cured).

The skill tree can be composed of NFTs, personality traits and experience can also be on a "level card" which in itself is an NFT that can grow over time.

This allows true ownership of experience, as documented in our [Skybreach post](https://url.rmrk.app/meta).

The [Soulbound 2.0](https://docs.rmrk.app/nontransferable) concept exclusively from RMRK allows an avatar to also collect non-transferable tokens like experience points, skills, etc. as well as have an "NFT brain", a non-transferable token with skill slots into which skills can be equipped, etc.

Without pivoting to gaming tech, RMRK is still uniquely capable of powering the decentralized metaverse and character progression systems, purely due to the flexibility of our primitives.

### The Twitch DAO

With fractional NFTs and the above gaming mechanics, it is not hard to imagine a Twitch streamer distributing tokens for their in-game character and letting the community govern, for example, this character's equipment and skill setup for the next raid.

You now have a direct and decentralized way for the audience to interact with what they're watching online.

### Reforestation Game

A real-world parcel of land is bought by a charity, aiming to reforest the land. They need funding.

The tokenize the land into 500 parcels of 5x5 meters. Each tile is an NFT which has two resources: the photo of the land, and a digital representation of the land:


The land NFTs have a dedicated dapp website where they are all rendered via their isometric resource, resembling a game.


The land NFTs can be bought up, funding the charity effort. The ownership is not real, it's symbolic, like in those "Buy a lordship title" deals.

The charity is now funded and can start tiling the land and renewing the ecology.

Once the land is secured and fenced off, protected, regulated, for a second fundraiser the charity organizes the growing of 500 seedlings of trees, different (but compatible) types and breeds.


Users can buy these seedlings as NFTs, send them to the land of their choice, and the owner of the land can equip the seedling on their plot.

With conditional rendering and nested NFTs, the dapp showing the full terrain now also shows the seedlings being virtually planted, but in reality, the charity makes sure to plant those exact seedlings in their exact locations too.


The charity regularly maintains and cares for the seedlings, documenting each parcel's evolution and each tree's growth. These photos are sent into the seedling NFTs as new resources, and new illustrated digital seedling resources are added on top. This lets a digital tree "grow" alongside its real-world counterpart, showing a digital version of this plot of land being reforested in real-time.


## Revealable NFTs

In last-gen NFT systems, selling a collection of seemingly identical NFTs and then "hatching" or
_revealing_ them later into unique NFTs requires centralized metadata where either the tokenURI
points to a centralized server that can be swapped out after launch, or the contract itself has a
mutable metadata field.

This is not very web3.

RMRK's [Multi-Resource NFTs](/lego2-multi-resource) are uniquely positioned to resolve this in a
fully on-chain way, with no issuer rug-pulls being an option.

An NFT can have zero resources, in which case the metadata - including the URI to the media file - is placed in the root level of the NFT, just like in standards like ERC721.

In this case, such a RMRK NFT is fully compatible with ERC721 and is considered to be _revealable_.

If the **issuer** of the collection adds a new resource to an NFT from this collection, this new resource will, if [accepted](/lego2-multi-resource#proposing-accepting-replacing), replace the root-level metadata in all interfaces, renders, wallets, etc.

> ⚠️ A resource **always** takes priority over root-level metadata

You may be wondering if this makes it possible to still rug the art from the issuer side - just keep replacing resources, and eventually replace with something unfitting?

No, in Multi-Resource NFT systems, each mutation like a resource addition or a resource replacement is a two-party operation where the issuer _proposes_ the new resource, and the NFT owner _accepts_ the new resource.

Now, rather than hit the Opensea "refresh metadata" button, the user only has to click "Accept new resource" after inspecting it - and it all happens on chain.

If the owner wishes to keep the old resource or even keep the NFT unrevealed, they can just choose not to accept the new resource (though it should be noted that the revealed resource is on chain in the pending queue - just not applied - so it is easy to find out what it was revealed as).

## Ticketing

Traditionally in blockchain-based ticketing systems, a user is expected to buy an NFT ticket and then on location of an event do one of the following:

1. show the NFT and sign a message
2. burn the NFT
3. show the NFT

1 and 2 require the user to have a wallet, or surrender control of it - i.e. have a custodial wallet in his account in a centralized ticketing provider's system. This is neither very web3, nor very secure.

3 is very insecure in that anyone can just download the NFT and show it instead of the real owner. This will either let an infinite number of people in, or require centralized tracking on the gatekeeper side so make sure a single QR code did not enter twice. Even then, there is no guarantee the right person got in.

There is a better way with multi resource NFTs.

A user buys an NFT ticket. The ticket, just by being a RMRK MR NFT, is compatible with ERC721 and thus all marketplaces, but is also enriched with more functionality. While buying, the user provides a custom string, like a special keyword, which is hashed and added as the ticket's attribute. Let's assume this special string is `banana` and the Sha1 hash of it is `250e77f12a5ab6972a0895d290c4792f0a326ea8`.

The null-resource is set to be the ticket itself. The null-resource is the initial resource, the default shown when no other resources are available. Null-resources are typically used for revealable NFTs, and these come in very handy in this scenario.

The user shows up at the door of the event, and displays the NFT QR code.

The gatekeeper scans the QR code, and asks the user for the keyword. The user says "pineapple", and the gatekeeper's software automatically runs it through sha1 to get `ff9907a80070300578eb65a2137670009e8c17cf`. Whoops! You do not seem to be the real owner! NEXT!

This fraudster is kicked out of the queue and the processing continues. A few people later, another person shows up with the same QR of the NFT, and the correct word: `banana`. The software again runs it, this time it matches.

The gatekeeper's app now creates a new resource - a "ticket stub" image with some cool visuals, and adds it to the NFT that was just loaded via the QR code.

Since _any_ resource takes precedence over _null_, the original ticket resource would be overwritten by this new one, the ticket stub, proving the attendance of this user, and marking the NFT as "used", all in a fully decentralized way - all on protocol.

## NFT Evolution

With last-gen NFT technology, replacing an NFT to evolve or change it requires either centralized metadata, or a burn-and-mint mechanic.

With RMRK's [Multi-Resource NFTs](/lego2-multi-resource), this is easier.

If a resource is added to an NFT with an extra argument provided targeting an existing resource by resource ID, that targeted resource will be **replaced**.

This makes for good _evolution_ mechanics where an NFT can grow or change over time. E.g. a tree that grows from seed, to sapling, to young tree, to mature tree. Additionally, assuming the tree NFT
needed to be watered with 💦 emoji every week or else it would die, it is possible that yet another resource could represent a tree's death stage.

Each stage of its growth is a new resource, replacing the previous one.

This is also useful in games. Imagine Pikachu evolving into Raichu by just having a resource replaced in a fully decentralized way, no single point of failure in between.

###### tags: `rmrk`