Silika Studio is a web3 dev studio that maximizes the potential of your next project.
Silika Studio is a web3 dev studio that maximizes the potential of your next project.
Subscribe to Silika Studio
Subscribe to Silika Studio
Share Dialog
Share Dialog
The vast majority of collections today are static in nature. This has been sufficient for most NFT use cases, e.g. 10k profile picture collections, membership passes, 1/1 art, etc., but we believe the next generation of engaging use cases requires dynamic tokens. Dynamic NFT (dNFT) collections enable a compelling paradigm, one in which non-fungible tokens can evolve over time. Examples of dNFTs include video game skill progression, upgradeable community reputation tracking, vendor-limited promotional deals — the sky’s the limit.
With an evolving NFT, where the metadata could change with every bounce of a ball in a tennis match or every enemy slayed in a video game, the metadata is the single source of truth. Although it currently seems as if most view the image of a token as its primary descriptor and the metadata as a way to describe the image, we believe the image is actually a derivative of the token’s metadata. This notion motivated our hack at ETH Mexico: a platform to make metadata updates and the resultant image generation as easy as possible.
We see the future being filled with dNFTs, and in order to best build dNFTs, we believe in metadata-driven development (MDD). The idea of MDD isn’t necessarily new, as with most generative art engines, such as the popular Hashlips engine, assets are generated as a result of the combination of various trait layer names, which is effectively the metadata. However, any updates after the initial generation require a decoupling of metadata and asset, as both must be updated and uploaded separately unless you roll your own connected backend solution. This is because the original files are typically still on the developer’s machine, which means that the developer has to go back, manually update the JSON metadata, and procure the updated image from the artist. This can potentially lead to a mismatch between metadata and asset which could prove disastrous for the reputation of the project. Current standard asset development workflows don’t allow for the type of granularity a team would want when iterating on dNFTs.
Current NFT metadata conventions advocate pinning metadata to IPFS (there are other data storage solutions such as Arweave, Filecoin, and Sia, but for the purposes of simplicity, we will focus on IPFS in this article). This means that the metadata is effectively immutable. If the developer wishes to update the metadata, they are tasked with updating the metadata file locally and re-pinning the entire collection to IPFS, which results in a new CID, with which the developer will have to update the contract’s tokenURI or uri method.
This system is sufficient for static NFTs, but in the growing dynamic NFT ecosystem, this approach can prove to be cumbersome and potentially expensive. These issues would be further compounded if one were to leverage a storage solution like Arweave as each upload would cost some number of AR tokens.
There exist platforms that handle NFT updates for you, but as developers ourselves, when we had the option in the past to use one of these services, we decided against it. The problem with the current dNFT infrastructure market is that in order to update the metadata, a collection has to host their data on opaque and centralized services.
Web3-native entities need web3-native solutions.
Our approach to MDD is accomplished through use of the Tableland protocol, a “decentralized web3 protocol for structured relational data”. Tableland directly addresses this shortcoming; it facilitates a system in which metadata is hosted in tables on validator nodes connected to the Tableland Network. The unique benefit of Tableland though is that the access control for these tables happens entirely on-chain. Metadata reads and writes are performed via SQL queries, and tokenURI or uri methods are directly connected to the Tableland Network gateway. This allows for any writes to the Tableland Network to be immediately reflected in your token’s metadata. In simple terms, this paradigm helps foster the ideas of mutable metadata and dynamic NFTs.
Two of our founders, @0xetash and @0xtygra, recently had the opportunity to participate in the 2022 ETHMexico hackathon, sponsored by ETHGlobal. They entered Mexico wanting to create an application that would address many of the pain points experienced in Ethereum NFT development. More specifically, the hack would:
Upload and manage collectible asset layers
Swap out traits for one another
Generate new assets on-the-fly
Foster updates through MDD
An additional goal would be to wrap up all these processes into the following continuous development cycle:
Update metadata
Art updates accordingly
Assets are pinned to IPFS/uploaded to a decentralized storage protocol
Fortunately, the proof-of-concept was successful enough to be selected as one of twelve finalists and even secured sponsor prizes from both WalletConnect and Protocol Labs.
The currently planned features for Spiritus include the following:
Upload individual layers to a project workspace
Randomly generate assets with uploaded layers and rarity weightings, and easily manage which assets will be selected for the final collection
Generate assets with specific layers on-the-fly and preview assets before changing metadata
Pin to IPFS / upload to Arweave directly from the project workspace
Allow for multiple wallets to connect to the same team workspace to facilitate simpler asset reviews
Allow for anyone to easily deploy their own contract and collection
Enable the user to tie an oracle to metadata changes
Support any contract addresses that expose both layersURI and updateTokenMetadata methods and a new MetadataUpdate event
Any wallet allowed by the contract to update metadata could connect to our app and update individual tokens with ease
MetadataUpdate events will allow for the entire history of a token’s metadata to be on-chain, forever
This is experimental and would require us to write a new smart contract standard
Release robust API documentation to allow for developers to programmatically use our service
As the use cases for NFTs expand, we believe an all-in-one NFT development platform is needed to best serve the market. We see Spiritus as growing into a platform where anyone can create engaging, dynamic NFTs. Where each collection may be reinventing the wheel of asset generation, hosting, and updates, we’re excited to build towards a world where those efforts could instead be redirected to the novel and unique aspects of their collection.
We look forward to building out this product and welcome feedback on features you’d like to see. Feel free to reach out to us via email or Twitter.
The vast majority of collections today are static in nature. This has been sufficient for most NFT use cases, e.g. 10k profile picture collections, membership passes, 1/1 art, etc., but we believe the next generation of engaging use cases requires dynamic tokens. Dynamic NFT (dNFT) collections enable a compelling paradigm, one in which non-fungible tokens can evolve over time. Examples of dNFTs include video game skill progression, upgradeable community reputation tracking, vendor-limited promotional deals — the sky’s the limit.
With an evolving NFT, where the metadata could change with every bounce of a ball in a tennis match or every enemy slayed in a video game, the metadata is the single source of truth. Although it currently seems as if most view the image of a token as its primary descriptor and the metadata as a way to describe the image, we believe the image is actually a derivative of the token’s metadata. This notion motivated our hack at ETH Mexico: a platform to make metadata updates and the resultant image generation as easy as possible.
We see the future being filled with dNFTs, and in order to best build dNFTs, we believe in metadata-driven development (MDD). The idea of MDD isn’t necessarily new, as with most generative art engines, such as the popular Hashlips engine, assets are generated as a result of the combination of various trait layer names, which is effectively the metadata. However, any updates after the initial generation require a decoupling of metadata and asset, as both must be updated and uploaded separately unless you roll your own connected backend solution. This is because the original files are typically still on the developer’s machine, which means that the developer has to go back, manually update the JSON metadata, and procure the updated image from the artist. This can potentially lead to a mismatch between metadata and asset which could prove disastrous for the reputation of the project. Current standard asset development workflows don’t allow for the type of granularity a team would want when iterating on dNFTs.
Current NFT metadata conventions advocate pinning metadata to IPFS (there are other data storage solutions such as Arweave, Filecoin, and Sia, but for the purposes of simplicity, we will focus on IPFS in this article). This means that the metadata is effectively immutable. If the developer wishes to update the metadata, they are tasked with updating the metadata file locally and re-pinning the entire collection to IPFS, which results in a new CID, with which the developer will have to update the contract’s tokenURI or uri method.
This system is sufficient for static NFTs, but in the growing dynamic NFT ecosystem, this approach can prove to be cumbersome and potentially expensive. These issues would be further compounded if one were to leverage a storage solution like Arweave as each upload would cost some number of AR tokens.
There exist platforms that handle NFT updates for you, but as developers ourselves, when we had the option in the past to use one of these services, we decided against it. The problem with the current dNFT infrastructure market is that in order to update the metadata, a collection has to host their data on opaque and centralized services.
Web3-native entities need web3-native solutions.
Our approach to MDD is accomplished through use of the Tableland protocol, a “decentralized web3 protocol for structured relational data”. Tableland directly addresses this shortcoming; it facilitates a system in which metadata is hosted in tables on validator nodes connected to the Tableland Network. The unique benefit of Tableland though is that the access control for these tables happens entirely on-chain. Metadata reads and writes are performed via SQL queries, and tokenURI or uri methods are directly connected to the Tableland Network gateway. This allows for any writes to the Tableland Network to be immediately reflected in your token’s metadata. In simple terms, this paradigm helps foster the ideas of mutable metadata and dynamic NFTs.
Two of our founders, @0xetash and @0xtygra, recently had the opportunity to participate in the 2022 ETHMexico hackathon, sponsored by ETHGlobal. They entered Mexico wanting to create an application that would address many of the pain points experienced in Ethereum NFT development. More specifically, the hack would:
Upload and manage collectible asset layers
Swap out traits for one another
Generate new assets on-the-fly
Foster updates through MDD
An additional goal would be to wrap up all these processes into the following continuous development cycle:
Update metadata
Art updates accordingly
Assets are pinned to IPFS/uploaded to a decentralized storage protocol
Fortunately, the proof-of-concept was successful enough to be selected as one of twelve finalists and even secured sponsor prizes from both WalletConnect and Protocol Labs.
The currently planned features for Spiritus include the following:
Upload individual layers to a project workspace
Randomly generate assets with uploaded layers and rarity weightings, and easily manage which assets will be selected for the final collection
Generate assets with specific layers on-the-fly and preview assets before changing metadata
Pin to IPFS / upload to Arweave directly from the project workspace
Allow for multiple wallets to connect to the same team workspace to facilitate simpler asset reviews
Allow for anyone to easily deploy their own contract and collection
Enable the user to tie an oracle to metadata changes
Support any contract addresses that expose both layersURI and updateTokenMetadata methods and a new MetadataUpdate event
Any wallet allowed by the contract to update metadata could connect to our app and update individual tokens with ease
MetadataUpdate events will allow for the entire history of a token’s metadata to be on-chain, forever
This is experimental and would require us to write a new smart contract standard
Release robust API documentation to allow for developers to programmatically use our service
As the use cases for NFTs expand, we believe an all-in-one NFT development platform is needed to best serve the market. We see Spiritus as growing into a platform where anyone can create engaging, dynamic NFTs. Where each collection may be reinventing the wheel of asset generation, hosting, and updates, we’re excited to build towards a world where those efforts could instead be redirected to the novel and unique aspects of their collection.
We look forward to building out this product and welcome feedback on features you’d like to see. Feel free to reach out to us via email or Twitter.
<100 subscribers
<100 subscribers
No activity yet