---
# System prepended metadata

title: Why we are deprecating legacy Kusama RMRK implementation

---

# Why we are deprecating legacy Kusama RMRK implementation

## Kusama Implementation History

RMRK is a standard for the most advanced NFTs.

The RMRK standard was outlined at the beginning of 2021 as a language-agnostic set of rules on how NFTs 2.0 can work. Because we at RMRK were rooted in the Polkadot and Kusama ecosystems, we wanted to implement it there. However, neither Kusama nor Polkadot has any way to add the on-chain logic that is required to implement the RMRK standard, and at the time, there were no Parachains where we could add this.

So, early in 2021, we decided to "force" our way into Kusama and implemented our standard using the ["graffiti" approach](https://github.com/rmrk-team/rmrk-spec/tree/master/standards/kusama). In short, with this "graffiti" implementation, we were sending events on-chain and then parsing them off-chain using TypeScript and a tool we call the "consolidator." We read all blocks from the first RMRK event sent until the latest block and parsed them one by one until we got the latest state.

This was never meant to be a real or sustainable implementation of the RMRK standard, but because this was the only way to have NFTs on Kusama, and the community was thriving and eager to create and interact with next-generation NFTs, it took off quite well.

## Challenges with the Kusama "Graffitti" approach

We always warned our users through different channels of the shortcomings of this implementation, namely the inability to validate if an NFT was already purchased until the consolidator has done its job, thus relying on a centralized module (our server with consolidator in this case) to listen to new blocks for "system.remark" events, consolidate them with all the historic blocks, and finally transmit the latest state to each client (through our centralized indexer/database). While the consolidator and all the tooling are open-sourced, and anyone could run our consolidator on their own server or a machine, to this day, we are the only ones to maintain and support it to make sure our dapps (like singular.app NFT marketplace) display the latest up-to-date state.
    
Not having a way to validate these transactions on-chain came with a plethora of problems, which were known and communicated at all times. Ultimately, this was a temporary hack until we could write an implementation of RMRK standard on a different stack, including EVM smart contracts using Solidity language, Substrate pallets using Rust, Ink! WASM smart contracts using Rust, Gear smart contracts, and more.
    
On one hand, having this “graffiti” implementation allowed us to move quickly and at a time position ourselves as the principal and most popular NFT implementation on Kusama. NFT is a very social technology, and it resulted in a thriving and very engaging community, not just within RMRK but within Polkadot ecosystem as a whole, it brought people together, sparked creativity, helped hundreds of artists, and content creators, and even Parachains to monetize and engage with their and wider Polkadot community.

On the other hand, it meant countless sleepless hours for RMRK team in maintenance of “RMRK consolidator”, debugging and fixing issues when Kusama RPCs disconnect, customer support when infamous “double spends” and “double buys” happen, dealing with the out-of-sync state, maintaining centralized servers and databases and maintaining a large client-side code that is ultimately a band-aid to prevent the outdated or incorrect state, just because there’s no on-chain logic.
    
So while we could move fast initially thanks to “graffiti” implementation, it slowed us down significantly later on.

## RMRK Standard Implementation

In December 2021 we started working on EVM implementation of RMRK standard, and this is where we could finally implement our full vision of NFTs 2.0 properly, without any shortcomings of “graffiti” support, it took us over a year of active development to finish the contracts, resulting in several EIPs and soon to be ERCs on Ethereum. This is the first full-featured implementation of RMRK standard. And with it being feature complete we now had to add its support to Singular marketplace. but by this time, thousands of NFTs were created and traded on “graffiti” implementation of RMRK, so we had to keep maintaining it.
    
In 2022, once RMRK EVM smart contracts were close to being done, we had to start the undergoing of adding support of it to Singular marketplace. As mentioned before, by this time the “graffiti” implementation was very well received and popular, and the fact that it was a “hack” with a lot of “band-aids” was actively ignored by everyone who wanted to play around with these next-generation NFTs. So we couldn’t just shut it down, and because of this, we made a decision to add EVM support alongside “graffiti” support, and not stop even there, we decided to refactor our code base for Singular in such a way that more RMRK implementations and chains could be added with the breeze. The code base at the time was very tightly coupled to Kusama and polkadot.js tooling. Eventually, we landed on a satisfying React pattern to organize our code and split components into presentational and data-fetching or data-mapping components. We managed to refactor most of our UI components and business logic code in this way, however some Kusama and legacy RMRK “graffiti” quirks, still required quite a few exceptions and special cases that could not be decoupled from re-usable and network-agnostic code. This overhead of having to support the legacy RMRK implementation coupled with constant maintenance of legacy infrastructure and bugs, resulted in our productivity decreasing significantly.
    
As of this day, we have both implementations fully working and functional on our staging environment and we have started multiple cycles of QA and polishing before we can ship it. But despite all the refactoring and code clean-up, maintaining this legacy RMRK implementation alongside a proper implementation with on-chain logic will have a great effect on our productivity and speed. **This pushed us to decide to expedite the deprioritization of legacy RMRK implementation.**

## Future Plans for Singular Marketplace
    
We are very close to releasing RMRK EVM support on Singular, and for a short while it will live alongside our Legacy graffiti implementation on singular.app, but shortly after we will be splitting Singular into 2 websites.
    
1. the singular.app will only have RMRK EVM implementation, and later other “real” RMRK implementations (looking at you Ink!)
    
2. the legacy.singular.app will only have legacy Kusama’s graffiti implementation of RMRK, and we will actively discourage users to create or purchase NFTs there. With the further deprioritization timeline roughly outlined below:
    
    * For the first month after the split, the 2 versions of the Singular marketplace will function mostly normally with almost the full feature set. The “Mint” and “Collection create” will be disabled on the legacy Singular so no new NFTs can be created there through the UI on Kusama. We will also add a notification, warning users about the deprioritization.
    * After 1 month, we will add a Migration option for non-nested and non-equippable NFTs only. Legacy RMRK collections created on Kusama, that don’t use the Equippable part of RMRK standard will be able to redeploy their collection on RMRK EVM. This will unlock the option for all NFT owners within this collection to migrate their NFTs to the associated EVM contract collection. Additionally, we will reach out to the most active and creative Equippable collection creators to help them with manual migration to EVM if they wish to do so.
    * This migration option will be actively maintained for 2 - 3 months, during this period at some point we will disable trading on legacy Singular. Bear in mind that the legacy RMRK standard is open source, and other teams can create their own marketplaces and UIs if they wish to keep the support for it.
    * After ~3 months we will gradually stop supporting legacy infrastructure for “graffiti” RMRK implementation on Kusama. We will not shut it down completely yet, but our indexer and database state might not be up to date at all times, and any issues with it will not be dealt with by RMRK team. If you are willing to maintain consolidator and indexer infrastructure for legacy RMRK on Kusama, please reach out to us, once we start the migration proccess.
    * After ~4 - 5 months we will completely shut down Kusama infrastructure and legacy Singular dapp.
	    
Removing all the legacy code from the new Singular codebase will significantly increase our productivity and allow us to ship faster and better. Removing the burden of maintaining Kusama consolidator infrastructure will significantly improve RMRK team’s quality of life and allow us to focus on what is important for RMRK and for the community in general. We are grateful to the Kusama community for all the creativity and engagement that happened during these 2 years, and this is not the end of our involvement with Polkadot ecosystem, we will continue to build on Polkadot parachains with our EVM implementation and later with the “Ink!” smart contract implementation that Astar team helped us build. We hope that the community understands that the deprioritization of legacy RMRK implementation is the best for everyone involved.
	    
Onwards and upwards,
RMRK team.