Downside Liquidity: A Hypothesis on Short Pools for EVM

The new market cycle truly feels different. While 2017 was marked by the ICO boom and 2021 by the rapid growth of the DeFi sector and NFTs, in the current cycle, meme tokens are taking the lead. Public figures have entered the scene, including presidents and even leaders of major countries.

In January 2024, the project pump.fun was launched on the Solana blockchain, allowing users to create tokens as quickly and cheaply as possible.

However, most meme tokens experience rapid growth followed by even faster declines. Sometimes, it all ends with a simple rug pull.

When transferring liquidity from the launchpad to a DEX, and as the community grows, the price development should generally follow this pattern:

But in reality, it turns out like this:

In my view, this is due to the fact that the market operates on a zero-sum game principle. However, with the use of liquidity pools on DEXs and the ability to sell without a matching counter-order, the balance between supply and demand becomes distorted.

Ideas on how this could be improved came to me after analyzing algorithmic stablecoins, particularly Terra Luna. For those unfamiliar with this project, here’s a brief explanation of how it works:

1. In the case of UST’s price falling below $1, the Debase algorithm was triggered, allowing traders to exchange 1 UST for 1 LUNA. During this process, UST was burned while new LUNA was minted.

2. When UST’s price rose above $1, the Rebase algorithm activated, where LUNA was burned and, conversely, new UST was minted.

However, the entire ecosystem faced the so-called "death spiral," rooted in the endogenous (on-chain) nature of its collateral. Despite differences in algorithms, projects like Basis Cash and Empty Set Dollar repeated the same mistake — relying on internal collateral led them to similar issues and eventual collapse.

In contrast, the example of DAI shows that exogenous (off-chain) collateral can also be vulnerable: when ETH crashed by nearly 50% in a single day, the system was put at risk. Yet, it was precisely the use of external collateral that made it possible to stabilize the situation afterward — through emergency issuance of the MKR token and intervention by the community.

After comparing the two types of collateral, I came to the conclusion that in order to support the price, it is necessary to create a separate pool with short liquidity, independent from the long pool.

It could work as follows: along with transferring liquidity to the DEX, liquidity is also added to the protocol specifically for opening short positions.

From there, several scenarios are possible:

1. Both pools grow — which means someone is opening a short position. This is where the first advantage of the idea becomes evident: increased market transparency.

2. If demand exceeds supply, that’s a natural market situation.

3. Similarly, when supply exceeds demand, it’s also part of normal market dynamics.

4. In the case of a sharp change in the long pool — so drastic that even the label doesn’t fit — a rebalancing algorithm can be activated. As a result, the price returns to equilibrium through the participation of the short pool, without an seller.

For the rebalancing algorithm to function, the following are required:

• Defining what percentage of price change over a given time period will be considered an “abnormal” market fluctuation;
• Setting up continuous price monitoring;

• When the specified conditions are met, executing rebalancing, limiting its size to a single cycle up to a certain percentage in order to protect the system from manipulation.

In this article, I will take a closer look at one of the key components of this mechanism — creating a short liquidity pool for EVM-compatible blockchains using Solidity.

Preparation

The protocol will be handling user funds, we’ll import OpenZeppelin’s Ownable and ReentrancyGuard contracts, as well as a contract for fetching asset prices from Chainlink.

For simplicity, we’ll use WBTC and WETH tokens on the Ethereum Mainnet, though ideally, the list of available tokens should be defined when deploying the smart contract.

To make the contract more extensible, we’ll add a mapping for supported tokens, where the key is the token’s address and the value is the address of the corresponding Chainlink price feed contract.

Let’s also implement a utility function for adding values to the mapping. To enhance security, we’ll prevent updating the Oracle contract address for a token that has already been added.

To store positions, we’ll use a mapping where the key is the user’s address, and the value is an array of structs containing:

• Token address
• Opening and closing prices
• Position size
• Current status (open, closed, or liquidated)

Opening a Position

In this protocol, prices will be denominated in USD, so we’ll need an internal function for value normalization.

To obtain the opening price in USD, we first query the oracle for the current ETH price and the token price, normalize both values, and then calculate the position size. If all checks pass, we add the position to the mapping and emit an event using emit.

Closing a Position

To unify the logic for closing and liquidating positions, we’ll create a modifier that checks the current status of the position.

We’ll also create a helper function to calculate the withdrawal amount and the closing price.

Next, when closing a position, there are two possible scenarios:

1. If the user is eligible to receive funds back, we set the closing price and withdraw funds to the user.

2. If the position must be liquidated (for example, due to insufficient collateral), the position is marked as liquidated without transferring funds.

As a placeholder for the closing price in case of liquidation, the maximum uint256 value can be used.

This implementation is simplified, so it would be better to add automation using Chainlink or Gelato for periodic price checks and automatic liquidation when necessary.

To support this, the liquidation function should accept the user’s address as a parameter to specify which position needs to be liquidated.

Conclusion

In this article, I’ve shared a hypothesis about a short liquidity pool and proposed a basic implementation in Solidity for the Ethereum blockchain. If anyone finds this idea interesting, I’d be glad to see it become part of a larger project!

The full code is available on GitHub.