As I discuss in Section 4.3 of Modern Monetary Theory and the Recovery, the “Monetary Monopoly Model” is the core macro model that captures some of the key ideas of Modern Monetary Theory (MMT). The key concept is that the government needs to set a key price (or a set of prices) in order to determine the price level of a fiat currency. This is contrast to mainstream models, where pinning down the price level is an embarrassing theoretical muddle.
For a commodity currency, real factors can be used to pin down the price level in a model. (Sure, the real world can be messier, but the model logic will still be present.) Let us assume that the currency is gold-based. We look at the number of hours of labour to mine an ounce of gold, and we can then get a fair value for an hour’s labour. We observe that mine owners should be able to mine gold with a profit, as otherwise no gold will enter the system. Once we determine the income split between miners and mine owners (which is either based on power relationships, or magical marginal thinking, depending upon ideological preferences), we get a fair value for an hour’s wage. We then can pin down wages in other industries via the level of gold miners’ pay, and then can back out other prices. The key is that real parameters within the model — productivity — pin down the price level for a commodity currency.
For a fiat currency, there are no real factors associated with the currency creation. We could multiply all prices by the same factor, and preserve all relative value relationships between all real goods. From a modelling perspective, this implies that the solution to the model is indeterminate: the set of prices implied by the model is the set of all scalings of any price vector that works as a solution.
We need something to pin down the set of solutions to the model, and the MMT solution is the government to fix a key price that forces a single solution.
Although this discussion refers to an abstract problem in economic model building, the argument is that price level instability in models is related to inflation control. That is, can governments set key prices to help stabilise prices? The MMT argument is that is exactly what a Job Guarantee can do.
Levey’s Levy Paper
Sam Levey’s paper steps through a sequence of models of increasing complexity. They are discrete time models in which the government is a monopoly supplier of money, and examines “the price of money” (ratio at which labour is exchanged for money).
He examines what happens when the government sets a price for labour via a Job Guarantee, competing against private sector demand for labour. Using his reversed definition of price, this can be thought of as the government having one price of money versus the private sector (when expressed in labour hours).
This framing then leads to the debate whether a fiat currency issuer truly has a “monopoly” on “money,” given that a lot of “money” are private sector liabilities (mainly bank deposits, but we get wackier credit instruments in broad aggregates). Levey writes:
An analogy can be drawn to the study of “durapoly,” a situation noted in mainstream antitrust and industrial organization literature in which there is a monopoly producer of a durable good and, once sold, this durable good can be “recycled” or resold by other suppliers back into the market (Orbach 2004). Of particular interest is the 1945 antitrust case of United States vs. Alcoa, concerning whether Alcoa, which controlled 90 percent of the production of new aluminum, in fact lacked monopoly power due to the existence of a competitive market in recycled aluminum.
There is significant mainstream literature on durable goods markets in general (Waldman 2003) and the Alcoa case in particular (Gaskins, Jr. 1974; Swan 1980; Suslow 1986). We need not delve deeply into the topic, but we can borrow a general result that a monopoly producer can retain pricing power over a durable good if there is some reason why outstanding units of the commodity become insufficient for meeting the community’s demand. This can happen if units are lost or otherwise unavailable for recycling, or if demand is growing. One or more of these conditions, if continued indefinitely, will eventually force buyers of the good back to the producer, granting the producer bargaining power. For our model this will be taxation: in the absence of government spending, taxation would eventually drain the supply of state money to zero, creating “shortages” in the “secondary market,” forcing demanders of fiat money back to the government and thereby imparting it with pricing power.
The argument is that setting the Job Guarantee wage alone does not fix the price level by itself, rather it operates in conjunction with the monetary drain of taxation.
I looked at the paper relatively quickly, but the models looked clean and seemed well laid out. Since I am supposed to be working on my own agent-based version of a similar model, I do not want to get too side-tracked on going through the details of Levey’s work just yet.
The true challenge with modelling the Job Guarantee is trying to pin down how private sector wages would be set versus the Job Guarantee wage. The standard belief is that private wages would be set as a markup to the Job Guarantee wage, with the markup varying with the cycle. Although that is reasonable (and somewhat non-falsifiable), the trick is modelling the markup. Given the lack of full scale implementations of Job Guarantee programmes, we do not have much in the way of empirical data to work with.
I might return to this paper later, but I just wanted to let everyone know that it is out.
Postscript: Agent-Based Version?
I am plugging away at my agent-based framework, which is an open source Python project. At this point, I have something resembling a closed loop model running. However, I am refactoring it heavily, so I do not consider what I have to be in any sense a completed model.
The problem with a complex agent-based model (like the one I am attempting to build) is that sensible looking decision rules require agents to have a lot of input data to work with, and they need to interact with other many other agents.
For example, the simplest production firm hires workers and then attempts to sell its output. Modelling this requires a few steps.
The production firm needs to get the posted market prices for its output, and have an idea what market wages are for setting hiring offer wages.
It needs to look at prices and wages (at least) and decide how many workers to hire. (Realistically, they would need more data to make more sensible decisions.)
It needs to interact with the worker agents to pay them salary, and with the government to pay withheld income tax.
The production event needs to follow its production function.
It needs to interact with the market to sell its output.
From a programming point of view, this means that the firm needs to interact with a lot of different other software entities — each of which also needs to interact with others. This turns into what is known as “spaghetti” in software engineering jargon.
I am in the process of creating a standardised interface so that all of the agents can make their decision process in a structured fashion. The agents just indicate what input data they need, and then when that data is supplied, they give a list of actions to be taken. The software framework then processes those actions, which means that decision-making code does not need to know how interactions between agents are implemented.
Going with this more elegant solution slows down adding new features. However, once it is in place, it should be easier to add new decision rules, which is ultimately the most interesting part of the project.
I write more about this project on my Patreon.