This repository has been archived by the owner on Dec 23, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 70
feat: Variable Supply Auctions #188
Open
neodaoist
wants to merge
31
commits into
ourzora:main
Choose a base branch
from
neodaoist:variable-supply-auctions
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New Module Proposal
Description
This module enables creators to conduct price discovery and right-size the market when selling a digital product.
Motivation and Context
Overview
Creators of all levels and backgrounds need to determine price and edition size when selling a new piece — how many to sell, at what price. There can be minimal data to make this decision, especially for emerging creators still building their base. I've spoken with artists, musicians, writers, filmographers, and entrepreneurs that share a similar experience of either underpricing or overpricing, undersizing or oversizing a new release. This leaves revenue on the table, misses possible collector/fan connections, and hurts their secondary market, among other bad outcomes.
Variable Supply Auctions aim to fix this, by giving creators better tools for collectively determining price and edition size.
For digital works, we can use cryptoeconomic mechanisms just now becoming possible to improve the experience for both creator and collector/fan. We can imagine a new type of auction, with the near-zero marginal cost of reproduction and potential buyers' ability to cryptographically signal the value they ascribe a yet-to-be-minted piece.
Inspo
In crafting this module, I was inspired by Dan Finlay's concept of MATT auctions and Seth Godin's concept of smallest viable audience.
MATT auction stands for Maximizing Artist Turnout and Takings. In Dan's words, "If you consider any set of bidders, each with a max price they'd be willing to pay, there is always going to be at least one optimal edition size and price where the seller is able to get the maximum total revenue for any price and run size...[and a MATT auction] guarantees [bidders] that if they win, they will pay no more than anyone else."
The seller is able to consider all submitted bids and choose a price point / edition size / revenue amount at which to settle the auction. For bidders, this creates incentives similar to a Vickrey / second price sealed bid auction, where the best strategy is to submit their true bid amount.
The concept of smallest viable audience asks creators, "What's the smallest group of people you can bring your idea to, and still be able to survive?" Creators may be operating from a top-down, all-or-nothing, scarcity mindset, and Seth encourages us to consider a bottom-up, slow-and-sustainable, abundance mindset when finding a market for our work. We don't have to mint a 10k collection, we don't have to auction our 1/1 with a reserve of 10 ETH. We can find other options by engaging with our audience.
Similar to Nounish DAO slow-start governance, smallest viable audience thinking encourages creators to start small and grow alongside their collector community / fanbase.
A Sealed Bid Auction for Digital-Native Creators
Combining these two concepts, we get a variable supply, seller's choice, sealed bid auction — a value-based mechanism for price discovery and edition sizing, with a minimum viable revenue backstop to provide sellers with peace of mind. If none of the possible settle outcomes would meet their minimum viable revenue threshold, the seller can choose not to settle an auction. There are various strategies to employ when settling, including non-market-clearing options:
Variable Supply Auctions could offer a new paradigm for the creator–collector/fan relationship, helping to shift the NFT meta away from hype-driven scarcity games towards relationship-centered co-creation games.
Possible Future Directions
Refining the bidder experience
Refining the seller experience
Improving the sealed bid mechanics
Evolving the technical design
How has this been tested?
I wrote this module with a BDD/TDD approach — first start with a failing feature test, then a failing unit test, and only then write some module code, followed by refactoring, more unit tests, until finally the feature test is satisfied. In this way, I implemented all 8 functions of the ABI. The test suite follows Zora conventions, with a couple additions — using Forge Test instead of DSTest, and splitting out Event assertions into their own unit tests to improve readability.
Definitely more fuzzing needed. There's an opportunity to shift the larger settleAuction() automated tests from the unit test suite into the integration test suite. The Cucumber feature tests are currently manual, but we could wire them up using ethers-rs, ethers-js, or similar. I started going down the path of actor-based invariant testing for module invariants, but wanted to open the PR and get feedback.
The module currently uses a test double for the Zora ERC721Drop contract required by each auction. It's probably better to keep the module ignorant of this interface and instead use something like an ERC721DropHelper, similar to ERC721TransferHelper.
Checklist: