# Spiritus: A Hackathon Retrospective By [Silika Studio](https://paragraph.com/@silika-studio) · 2022-09-13 --- 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](https://mexico.ethglobal.com/): a platform to make metadata updates and the resultant image generation as easy as possible. Metadata-driven development =========================== 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](https://hashlips.online/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](https://www.ipfs.io/) (there are other data storage solutions such as [Arweave](https://www.arweave.org/), [Filecoin](https://filecoin.io/), and [Sia](https://sia.tech/), 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](https://docs.ipfs.tech/concepts/content-addressing/), with which the developer will have to update the contract’s `tokenURI` or `uri` method. ![Standard Developer Workflow (IPFS)](https://storage.googleapis.com/papyrus_images/dac0f06a775a3be6e67876f48d20dd558ecfe6152d36c92368219d516185db95.png) Standard Developer Workflow (IPFS) 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](https://tableland.xyz/) 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. The Hackathon ============= Two of our founders, [@0xetash](https://twitter.com/0xetash) and [@0xtygra](https://twitter.com/0xtygra), recently had the opportunity to participate in the 2022 ETHMexico hackathon, sponsored by [ETHGlobal](https://ethglobal.com/). 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: 1. Update metadata 2. Art updates accordingly 3. Assets are pinned to IPFS/uploaded to a decentralized storage protocol ![Spiritus Proposed Workflow](https://storage.googleapis.com/papyrus_images/5269d10a63da9e9c3c3d6e5aa7ffa59e66e8505de664ebdefcf060c643bee887.png) Spiritus Proposed Workflow Future Plans ============ Fortunately, the proof-of-concept was successful enough to be selected as one of twelve finalists and even secured sponsor prizes from both [WalletConnect](https://walletconnect.com/) and [Protocol Labs](https://protocol.ai/). 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 ![Spiritus Value Props](https://storage.googleapis.com/papyrus_images/2f754894ff40588fd3343076719e9355a40d7a93bd7799f910f4b724e5bd08d1.png) Spiritus Value Props Conclusion ========== 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](https://mailto:team@silika.studio) or [Twitter](https://twitter.com/SilikaStudio). [https://silika.studio](https://silika.studio) --- *Originally published on [Silika Studio](https://paragraph.com/@silika-studio/spiritus-a-hackathon-retrospective)*