On Collateral Valuation and Design in Decentralized Financial Applications

When implementing a financial application involving loans, be it leveraged yield farming, collateralized lending markets or decentralized perpetual futures exchanges, serious consideration must be given to the process and method used to price assets within the decentralized, on chain environment.

This consideration is separate from designing aspects like collateral ratio (LTV) and pertains specifically to gathering and utilizing asset price information which will eventually be included in the LTV calculation.

While the oracle problem is largely solved by many industry provider like chainlink, pyth or redbrick; understanding the what the prices delivered by these providers are actually based off of and how to best integrate them into the specific use case of your DeFi application are of critical importance.

For the most part, this issue comes down to risk management particularly as it pertains to liquidations on any platform that allows users access to leveraged products and loans.

Defi application offering leverage, generally serve two parties the liquidity provider and the trader and thus, must balance offering the highest possible leverage for the trader and the most collateral safety for the LP. When a trader's collateral is liquidated at a price that results in proceeds less than the amount of the loan owed to the LP this balance is violated and the difference in value is marked as bad debt resulting in an impairment of the liquidity provider pools funds.

For this reason, a safety ratio is often built into the lending markets design resulting in two critical numbers attached to any loan that is opened. The initial margin requirement and the maintenance margin requirement.

There Is No Price

Thinking of the price as single, definitive number is a misconception. Allow us to briefly re-conceptualize price. Price is, of course, what someone is willing to pay. However, if we invert this statement, price is what someone is willing to receive. From this stand point, it is easy to imagine that these numbers are different depending on whether we are looking to buy something or looking to sell it. We need only imagine a limit order book for any asset to understand that, at any given moment, the only definitive is that there is one price at which we know a party is willing to buy and another price at which we know a party is willing to sell. These must be different prices, or else the two parties would have already bought and sold from each other leaving us to have to find a different party to buy or sell from at an even different price point.

True market pricing, involves a bid / ask price. a price for buying and a price for selling.

Mark To Market, Mark To Model

So, When our DeFi application calls an oracle and gets a single number, we think of it as a price but is it a market price? No. In this case we are working with some model of a price. A useful approximation used to evaluate the our assets in an application specific way.

For example, if we have a DeFi application with two pools, one of ETH and one of WBTC. We might fetch some general price, like the last trade price, for both BTC and ETH in terms of USD. We then multiply the amount of ETH by the USD price of eth and the amount of WBTC by the USD price of BTC, add the two numbers together, call it our TVL and display it on our front end. "$xxx,xxx,xxx Total Value Locked"

Pretty harmless assumption to make that the last trade price is a good price to use in this scenario because the result of this calculation is merely cosmetic and not mission critical to the application. But, can we really expect the receive $xxx,xxx,xxx in exchange for liquidating both pools for USD at this moment. Absolutely not, we have just naively marked marked all the assets locked in out pools at the last trade price.

However, in the case of a loan or leveraged position, we are fetching a price and marking an asset value because we expect we might actually have to liquidate the assets immediately, into the market in the case of a collateral ratio violation (loan liquidation). In this situation, we actually we want to be very confident of the value we can actually get for selling these assets at this moment. The last trade price is not a good model to mark by for several reasons. How long ago was this trade made at this price? In what size was the this trade executed at for this price? Was this trade executed as a buy or sell?

We can see, though this example is absurd, that there are many considerations about how a price was arrived at (the model) when marking collateral to certain price. In order to manage the risk of a lending market, we need to have strong confidence in what value can we actually receive if we liquidated a certain amount of a collateral asset at this moment.

The Models

Considering that we know understand why we need different models of pricing for different situations, let us review a few basic price types. First, we can think about a perps exchange allowing counterparties to trade futures against each other on a perpetual basis. Exchanges like Bitmex or even DEXs rely on an index price to mark the value of futures contracts P/L against the associated margin of a trader. Combining prices from several liquid exchanges, using a formula that weights each price based on the volume, they create a Volume weighted average price across all the exchanges and mark position based off of this model of pricing.

If we had some simple graphic displaying the ticker of a given asset, meant for nothing more than to give the user a general idea of what price that asset might be trading around. A website will often call an exchanges api, which provides the current bid/ask price and then take the mid-point, a price directly in between the spread and display it as the price.

On chain applications, typically using the popular UniswapV3 price as an oracle, are calling a price from a highly liquid uniswapV3 pool which represents the time weighted average price of an asset, TWP. A the TWAP calculates the geometric mean of relative prices of the two assets in a pool over a certain rolling window. The rationale for using this model on chain, versus the VWAP (volume weighted price) used in traditional markets, is primarily on of security. This is because one popular vectors of attack against lending markets is to temporarily manipulate the price of an asset inside of the pool used as a reference price and earn a greater profit than the cost of the manipulation on the lending market as a consequence of this mis-pricing. However, since this price is calculated over a certain window of time, an attacker must manipulate the price over a longer period in order to affect the mark price used in lending markets thus making such an attack infeasible.

Liquidity and Size

An additional consideration when pricing collateral assets, especially with regards to liquidation is the size of the potential liquidation and the depth of the liquidity in the market you might liquidate into.

This is particularly important for exotic markets, even less exotic markets such as options, where the market liquidity may be thinner than a standard blue-chip asset like ETH. Fragmentations of market liquidity pools is also an important factor to take note of when designing a lending market.

Especially in ultra high leverage markets, where the margin of safety with regards to a user's collateral ration is razor thin, the price slippage of liquidating a large position into a thin market can cause serious insolvency issues and create bad debt. Practically speaking, the higher the leverage and the thinner the market liquidity, the more pessimistic your implementation should be when assigning a value collateral assets.

One design consideration that could be made is adjusting the pricing model in addition to the collateral ratio to manage risk on a size aware basis. It may be appropriate for a smaller loan (relative to the market liquidity) to have a lower collateral ratio requirement than a larger one on the basis that liquidations on a smaller loan will execute at a better effective price. Further, the oracle mechanism that fetches the price and assigns a value to the collateral of a given position can take into account the size of the position when marking a price given the available liquidity providing a more pessimistic (less risky) model to mark the collateral. Though, in practice, fetching the depth of market liquidity is a difficult task and is currently an emergent research topic.

Implementation

So, now let us outline the actionable take aways from these considerations.

First, when fetching oraclized price data on-chain, we must implement EIP-7726. Since, oracles typically return a fixed price ticker, it is essential to wrap them in a standard interface that shifts our conception (as well as our interactions) with this price data from one of fetching a definitive price to fetching a quote

The getQuote interface, implemented by EIP-7726, allows contract calls to request a quote for a certain amount of a certain asset in terms of another asset.

In this way, we get to the heart of our actual requirement in a lending market. The price of 1 ether is not actually relevant to us when we are trying to manage the risk of a USDC loan collateralized by ETH. Instead, we care about how much USDC we can receive were we to liquidate a specific amount of collateral. Thus, getting a quote for a position's collateral assets more closely aligns our conceptualization of the oracles function to the requirements of our application.

We can also implement bid/ask awareness when fetching the price of an asset. In the event of a liquidation are we buying or selling into this market? Specifying the direction of a liquidation helps us fetch a more pessimistic price assumption.

Further our design needs to carefully consider the purpose of quoting these asset's value. Do we need an index price? weighting across several markets based on volume in order to enforce some contract between counterparties? or do we need a price that is resistant to manipulation such as TWAP?

Lastly, we need to consider the amount leverage that is offered to traders (borrowers) on our platform and how can we best model a quote that effectively manages the risk to our liquidity provider (lenders). How will the platform manager open interest vs market depth to create a platform large liquidations don't encounter price slippage that effects the solvency of the LPs.

Here must make careful considerations when designing a DeFi application that balances risk management, high leverage and usability to carefully engineer an efficient and valuable platform.

At Yield Dev Studio we specialize in DeFi design and development. Reach out if you before you undertake your next project.