https://www.loom.com/embed/6f29009355a94469ac90e4c76b61a107
Dynamic NFT (dNFT) metadata requires many updates. NFT metadata typically lives off-chain in one of two places: centralized servers or decentralized storage, e.g. IPFS, Arweave.
The issue with storing metadata on a centralized server is its opaque infrastructure, ease of mutability, and closed access control.
While IPFS solves the aforementioned issues of the centralized server, dNFT collection updates require a tedious loop of pin, update URI, unpin, pin, update URI, unpin, ad nauseam. There’s also a lack of context and reference between previous and current metadata updates/files, i.e. there’s no clear connection between the previous content hash and the current content hash.
dNFT metadata should be represented as mutable database objects, each with a rich, queryable history, not as disconnected, immutable, persistent files — which is the current norm. In addition, many view the image of a token as its primary descriptor and the metadata as a way to describe the image; however, we posit that for generative collections, the artwork of an NFT is derived from its other metadata properties. For example, an NFT with the following metadata should deterministically produce the same artwork every time.
{
"sport": "basketball",
"color: "orange",
"size": "large"
}
We call this approach metadata-driven development (MDD), and it is the foundational principle behind Opal, a comprehensive dNFT (and static NFT) development platform, powered by Tableland.
Opal users begin by creating a “collection”, the top-level construct in Opal. Then, users can upload asset layers and use these layers to generate (manual or random) combinations of metadata and artwork derived from it.
Collections created in Opal have their metadata stored and managed via the Tableland Network. Artwork assets are pinned to IPFS and referenced in the Tableland table. Any subsequent updates are handled via the project’s smart contract (either manually via the Opal UI or directly via automatic conditional execution from a service like Chainlink Keepers).
Users may browse their assets, i.e. the metadata and artwork assigned to tokens, and update any metadata, which entails sending a query to the Tableland Network. Opal can recognize the Tableland update and kick off an artwork regeneration cycle, in which the new artwork, derived from the other values in the corresponding row, is pinned to IPFS and subsequently referenced in the Tableland table. This entire update loop kicks off with a click in the Opal web app and completes within a matter of seconds. Metadata updates are paired with a MetadataUpdate event, allowing for the full history of every token’s metadata to live on-chain, forever.