Small/Midcap and suffering from illiquidity? Try an AMM.

Photo by Museums Victoria on Unsplash

One of the biggest issues that plague the lives of anyone dealing in the world of small/midcap equities is liquidity: for the brokers, making a market is hard; for the companies, it seems like no matter what they say, no one seems to be interested in buying their stock.

For the few strategic investors who do buy the stock, they end up sitting on it, ironically removing liquidity from the market. As a result, regardless of how innovative a company is, barring the occasional miracle, getting listed at an early stage simply doesn’t cut it (even if you’re profitable!). The ticket out of the illiquid, “no one except small cap funds which are suffering equally gives a damn” pot is to get into the index and draw in passive flows. But one doesn’t get into the index by being small. The catch-22 is clear: small = not in index; not in index = can’t get big.

The result: frustration.

The traditional “solution” has been to engage a specialist broker in the small/mid-cap space who supposedly provides the service of making markets and providing liquidity in the stock. In exchange for some pretty generous fees, these brokers are meant to be able to get things moving for a stock, drum up some interest via research and eventually help smaller companies grow their market presence, trading volumes and market cap.

But in all honesty, has this really worked out as planned? Against the tide of passive flows sucking liquidity into the top index names and away from everything else, arguably the only party that wins from this is the broker – for multiple reasons.

Perhaps it’s time to try another approach and take a leaf out of the books of another class of assets that faced a shortage of market makers.

We’ve been reluctant to write about such a technical topic for a while, but now seems to be the right time.

Ladies and gentlemen, we present to you: Automatic market makers.

Origins of the AMM

The idea of an automatic market maker came about as a result of the initial failure to implement a “real life” solution to the liquidity problem in crypto markets. Traditionally, prices are quoted as a function of what is known as a “Central Limit Order Book” (or a “CLOB”), where buyers and sellers queue up their limit orders (bid and ask prices) and transactions happen at the intersection of the highest bid and the lowest ask.

This worked decently well for stocks, especially liquid ones, since the existing liquidity in the market allowed brokers and market makers to always have opportunities to make money from crossing the bids and asks, looking for arbitrage opportunities. Of course, the onset of high frequency trading (recommended reading here is “Dark Pools” by Scott Patterson) suggests that even the bids/asks being posted may be fluff, thanks to the quick reflexes of trading bots especially on the top index names.

Nonetheless, the underlying principle is that someone needs to be willing to offer liquidity in the market. The problem with early crypto was that few parties were willing to sit in the market and provide liquidity, ESPECIALLY in smaller tokens and given the overall volatility in the space. Initial iterations of crypto CLOB systems were abject failures – market makers were willing to make prices around the current price, but as prices moved away from the status quo (especially if the move was downwards), liquidity quickly disappeared, exacerbating price moves and contributing to the overall reputation of the space being “volatile”. Furthermore, the number of crypto assets was growing faster than centralised exchanges could (or were willing to) list them, and the market needed a way to build liquidity independent of the whims of the powers that be at the large exchanges.

And necessity truly was the mother of innovation. The crypto world needed a way to ensure trading could happen at all levels (even a poor price was better than no price), and that liquidity providers could be incentivised to commit liquidity on a somewhat permanent basis.

Thus, the team at Uniswap pioneered the first Automatic Market Maker, built on what is now known as the “constant product model”.

AMM math

As we mentioned earlier, we do try to keep our notes readable and not heavily technical, but for the purposes of demonstrating the brilliance of the AMM model, we do need some math. We will try to keep it simple, so bear with us.

The underlying equation for the constant product model is a simple one: x * y = k. This formula denotes the equilibrium relationship between the quantities of two assets in a pool (x and y being the quantities of asset 1 and 2, and k being the product of those initial quantities).

The value k is known as the “invariant” because it remains constant regardless of the fluctuations in the relative prices. Governed by such a relationship, a quick look at a graph plot of such a function should yield one clear conclusion: there exists a combination of x and y for all values of x and y. In plain English, it means that the x*y=k function will be able to provide a trade for any prevailing market price.

This is important because it means liquidity never dries up completely. You may get a bad price, but you won’t get no price, and that’s a HUGE improvement. As long as the proposed trade size is smaller than the total liquidity in the pool, any trader could come with a proposed trade, and the pool would make an offer for the other side: automatically, dispassionately and mechanically.

And where did the liquidity come from? None other than the tokenholders themselves: as a source of passive income, liquidity pools offered liquidity providers a large chunk of the 25bps trading fees charged per trade, which accrued mostly as additions to the liquidity pools denominated in either side of the trade.

This was crowdsourced liquidity from tokenholders, and it was this dynamic that bootstrapped the explosion in on-chain liquidity, way beyond what the centralised exchanges and their market makers could provide.

The discussion on AMMs can continue for hours more, with debates around the optimal pricing curves, capital efficiency, fungibility of liquidity and stability, to name just the topics that are top of mind – but those can be left for another note.

*We’ve included a worked example in the appendix for anyone who’s interested in the math.

Take the humans out of the picture

The underlying issue here is actually the humans. More accurately, it is a fundamental misalignment of incentives when it comes to using a broker as a market maker. Let’s break it down.

The interests of the issuer (whether of token or stock) are as follows: ideally the asset price goes up, but most importantly there needs to be liquidity AT ALL TIMES so that in times of duress, prices don’t implode.

The interest of the market maker/broker engaged to provide liquidity on the other hand is profit. Make markets when prices are stable so that profits are maximised when others cross the bid/offer spread, but avoid making markets when prices are volatile to minimise risks to internal P&L.

The problem is clear: when the market makers are MOST needed, they are LEAST likely to be around.

Furthermore, a broker has multiple market-making mandates: naturally they will focus on the ones that make them the most money, which will naturally be the ones that are most liquid. Those that are illiquid will be charged larger bid-offer spreads, which make them ever less attractive to trade, thereby reducing volumes and liquidity, making them less attractive…

Turning to the AMM model takes the human discretion out of the picture: a pool of liquidity, say cash and asset, is set aside and provides an underpin to market liquidity, ensuring that there is always a price for a trade to get done.

Lessons from the other side

So now the question is: if it worked for crypto, why can’t it work for stocks?

We think there is no reason for this not to work for stocks, other than the inadvertent protestations of small/midcap specialist brokers who may lose out on a lucrative pot of business. Of course, there are functions such as the publication of research including ratings and target prices that a broker can perform, but in a world of increasingly transparent information transmission and unbundling of execution/research costs (remember Mifid2?), that investor education function is increasingly taken on by companies themselves.

It will most certainly be economically unviable for a smaller company to have an internal dealing desk which helps to stabilise its own stock and provide liquidity in the market, not least having to deal with the inadvertent issues of insider dealing and market manipulation. But perhaps that’s where an unbiased, emotionless automatic market maker comes into play. It’s really just an algo – simple and quite clever.

That budget allocated for buybacks? Allocate that into the AMM pool. And that stock of treasury shares? Stick that in too. Then we get a two-sided pool, dictated by an invariant that mechanically dishes out liquidity on either side, buying or selling, and making sure that the stock trades in a liquid market at all times. No human intervention removes the temptation to break the law with insider dealing, as well as the inefficiencies of greed and fear.

And who should administer that pool?

Certainly not your average broker given the scope for conflicts of interest (although maybe a more forward-looking establishment might be up to the challenge!), but perhaps that’s where some of that expertise in the world of cryptos can come into the legacy world and give things a bit of an upgrade.

It’s at the very least worth a thought.

And seems like a much better alternative to having great businesses with stock that no one cares about.

* * * * * 

AMM worked example

Suppose there is a pool with 1m units of an asset (let’s call it Asset A: shares, crypto tokens etc) and the equivalent amount of another asset in the pair (call it Asset B).

Let’s say Asset A is priced at $10 each at inception of the pool, and Asset B is USD cash.

The pool contains 1m x A and $10m of cash (priced at $1 each for simplicity).

Let x0 be the initial quantity of asset A, and y0 be the initial quantity of dollars. In this case, x0 = 1,000,000 and y0 = 10,000,000.

Therefore, with a constant product model, x0 * y0 = k. So, k = 10,000,000,000,000.

How to price a trade and calculate slippage in the pool

Assume a buyer comes and wants to buy 100,000 of Asset A.

The proposed trade is to remove A from the pool and add dollars.

The end state of the pool is that there will be 1,000,000 - 100,000 = 900,000 units of Asset A remaining.

Let x1 be the quantity after the trade is done. x1 = 900,000. k is invariant = 10,000,000,000,000. Therefore the resulting quantity of dollars in the pool, y1, has to be 10,000,000,000,000/900,000 = 11,111,111.11.

The price per A quoted in this transaction would therefore be y1-y0/x0-x1 = $11.11 each.

The slippage from the trade size being large (10% of the pool) is 11.1%, and it follows that the larger the pool is relative to the size of the proposed trade, the lower the slippage. To put things in context, the most liquid pair on Sushiswap is WBTC-ETH, with $527m of two-sided liquidity available.

From that point, additional trades in the same direction (buy A) would push the price of incremental units up, while trades in the other direction (sell A) will lower the price of incremental units down, in an exponential manner reflecting the availability of supply.

Variations on the constant product model also exist: for example, Curve uses a constant price model , which in general only applies for swapping assets that have largely stable relative prices e.g. stablecoins, wrapped/pegged versions of other tokens (e.g. wBTC-renBTC, ETH-stETH etc).

A commission parameter can be added for the pool to receive commissions denominated in the asset paid in (i.e. if buying A, pool receives more USD; if selling A, pool receives more A).

Finally, there is also the matter of “impermanent loss” from LP pools – the counterpart to the arbitrage profit made from correcting the price differential implied in the pools to the prevailing market price. Unfortunately, we’ve been advised that extending the worked example to include calculations for IL would be overkill, but if anyone wants to see a simple example, please drop us a line, happy to provide it!