Video

https://www.loom.com/share/9662af894897427fa1a3a9a63ee3d5b9

Project overview video ^ https://www.loom.com/share/9662af894897427fa1a3a9a63ee3d5b9

https://www.loom.com/share/90e947b92d5f4e4c9c443489389b6f2c

Technical walkthrough video https://www.loom.com/share/90e947b92d5f4e4c9c443489389b6f2c

Summary

Chain Runners extension collection with toggleable traits

I am building a Chain Runners extension NFT-collection that supports enabling/disabling individual traits by storing the metadata in Tableland and allowing holders of tokens to update certain parts of the data. All tokens in the extension collection will essentially be 'mutable copies' of tokens from the original collections that are always bound to the original token (similar to how ON1 Frames works). For example, extension runner #1337 will always be controlled by whoever owns chain runner #1337. The collection will be deployed on ETH mainnet.

I expect to finish everything needed to be able to deploy the collection and have users mint tokens during the pilot program.

Technical approach

I will be building:

• Three smart contracts:
  • The NFT collection contract that supports minting tokens for the CR tokens that you own
  • A separate metadata contract that the token contract delegates tokenURI calls to so that we can easily upgrade how we query for the data
  • A TablelandController that allows CR holders to toggle traits for their extension tokens
• A website where users can mint tokens and toggle traits (can also be done directly from contract)
• A rendering engine (a centralized web app that accepts a list of traits and returns an image)

<SEE ARCHITECTURE DIAGRAM>

Tableland

I am planning to use three Tableland tables to store the metadata. One for storing tokens, one for token attributes with one row per attribute and token, and one look up table with trait names and some other trait-related data to make generating the image urls simpler.

Using a separate table for attributes makes it much simpler to write queries for enabling/disabling a trait and to write the tokenURI query. I want the tokenURI query to be as simple as possible so that others can use the data and build upon if they want to without having to learn a complex table structure.

Table schemas: