Perpetual Auction Currency

I conveniently forgot about this thread and wrote about a Great New Idea in another that, now that I looked, is really just a variation on this one. Here it is:

  1. Sections keep (or select upon receiving a request?) a pool of M vaults, more than the necessary N to store a chunk, and get their bids.

  2. Requests to store a chunk will specify the P largest acceptable price.

  3. The section assigns the chunk to the N vaults with the lowest bids if their sum is not larger than P.

BAM, FREE MARKET!

Notes:

  • Overly greedy vaults would remain underutilized and poor.
  • Stupid vaults would fill up and make little money.
  • Vaults with less free space would increase their price. (Explained right below.)
  • Users unwilling to pay up would not get their data stored.

Potential extensions:

  • Sections would keep and split the change.
  • Vaults may be notified about the per-vault acceptable price received, as potentially useful information for placing their bids.
  • I’m not sure if sections work with the same set of vaults. If so, they can just keep track of the bids continuously.

Clever vaults, if they couldn’t grow, would set their prices so as to always keep some free storage around for times when the rest of the vaults are also getting full, lest they miss out when the price got higher. It’s similar to airlines that ask more and more as they have fewer and fewer free seats left.

The strength of this model is that it isn’t sensitive to the exact method vaults used to set the price. The role sections play is also simple and minimal.

Provided vaults act in their self-interest, chunks will get stored at the lowest possible price and the network will be reasonably protected from getting full. As with any economic actor, the specifics may vary from vault to vault as each tries to game the system and come out on top, but the end result would still be a price set by the market somewhere around the “correct” value.

7 Likes