One of the most popular ways for bootstrapping a DeFi project is through Liquidity Mining. Most DeFi projects are two-sided marketplaces for some type of financial service — for example, Compound is a marketplace for borrowers/lenders and Uniswap is a marketplace for LPs/traders. Bootstrapping a new two-sided marketplace is difficult because of the cold-start problem: if there is no demand, there won’t be supply, and if there is no supply there will be no demand. This is where tokens come in handy — projects can incentivize one (or both) sides of the marketplace through distributing their own token to kickstart the demand-supply flywheel.
Another side effect of executing liquidity mining program is that the project is able to distribute their native token to more people. More holders of the token often leads to broader support for the project, or greater level of decentralization if the token is used for governance. This dual-benefit often makes LM programs a no-brainer.
However, the primary drawback of Liquidity Mining programs is that it often gets farmed and dumped by whales or yield aggregators — the capital committed to providing liquidity often dries up the moment the incentives stop flowing. Projects often find it difficult to have sustained benefits from the LM programs after they are done.
Instead of simply incentivizing liquidity, what if we could indirectly incentivize usage through subsidizing an insurance market for smart contract failure? For example, we could give out tokens to insurance sellers for a new protocol, attracting tons of liquidity into the insurance selling pool, and on the opposite side providing cheap cover for users of the project.
We can call this Liquidity Mining Rewards V3.
Being able to purchase cheap cover could potentially remove much of the early friction in trying out a new DeFi project. Over time, the project can slowly build up “Lindy-ness” as it gets derisked by being in production without getting exploited, and the incentives can be gracefully turned off over time.
As per this illustration, the cost of cover is highest when a project is in the earliest stages due to unknown smart contract risks. Over time, the cost of cover should come down as people gain more confidence in the project’s code. If projects can provide a subsidy for insurance in the early stages, they can likely attract more users — another way to solve the “cold start” problem of two sided marketplaces.
Furthermore, Insurance Mining also has the nice property of being able to be gracefully turned off without materially damaging the experience of the product. Liquidity Mining only benefits a project while that liquidity is in the protocol — once it leaves, the project becomes as shitty as it once was. Insurance Mining on the other hand is much more elegant because the cost of cover naturally comes down over time, so insurance subsidies can be turned off without users having to suddenly pay more for cover.
The next natural question to ask is, how do we construct an Insurance Mining program on a code-level?
In theory, it should be pretty simple — projects can bootstrap an insurance market on a protocol of their choice (ideally it gives insurance sellers a receipt token), then have insurance writers stake their receipt tokens in a custom Insurance Mining contract to earn rewards.
One caveat to note is that to assign rewards fairly to insurance sellers, we must create segregated insurance pools that only use the capital to write insurance on your specific protocol. This itself could make the whole exercise not economically viable for insurance sellers, since the economics for fully-collateralized insurance are not very favorable (capital inefficient) — but we can potentially make up for that inefficiency with a more aggressive rewards schedule.
Insurance Mining can be a much more incentive-aligned way of distributing tokens to parties who create sustainable value to a protocol, compared to Liquidity Mining. To learn more about on-chain insurance, specifically Algorithmic Insurance, please read this post first:
Lastly, if you are thinking of building this, please do not contact me because I will likely not have much useful input beyond what I have laid out in this post. But feel free to add this post to the citations in your whitepaper when you go out and raise money.