Policy

The protocol automatically determines the premium or policy fees by taking numerous aspects such as policy term/cover duration, adverse selection, sum insured, utilization ratio, total pool balance, reassurance pool, etc into account.

Equation:

The policy fee denoted PF is given by the equation

where the value of x is always between constants F and C,  c is the cover commitment amount, t is the total balance of the pool, CD is the policy duration desired, CA is the desired cover amount, IP is incident support pool amount for the cover pool, IR is incident support pool capitalization ratio.

For simplicity, this equation can also be written as:

PF = (CD/100) + (CA+c) / (t + (IP + IR))

Market vs Adverse Selection#

Soft Market#

When there is high liquidity available (supply) and relatively low proposers (demand), the policy fees are lower. Unless there is massive fear in the market, well-established projects, exchanges, and custody providers generally fall into this category. The assumption is--liquidity providers want to pool liquidity for high-quality and secure projects because there may be a relatively lesser likelihood of exploits. On the demand side, users may also feel less nervous about purchasing protection which equates to less demand.

Hard Market#

In the hard market, the number of proposers would be high, but the cover pool would have relatively less liquidity available. Because of the high demand from proposers, the cover fees get higher. This attracts more liquidity providers to take more risks to get higher returns. The assumption is--the users may feel nervous about an unproven or relatively new project that there is a higher likelihood of attacks and exploits. They would therefore want to purchase a policy to protect against possible attacks. On the supply side, liquidity providers feel nervous about possible liquidations and therefore want higher returns.

Adverse Selection#

Adverse selection refers to a situation when either the seller or buyer has more information than the other party. For example, a cover creator could have insider information on their project and use that information to attack or gain an unfair advantage against Neptune Mutual protocol, liquidity providers, or policyholders.

A malicious project can cleverly word their cover rules (or parameters) and purchase large protection. They can then attack their project to claim and receive a payout.