Author:@tuba, the author authorizes Lianwen to publish the Chinese version of the article
Compiled by Perry Wang
The concept of decentralized insurance has always been one of the classic examples of ideal use cases for blockchain applications. Insurance companies are motivated to delay claims for as long as possible, and because this process is almost completely transparent, users seriously lack the right to know, which leads to poor overall user experience. The idea of putting these insurance processes on the chain is attractive: if certain conditions are met, insurance claims can be paid immediately programmatically, and the state of the whole system is always completely transparent to everyone.
For example, you can buy travel insurance for your flight. If Google flights reports flight delays, the smart contract can automatically compensate.
Over the years, people have tried many decentralized insurance projects, but none of the projects that touch the real world have been developed too much.
First of all, there are many concerns about obtaining reliable data on the chain. For example, the smart contract may be maliciously input data to inform that a hurricane has occurred, but it has not occurred in fact, so the weather insurance market on the chain is not very easy to use. Second, current Ethereum / defi users usually don't look for vehicle / family / travel insurance on the chain - they are looking for more encrypted native items.
Over the past two years, defi has achieved explosive growth and has independently restored the market demand for decentralized insurance products. Many individuals or funds invest a lot of money in these defi protocols, and there is a real need to prevent the loss of funds due to attacks on smart contracts. Therefore, a new wave of decentralized insurance protocols emerged last year, mainly focusing on smart contract insurance.
Most of these projects tend to innovate along two main axes - payment mechanism and Pricing:
On the pricing axis side, some projects use a joint curve based on utilization to price insurance. For example, some formulas for pricing insurance according to the supply-demand relationship of this insurance market. Other projects rely on the human expert team to determine the "fair" value of the agreement premium according to the tracking records, audits and other information that the agreement has not been hacked.
This paper will focus on the compensation mechanism of decentralized insurance agreement.
In traditional finance, insurance companies need various reliable intermediaries to verify whether some events have occurred before paying claims. Since the blackout of smart contracts is purely an event on the chain, we should be able to write programs on the chain to determine whether other events on the chain actually occur - the assumption of zero trust is required.
As builders and investors in this field, we should always pay attention to the new things enabled by the blockchain that cannot be achieved by traditional finance. Algorithmic insurance may be one of them.
The easiest way to think about how these systems work is to think of them as a predictive market about whether specific conditions in smart contracts are met.
For example, if you lend usdc on the compound contract, your usdc balance should increase one-way over time with the accumulation of interest - if suddenly the usdc you can withdraw is less than the amount you originally deposited, it can be inferred that the smart contract has been attacked. Since we can reliably check this situation on the chain, we can create a report about getpriceperfullshare() & gt; one Forecast the market to see whether the return value is true or false.
Because compound has never been hacked, we can imagine that most people prefer to choose the "true" end, resulting in a wide difference in the odds between the two ends of the forecast market. This widely different odds creates an attractive opportunity for the "false" end of the market - once compound is hacked, they will get huge returns. Even if there is no hacked event, they will lose only a small amount of capital. You can see that this starts to look like an insurance market. The "false" side of the betting pays a premium to the "true" side of the betting, so as to obtain the opportunity to obtain a large profit once the market is predicted to have a favorable result.
For more complex defi protocols, we may want to define more complex payment conditions instead of simply checking whether token deposits match the underlying assets. For example, we can combine multiple conditions, such as totalassets () & gt; x && amp; getPricePerFullShare() > 1. Even define a condition to check the contract status over a period of time. For example, totalassets must not be reduced by more than 50% in a 10 minute window, otherwise the condition will return true.
The beauty of programmable finance is that we can create arbitrarily complex payment terms because we are confident that on chain checks will be performed with certainty. In addition, since all these payment terms are defined on the chain, we can always know when the market will pay, no matter how complex the conditions are, and it is impossible to confuse the public and define them through legal "terms and conditions".
One way to guide the development of these markets is to let the core team create these insurance markets and short them themselves - both as a way to guide the liquidity of insurance buyers and show confidence in their own code.Ante It is a project case focusing on this point, trying to obtain adoption and popularization through the insurance market written by developers for their projects. We can imagine a world where projects that do not insure their own agreements are as full of risks as projects with unaudited smart contracts.
When users buy smart contract insurance, they just want to get financial protection when the agreement is hacked. However, it may be difficult to define exactly how to be hacked through code. For example, the creator of the liquidity pool removes the classic "roll money run" of all liquidity, which may cause the token value held by LP to return to zero. Is this a kind of blackout, or is it the expected result of users providing liquidity in AMM?
One "solution" to this problem is simply to let the free market decide which markets are the regulated insurance markets of various agreements. For example, we can create two different insurance markets for compound: the first is that the extracted value in ctokens cannot reach & gt; 1. Make compensation when the underlying assets; The second extraction value in ctokens cannot reach & gt; 0.5 compensation shall be made when the underlying assets are.
I personally think that as compound's "normative" insurance market, the market is likely to gradually converge around one of the two, perhaps through the way that compound team advocates "Schelling point" for one of them - keeping most of the liquidity in one market.
If the complexity of the agreement is very high, which market becomes the standard market of the agreement may not be so "eye-catching", but the assumption of this free market approach is that the market will solve it by itself.
In the first mock exam, you have a great influence on the specific insurance market. The agreement may be clearly (visually) hacked, but the payment terms of the market you are betting on may not have been triggered. On the contrary, if the marginal situation in the agreement leads to the triggering of compensation conditions, even if the agreement is not hacked, the insurance seller may be "unfairly" forced to pay the claim.
Therefore, it is very important to accurately communicate the specific compensation conditions so that insurance buyers and sellers can know exactly what they signed. This is mainly a user experience (UX) challenge. Translating compensation conditions from code to text is an extraordinary task. The team may try to confuse the risk of insurance peddling with "risk-free return" to attract total lock in value (TVL), or boast to buyers that its products are all inclusive smart contract insurance to improve sales.
The smart contract insurance market has great potential, but such agreements can also be used to create a strange swap derivatives market serving speculators. Changing the payment terms from "should never happen" to "should rarely happen" makes speculators looking for asymmetric opportunities more interested in it.
Composability also allows developers to combine these markets in any way. For example, collateral used to sell insurance in one market can be re mortgaged to collateral in another market, and one fund pool can sell insurance covering multiple (ideally unrelated) things at the same time.
These tokens from both ends of the insurance market should also be able to be combined with other defi protocols. Some possible ideas include:
Algorithmic insurance opens up the design space for the remarkable financial products on the chain, because it is completely independent and does not rely on manual decision-making for compensation. This objectivity helps developers accurately infer the risk exposure provided by the insurance market, and can build other applications on these financial primitives without worrying about human decision-making or trust - which is what defi should do.
Thank Miyuki and Emily for reading this article and giving feedback.