Data Model

Overview

Here you get an overview of the individual data models. The individual sections represent the complete process of creating a policy up to the termination, either by a claim and the payout or the end without a claim in chronological order.

Here the complete process:

  • the customer inquires (application) about an insurance policy. By taking out the insurance policy, one wants to protect themself against a specific risk.

  • the insurance company examines the customer’s application.

  • the application is accepted or rejected.

  • in case of rejection, the customer is informed and no further activities occur.

  • in case of acceptance, the contract comes to the “underwriter.” The acceptance of the application is called “underwriting.”

  • the insurance company commits itself to the “underwriting” to take over the customer’s risk and transfer it to itself. It further undertakes to cover the loss if the insured event occurs.

  • the customer, for his part, undertakes to pay the premium.

  • both declarations of obligation are documented in a contract. This contract is called the insurance policy.

  • if a claim occurs, the customer reports it to the insurance company.

  • the claim is checked by the insurance company and accepted or rejected.

  • in case of acceptance, the agreed insurance sum is paid out (payout).

Metadata

Metadata or metainformation refers to structured data containing information about other resources. Metadata thus describes the actual data in a way. Metainformation becomes necessary when there are more significant amounts of data to manage.

data metadata

  • the address of the owner of the smart contract

  • the product ID

  • state of the policy flow module

  • data

  • the date of creation

When a new policy is created, metadata is entered first, i.e., before the application, it is determined who is the policy’s owner (owner), to which product the policy belongs (productID) and a process ID is generated.

The process in Metadata, Application and Policy is linked to unique unique process ID, so you can tell exactly which steps have been completed.

Applications

data application

The application then specifies the insurance sum (sumInsuredAmount) and what amount of premium (premiumAmount) must be paid. Additional information is also entered to determine the insurance premium depending on the insurance type (data).

When the application is 'underwritten,' the insurance sum is reserved in the risk pool and the policy is generated.

States of the application:

  • applied

  • revoked

  • underwritten

  • declined

Policies

data policy

The policy will then log how much premium you have already paid (premiumPaidAmount) and the total premium (premiumExpectedAmount). Here you will also find the outstanding claims (openClaimsCount) and the claims already paid out (claimsCount). The policy can be closed when no more open claims exist or the policy has expired.

Further information is the maximum amount of the payout (payoutMaxAmount) and how much has already been paid out (payoutAmount).

States of the policy:

  • active

  • expired

  • closed

Claims

data claim

In the claim smart contracts, you can look up how much the policy owner has claimed (claimAmount) and how much has been paid out (paidAmount). If the two amounts match or the claim is declined, the claim can be closed.
Claims can only be created if the policy has the ‘active status.’

States of the claim:

  • applied

  • confirmed

  • declined

  • closed

Payouts

data payout

Each planned payout has a certain amount. With each payout, the claim amount increases. Only when the planned payouts have been paid out the claimed amount decreases and the paid amount increases. When the claim amount is equal to the paid amount, the claim can be closed.

States of the payout:

  • expected

  • paid out

Oracle Request

Here is defined which oracle is requested and the time intervals the request takes place.
With our depeg app, Chainlink already provides us with the USDC rates on-chain.

Bundles

data struct bundle

Everybody who wants to provide risk capital creates his risk bundle by staking USDT stablecoins in the Etherisc Depeg Protection web app. In your risk bundle, you can set parameters like lifetime, minimum or maximum staked amount.

Each risk bundle has its own NFT (ERC721).

You can find detailed information in the Depeg Protection Tutorial and the Depeg Protection FAQ’s.

States of the bundle:

  • active

  • locked

  • closed

  • burned

Risk Pools

data struct pool

The risk pool bundles and manages the individual risk bundles. The risk pool provider defines the general conditions, such as the maximum total sum insured or the collateralization level.

The risk pool has a unique ID and wallet in which the assets are managed. The risk pool can also issue its own risk pool token (ERC20), which can then be traded. The risk pool keeper can define how much must be deposited for collateral damage (collateralizatoinlevel1) and the maximum amount to which policies can be issued (sumOfSumInsuredCap).

The risk pool shows the aggregate sum insured of all existing policies (sumOfSumInsuredAtRisk), the balance (capital), the capital locked up in policies that have been completed but have yet to expire (lockedCapital), the total amount of funds (balance), when the risk pool was created (createdAt) and the date of the last update (updatedAt).

← Global Registry
Roles →