# RMRK introduces NFT DEGEN Score

With the introduction of the concept of a _global item economy_, an ecosystem of mutually compatible NFT collections that span chains, metaverses, and media types, we are proud to introduce RMRK's latest innovation: the _DEGEN_ (Demand for Globally Equippable NFTs) score.

In short, the DEGEN score is a dynamically updated rarity score that applies to NFTs compatible with other projects, indicating their cross-project demand and dynamic scarcity.

Let's dive in.

## Problem

Right now, there are two types of rarities to consider in the RMRK ecosystem.

The first is the regular rarity, as present in all simple NFTs like those on Ethereum and elsewhere - attributes in a collection that certain NFTs have, and a percentage readout on how many others in that collection have it. This score is sticking around on RMRK and makes sense in the context of in-collection rarity.

IMAGE OF PERCENTAGE ATTRIBUTE - TODO when attributes have percentage

The second one is trickier. If we take for example a Samurai Hat that can be worn by 8000 Kanaria birds and has 1000 copies, that hat is fairly common in that collection. But if the Chunkies collection with its 10000 avatars makes the hat compatible with itself, then the scarcity of the hat is suddenly 1 in 18, and not 1 in 8. The rarity of the item has increased.

If we look at it from another angle - music. Say we have an empty music sheet NFT with 5 slots: drums, vocals, bass, lead, synth, and that this music sheet NFT was minted in 10000 copies. Let's say Bob minted 5000 CrazyDrums tracks that are compatible with the drums slot in the aforementioned NFT collection. The rarity of the CrazyDrums is 1/2, very common. But if the number of music sheet NFTs gets updated to 100000 because the collection is uncapped, the rarity is suddenly 1/20. Furthermore, let's assume the Skybreach lands NFTs collection is one day updated with a music NFT slot that is compatible with drums, so that a drum track plays in the background, and say that there are 50000 tribal land slots that can host the drum track. Now the rarity is 5000 / (100000 + 50000), or 1 / 30.

But it is not all about supply and demand of one collection in another. It is about the effect of supply and demand of one collection on another's.

Building on the example above, let's assume that Charlie comes up with his own drum track, and mints 3000 copies. If a drum track is equipped in a drum slot of a compatible collection, then the other drum track cannot be equipped there. In effect, the new collection has _reduced_ the "rarity" of the previous one by offering to fill those slots with something else: (5000 + 3000) / (100000 + 50000).

And here we come to the re-definition: it is not rarity, it is **demand**.

Thus: Demand for Globally Equippable NFTs, or _**DEGEN**_. To make it a whole-number indicator that GOES TO ELEVEN, we can invert this by dividing 1 with this number, making it a bit more reminiscent of an actual **score** to achieve.

So the full DEGEN Score of the drum track is now: 1 / ((5000 + 3000) / (100000 + 50000)) or **18.75**, down from **30** before Charlie minted his track.

## xcRMRK-based TCR

But the problem presents itself: if all it takes is having collection compatibility to change a score, then issuers can easily manipulate this by just pumping out collections that are willy-nilly compatible.

Thus, it is very important that:

1. The DEGEN score be considered a beta, a test, and that it can go away if irreparably broken and
2. We need a way to _decide_ which collections are counted in a score, so that we ignore-by-default and only score when collections are whitelisted/validated

Because of 2), we will be introducing a TCR (Token Curated Registry) on Moonriver which contains a list of all whitelisted collections and their current supply. Only the collections in this list will be considered for DEGEN Score calculation.

Registering a collection for DEGEN Scoring on this registry can be proposed by anyone, but requires a RMRK deposit which increases every time a collection is removed and re-added. It can only be added by community vote, modified by community vote, and removed by community vote - that is the *curation* part.

While these game-theoretic approaches to collection registration (and potential bribery of issuers to willingly exclude their collection from the TCR) should be fun to watch play out, we do need _some_ rules.

1. Adding a collection requires a deposit. The deposit is locked in the TCR until the collection is removed by community vote. The issuer / proposer cannot singlehandedly remove it as this would change the score in other people's NFTs which would have large scale implications on popular and widespread collections.
2. It is possible to add two types of collections: slotted, and equippable.
- When adding a slotted collection to the TCR (one that supports other NFTs being added into it), a static supply number MUST be provided. This is for two reasons: one is to prevent dynamically pumping the supply and DEGEN score by just infinitely issuing new NFTs in a collection, and the other is being able to read information about cross-chain collections. Kanaria, living on Kusama, cannot be read from MOVR, but this TCR lives on MOVR. Same with collections on Moonbeam, Karura, etc. Thus, a central TCR is needed.
- When adding an equippable collection, you can add two types of entries. Add the collection in general, and this follows the same rules as above: minimum deposit is number of units * 0.01 xcRMRK. But each equippable collection must be mapped to the slotted collection to be able to have a DEGEN score calculated. Each new entry mapping an equippable collection to a new slotted collection or another slot in the same collection (i.e. left hand vs right hand) requires another deposit of TODO.
4. There is a minimum deposit of 0.01 per unit in a collection. This means a collection with 10000 NFTs will need at least 100 xcRMRK to be added. A collection can crowdfund its xcRMRK for curation by initiating a request. Others can then lock their xcRMRK as a show of support. Rewarding the loaners is up to the collection issuer or proposal submitter. No reward is implied by or expected from the TCR.
5. Once a collection is removed from the TCR, it requires double the previous deposit per NFT in collection to be added back in. This doubling stacks with further removals and re-additions to make gaming the system prohibitively expensive. This maxes out at 100,000 RMRK. The collection cannot be added for less of a total deposit than it was added with previously.
- E.g. Puppies with 100 supply are added for 1 xcRMRK. Puppies are removed. 60 puppies are burned. Puppies are re-added. Re-adding costs 0.02 per unit, there are 40, so math adds up to 0.8 xcRMRK, but because last adding cost 1 xcRMRK, this one also costs 1 xcRMRK. If no puppies had been burned, the cost would have been 0.02 * 100 = 2 xcRMRK.
6. A collection can be removed from the TCR through voting. There is slashed and slashless removal.
- Slashed: proposed as a penalty, requires a deposit of TODO which is refunded in TODO way when TODO. If passed, slashes 50% of the original depositor's deposit, burning half the xcRMRK. All the crowdloaners of the xcRMRK also lose 50% of their loaned xcRMRK in that case.
- Slashless: proposed when a collection is all burned, no longer maintained, merged with another, no longer wishes to count, etc. No slash is applied, full refund is given if passed. Proposal requires a deposit of TODO which is refunded if TODO.
7. A collection's supply can be increased in the TCR through voting. This requires an additional deposit in the size of the new value / 100 or, if the new value is lower, old value / 100, and cannot be crowdloaned. Once voted in, the deposit is refunded in full. One should only submit a collection once they are reasonably certain of its final or near final supply, to reduce the need to update it soon thereafter.

### Example

Back to the hat now with a more concrete example.

Say that there is a Samurai Hat of 1000 supply, in the TCR as two records: "SamuraiHat:1000" and "SamuraiHat:Kanaria:head", and the Kanaria collection is in this TCR like so: "Kanaria:8500".

So if, as specified in the TCR, the hat has a resource compatible with Kanaria, head, then its DEGEN Score is (1 / (1000 / 8500)) or 8.5.

Even if another collection exists, Chunkies, and they are compatible with the Hat, the score of the hat is still **8.5**. First we need to add a new record which states that this hat is compatible with Chunkies: "SamuraiHat:Chunkies:head". Now the SamuraiHat has three records in the TCR, fully describing it:

- SamuraiHat:Chunkies:head
- SamuraiHat:Kanaria:head
- SamuraiHat:1000

But the score is still 8.5 because Chunkies are not in the list yet.

If we add Chunkies to the TCR as "Chunkies:15000", **then** the score gets updated and becomes (1 / (1000 / (8500 + 15000))) or **23.5**.

Now let's say someone launches a collection of Victorian Hats and adds it to the TCR:

- VictorianHat:Kanaria:head
- VictorianHat:1500

These have 1500 supply, and are compatible only with Kanaria, not Chunkies. What happens?

The Samurai Hat is now compatible with two collections, Kanaria with 8500 supply, Chunkies with 15000 supply.
The Victorian Hat is now compatible with one collection, Kanaria with 8500 supply.

These compatibilities now influence each other.

The score of the Samurai Hat is now: (1 / ((1000 + 1500) / (8500 + 15000))) or **9.4**, while the score of the Victorian hat is (1 / 1500 / 8500) or **5.66**. The addition of the Victorian Hat has therefore _significantly_ reduced the DEGEN score of the Samurai Hat.

Todo: consider entry age for saving loan protocols

todo: consider only some nfts in a collection accepting a res. so probably need to add res hash not nft into tcr