jgeary
commented
1 year ago Thank you for your proposal @neodaoist - I will review it and tag some others to look as well.
Open neodaoist opened 2 years ago
jgeary
commented
1 year ago Thank you for your proposal @neodaoist - I will review it and tag some others to look as well.
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: