About Path Independence

Author: Vitalik Buterin

Original Title: 《On Path Independence》

Publication Date: July 22, 2017

Suppose someone walks up to you and starts shouting that he thinks he has figured out how to create a source of infinite free energy. His scheme is as follows. First, you get a spaceship to low Earth orbit. There, the gravity of the Earth is quite high, so the spaceship will begin to accelerate violently towards the Earth. The spaceship will position itself on a trajectory that barely grazes the Earth's atmosphere and then continue flying into deep space. In space, the gravity is lower, so the spaceship can fly higher before it begins to descend again. As it descends, it will follow a curved path towards the Earth to maximize its time in low orbit, maximizing the acceleration it gains from the high gravity there, so that after passing the Earth, it will fly higher. After reaching a sufficient height, it flies through the Earth's atmosphere, slowing itself down but using waste heat to power a thermal reactor. Then, it will return to the first step and continue forward.

Something like this:

Now, if you have any understanding of Newtonian dynamics, you will likely realize immediately that this scheme is complete nonsense. But how do you know? You could appeal to symmetry and say, "Look, for every segment of the trajectory path you say gravity gives you high acceleration, there is a corresponding segment of the trajectory path where gravity gives you the same high deceleration, so I don't see where the net gain comes from." But suppose that man presses you. "Ah," he says, "but in that high-acceleration segment, your initial speed is low, so you spend a lot of time in it, while in the corresponding segment, your incoming speed is high, so you spend less time decelerating." How do you really, ultimately, prove him wrong?

One way is to delve into the mathematics, calculate the integrals, and prove that the assumed net gain is actually zero. But there is also a simpler way: recognize that energy is path-independent. That is to say, when the spaceship moves from point A to point B, where point B is closer to the Earth, its kinetic energy will certainly increase because its speed has increased. But because total energy (kinetic plus potential) is conserved, and potential energy only depends on the position of the spaceship and not on how it got there, we know that regardless of the path taken from any starting point, once it reaches point B, the total change in kinetic energy will be exactly the same.

Different paths, same energy change

Furthermore, we know that the kinetic gain from starting at point A is also independent of the path you take along the way: in all cases, it is completely zero. Sometimes concerns are raised about on-chain market makers (i.e., fully automated on-chain mechanisms that provide a counterparty always available for those wishing to trade one token for another).

One concern is that they are always easily exploited.

For example, let me quote a recent post discussing this issue in the context of Bancor:

The price that Bancor provides for tokens is unrelated to the actual market equilibrium. Bancor will always lag behind the market, and doing so will deplete its reserves. A simple thought experiment suffices to illustrate the problem. Suppose market panic unfolds around token X. Baseless rumors about your system flood social media. Assume people are convinced that your CEO has fled to a remote island with no extradition treaty, your CFO has been embezzling funds, and your CTO is buying drugs from the dark web and having them delivered to his work address to make a Scarface-style pile of white powder on his desk. Worse still, suppose you know these accusations are false. They are being spread by a troll army from a company with no product, whose business plan is to stop everyone’s coins from flowing. Bancor would provide a continuously decreasing price for token X during a bank run until it has no reserves left. You would watch helplessly as market panic takes over and consumes your reserves. Remember, people are convinced that in this case, the true value of X is 0, and the Bancor formula guarantees a price above that value. So your entire reserve would disappear.

This article discusses many issues surrounding the Bancor protocol, including details like code quality, which I will not delve into; instead, I will focus purely on the themes of efficiency and exploitability of on-chain market makers, using Bancor (and MKR) as examples without making any judgments about the overall quality of the project.

For many naively designed on-chain market makers, the comments above regarding exploitability and tracking the market apply verbatim and very seriously. However, there are also some on-chain market makers that would never doubt that their entire reserves could be depleted due to some kind of pump attack. For a simple example, consider a market maker selling MKR for ETH, whose internal state consists of the current price and is willing to buy or sell an unlimited amount of MKR at each price level. For instance, suppose you want to buy 2 MKR. The market would sell you:

0.00…01 MKR at a price of 5 ETH/MKR
0.00…01 MKR at a price of 5.00…01 ETH/MKR
0.00…01 MKR at a price of 5.00…02 ETH/MKR
….
0.00…01 MKR at a price of 6.99…98 ETH/MKR
0.00…01 MKR at a price of 6.99…99 ETH/MKR

In total, it sells you 2 MKR at an average price of 6 ETH/MKR (i.e., total cost 12 ETH), and at the end of the operation, it has increased to 7. If someone wants to sell 1 MKR, they will spend 6.5 ETH and will drop back to 6 at the end of that operation.

Now, suppose I told you that this market maker started at a price of 5, and after a series of unspecified events, it is now at 4. Two questions:

1. How much MKR did the market maker gain or lose?
2. How much ETH did the market maker gain or lose?

The answer is: it gained 1 MKR and lost 4.5 ETH. Note that this result is completely independent of the path taken. If these answers are correct directly with a buyer from 5 to 4, they are correct from 5 to 4.7 and the second buyer remaining on the way to 4, they are even correct if it first drops to 2, then rises to 9.818, then drops again to 0.53, and finally rises back to 4.

Why is this the case? The simplest way to see this is to look at the fact that if it drops below 4 and then rises back to 4, the sells during the drop are exactly offset by the buys during the rise; every sell has a corresponding buy of the same amount at the exact same price. But we can also see this from a different angle by looking at the core mechanism of the market maker. Define the market maker as having a one-dimensional internal state and having MKR and ETH balances defined by the following formula:

Anyone has the right to "edit" (though only within values between 0 and 10), but they can only do so by providing an appropriate amount of MKR or ETH and taking back an appropriate amount of MKR and ETH so that the balances still match; that is, the number of MKR and ETH held by the market maker after the operation is exactly the number that should be held according to the formula above, with the new values being set. Any edit that does not automatically match the balances with MKR and ETH transactions fails.

Now, any series of events that drops from 5 to 4 will also increase the market maker's MKR balance by 1 and decrease its ETH balance by 4.5, regardless of what the series of events is, which should look quite simple:

This means that conducting a "reserve bleed" attack on a market maker that retains this path-independent property is impossible. Even if some trolls successfully create market panic, driving the price down to near-zero levels, when the panic subsides and the price returns to its original level, the market maker's position will remain unchanged—i.e., even if the price and the market maker's balances made a series of crazy moves during that time.

Now, this does not mean that market makers will not lose money compared to other holding strategies. If, when you start, 1 MKR = 5 ETH, and then the MKR price changes, we will compare the performance of holding 5 MKR and 12.5 ETH in the market maker with simply holding the asset, resulting in the following:

A balanced portfolio always wins unless the prices remain exactly the same, in which case the returns of the market maker and the balanced portfolio are equal. Therefore, the purpose of such market makers is to subsidize guaranteed liquidity as a public good for users, acting as the last trader, rather than to earn income. However, we can certainly modify the market maker to earn income, and it's quite simple: we let it charge a spread. That is, the market maker might charge just for buying and quoting sales. Now, becoming a beneficiary of the market maker turns into a gamble: if prices tend to move in one direction over the long term, then the market maker will lose, at least relative to the returns that they could have earned by holding a balanced portfolio. On the other hand, if prices tend to rebound sharply but ultimately return to the same point, then the market maker can make a considerable profit. This sacrifices the "path independence" property, but any deviation from path independence is always favorable to the market maker.

Path-independent market makers can take many designs; if you are willing to create a token that can issue an unlimited number of units, then the "constant reserve ratio" mechanism (where for some constant ratio, the token supply is and the reserve size is also counted as one, provided it is correctly implemented and path independence is not affected by boundary and rounding errors).

If you want to create a market maker for an existing token without a price ceiling, my favorite (thanks to Martin Koppelmann) mechanism is to maintain a constant mechanism for some constant. So the formula is:

Where P is the price at which. In general, you can create a path-independent market maker by defining any (monotonic) relationship and calculating its derivative at any time to give the price.

The above only discusses the role of path independence in preventing a specific type of problem: an attacker conducting a series of trades in the context of a series of price changes to repeatedly extract funds from the market maker. For path-independent market makers, this "fund pump" vulnerability is impossible. However, there can certainly be other types of inefficiencies. If the price of MKR drops from 5 ETH to 1 ETH, then the market maker used in the above example will lose 28 ETH in value, while a balanced portfolio will only lose 20 ETH. Where did those 8 ETH go?

In the best case, the price (i.e., the "true" price, the price level at which supply and demand match among all users and traders) drops rapidly, and some lucky traders rush to trade, gaining 8 ETH minus negligible trading fees. But what if there are multiple traders? Then, if the price between blocks and prevents different traders from bidding against each other by setting trading fees, this fact creates a fully paid auction, with the revenue going to the miners. Due to the revenue equivalence theorem, we can infer that we can expect the trading fees sent to that mechanism by traders to continue to rise until they are roughly equal to the size of the profits earned (at least initially; the true equilibrium is for miners to rob the money themselves). Therefore, in any case, schemes like this ultimately end up being a gift to the miners.

One way to increase social welfare in this design is to make it possible to create purchase trades that are only worth including if the miners actually make the purchase. That is, if the "true" price of MKR drops from 5 to 4.9, and there are 50 traders rushing to arbitrage the market maker, and only the first of those 50 traders will make the trade, then only that person should pay a trading fee to the miner. This way, the other 49 failed trades do not clog the blockchain. EIP 86 planned for Metropolis paved the way for standardizing this conditional trading fee mechanism (another good side effect is that it can also make token sales less conspicuous, as similar fully paid auction mechanisms apply to many token sales).

Moreover, if the market maker is the only available trading venue for the token, there are also other inefficiencies. For example, if two traders want to conduct large trades, they will need to do so through a series of small buy and sell trades, unnecessarily clogging the blockchain. To reduce this inefficiency, on-chain market makers should simply be one of the available trading venues, rather than the only one. However, for protocol developers, this can be said to not be a big issue. If a venue facilitating large trades is ultimately needed, others may provide it.

Additionally, the argument here only discusses the path independence of market makers, assuming given starting and ending prices. However, due to various psychological effects and multiple equilibrium effects, the closing price seems to be a function not only of the starting price and recent events affecting the asset's "fundamental" value but also of the trading patterns that occur in response to those events. If a price drop event occurs, and due to poor liquidity, the asset price drops rapidly, it may ultimately recover to a point lower than when there was more liquidity initially. That is to say, this may actually support the argument for subsidizing market makers: if such multiplier effects exist, they will have a positive impact on price stability beyond the first-order effects of the liquidity provided by the market makers themselves.

Determining which path-independent market maker is optimal may require a great deal of research. It is also possible that hybrid semi-automated market makers have the same guaranteed liquidity properties, but include some asynchronous elements, as well as the operator's ability to "cut in line" and charge profits in cases where otherwise miners would lose a significant amount of funds. For various objectives, how much on-chain automation guarantees liquidity (if at all) is optimal, and to what extent these market makers should be subsidized and by whom, there is currently no coherent theory. In summary, the design space for on-chain mechanisms is still in its early stages, and certainly deserves broader research and exploration of various options.