Policy Lifecycle
This page describes the full lifecycle of a policy on Ensuro's protocol, from its creation to its resolution, either by expiration or because of a claim.
New Policy
New Policy transactions are sent to risk modules. Each risk module has its logic related to how to validate/calculate the parameters of the policy. The input parameters for creating a policy are:
payout: the maximum amount paid for this policy to the policyholder.
premium: the amount paid as a premium.
lossProb: the estimated probability of having to do a payout equal to the maximum payout.
expiration: the expiration date of the policy (timestamp). After this date, the policy is no longer claimable.
internalId: a user-defined id that has to be unique within a risk module.
The lossProb is used to calculate the expected losses of a policy. If the policy can have multiple payouts, the lossProb is computed as the ratio between expected losses and maximum payout. For example, if the maximum payout is $ 100, and the payouts can be $ 100 with 10% of chances and $ 50 with 10% of chances, then the lossProb will be 15% (= ($100*10% + $50*10%) / 100$ ).
Based on the input parameters and the risk module's parameters, a Policy is created and sent to the PolicyPool.
Here you can see a sequence diagram of the process with all the contracts involved. As a final result, we should see the following effects:
A new Policy is stored, and an NFT is minted for the customer. The NFT represents the policy's ownership, and the owner of the NFT will receive the payout.
The solvency capital sourced from the liquidity pools (eTokens) is locked until the policy is triggered or expires.
The premium amount is transferred from the customer and split among the different parties:
The cost of capital is paid to the junior and senior eTokens.
The commissions are paid to Ensuro and the risk partner.
The pure premium is sent to the PremiumsAccount contract associated with the risk module.
A NewPolicy event with all the Policy fields that will be needed for upcoming operations.
Open the sequence diagram in a new window.
The sequence diagram above is based on the TrustfulRiskModule. In this particular implementation of the risk module, the policies can only be created by users with a specific delegated role. In this way, they can define critical parameters like the lossProb.
There are other implementations of risk modules where the lossProb and other policy parameters are calculated in the risk module from other specific policy parameters.
In the process of creation of a policy, several things are validated and can fail, reverting the operation:
Some of the policy's features, like policy duration, maximum payout per policy, and maximum exposure, exceed the risk module limits and are not validated by the risk module.
Risk module deprecated or suspended.
Lack of available funds in the eTokens to cover the required solvency capital (SCR).
Not enough funds in the customer's wallet to pay the premium or no allowance for spending given to the PolicyPool.
Repeated policyId/internalId (used to avoid repeated transactions).
Resolution - payout
The resolution of the policies when there is a payout is triggered from the risk modules. The criteria for triggering a payout change from one module to the other: some risk modules use information from oracles to define if a policy is triggered, while others rely on a trusted user (EOA) with a designated role.
Below you can see a sequence diagram of the process with all the contracts involved. As a final result, we should see the following effects:
The payout has been sent to the PolicyHolder.
The solvency capital (SCR) is unlocked.
The funds to cover the payout are taken from the premiums, the junior eToken, or the senior eToken (in this order).
Open the sequence diagram in a new window.
In the process of policy resolution, several things are validated and can fail, reverting the operation:
The policy doesn't exist. This might happen if the risk module receives a wrong input or if the policy has already been resolved. It is validated using the policy hash.
The policy has already expired.
The risk module is suspended.
Both premiums, junior eToken and senior eToken are exhausted, and not enough money for the payout. It shouldn't happen with a correct collateralization ratio.
Adjustment: you can see in the diagram that unlockScr calls include an adjustment parameter.
When policies are created, a premium fraction is used to pay the cost of the solvency capital locked for the policy. That cost of capital is received in bulk at the policy creation but released as a progressive interest rate to the LPs.
When the policy is resolved, it will be before the expiration, when part of the cost of capital is still not disbursed. So this adjustment disburses the remaining cost of capital not yet accrued because of the early finalization of the policy.
The policyholder can be any Ethereum address; this includes EOAs (externally owned accounts) and contracts. If the policyholder is a contract, a specific callback is called to notify it of the payout. The callback can be used in the policyholder contract to do something with it, like covering a liquidation position, swaps, or transfers.
Internal loans: most of the time, if a model is well-calibrated, the premiums should cover the losses. But even in well-calibrated models, because of the deviations of random variables around the mean, in some cases, premiums are not enough, and we need to use the solvency capital from the junior or senior eTokens.
When we do so, the total supply of those eTokens is reduced, producing a negative return to the LPs. This money is taken as a loan from the eToken to the PremiumsAccount.
But as well as random variables might be sometime above the mean (losses more than expected), in the future, they might be below the mean (losses less than expected). When that happens, premiums will be accumulated, and if the PremiumAccount has a debt with the eToken, it will repay the debt producing a positive return to LPs.
Resolution - Expiration
Every policy, when created, has an expiration date. After that date, anyone can issue an expiration transaction. This expiration transaction is needed to unlock the solvency capital reserved for that policy since it's no longer claimable.
Here you can see a sequence diagram of the process with all the contracts involved. As a final result, we should see the following effects:
The solvency capital (SCR) is unlocked.
The PremiumsAccount earns the pure premium.
If the premiums account has outstanding loans with the Senior or Junior eTokens, it uses the pure premium earned to repay its debts (with that precedence).
The remaining pure premium is accumulated in the PremiumsAccount contract.
Open the sequence diagram in a new window.
In the process of policy resolution, several things are validated and can fail, reverting the operation:
The policy doesn't exist or is not expired (i.e., its expiration date has not come yet).
The risk module is suspended.
Any user can call the expirePolicy function after the expiration of a policy. Ensuro has processes running and checking the database of policies to run these expiration transactions. But since it's an open end-point, anyone can call it, guaranteeing to the liquidity providers that their funds won't be locked indefinitely.
Last updated
