Quadratic Voting as a way to allocate resources for increasing capacity of services

General
1

I’ve been working on a concept for a while and figured I would share it here to see if anyone has any ideas for what direction this could take.

TLDR:
Quadratic Queues - using the quadratic formula on queues to determine resource allocation, measuring interest, or as a basis for pricing.

It started as a simple queue as a service platform:

  1. Let anyone create a queue with a simple configuration and show a QR
  2. Have their customers scan the QR to get a ticket for the queue
  3. Move the queue along to update the customer when it’s their turn.

qlink
qlink1920×1631 157 KB

Later, I started to explore using ERC721 NFTs instead of web2 backend and database. These tickets could then be traded on a marketplace, used as proof of attendance, and as building blocks. They could also be placed in a wallet which contains identity NFTs. These use-cases would probably be more towards events or wait-lists.

Recently, I’ve been exploring the quadratic formula and I started to think about how it could be applied to other areas.

Could the formula be used as a way to measure how resources can be allocated to services and increase capacity in those places where needed?
Or as a way to gauge interest in ideas and projects (kickstarters, hackathon projects)?
Or could it be used as a basis for pricing?

Let’s make the following assumptions:

  • Any queue is a simple primitive representing a load balancer for a service or a product with limited capacity.
  • This capacity can be either a finite resource (x tickets) or fluid over time (max people in a venue) and sometimes both.
  • Each person queuing is a vote for access to this resource
  • The amount of time invested into this queue is a value of how important this resource is (number of votes cast)

What if anyone could create one of these Quadratic Queues configured with a configuration (capacity, max queue length, metadata, etc)?
A collection of these queues could be run through the formula to get a score, updated in real-time as more people mint queue tickets.

Additionally, because each queue/event is an ERC721:

  • tickets can be transferred or put on a marketplace for trading
  • it can contain metadata with image, url, attributes, etc (even dynamically generated by the smart contract)
  • other smart contracts and APIs can check balanceOf(address) as a way of access control lists

Here are some screenshots of the UI I’ve been prototyping:

q_screens
q_screens1920×2510 143 KB

From left to bottom:

  1. Create new queue
  2. List created queues - the percentage to the right of each title is the quadratic calculation
  3. Admin view of queue to push queue forward
  4. View queue and mint ticket
  5. Wallet of tickets
  6. View ticket - scan to verify

What are your thoughts? Mad science? A “solution” looking for a problem?

3 Likes