Can market-making be generalized beyond trading? In a new post, I describe a novel mechanism that allows market-makers to not only price, but also efficiently allocate scarce resources in any decentralized computing system.

Say you have some compute requests (e.g. transactions, oracle requests, etc.) and some nodes that can execute the request. How can we price and allocate compute requests to nodes in the presence of complex (e.g. resource, state, parallelization) constraints?

We’d ideally like to efficiently utilize the network’s scarce resources and provide non-extractive prices that users and nodes will accept. Further, we’d like to offer posted prices so participants can have a simple UX (like Uber) instead of having to strategically bid.

But without bids, the network has no information to gauge the efficiency of its resource allocation. We resolve this by recruiting market-makers who can estimate demand and supply parameters. But utilizing them without giving them all gains from trade is quite challenging.

With just one market-maker, we can incentivize an efficient allocation by letting the maker set prices and keep the margin. However, the maker will charge users high prices and pay nodes low rewards, pocketing all gains from trade. This is what happens in marketplaces like Uber.

But with multiple makers, it’s unclear how to select the best proposal, since the mechanism has no information on supply/demand parameters. The main contribution of this post is a novel mechanism that places makers in careful competition to achieve efficiency without extraction.

The mechanism sequentially considers maker proposals, with a running “current best” proposal. If the next proposal offers strictly better prices for conflicting participants, the current proposal may attempt to price match by making prices worse for nonconflicting participants.

The current best proposal is replaced if it is unable to price match. At equilibrium, the mechanism returns a plan for allocating and pricing resources that is efficient, and will be accepted by users and nodes without being extractive.

Special thanks to @0xemperor @noamnisan @0xQTpie @ArshanKhanifar @PGarimidi @MaxResnick1 @bahrani_maryam @ckartik_ and more for feedback, and @achalvs for design