Services

The services supply the core contracts with data and ensure that only the authorized owners can supply the core contracts with data or query data.
Here in these modules, the core functionalities of the GIF are deposited from a technical view. Here you will find all functions. Access (access control), Bundles, Components, Licenses, Policies, (Risk) Pools, Queries (Oracles), Registries and the Treasuries (capital flow).

You will undoubtedly notice fewer services here than in the modules and that the view has changed.
The services are tailored and aligned to the different roles. In the services are all information and functions that the role owner may use. Furthermore, the services also check whether the corresponding role wants to access the core contracts.
Either one has the role, in which case it continues, or one does not have access authorization, in which case it is rejected.
The idea behind this is that the users of the GIF never access the core contracts themselves but always go through the ‘intermediate layer’ services. The services do not work according to the logic of the core contracts but according to the permissions of the existing roles.

The instance operator has vast powers, so the InstanceOperatorService.sol is extensive.

The instance service is not tuned to a specific role but to the complete instance. But you won’t find a function that can change a state. All functions are queries to the instance. The service defines what information can be retrieved from an instance. Here there are also no permissions for who can query what. Everyone can retrieve all data. This is how open source works.

This is the convenient service to get, for example, as a product owner, information such as

to be displayed.

The oracle service is relatively manageable. It is merely a matter of retrieving information outside the blockchain and utilizing it on the blockchain.

In product service, the complete life cycle of a policy is mapped from registering the product (newApplication)to collecting the premiums (collectPremium) and checking if the premium is paid in full (adjustPremiumInsured).

In this section, you can see the functions of the individual life cycles of a policy, from revocation (revoke) to acceptance of the policy (underwrite) or its rejection (decline) to expiration (expire) and termination (close).

In the event of a payout, a claim must first be received (newClaim). The claim can be accepted (confirmClaim) or rejected (declineClaim). In both cases, the claim is closed afterwards (closeClaim).

In the case of acceptance, the payment is made (newPayout). In the event of a payout, partial amounts can be paid out once or several times up to the agreed sum insured (processPayout).

Oracles provide the data required for a claim and payout. As the product owner, you define which oracle is to be used and how often the required data is requested (request). You can cancel the data supply if you don’t need it anymore (cancelRequest).

In the risk pool service, the complete functional scope of a risk pool is mapped. First, the risk pool must be registered (registerRiskpool) on the instance. After that, you can create new risk bundles (createBundle) and stake or (fundBundle) unstake (defundBundle) tokens.

As a risk bundle owner, you can lock (lockBundle) and unlock (unlockBundle) your risk bundle. If you want to end your risk bundle, you can close it (closeBundle). When the last policy is paid out or expired, you can burn (burnBundle) the ERC721 token minted when you opened your bundle.

The following describes the functions related to a risk bundle and risk bundle owner, analogous to our Etherisc Depeg protection web app. You can write risk pool and risk pool keeper wherever risk bundle and risk bundle owner are written. This differs from product to product.

When a policy is taken out, it must be collateralized (collaterizePolicy) from the risk bundle. The premium flows into the risk bundle (processPremium) and if a claim is made, the amount is paid out (processPayout) of the risk bundle.

When a policy is closed, the logged funds are rereleased. As a risk bundle owner, you can decide whether the funds remain in the risk bundle and are used for new policies or taken out of the risk pool as profit (releasePolicy).

As a risk pool keeper, you can also define the maximum number of active risk bundles in your risk pool (setMaximumNumberOfActiveBundles).

A component owner can be an oracle owner, a product owner, or a risk pool keeper, depending on the core object it manages.
A component owner can propose (propose) his component. The instance operator registers, approve and activates the component.
Here the possibility of staking for the component owner is already built in (stake, withdraw). These are currently only placeholders. The evaluation of the process still needs to be finished.
As a component owner, you can pause (pause) your product if you don’t want to run it anymore. You can reactivate (unpause) or archive (archive) the product when all liabilities and terms of the sold products have expired. An archived product cannot be reactivated.
As a risk pool keeper, you can also define the maximum number of active risk bundles in your risk pool.