Now we’re going to describe how we’ll build our markets. Before we get started though, I’d like to distinguish two concepts in our simulations. The first element is an agent, which is an entity in our simulation that attempts to make an intelligent decision to accomplish some kind of goal. Individuals attempt to maximize their utility/happiness, firms attempt to maximize profits, governments attempt to maximize…something. Contrast with the second concept, a mechanism, which is an element that simply follows a set of mechanical rules. An example of this is the double-auction market that we’ll describe in this article; it simply accepts orders and in all cases it follows a set of well-defined rules. It does not have any sort of objective.

It’s important to distinguish this because our simulations are decentralized: there is no auctioneer or benevolent overlord guiding the system. We expect to see a true invisible hand at work. If we had some sort of agent managing the interaction between other agents, then we don’t really have a decentralized system.

Now with that out of the way, let’s talk a bit about double-auction markets. These are markets where participants submit orders to buy or sell a certain quantity of a good with a certain price called the limit price. As the market receives these orders, it will compare them to the existing orders it has received and execute a match if possible. It will then notify both the buyer and the seller of a fill which says that the owner has traded a certain amount at a certain value.

Let’s run through an example. There are some existing orders already placed in the market; one buy order at $\$$5, a sell order at $\$$5.50, and a sell order at $\$$6. In this case the bid, the highest buy order price, is $\$$5; and the ask, the lowest sell order price, is $\$$5.50.

Suppose someone comes along and submits a buy order with a limit price of $\$$5.51. Since this is greater than the ask, the order will execute with a price of $\$$5.50 (the price is based on the order that was already in the market). What happens next depends on the sizes of the orders. If the buy order has a greater size than the sell order then the entire sell order will be filled, the buy order will be partially filled, the new bid will be $\$$5.51, and the new ask will be $\$$6 to match the sell order remaining in the market. If the sell order has a greater size, then the buy order will be completely filled, the sell order will be partially filled, and the bid/ask prices will remain the same. If the sizes are equal, then both orders will be filled and the new ask will be $\$$6.

The way we’ll implement this is with two heaps: one for buy orders and one for sell orders. These heaps will be indexed by the price of the orders. When each order comes in, we’ll check against the heap containing the opposite types of orders, and pop orders off and fill them until we either no longer have a price overlap, or the size of the new order has been reduced to zero. As mentioned earlier, there will be a callback that is sent to the owner of each order to let them know they have been filled.

That’s it for the primary logic of the system. There are a few edge cases that we haven’t talked about, those are handled in the code and you’re welcome to browse that if you want to know more details. We’ll move on now to how we’re going to code this up.

The code is in a Git repository called complexeconomics. The code is written in the Go programming language, a newer language that makes a good trade-off between performance (much faster than Python, Matlab) and ease-of-use (much easier to use than C++, Java, Fortran).

You can run the project easily enough, however you’ll want to follow the instructions for the baseline-2019-03-09 tag since this repo will be liable to change over time as I play around with new ideas. The code for the double auction market is here. Enjoy!