Low Liquidity Data Problems

Discovering True Spot Price for Liquidators

This piece will differ from my others, as it is a collection of ideas and thoughts around problems in low liquidity pairs, without a concrete conclusion. It is a conversation, if you will. So please feel free to comment your reactions or reach out to me!

Front-running, Source: FashionABC

A Liquidator’s Dream

The 9 figure Mango Markets hack was an oracle exploit. Some would say the oracles “did their job” as they delivered the correct price of $MNGO, this is dangerously misleading for two reasons.

The first is that these oracles, Pyth’s “first-party oracle” and Switchboard, did not aggregate from sources representing all trading volume. This meant that the attacker could manipulate fewer sources and thus achieve higher leverage.

The second was that the oracles reported the market price, not the spot price. In other words, it made no assurances to the “real” price at which the liquidator could actually settle.

A liquidator or any party involved in collateral needs the true spot price to be secure. Often, spot and market price are the same, as the latter is calculated on previous trades, which often dictates the future price. This is not always true in low liquidity pairs.

Ontropy achieves price discovery without the use of an oracle. This has the benefit of low latency and higher liquidity, which eliminates the first issue the Mango oracles suffered. The current tech does not solve the second issue, but it’s easy to imagine how the oracleless framework allows for this to be possible. Let’s explore.

Further Constraints

Delivering the true spot price to DeFi applications is not enough. This data also needs to be fast and not exceedingly volatile. So, a solution cannot discount the market price and sacrifice incorrect liquidations for safety.

The spot price also needs to be genuine. In a 9 figure attack, it could be profitable to create fake buy orders. Testing the validity of the order book will prove to be a challenge.

The delivery of this information ought to be decentralized and widespread, meaning we cannot rely on third party providers. This is not only because third party sources have the means and motive to exploit, but because they cannot meet a volume threshold to be useful.

For example, a liquidator cannot use transactions from just themselves and their trusted network because these trades will represent a small portion of an already low-liquidity asset. They may also be one-sided, mostly buying on uptrends and selling on the way down.

User-Validated Data Aggregation

The first principle is clear: more efficient aggregation of volume reduces an attacker’s ability to exploit. The “user-validated” element deserves further conversation about its utility.

As a quick refresher, Ontropy’s Proof of Result allows users and protocols to bypass oracles in swaps, valuing derivatives, and sizing collateral. It then uses these transactions to derive a consistently flowing spot price.

The data being user-validated is important because it cannot be exploited by a third party oracle (or “first-party” oracle)—the traded price is now undoubtedly visible to everyone, so exploitations at the oracle layer can never occur again, changing the market itself is still possible and what we discuss here. This happens as PoR is interoperable, it can scale to incorporate data from all DEXs, on-chain data, AND centralized exchange transactions. This also improves liquidity while allowing the spot price to be tested. Also, because the finality is first achieved off-chain, the data can be delivered to liquidators to front-run and secure transactions in selling pressure—we’ll get to this.

Here’s a fun example from AllianceBlock’s $120 million oracle exploit two months ago. The attacker just changed the price feed origin due to the contract’s single point of failure, so this is an exploitation easily covered by Ontropy’s distributed system. These types of oracle exploits do not need the additional nuance provided here to be eliminated.

Source: PeckShield Security

Now let’s go back to our more complicated Mango exploit example. If a liquidator had attempted to sell $MNGO at the high $0.91 price, they would not have been able. This information alone would have alerted them to not write loans against this collateral. But they did not have this knowledge.

The question then becomes accurately attaining this information to deliver to the liquidator or other relevant parties. It’s also worth mentioning that the underwriter and liquidator are often disjointed parties that do not communicate, so providing a frequent, validated price feed is crucial as a common reference point.

The most common concern of Ontropy’s user-validated data is that one party can manipulate the price by trading with themselves. This is a valid problem. We solve this by achieving high volume, but non-ETH and non-USDT pairs would rarely have this volume. So we need to innovate.

Yet, it is impossible to create liquidity out of thin air. And this is precisely why the “trading with yourself” manipulation problem is not unique to Ontropy, but is exactly what occurred with Mango’s oracles.

It might be worth clarifying at this point that bots have no advantage in exploiting the user-validated price feed as contributions are weighted by volume. So, a bot cannot spam the system with dozens of small transactions. Because truth is derived from counterparties trading a real asset, it could be easy to determine two wallets trading back and forth with one another.

So, how can we acquire a true spot price and then deliver it to a liquidator? Here are some ideas.

Tests, Front-running, and State Channels

The first is testing. One party can create sell orders during heightened market activity and observe if they are filled. As spot price is defined by the ability for an asset to be “bought or sold for immediate delivery,” significant order sizes would prove this case.

There are two problems. This creates short-term exposure to the tester, but this can be mediated with a subsequent buy order if the sell order is filled. If the sell order is not filled, then the market price has deviated from true spot and no exposure is held.

The second problem is that attackers can provide some liquidity to pass these tests. While some additional checks can be implemented like previous trading history or if the volume involved “a large volume player,” like a DEX, this intrinsically involves trust.

There are other possible checks, like comparing open orders at the current market price and the price before a recent spike, and orders in between. Some versions of these tests may work, but they seem insufficient on their own.

The second idea to attain true spot prices is rerouting order flow for liquidators. This only applies when there is actual market volume, but say the price of a low-liquidity asset is beginning to fall amid selling pressure. As finality occurs off chain in a Proof of Result-style user-validated data system, a liquidator could pay for this information ahead of time after agreement but before on-chain settlement. 

Additional information, like the spread or discount accepted by each party, would be very useful at determining spot and informing a liquidation decision generally. This is where we deviate from traditional order book flows—although in some sense this system creates an order book, just a universal one with everyone’s collective transactions.

So, the value-add is that liquidators can attain actionable data with ultra-low latency. Even more, however, is that they can step in before agreement and undercut the existing seller and liquidate all of their positions off-chain—before anyone else knows or can react.

Yet a third way to reach consensus on the spot price of a low-liquidity pair is to force settlement of a portion of recently acquired assets in a different token. For example, Mango would tell the attackers that they will write a loan for the entire value of their $MNGO, but the value must be 20% (an arbitrary number to prove true spot) represented in ETH. This forces the attacker to sell their $MNGO on the open market and acquire ETH using their pumped-up market price.

This system works wonderfully. It not only ensures partial collateral in a liquid asset, but verifies the legitimacy of the low-liquidity asset spot price. Critics would argue this friction is way too high for the user: additional gas fees, latency, and just an unneeded extra step.

Here is where off-chain finality comes into play. Similar to a state channel, Proof of Result allows only the end result to be posted. There are two huge innovations that allow the user to use PoR seamlessly and acquire collateral with a high-liquidity asset: trading with three or more parties, not just two, and the ability to collectively cancel transactions (all parties agree the transaction won’t go to chain after all).

Let’s say a legitimate user just bought a low-liquidity asset and wants to take out a loan. They would call Mango and the two would complete the PoR process off-chain and reach finality. But because Mango wants this price point proven, they request 20% of the value validated in ETH. Either Mango or the user can bring in a third participant (or more) to enter the transaction. They can be a willing party who wants to purchase the asset, or more likely, someone backing the price point. Because this occurs off-chain, there are no gas fees or latency, and the transaction does not need to be executed if the spot price is deemed to be valid (all parties would agree to cancel). The attacker would not be able to produce this as there would be no willing buyer at the heightened price. If they acted as the buyer themselves, it would, at the very least, greatly reduce their profitability.

Again, legitimate buyers are able to produce this collateral, as the market and spot prices would be the same. It would not add friction, as the DKG and ZK steps occur off-chain via a p2p network and are so simple and abstracted they need not realize they are using it.

What oracles currently fail to do is provide the accurate price a liquidator could sell at, need be, especially in low-liquidity tokens during hacks. This is a multi-billion dollar problem.

Source: Money

Retail’s POV

We’ve mostly discussed the protocol’s side. Proof of Result benefits the user as well. This is principally from the assurance of fair prices and the security of their loans and holdings. It’s also from higher-liquidity order flow.

Like mentioned earlier, users can be directly paid for information on their trades and even earn favorable buying and selling prices. A possible Ontropy killer app idea is an extension that scans trades you are making, and indicates if there is a better price elsewhere. It can even direct order flow between users making a trade, or to the liquidator.

Final Thoughts

While the issue of market manipulation in low-liquidity assets is difficult, it is also fascinating. In this article, we talked about the requirements of data providers, why this is so crucial to liquidators and DeFi at large, and several possible solutions accessible through user-validated price discovery.

I would really love to talk to y’all and hear your thoughts and reactions to this topic. My DMs are open, and the comments are right below :).

As always, thank you for reading! To stay updated, follow me and Ontropy on Twitter and check out our website.

Sources

Mango Markets

Investopedia

FashionABC

PeakShield

Money