Introducing RMRK2 on Singular.app

It is with great pleasure and a hearty sigh of relief that we announce the immediate availability of RMRK2 on Singular! ✊

This brings with it many updates, so please read carefully! In short:

  • Singular.app is the RMRK2 version of Singular.
  • We now have royalties built-in.
  • We now have Dutch Auctions for select launches.
  • NFTs now support custom attributes.
  • NFTs can now be made revealable without centralizing the metadata.
  • NFTs can have multiple resources.
  • We are working on adding equipping and cross-collection logic to the UI in the next two weeks.
  • We are feature-freezing RMRK2 in order to focus on pallets and contracts next.
  • You will no longer be able to launch collections on the old Singular, but you can still mint NFTs into existing collection. New collections should be launched on Singular.app.

Let's go into more detail.

Singular.app and RMRK2

By means of a recap, RMRK's NFT 2.0 system is composed of the following NFT legos:

  • NFTs being able to own and equip other NFTs
  • NFTs being able to have multiple resources
  • NFTs accepting emotes
  • NFTs having conditional renders
  • NFTs being DAOs

This is further detailed in this post and this thorough intro.

With RMRK2 on Kusama, we are limited in what we can do with conditional renders and DAOs - without smart contracts, this functionality is very hard to do. But the rest is now supported on Singular.app. Notably, multi resource, emotable, and nested NFTs.

From now on, whenever you mint a new collection or NFT on Singular.app, it will by default be based on the RMRK2 standard. Due to these upgrades, and the need to store vastly more information, we raised the marketplace commission to 3.5%.

One thing to note is that your RMRK2 NFTs (as minted on Singular.app) will NOT be visible on RMRK1 Singular, nor on any other current-gen RMRK marketplace. We eagerly await more implementations of RMRK2 across the ecosystem, and have APIs prepared for the teams who wish to show our NFTs but do not necessarily want to process the chain.

Royalties

Starting with Singular.app's launch, RMRK NFTs now support author-defined royalties.

These are NFT-specific, NOT collection-level, and we are working on adding an account-level setting for the default, so it is auto-applied to your mints, and you do not have to manually input it every time.

The range you can set is anything between and including 0.1% to 25%. This means any secondary sale of your NFT on the marketplace will give this much of the sale price to you.

Royalties cannot be back-ported into RMRK1. However, as we slowly enable the migration of collections from RMRK1 to RMRK2, the issuer will be able to define a royalty to be applied during this migration and if you choose to migrate, you will have to also accept this new value. You can, of course, stay on RMRK1 forever.

Additionally, on RMRK2, issuers will be able to modify an NFT's royalty IF they also own it. They cannot change royalty on items they no longer own, but as long as the issuer == the owner, the royalty is mutable.

Nested Royalties

As documented at the bottom of this post, nested royalties are a HARD problem to solve. Our solution is coming as soon as we add equipping and nesting logic to the new Singular UI, and it involves, in a nutshell, setting a price for every child if you are also selling a parent.

In other words, if you have NFT A with NFT A1, A2, A3 inside it, and you decide to sell A, the only way the authors of A1 - A3 get their fair royalties is for you to set a price for each of them, and they all get listed separately alongside A.

This means that someone can buy A2 on its own without buying A, but it also means that if A gets sold, all authors of A1 to A3 get the appropriate royalty.

This is the only possible compromise we have come up with, and we have given this a lot of thought. We are now translating this into an intuitive enough UI.

NFT Taint

Most marketplaces will not support royalty from the get-go - it is not an easy thing to implement. It is also cheaper to buy an NFT without royalties, because the way it is implemented now includes adding the royalty fee on top of the on-chain listing. This means that, yes, a bot can snipe an NFT without paying a royalty, and actually gets it cheaper.

To combat this, we will introduce a taint attribute to all NFTs that have been traded without royalties.

This indicates scripting, black market, and OTC trades. Any NFT that has been transferred without the royalty being paid will be tainted, and this tarnished reputation of the NFT should, in theory, reduce its secondary market value so that in the end it always pays to pay the royalty.

A tainted NFT can be untainted by manually paying the royalty that was missing in a transfer (a button will be added for "untainting", payable by anyone). In the case of a cold storage transfer (which might get interpreted as an OTC trade and taint the NFT), the owner can just sign a message with each address and remove the taint without paying.

Dutch Auctions

A Dutch Auction is one that starts high and then periodically lowers the price until purchased. This will be clearly indicated alongside every Dutch-auctioned NFT.

Right now, Dutching an NFT is reserved for RMRK-launched NFTs, but soon we will allow select others to launch Dutch Auctions through our Auctioneer escrow account.

Custom Attributes

While minting an NFT, you can now define custom attributes:

These are currently read only, but their renders in the NFT's UI will soon be upgraded to allow:

  • filtering by attribute
  • showing how many other NFTs in the same collection have the same attribute, indicating rarity

Revealable NFTs

You can now set an NFT as revealable.

A Revealable NFT is one that you expect to "hatch" later, discarding the original art. Think eggs hatching into birds, or gifts opening and revealing another NFT.

With a Revealable NFT, the media metadata is added to the root level of the NFT. Since RMRK2 spec says that once an NFT has ANY resource, that takes priority over the root level media, this means that as soon as you add a resource to the NFT (like a trading card) the original art (gift box) will be overwritten and only the card will be visible. Note that the owner of the NFT still has to ACCEPT the new resource (see below), otherwise the NFT cannot be updated. It is not possible to update someone's NFT by force.

With a non-revealable NFT, the first thing you mint is also its first resource, so the root-level media does not exist and there is nothing to overwrite and reveal. This type of NFT requires two transactions - one to make the NFT, and one to make a resource for it at the same time.

In either case, you can add more resources to an NFT later to make it multi-resource.

Multi-resource NFTs

Multi-resource NFTs are NFTs that can have different outputs, as explained in this post.

To add a new resource to an existing NFT, use the NFT's context menu:

A resource is NOT a separate NFT. It is another "face" of the same NFT. Fill out the fields:

  • image: main image of the new resource
  • thumbnail: optional image for what to show in small format, like in SERP pages and catalogs etc, representing this new resource
  • name: will be used as default name of the NFT once this resource is set as primary
  • description: overwrites default description when this resource is primary
  • attributes: see section above, each resource can have its own attributes

To credit an artist or the source of this new resource, we propose the following standardized set of attributes:

Attr nameAttr purpose
SourceName of the artist, studio, or company who made this. Alternatively, title of the game, app, or contract this resource came from.
Source AffiliationIf the Source is an individual, they might have an affiliation, like a studio, but still want to be credited as source separately. See example below.
Source URLURL to the source - game studio, artist instagram, etc.

Please note that adding a resource to an NFT you no longer own will require its owner to ACCEPT this new reesource:

Once added, all resources will be browsable under an NFT:

The ability to bind a resource to a certain slot in a certain collection is coming to the UI soon. This will allow composable cross-collection projects. Expect a detailed post about that when it's out.

Future plans

We are now feature-freezing RMRK2 as a standard/specification on Kusama (the so called "remark" version) in an effort to focus on pallets (parachain modules for integration of our standards into the runtimes of interested parachains) and contracts (EVM version of the standard for EVM based chains like Moonriver, Moonbeam, and others).

This means that:

  1. RMRK1 on Singular (singular.rmrk.app) will get no further updates except critical bug fixes.
  2. RMRK2 on Singular (Singular.app) will get nesting and equipping for UI functionality, and Dutch auctions will open for other users, all in the next few weeks hopefully, but nothing else beyond that.
  3. All effort is being redirected to the EVM and pallet version of the UI so that Singular becomes the true cross-chain destination for NFT minting and trading, truly kickstarting the global item economy.

You will also notice that NFTs on Singular.app do not have hardcoded rarities like "Legendary" etc. This is because they no longer apply in the "old way" - a hat with 2000 copies is quite common on a collection of 8000 avatars, but if a new collection of another 8000 appears and is made compatible with the hat, suddenly the hat's demand doubles. This is why we are introducing a new score and way of applying it soon, which will be detailed separately, stay tuned.

What about my RMRK1 NFTs?

Your RMRK1 NFTs will continue to live on rmrk.singular.app, and we will look at ways to visualize them on RMRK2 Singular, but we will discourage further minting of new collections on RMRK 1.

You can still mint NFTs into existing collections. The idea is to make as many people mint on RMRK2 as possible, and allow a migration of RMRK1 NFTs into RMRK2 soon after.

Hopefully, we can completely phase out RMRK1 by the end of 2022.

7 comments

Loading replies...