Sign in

Internal Oracle

Defensive Computation

Fail-Fast

Value the position at its worst

Defensive Computation

Suggest an edit

Due to the nature of Web3, programs cannot trust anyone and have to consider the worst-case scenario at any point of time. Because of that, the programs have to do what we call ‘Defensive Computations’: choose the lowest possible boundary to work it. It can be the lowest evaluation of assets’ price when accepting them as collateral, or the highest evaluation of existing debt.

The same position when the band widens Two boxes side by side. Both show a position with 10 tokens of A as collateral and 100 tokens of B as debt, with the same middle prices: A at 150 and B at 10. On the left the market is calm, the band around A is 149 to 151 and the band around B is 9.9 to 10.1. The program values the collateral at the bottom, 1,490, and the debt at the top, 1,010. On the right the market is stressed, the band around A is 144 to 156 and the band around B is 9.5 to 10.5. The collateral is valued at 1,440 and the debt at 1,050. The middle prices did not change, but the position looks worse from both sides. Same middle prices, wider band Calm market collateral: 10 A 149 151 10 x 149 = 1,490 debt: 100 B 9.9 10.1 100 x 10.1 = 1,010 1,490 / 1,010 = 1.48 Stressed market collateral: 10 A 144 156 10 x 144 = 1,440 debt: 100 B 9.5 10.5 100 x 10.5 = 1,050 1,440 / 1,050 = 1.37 The middle prices are 150 and 10 in both boxes. A middle-price program sees 1.50 in both. Red dot = the end the program uses. The numbers are only an example.

That is, in order to avoid the risk of taking inaccurate data, the data has to be taken into account at the worst possible version.

Examples

Marginfi. The oracle gives a price and a confidence band. To value a user's collateral, the program takes the bottom of the band. To value the debt, the top. When the band widens, the position looks worse from both sides at once: the user can borrow less, and the liquidation line moves closer. The protocol never lends against the optimistic reading. Two limits keep the band reasonable. The widened confidence is capped at 5% of the price and if the widened confidence is above the limit set for the bank (10% of the price by default) the program does not use the price at all and returns an error.

One line for opening, another for liquidation A horizontal scale of loan to value, from 0 to 100 percent. A line at 75 percent marks where borrowing stops, and a line at 85 percent marks where liquidation starts. A position opened at 74 percent is allowed. After the collateral price falls, the same position is at 80 percent. It cannot borrow more, but it is not liquidated, because it is still below 85 percent. Only at 86 percent can a liquidator take it. The gap between the two lines is the buffer that keeps a fresh position from being liquidated by the next small move. One line for opening, another for liquidation 0% 100% loan to value 75%: borrowing stops 85%: liquidation opened at 74% allowed price fell: 80% can't borrow more 86% liquidated The user chooses when to open, so opening gets the stricter line. Liquidation happens to the user, so it gets the looser one. The numbers are only an example.

Image above is the example of how lending and perp protocols use two different caps for “user action” and “protocol action”. They have a band for the protocol to make a decision so users could not move borrowed percent and manipulate.

Drift refuses to fill when the band is too wide relative to the price, and rejects prices that are too old. Let's assume the collateral's price jumps for a few seconds, because of a real move or a manipulated one and then the oracle shows the new price at once, but the 5-minute average does not. The deposit is still worth the lower number and the user cannot borrow against the jump until it has lasted long enough to move the average. On the other hand liquidations do not use such strict mode, they utilize the plain oracle price, for the same reason as the two lines above. We want the protocol to reflect any changes faster than the user could manipulate this change.

Kamino rejects a USDC price far from $1, no matter what the oracle says.

Helium prices Data Credits at the bottom of the band. Its a good example of this pattern to show that this is not only about lending. Helium sells the use of its network in Data Credits (1 Data Credit = $0.00001). To get this Data Credits user needs to burn his HNT token (which price can be different). The protocol reads the price from oracle, takes the exponential moving average and subtracts twice its confidence - by this formula they calculate “most conservative price”. Such ways allows Helium creators to be confident that users never get more Data Credits than HNT tokens were burned.

Previous

Internal Oracle

Next

Fail-Fast