services modules

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).

services services

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.


services instanceoperator registry

Here you, as an instance operator, can manage releases and contracts. He can create and activate a new release (prepareRelease). You can create new contracts (register) or remove them (deregister). Then you can register (registerInRelease) and deregister (deregisterInRelease) the contracts in the corresponding release.


services instanceoperator access

Here you can administrate access management. You can create (createRole) or remove (invalidateRole) a participant (role). Once the role is created, you should check the component the new participant wants to deploy. If all this fits, you can grant the new participant (grantRole) or revoke the legitimation (revokeRole).


services instanceoperator component

A component can be a product, risk pool or oracle. The component owner can request the implementation of his component. You, as an instance operator, can approve (approve), decline (decline), suspend (suspend), resume (resume) or archive (archive) the component.

Service staking

services instanceoperator staking

This functionality is still under development. We will inform you when we have a version here. You can then check if the component meets the requirements and then activate the component.


services instanceoperator treasury

This is about money or tokens. If you get hacked, you can turn off the entire treasury (suspendTreasury) and re-enable it after fixing the cause (resumeTreasury).
You can include the wallet of the instance (setInstanceWallet), include the wallet of a risk pool (setRiskpoolWallet) and define the tokens that are accepted in a product (setProductToken).
As an instance operator, you can also set your premiums (setPremiumFees) and those of the investor (setCapitalFees).

services instanceoperator treasury01

As an instance operator, you can also define how the fees are divided on the component level (createFeeSpecification). What you get, what the component owner gets and any other fees, for example, to an oracle.


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

services instanceservice
  • how many claims (getClaim) has my product

  • how many payouts (getPayout) have I paid

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.


services product premium

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).

services product policy

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).

services product claim

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).

services product payout

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).

services product request

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).


services riskpool

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.

services riskpool bundles

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.

services riskpool payout

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).


services componentowner

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.