LUKSO — “Updatable” metadata (Part 1)
This post is part of a series where DROPPS breaks down the meaning of the keywords in the LUKSO website section about Universal Profiles, NFTs and Cultural Currencies.
(written by António Pedro Silva)
This time, we will analyze what’s behind “Updatable” metadata, under the NFT 2.0 section.
Intro
In the beginning, NFTs demanded immutable metadata. That’s because their value was in the metadata itself, bound to attributes such as the rarity of a character or the image of an art piece. Thus, IPFS became the standard to store such metadata, as it allowed for tamper-proof NFTs using a technique called content addressing.
However, in order to increase the use cases for digital assets, we should endow some of them with the possibility to evolve, to change. That’s the case for assets that have physical world counterparts, known as phygitals, or characters in a game, or even records that represent physical world entities, such as houses or cars. If we snatch the opportunity, we might want our digital sneakers signed by a famous NBA player. Or our character in a role-playing game might level up. Or we might want to paint our car a different color in real life and keep a matching image in its digital counterpart.
InvenGlobal puts out a great example of mutable NFTS:
“Imagine an old-fashioned baseball trading card. The details on that card are entirely static, representing the player’s stats for the particular season it was issued for. In other words, that baseball trading card is immutable. A hypothetical mutable trading card on the other hand would be able to update its stats on the fly, from one game to the next, tracking the player’s entire career.”
However, a small problem lies in how to do it. Currently, metadata updates are all or nothing: you replace the whole metadata file by a new one. There is no granularity or control in what parts of the metadata are subject to change and what rules govern this change, if any.
Another problem lies in the “who can do it”. Usually, there is a designated owner of an NFT collection, which has the rights to change the metadata, by replacing the link to IPFS. Of course this owner can be a smart contract, representing a DAO or any type of collective, but still, there’s no granularity here either. Only one address is entitled to update the metadata, and the change is done by fully replacing the old file URI with a new one.
New paradigms for storing and displaying NFT metadata
Because the market demands more utility from NFTs, the traditional ERC-721 and ERC-1155 standards are falling short. Modern scalability solutions and blockchains encourage storing more info about the NFT on-chain. On the other hand, the traditional approach of bundling all metadata in a static file and storing it in some decentralized network, like IPFS or Arweave, is becoming obsolete.
Some solutions aim to extend existing standards, others are completely disruptive. The common trait is making the attributes that define an NFT more dynamic and more programmable.
Tableland
Tableland is a decentralized protocol for relational data. It’s not great for storing images or videos off-chain, but it’s much better than IPFS or Arweave to store information that would fit a database table. This is because it works like a database and not like a file storage system. Inserting, reading and modifying data in Tableland works just like regular SQL databases.
The twist that Tableland brings to NFT metadata is making it a database and not a set of files anymore.
Now instead of saving a link to IPFS on the collection contract, you save the link to Tableland and the corresponding query to select all the metadata:
When a platform calls your NFT contract to fetch a link to the metadata, instead of getting a static object in the end of the link with all the metadata written on it, it triggers a database query! This database query will generate the object in real time and finally deliver the file with the metadata.
Tableland has launched its own NFT collection called The Rigs, where they use this technology.
EIP-5185
Another approach to tackle this problem is described on EIP-5185.
The thread was created on June, 2022, to start a discussion on updatable metadata and it sets out with an interesting goal:
“Define a standard way to allow controlled NFT metadata updates, along predefined formulas.”
Basically, it suggests to add a new section to an NFT’s metadata describing what attributes can be updated and what values can they take:
Then, the update is made permanent by registering a link to the update file in the NFT collection contract. The update file could look like this:
By using the rules defined in the updatable section of the metadata, a platform can determine if token 1 from this collection is allowed to “levelUp” and have its description updated. If the update is valid, the new traits are displayed, if not, the platform sticks to the original metadata.
Balancing security and updatability
As we’ve covered in the Intro, different use cases require different degrees of mutability. In order to remove the need for trust, it is necessary to establish rules on how metadata can change or, alternatively, frame these changes through smart contract code, which results in predictable updates.
Regardless of the approach, static metadata is simple and intuitive: a file stored off-chain. Developers in the ecosystem need to be wise and focus on solving the problem without further increasing the complexity. There’s a reason why ERC-20 and ERC-721 are still in use today and that’s because they’re simple and they just work.
Maybe it’s time to say goodbye to our ancestral roots and sacrifice backwards compatibility in order to keep the same pragmatic and simple approach in the new standards we adopt in our ecosystem. That’s why we, at DROPPS, love LUKSO.
Don’t miss part 2 of this article where we’ll dive deeper on how the new standards developed by the LUKSO team may combine with the ones in this article and tackle the problem of NFT updatability.
