Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Variable Supply Auctions #188

Open
wants to merge 31 commits into
base: main
Choose a base branch
from

Conversation

neodaoist
Copy link
Contributor

@neodaoist neodaoist commented Nov 1, 2022

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:

  • Maximize revenue "stack cash"
  • Maximize reach "grow collector audience / fanbase"
  • Minimize supply while generating minimum viable revenue "smallest viable audience"
  • And so on...

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

  • Conduct usability testing of various dapp prototypes
  • Add ability for bidders to specify a bid range or maximum edition size interest

Refining the seller experience

  • Present the bid space and possible settle outcomes to sellers as a 3d data viz
  • Add ability for sellers to specify maximum edition size commitment

Improving the sealed bid mechanics

  • Allow off-chain sealed bids via signed messages, which include the bid amount along with sufficient ERC20 permit()
  • Use some CREATE2 / zkp wizardry, where bidders fund a yet-to-be-revealed contract with their true bid amount and submit a zk-proof at bid time, only revealing the contract address and true bid amount at reveal time

Evolving the technical design

  • Optimize gas/storage costs (many opportunities — I favored clarity over optimization in the initial implementation)
  • Expand into an Omnibus implementation with support for ERC20, finder's fee, and ZORF-controlled fee switch

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:

  • The module includes tests written for Foundry
  • The module is documented with NATSPEC
  • The documentation includes UML Diagrams for external and public functions
  • The module is a Hyperstructure

@jgeary
Copy link
Contributor

jgeary commented Nov 16, 2022

Thank you for your proposal @neodaoist - I will review it and tag some others to look as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants