Policy Lifecycle

New Policy

New Policy transactions are sent to risk modules. Each risk module delegates the pricing and validation of the policy to an Underwriter contract, which decodes the inputData provided by the caller and returns the parameters required to build the policy:

• 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.
• params: the pricing parameters (margin of conservatism, collateralization ratios, returns on solvency capital and fee percentages) used to compute the policy’s solvency and premium split.

Note: 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 5% of chances, then the lossProb will be 12.5%.

Based on these 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:

1. A new Policy is stored, and an NFT is minted for the policyholder. The NFT represents the policy’s ownership, and the owner of the NFT will receive the payout.
2. The solvency capital sourced from the liquidity pools (eTokens) is locked until the policy is triggered or expires.
3. The premium amount is transferred from the payer and split among the different parties:
   1. The cost of capital is paid to the junior and senior eTokens.
   2. The commissions are paid to Ensuro and the risk partner.
   3. The pure premium is sent to the PremiumsAccount contract associated with the risk module.
4. A NewPolicy event with all the Policy fields that will be needed for upcoming operations.

Open the sequence diagram in a new window.

Note: The pricing parameters (params) are not stored on-chain in the risk module; they are provided off-chain by the risk partner (or an authorized signer) and validated by the Underwriter contract. There are two underwriter implementations: the Full Signed Underwriter (which validates a signature from an authorized signer) and the Full Trusted Underwriter (which simply trusts the caller).

Policies can also be created in batch with newPolicies (RiskModule) / newPoliciesBatch (PolicyPool), which aggregate the premium transfers.

In the process of creation of a policy, several things are validated and can fail, reverting the operation:

• Risk module deprecated or suspended.
• Lack of available funds in the eTokens to cover the required solvency capital (SCR).
• Not enough funds in the payer’s wallet to pay the premium or no allowance for spending given to the PolicyPool.
• Repeated policyId/internalId (used to avoid repeated transactions).

Policy replacement

An active policy can be replaced with a new one, keeping the same owner. The replacement is flexible: almost everything can change — the exposure (payout), the expiration, the collateralization ratios, the returns on solvency capital, and the premium components (pure premium, cost of capital and commissions), which can only increase.

The flow is similar to policy creation: the risk module delegates the pricing to the Underwriter (pricePolicyReplacement) and then calls replacePolicy on the PolicyPool. Only the premium and SCR differences are charged and locked.

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:

1. A new Policy (with a new id) replaces the old one; a new NFT is minted for the policyholder.
2. The old policy is no longer active.
3. The premium difference is charged and the SCR differences are locked/unlocked.
4. A PolicyReplaced event (with the old and new ids) and a NewPolicy event are emitted.

Open the sequence diagram in a new window.

Policy cancellation

An active policy can be cancelled, executing a total or partial refund of the premium — except the Ensuro and partner commissions, which are not refunded. The refund covers the pure premium and the non-accrued cost of capital. After the cancellation, the policy is no longer claimable and its locked solvency capital is unlocked.

The flow is similar to policy creation: the risk module delegates the pricing to the Underwriter (pricePolicyCancellation) and then calls cancelPolicy on 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:

1. The policy is no longer active.
2. The solvency capital (SCR) is unlocked.
3. The refund (pure premium + non-accrued cost of capital) is transferred to the policyholder.
4. A PolicyCancelled event with the refund amounts is emitted.

Open the sequence diagram in a new window.

Resolution with 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:

1. The payout has been sent to the PolicyHolder.
2. The solvency capital (SCR) is unlocked.
3. 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.

Note: 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.

Note: 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.

Note: 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 at 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:

1. The solvency capital (SCR) is unlocked.
2. The PremiumsAccount earns the pure premium, adding it to its surplus.

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.

Note: 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.

Note that outstanding loans with the eTokens are not repaid on expiration. They are repaid separately by calling the repayLoans function of the PremiumsAccount, which is triggered by an operative account (with the REPAY_LOANS_ROLE).