tl;dr and Motivation for Creator Nouns

We are launching a Nounish protocol and creation tool called Creator Nouns that allows creators to monetize using recurring auctions. Anyone can upload a collection consisting of images (and soon any file types like audio or video) and run auctions (which you can try here), with their own creator-owned NFT contract. Continuous auctions can be a powerful mechanism to fund systematically underfunded goods and a way for patrons funding them to have provenance in the work being funded.

One-off NFT drops are still a great way to capture value, but the goal of this protocol is to provide a sustainable, recurring way for creators to raise money over time so that more of their time can be shifted toward creating rather than having to constantly be building hype around new NFT drops in order to fund themselves.

We’ve taken the Nouns Protocol and made some custom tweaks which are outlined in this article. Our interface built on top of the protocol makes it super easy for anyone to spin up their own collection using the continuous auction mechanism with no coding experience required.

This post is dedicated to covering the motivations and technical challenges involved.

Applying the Nouns Mechanism to Creators

Applying the Nouns mechanism to fundraising for a DAO makes sense, but we wanted to take it one step further and unlock a new form of monetization for the creator. Instead of having to rely on one-off drops and carefully crafting a drop schedule, creators using a Nounish mechanism to raise funds would be able to have a regular cadence of dropped NFTs forming a body of work and an NFT always available for their fans to bid on.

An example of what this mechanism might be well suited for is raising funding for the production of an upcoming film, album, podcast, or educational series.

How it works: 

1. Create artwork for your collection and fill out the required parameters
2. Set the duration for each auction
3. Deploy your creator-owned contracts!
4. Auctions will run on the cadence that you set until there are no more NFTs (until all of the files that have been uploaded are exhausted)
5. Anyone can bid during the auction period and once complete, someone must settle the auction

Technical Challenges

A Creator Noun NFT isn’t attached to an on-chain SVG, but to an external IPFS file. Additionally, each Creator Noun collection is capped by the number of files uploaded. We believe these alterations make the protocol better suited for creators.

For those unfamiliar with how Nouns work under the hood, the daily auctions are fully executed on-chain, including even the art. The Nouns protocol uses a compression technique known as run-length encoding (RLE) to efficiently store art as on-chain SVGs. Also, because Nouns are generative, there are a tremendous number of possible Nouns: 40M days worth of distinct Nouns achieved with just 5 traits and all their combinations!

But our goal for Creator Nouns was to enable any individual creative to make their own Nounish collection that could be sold through daily auctions. To this end, we wanted to enable greater flexibility for the artwork and on-chain art was too restrictive. IPFS URLs allow for NFTs to be tied to any arbitrary image, video, or audio file, opening up a wider range of possibilities for creatives.

While moving the art off-chain allowed us to scrape away 6 out of the 8 Nouns smart contracts devoted to on-chain art, this change actually made this project a far from trivial Nouns fork. The largest technical challenge was allowing the IPFS links to be defined up-front by the creator and yet hidden until each individual item is up for auction. We introduced a few more wrinkles to the standard Nouns model, including finite collection sizes (as defined by the set of IPFS URLs), creator-owned token contracts, and a new treasury payout mechanism.

Our Trilemma and Merkle Proofs

First and foremost, we faced an important trilemma that we needed to solve.

We didn’t want the creator to have to think about uploading content every day, because that’s a hassle. But at the same time, if we had them upload all the content at the start, how could we store the items in a way that was safe from being tampered with (e.g. on-chain) but also not immediately viewable to everyone (e.g. gated AWS access)? Creators seemed to really like the ability to use this technology to roll out parts of a collection, so having items visible up-front would be a no-go.

More formally, we wanted collection items to be

• Hidden until available to be bid on
• Fully specified and unalterable from the time of collection creation
• Deterministically generated

Naive solutions (that don’t work)

• Basic NFT metadata stored on a contract
  • Fully specified and deterministic but not hidden until available to be bid on (everything stored on a contract is visible, even if stored in private variables)
• Metadata provided at the time of mint
  • Hidden and deterministic but not fully specified at the start (creator needs to upload an item each day)
• Pure fork of Nouns
  • Hidden and generated by a process fully specified at the start, but not deterministic (each Noun is generated randomly)
• Store the IPFS CIDs in AWS and pull the next one when creating a new auction
  • Trust is encoded in a centralized DB- the DB owner could tamper with the items and anyone can just interact directly with the smart contract off-platform (e.g. on Etherscan) with an incorrect CID and the contract would have no way of knowing it was dealing with a malicious user

Enter Merkle trees/proofs

We ended up developing a solution centered around Merkle trees and Merkle proofs. A Merkle tree is a tree where the leaves are hash values of a set of items and each parent is generated by hashing the combination of its children. The Merkle tree is anchored by the root, a hash that contains information about all the leaves in the tree.

A Merkle proof is a set of hashes that proves the existence of a leaf in the tree. For instance, in the tree below, providing Hʟ, Hɪᴊ, Hᴍɴᴏᴘ, and Hᴀʙᴄᴅᴇғɢʜ allows us to show that Hᴋ is a leaf since progressively combining the hashes in the upwards direction would yield the Merkle root.

Merkle trees are great for a few reasons

• Merkle proofs are hard to forge: because hash functions are one-way and impossible to reverse in practice, if you have a set of hashes that generate a Merkle root, you know with a high degree of certainty that the proposed leaf is in fact in the set of leaves.
• Storing the Merkle root alone on a smart contract is space efficient instead of having to store a whole tree.
• The set of hashes required in a proof submitted to a contract is low: lg(n) where n is the number of leaves.

So how exactly does this help?

1. During upload, we create a Merkle tree where the leaves are the hashes of the CIDs
2. We store the Merkle root on the contract
3. Now, whenever anyone tries to settle an auction and create the next one
   1. They have to pass in a CID for the new item
   2. They also have to provide a Merkle proof proving that this CID is in the set of CIDs
   3. Because Merkle proofs are impossible to forge in practice, they won’t be able to arbitrarily introduce a fake item into the collection

While the Merkle root is stored on the contract, the set of CIDs in a collection is stored in a DynamoDB database. When an auction is settled and the next one needs to be generated, a Node server behind an AWS API Gateway fetches the next item and its Merkle proof, which the user settling the auction submits to the smart contract. Note that while the full list of CIDs is stored in a centralized DB, the creator still has full control over the collection’s items because the Merkle root is saved on the blockchain at the beginning.

Other Nouns Modifications

• Finite collection size
  • At the time of publication, the collection size is fixed (based on the number of IPFS URLs)
  • All the logic around settling and creating auctions respects the collection size
• Custom auction lengths and reserve prices
  • Auction length is configurable on a per collection basis
  • Reserve price is configurable on a per collection basis
• Creator-owned contracts
  • The token contract is owned by the creator and has a custom ERC-721 name and symbol
• Treasury payouts
  • Because each NFT collection is finite and potentially wildly different, it doesn’t make as much sense for us to take every 10th NFT in the collection (as the Nounders do). Instead, we take 5% of each NFT’s primary sale.

Smart Contract Architecture

• Auction house contract
  • Contains logic to initialize a new collection and save the collection details
  • Logic to settle auctions, create new auctions, and create bids
  • Interacts with the token contract to mint/burn items
  • More details
    • Creating an auction: the next item is minted and held in the auction house contract
    • Creating a bid: the previous bidder (if one exists) is refunded
    • Settling an auction: the winning bidder (if one exists) gets the NFT, otherwise it’s burned
• Token contract
  • ERC-721
  • Handles mint/burning logic to/from auction house contract, respectively
  • Contains the token URI for each item in the collection

Our architecture closely models the Nouns architecture shown below. The only difference is that we don’t take every 10th item in a collection.

(n)ou(n)tro

The Nouns protocol is an incredibly powerful tool to raise money in a recurring way. We wanted to take the best pieces of the protocol and use them to enable individual creators to raise funds in a way that relied less on one-off hyped-up drops.

We wanted to open up more possibilities for these creators by allowing off-chain images/video/audio files but this was technically non-trivial because we had to ensure that items were hidden until auction-ready, tamper-proof after being specified up front, and deterministically generated.

We’re really excited about what this new model can unlock for creators and are to have this open for anyone to try out today.

Stay tuned for more updates on our Twitter!

⌐◨-◨