Supposons que 100.000 propriétaires de maison se regroupent dans une pool. Là encore, chacun paie une part de 100 $ ; ce montant est maintenant appelé "prime". Ils perçoivent un total de 10 000 000 $ en primes. Mais il y a maintenant une différence pour Alice, qui ne s’occupe que d’elle-même : en raison de la loi des grands nombres^[4], avec une très forte probabilité, il n’y aura qu’une centaine d’incendies, causant un dommage d’environ 10 000 000 $ ! Et comme la somme de toutes les primes est également de 10 000 000 $, l’ensemble des dommages peut être payé avec les primes collectées, sans que chaque propriétaire de maison ait besoin de contracter un prêt. (Étant donné que les primes sont collectées au début de l’année et que toutes les maisons dont l’incendie est "prévu" ne brûlent pas toutes au début de l’année, mais sont plus ou moins réparties de manière égale sur l’année ou les années, il existe ce que l’on appelle un "flottant^[5]" de liquidité qui peut également générer un revenu important. Pour des raisons de simplicité, nous ne nous concentrerons pas sur cet effet dans cet article.

Ainsi, les coûts pour chaque propriétaire de maison individuelle sont maintenant réduits de 1 100 $ à 100 $ !

Cette différence demande une explication économique. Examinons-la de plus près. Tout d’abord, si tous les propriétaires de maison suivaient l’exemple d’Alice, ils auraient besoin d’un prêt énorme, dont seule une infime partie de 0,1 % serait nécessaire en moyenne. Il est clair que fournir des liquidités inutilisées est coûteux.

Deuxièmement, si chacun ne se préoccupe que de lui-même, seule une infime partie des participants est frappée par la catastrophe et a la charge de rembourser réellement son prêt. Les autres peuvent rembourser sans perte, tant qu’ils n’ont pas besoin de protection. Dans une assurance collective, nous bénéficions de la solidarité : avec les primes, chacun paie pour les dommages des autres.

En résumé, une pool de risques offre trois avantages aux participants :

Une telle pool peut être conçue dans le seul but de bénéficier à ses participants et de ne réaliser aucun "profit". Si la pool génère des bénéfices, ceux-ci pourraient être redistribués aux participants, ce qui aurait pour effet de réduire à nouveau les primes à un niveau où aucun bénéfice n’est généré. Une telle assurance aurait un ratio de pertes de 100 %, car toutes les primes sont utilisées pour payer les pertes.

Il s’agit de l’effet de base du transfert de risques. Veuillez noter que l’effet augmente avec la taille de la pool.

Mais ce n’est pas tout.

Selon les années, le nombre d’incendies varie. Pour tenir compte de ces variations, l’ensemble de la pool doit réunir un certain montant, par exemple 10 millions de dollars, pour couvrir le cas peu probable d’une explosion du nombre d’incendies au cours d’une année donnée. Supposons même que le taux d’intérêt pour ce capital soit particulièrement élevé, par exemple 20%. Le coût total de ce capital sera de 2 millions de dollars. Le taux d’intérêt pour le capital est une fonction du risque et du taux d’intérêt sans risque sur le marché des capitaux ; dans un marché efficace, le taux d’intérêt compensera le risque plus élevé par rapport à un investissement sans risque et contiendra également un bénéfice équitable. Grossièrement, c’est là que sont générés les bénéfices pour l’apport de capital dans une structure d’assurance.

Les coûts globaux de 2 millions de dollars seraient alors répartis entre tous les propriétaires de maisons, ce qui entraînerait un coût supplémentaire de 20 dollars par propriétaire de maison et par an ajouté à la prime.

Désormais, une protection contre les "risques résiduels" ou "black swan events" est également assurée, à un coût de 20 dollars par propriétaire de maison. Là encore, l’effet de diversification des risques augmente avec la taille de la pool.

Globalement, les participants paient maintenant 120 dollars par an pour leur assurance habitation. Le rapport sinistres-primes est alors réduit à 83 % en raison des coûts liés à la protection des risques extrêmes.^[6]

Pour inclure 100 000 personnes dans une pool, une structure professionnelle est nécessaire. Sinon, chaque participant devrait se coordonner, ce qui serait tout simplement impossible. Le fonctionnement de cette structure professionnelle ajoute des coûts de transaction à la prime. Il s’agit en fait de la raison d’être des compagnies d’assurance :

L’effet est considérable et permet la forme moderne d’assurance avec d’énormes quantités de clients et une capitalisation qui peut même couvrir des catastrophes mondiales comme les ouragans ou les tremblements de terre. Cependant, les coûts de transaction restants sont encore considérables : une étude récente de KPMG montre que l’impact sur le taux de sinistres est d’environ 66% en moyenne.

La réduction des coûts de transaction s’accompagne d’une asymétrie de l’information, qui conduit à une nouvelle augmentation des coûts et à des profits incroyables pour les grandes compagnies d’assurance.

Elle crée un "avantage concurrentiel déloyal" pour les entreprises existantes : les entreprises disposant d’importantes bases de données peuvent proposer de meilleurs produits, et donc optimiser encore davantage leurs bases de données. L’un des objectifs fondamentaux d’une plateforme d’assurance décentralisée est de perturber ce système, en rendant aux clients la propriété de leurs données.^[8]

Les trois éléments décrits précédemment, à savoir la mutualisation des risques, le transfert des risques et une administration efficace, sont nécessaires. Il ne peut y avoir d’assurance sans chacun de ces éléments.

Pour les besoins de ce papier, je les appellerai:

Comme vu précédemment, une communauté peut ne pas souhaiter générer de profit à partir du premier élément. Le deuxième élément donne lieu à des frais de risque pour le capital attribué dépendant de la structure du risque particulier : Ils sont généralement plus faibles si les risques sont individuels et non corrélés ; généralement plus élevés si les risques sont groupés ou corrélés. Le troisième dépend de la complexité du processus. Un "produit" d’assurance simple et hautement standardisé présente une complexité de transaction moindre qu’un produit plus compliqué et non standardisé. Cela se traduira par des coûts de transaction plus faibles.

Ces trois éléments sont totalement indépendants de la technologie, de l’environnement économique ou des monnaies sous-jacentes. Ils sont les éléments constitutifs basiques de tout système de partage des risques.^[9]

L’asymétrie de l’information, inhérente aux systèmes d’assurance traditionnels, constitue un autre aspect non souhaitable.

La répartition de la valeur attendue (élément 1) et des coûts en capital pour les risques extrêmes entre les participants (élément 2) est inévitable et n’est pas spécifique à une solution blockchain. Par conséquent, concentrons-nous sur le troisième élément.

Les coûts de transaction sont également dû à un autre élément : les réglementations, qui sont jugées nécessaires pour protéger les clients dans un contexte de conflits d’intérêts. Les réglementations constituent une barrière à l’entrée très efficace pour les "concurrents". Alors que les compagnies d’assurance se plaignent souvent du poids des réglementations, elles n’ont en réalité pas grand intérêt à réduire ces charges, car elles découragent les nouveaux concurrents d’entrer sur le marché.

En tant qu’industrie de plusieurs milliards de dollars dominée par d’énormes sociétés, l’assurance est souvent confrontée à des obstacles tels que des réglementations strictes et des déséquilibres entre les incitations des entreprises et celles des consommateurs, qui font que le monde de l’assurance est souvent inefficace et coûteux. L’objectif ultime est d’éviter que les clients aient à se battre pour être remboursés par des compagnies dont les profits dépendent souvent de l’absence voulue de paiement.

Etherisc construit une plateforme pour des applications d’assurance décentralisées. La plateforme peut être utilisée par des entreprises, grandes et petites, des groupes à but non lucratif et des startups insurtech pour fournir de meilleurs produits et services. Nous souhaitons utiliser la technologie blockchain pour rendre l’assurance plus réactive, moins chère et plus transparente et ainsi démocratiser l’accès à l’investissement dans les produits d’assurance.

Nous incitons les nouveaux groupes à construire leurs propres risk pools et services d’assurance personnalisé sur la plateforme Etherisc. Le GIF permet de développer des polices d’assurance conformes et adaptées à l’économie émergente de la blockchain. Pour offrir une alternative aux systèmes d’assurance monolithiques traditionnels, nous pouvons identifier certaines nécessités et conséquences de la mise en œuvre d’un protocole d’assurance décentralisé.

En tant que structure ouverte, le protocole est un bien commun, il peut être utilisé et mis en œuvre par quiconque le souhaite. Nous veillerons à ce que les barrières à l’entrée soient aussi faibles que possible. Cependant, pour certaines parties du protocole, une certification sera nécessaire, afin de refléter les obligations et restrictions réglementaires. Nous avons créé une fondation basée en Suisse servant d’organe juridique. Cette fondation détient officiellement les droits de propriété intellectuelle du protocole et garantit que le protocole puisse être utilisé librement. Nous avons établi un processus d’amélioration continue du protocole, piloté par la communauté, similaire au processus EIP pour la plateforme Ethereum.

Le modèle de gouvernance Etherisc (EGM), son résumé et ses valeurs fondamentales, ainsi que d’autres sous-thèmes, seront développés au chapitre 5.

L’assurance est un moyen de protection contre les pertes financières. Il s’agit d’une forme de gestion des risques dont le but premier est de se protéger contre le risque de perte possible ou incertaine. La perte associée au risque peut être financière ou non, mais elle doit pouvoir être entendue en termes financiers.

Une compagnie d’assurance^[12] garantit les risques de l’assuré. Elle peut externaliser tous les services, tels que la vente ou la gestion des données, à d’autres prestataires de services. Seule la prise en charge effective du risque ne peut pas être déléguée. Ce risque doit toujours être assumé par la compagnie d’assurance. Par conséquent, la compagnie et ses clients doivent toujours avoir une comptabilité correcte des risques qu’ils couvrent et de la manière dont ils sont garantis.

Une police d’assurance est un contrat fourni à l’assuré par la compagnie d’assurance définissant les conditions et les circonstances dans lesquelles la compagnie d’assurance garantira les pertes subies par l’assuré en raison de sinistres reconnus. Dans la finance traditionnelle, il s’agit généralement d’un contrat juridique. Ici, une police est simplement un ensemble de données stocké sur la blockchain et manipulé via des règles définies par un smart contract.

Examinons le cycle de vie d’une police d’assurance type. Ce cycle de vie se compose généralement des sous-étapes suivantes, classées par ordre chronologique.

Il est facile de constater que le secteur classique des assurances génère une bureaucratie considérable et que de nombreuses sous-étapes nécessitent des activités manuelles. Par exemple, lorsqu’un client dépose une demande d’indemnisation, la compagnie d’assurance doit vérifier manuellement les détails de la demande. Cela implique du travail et, par conséquent, des coûts.

L’assurance paramétrique est un accord entre la compagnie d’assurance et l’assuré qui couvre la survenance d’événements prédéfinis plutôt que d’examiner et d’indemniser manuellement les pertes réellement subies.

Les polices d’assurance paramétriques correspondent à des accords entre l’assurance et l’assuré dans lesquels l’assurance approuve les paiements à l’assuré lorsque des événements déclencheurs prédéfinis se produisent.

Dans l’assurance paramétrique, les sinistres (les risques) sont définis comme des fonctions d’indices ou de paramètres sous-jacents répondant aux critères définis par la police d’assurance. Par exemple, la quantité de pluie ou la vitesse du vent sont des paramètres pouvant être pris en compte dans un contrat d’assurance lié aux conditions météorologiques. Dans le cas d’une assurance portant sur les retards de vol, le paramètre pourrait être la différence entre l’heure d’arrivée réelle et l’heure d’arrivée prévue d’un vol assuré.

Lorsque de tels événements se produisent, l’assurance calcule et déclenche directement le versement d’une indemnité à l’assuré sans passer par une procédure d’acceptation des demandes d’indemnisation souvent coûteuse.

Le potentiel d’efficacité et d’automatisation constitue le grand avantage de l’assurance paramétrique. La gestion des sinistres, l’une des parties les plus complexes et les plus coûteuses de l’activité d’assurance, peut être réduite à un processus simple et entièrement automatisé.

La technologie de la blockchain peut améliorer le domaine de l’assurance sur plusieurs points. Certains de ces avantages sont directement liés aux fondements de cette technologie.

La technologie de la blockchain peut apporter beaucoup de valeur, notamment pour l’assurance paramétrique.

Marché du transfert de risques
La levée de fonds pour soutenir les garanties techniques est effectuée par les investisseurs. Les investisseurs bloquent une certaine quantité de DIP token, également appelée "staking". Ces DIP token loqués sont une condition préalable pour pouvoir ensuite investir le capital-risque réel en DIP ou en stablecoins.
La communauté des détenteurs de DIP token a créé l’ensemble de l’écosystème Etherisc. Par conséquent, nous demandons que les parties qui profitent de l’écosystème Mettent en jeu des DIP token. Cette idée est empruntée à l’espace des entreprises coopératives. Elle reflète le fait que l’écosystème Etherisc est un bien public qui doit être protégé de la "tragedy of the commons.”

Legal framework
Les compagnies d’assurance sont fortement réglementées dans le monde entier pour de bonnes raisons, afin de protéger les clients et les investisseurs. Un grand nombre de lois ont été adoptées à cette fin dans la plupart des pays. En ce qui concerne la juridiction, une distinction générale peut être faite entre les régions américaine, européenne et anglo-saxonne.
Mais même au sein de ces régions, chaque pays a son framework juridique et monétaire propre. Etherisc s’engage auprès des régulateurs locaux pour aider à créer un environnement réglementaire efficace concernant l’assurance basée sur la blockchain. Etherisc soutient les parties intéressées et aide à guider le processus de coordination avec les agences et les ministères concernés.
Les obstacles financiers et organisationnels à la création d’une nouvelle compagnie d’assurance sont élevés. Pour des pays comme l’Allemagne, Etherisc propose un nouveau modèle juridique où la créance légale est échangée contre une garantie technique en utilisant la blockchain et les smart contracts. Ainsi, le prestataire - dans ce cas Etherisc - n’est plus soumis aux exigences juridiques et financières d’une compagnie d’assurance. Malgré tout, pour chaque projet, produit et juridiction, le framework juridique doit être pris en compte et le product owner est responsable de sa bonne mise en œuvre. L’équipe d’Etherisc a accumulé beaucoup d’expérience dans ce domaine et est heureuse de partager ces connaissances avec les utilisateurs de la plateforme.

Technical framework
Développé et maintenu par Etherisc, le Generic Insurance Framework (GIF) permet de modéliser, déployer et exploiter des produits d’assurance basés sur la blockchain de manière décentralisée et transparente.
Grâce au GIF, les parties intéressées peuvent rapidement mettre en œuvre et exploiter en toute sécurité leurs produits d’assurance.
Avec le GIF, il est techniquement possible de modéliser des polices d’assurance individuelles.

Pour exploiter les produits d’assurance, y compris la vente de polices, la collecte des primes, le calcul des événements déclencheurs et le traitement des paiements, un système d’exécution complet est nécessaire en plus des collections de smart contracts qui définissent les produits et les polices.

Cet environnement d’exécution - appelé instance GIF - peut être considéré comme une plateforme ou une place de marché complète dans laquelle les produits d’assurance basés sur le GIF sont gérés et exploités. Notre objectif est que le GIF soit utilisé par de nombreux fournisseurs différents et indépendants offrant divers produits d’assurance. La figure ci-dessous donne un aperçu des rôles des parties prenantes impliquées dans une instance GIF.

Assuré/Client
L’assuré/client est le titulaire de la police qui souhaite transférer son risque aux risk pools. Les tiers peuvent proposer des passerelles de paiement et des intégrations qui suppriment la nécessité de posséder des crypto-monnaies pour le client final.

Investor
Les investisseurs souhaitent participer aux risk pools pour équilibrer/diversifier leurs portefeuilles de risques. Les investisseurs fournissent des garanties pour les risk pools en échange de paiements d’intérêts.
Oracle Owner
L’une des applications les plus prometteuses d’un espace d’assurance décentralisé est la façon dont les données sont collectées et gérées. Le oracle owner fournit des oracles qui font l’interface entre les smart contracts de la blockchain et les sources de données externes. Dans le cas d’une assurance contre les retards de vol, l’oracle informe le smart contract si le vol a atterri à temps, de combien il a été retardé ou s’il a été complètement annulé.

Product owner
Le product owner conçoit et exploite un ou plusieurs produits. Il s’agit d’une compagnie d’assurance ou d’un AGG (agent général de gestion) dans le secteur traditionnel de l’assurance. Grâce à la capacité multi-client, un product owner peut utiliser tous les oracles situés sur les plateformes respectives des oracle owners.

Risk pool keeper

Un risk pool keeper gère une ou plusieurs risk pools.

Les risk pools collectent les garanties apportées par les fournisseurs de capital. Les pertes sont payées à partir de la pool de risques. Par conséquent, le capital dans la pool est risqué (risque de pertes défaut). Les investisseurs peuvent compléter leurs investissements et également retirer leurs fonds.

Instance operator

Tout déploiement complet d’une structure GIF est appelé "instance GIF". Il y aura toujours au moins une instance GIF complète exploitée par le projet Etherisc, mais en principe, n’importe qui peut déployer une nouvelle instance GIF. L’opérateur d’instance est le maillon crucial faisant fonctionner une instance GIF spécifique.

Les principales tâches de l’opérateur d’instance sont l’administration des produits et des oracles ainsi que quelques autres actions basiques. Toute instance GIF est capable de gérer plusieurs clients, ce qui signifie que plusieurs product owner et de fournisseurs d’oracles peuvent être exploités et administrés sur une instance GIF.

L’opérateur d’instance est représenté par une adresse Ethereum. L’opérateur de l’instance peut être une personne physique possédant la clé privée de cette adresse ou un smart contract - soit une structure multisig ou DAO. Ceci permet le fonctionnement entièrement décentralisé de toute instance GIF. Une adresse peut, bien entendu, gérer plusieurs instances GIF indépendantes.

Le contrôle décentralisées des instances gif est l’objectif déclaré du projet Etherisc - soit par multisig, soit par des DAO avec leur propre structure de gouvernance - elles doivent également être contrôlées par les parties prenantes de la plateforme (clients, product owner, oracle owner et gardiens du pool de risques). Au chapitre 5, nous examinons la manière dont l’écosystème peut encourager ce développement.

Chaque instance de GIF gère différents components. Un composant est un smart contract spécifique doté d’une certaine fonctionnalité de base. Les components peuvent représenter différents objets de base.
Les objets principaux sont :

Tous les components, et donc les objets qu’ils contiennent, peuvent prendre des états identiques et avoir le même cycle de vie, mais peuvent différer considérablement en termes de durée de vie.

Deux rôles peuvent déterminer le cycle de vie d’un composant.

Component owner
Le component owner peut être le oracle owner, product owner ou risk pool keeper, selon l’objet central qu’il gère.

Instance Operator
L’instance operator exécute une ou plusieurs instances GIF.

Un component du GIF est toujours dans l’un des états suivants :

La transition entre ces états et les rôles par lesquels ils peuvent être déclenchés sont décrits dans le diagramme ci-dessus. Le cycle de vie d’un composant commence par son développement et son déploiement sur la blockchain. Le component owner peut mettre en œuvre ses exigences spécifiques dans le smart contract du composant ou utiliser la fonctionnalité générique des components GIF. À l’étape suivante, le composant est enregistré, approuvé et activé par l’opérateur d’instance dans l’instance GIF. L’opérateur d’instance peut également refuser un composant. Le composant est ensuite supprimé.
En cas d’approbation, l’opérateur de l’instance continue à vérifier les détails techniques et procéduraux. L’opérateur de l’instance peut également confier la vérification à un audit indépendant.

Si le composant est actif, il peut être utilisé jusqu’à ce qu’il soit suspendu ou mis en pause. Seul l’opérateur de l’instance peut suspendre un composant ou faire cesser la suspension alors que la mise en pause d’un composant ou la réactivation de ce composant peuvent être effectués par le component owner ou l’opérateur d’instance. Si le composant est inactivé (en pause, suspendu) et non réactivé (cessation pause ou suspension), il n’est pas supprimé mais archivé.

Pour chaque type de composant (produits, oracles, risk pools), nous fournissons des exemples d’implémentation qui peuvent être utilisés comme point de départ.

Indépendamment du produit spécifique, chaque police traitée sur l’instance GIF a un cycle de vie. En général, une police subit plusieurs changements d’état au cours de son cycle de vie. Bien que tout concepteur de produit puisse mettre en œuvre son propre cycle de vie (dans notre terminologie, le cycle de vie est appelé "PolicyFlow"), le GIF offre un cycle de vie par défaut qui devrait être suffisant pour la plupart des cas d’utilisation. Ce cycle de vie générique est appelé "PolicyFlowDefault".

Le cycle de vie "PolicyFlowDefault" offre les fonctions suivantes :

L’instance GIF est indifférente à la manière dont les paiements sont effectués. Les paiements en crypto peuvent être effectués directement sur le contrat du produit, tandis que les paiements en fiat nécessitent une passerelle fiat et une infrastructure bancaire ou de carte de crédit externe. L’équipe centrale peut demander des informations sur la façon de mettre en œuvre les passerelles fiat.

Le moniteur GIF fournit une vue d’ensemble structurée de tous les blocs de construction génériques disponibles dans le GIF pour créer et exploiter un produit d’assurance. Vous pouvez visualiser tous les événements et toutes les transactions commerciales de l’instance complète.

Le moniteur GIF fournit toutes ces informations de manière transparente et en temps réel en ligne. Les informations sont lues à partir de la blockchain et du GIF.

L’URL https://gif-monitor.etherisc.com/ vous amène à la zone d’accueil du moniteur GIF. Dans la barre de menu, vous pouvez choisir parmi les éléments de menu suivants.

Dans la zone "Accueil", vous pouvez cliquer directement sur les éléments de menu de la barre de menu, puis sélectionner l’élément de menu correspondant dans le menu déroulant.

Core
La zone "Core" est de loin la plus étendue. Elle affiche les instances GIF disponibles, les contrats de base GIF par instance et les événements de ces contrats de base. La zone "Core" affiche l’ensemble des contrats de base que chaque utilisateur peut utiliser.

Vous trouverez ici les blockchains utilisées par les instances, telles que xDai ou Ethereum. En cliquant sur une instance, vous obtiendrez des informations détaillées comme l’ID de l’instance, le nom, le nom de la blockchain, l’ID de la blockchain et le statut (actif ou non). Chaque instance est identifiée par son adresse de registre. GIF est capable de fonctionner sur plusieurs blockchains et peut s’exécuter sur toutes les principales blockchains similaires à Ethereum.

Dans cette section, vous trouverez les 14 contrats principaux (intelligents) du GIF. Chaque contrat de base fournit des fonctionnalités essentielles à une Instance GIF.

Vous pouvez cliquer sur le nom du contrat pour tous les contrats principaux du GIF afin d’accéder aux détails du contrat. Vous y verrez l’instance dans laquelle vous vous trouvez, l’ID de l’instance, l’adresse sur la blockchain, le nom du contrat principal et la fonctionnalité détaillée du contrat telle que décrite par l’interface ABI (Application Binary) du contrat.

Les événements contractuels des contrats principaux du GIF sont affichés ici.

Les événements contractuels sont émis par les smart contract pendant l’exécution du code et stockés de façon permanente sur la chaîne. Les événements sont principalement utilisés pour documenter les changements significatifs dans les données des smart contracts, par exemple le changement de statut.

Oracles
Les oracles disponibles sont affichés dans la zone "Oracle" du moniteur GIF.
Sur cette page, vous trouverez tous les oracles disponibles sur la plateforme. Vous pouvez consulter toutes les entrées et rappel dont disposent les product owner. De plus, l’oracle concerné peut être sollicité aux oracle owner.
En cliquant sur un oracle, le moniteur GIF affiche les détails.
Bien entendu, des oracles individuels peuvent également être ajoutés sur demande.

Products
Dans la zone "Produits", tous les produits qui ont été créés dans le framework sont répertoriés. En cliquant sur un produit, les détails s’affichent.

Polices
Dans le domaine des "polices", vous trouverez des informations sur chaque phase du cycle de vie d’une police. Cela commence par des informations sur le produit, les métadonnées, la proposition, la police, le sinistre et le paiement. En fonction du cycle de vie de la police, plus ou moins de blocs d’informations sont affichés.

Lorsque vous souscrivez une police d’assurance, vous attendez un paiement en cas de sinistre. Pour garantir qu’il y ait toujours assez de liquidités pour commencer ou continuer à vendre des polices et pour effectuer tous les paiements, nous prévoyons de mettre en place un système avec deux risk pools correspondantes.

Les deux risk pools correspondantes collecteront les primes pour toutes les polices vendues et les liquidités supplémentaires fournies par les investisseurs. Chaque risk pool bien conçue est soumise à un modèle actuariel pour le risque assuré et détermine ainsi une certaine probabilité de défaut pour chaque police.

Nous définissons le staking dans le contexte de l’assurance décentralisée comme suit :

Les primes nettes (après déduction des coûts) provenant de l’achat de polices sont versées dans la risk pool, et les sinistres sont couverts par les fonds de la risk pool. L’investisseur choisit une option de placement en fonction de sa tolérance au risque et de la structure de son portefeuille.
Il peut aussi choisir son investissement en fonction d’aspects éthiques tels que le respect de l’environnement, la neutralité climatique ou l’engagement social. Si nécessaire, il accepte un bénéfice moindre pour offrir une assurance aux petits agriculteurs, par exemple. Nous encouragerons toujours la mise en place de produits verts et équitables sur le GIF !

Pour qu’une risk pool sans confiance fonctionne, il faut mettre en œuvre des méthodes qui garantissent, de manière technique et transparente, que les intérêts des assurés et des investisseurs soient respectés. Pour l’assuré, cela signifie que nous pouvons prouver que la risk pool de risques sera toujours en mesure d’honorer ses demandes.

Pour les investisseurs, cela signifie qu’ils reçoivent une part équitable des bénéfices réalisés et qu’ils peuvent décider des risques auxquels ils exposent leurs fonds. Il devient donc nécessaire pour le système de fonctionner entièrement sur la blockchain. Sur la blockchain, le calcul est coûteux, nous devons donc faire en sorte que ces calculs soient efficaces. Pour atteindre cet objectif, nous prévoyons de mettre en place des "périodes" dans nos risk pools. La durée d’une période dépendra du produit. Pour chaque période, toutes les polices vendues seront traitées de la même manière. Cette étape réduit massivement la complexité.

4.2.3 L’idée de base des risk pools et des récompenses dans l’assurance

Le processus économique central de l’assurance, le transfert du risque entre les assurés et les investisseurs, est mis en œuvre dans le GIF par le biais de risk pools.

Bien que le modèle standard de risk pool comprenne toutes les fonctions de base pour le traitement des primes, des sinistres, des dépôts, des paiements et des retours, le modèle laisse un maximum de flexibilité aux risk pool keepers pour concevoir leur modèle économique afin d’attirer les assurés, les product owner et les investisseurs.

Les primary risk pool (PRP) recevront les primes nettes (c’est-à-dire les primes brutes moins les coûts) payées par les assureurs en monnaies stables (par exemple USDC, dans cet exemple, ou xDai à Flight Delay) en échange des actifs mis en jeu par l’investisseur. Le PRP générera des NFT de pool de risque.

Un investisseur ne transfère pas son DIP token directement dans le PRP mais dans le SRP. Les DIP token déposés sont collectés et transférés au PRP à la fin d’une époque, et le PRP génère un nouveau risk pool NFT ; le propriétaire est le SRP. L’investisseur reçoit la valeur équivalente de sesDIP token déposés en risk pool tokens (RPT) frappés par le PRP.

La global staking pool couvrira tous les risk pools primaires d’une instance GIF. Comparable à la réassurance, elle intervient si, par exemple, des black swan events entraînent l’insolvabilité d’une primary risk pool. Les investisseurs peuvent également mettre en jeu leurs token et leurs pièces stables dans la global staking pool.

Si l’investisseur place des actifs dans la primary risk pool, il reçoit un risk pool NFT faisant office de reçu. Alors que les NFT sont en principe négociables, nous prévoyons que les risk pool NFT ne seront pas liquides. Pour faciliter l’échange de risques, nous introduirons des trisk pool token (RPT) via des "secondary risk pools". Une secondary risk pool acquerra les NFTs du pool de risques primaire et les fractionnera. Les investisseurs peuvent investir dans une secondary risk pool et recevront des RPT (ERC-20) proportionnellement à leur part dans la secondary risk pool. De nouveaux RPT sont frappés lorsque de nouveaux capitaux sont déposés dans la risk pool. Pour chaque risk pool, des RPT spécifiques sont frappés.

Les NFT sont liés à un PRP spécifique et couvrent les risques des polices d’assurance individuelles. Les NFT restent dans le SRP et les RPT dans les portefeuilles des investisseurs. Lorsque toutes les polices liées à un NFT sont expirées et que tous les sinistres associés ont été payés, l’investisseur peut retirer tous les actifs associés au NFT.

Nous voulons que les investisseurs déposent et résilient leurs contrats aussi rapidement et efficacement que possible. Mais la protection des autres investisseurs et des assurés est également essentielle pour nous. Nous avons donc trouvé un compromis qui profite à toutes les parties, les périodes (Epochs).Les périodes réduisent massivement la complexité de calcul, un facteur limitant dans les smart contracts en raison des limites blocantes de gaz. Le concept de période permet d’exécuter chaque transaction avec un plafond de gaz fixe.

Dans la première version de notre risk pool, nous proposerons uniquement le staking unilatéral (le risque est pris par un seul stablecoin). Cependant, vous devez miser un certain montant de DIP token dans la global staking pool par rapport au capital investi. Ce n’est donc que lorsque vous avez misé le montant de base en DIP token que vous pouvez apporter du capital-risque sous forme de stablecoins. À l’avenir, les investisseurs pourront miser différents actifs - pas seulement des stablecoins - en fonction des exigences du détenteur de la risk pool.

La norme offerte par le framework de l’assurance générique est simple. Les primes sont ajoutées à la risk pool (après déduction des coûts) et augmentent la valeur des token de ladite risk pool. Les paiements sont effectués à partir de la risk pool et diminuent la valeur desdits token.

Lors d’une mise en œuvre standard, les bénéfices restent initialement dans la risk pool. Les bénéfices sont réalisés au moment où le capital peut être retiré de la risk pool.

Les investisseurs reçoivent leurs primes lors de la conclusion du contrat. Les primes versées par les assurés sont créditées proportionnellement dans le rapport capital risque personnel / capital risque total. Les remboursements éventuels en cas de sinistre sont répartis proportionnellement entre tous les fournisseurs de capital-risque qui ont contribué aux primes depuis le début du contrat.

Ainsi, si vous avez deux investisseurs, l’investisseur 1 à 100.000 DIP, l’investisseur 2 à 50.000 DIP. Une assurance est souscrite avec une prime de 30 USDC. L’investisseur 1 reçoit l’équivalent de 20 USDC grâce au gain de prix de son RPT, l’investisseur 2 reçoit l’équivalent de 10 USDC. Les USDC restent dans le PRP.

Si une demande d’indemnisation est ensuite présentée à hauteur de 90 USDC sur cette police, les 90 USDC seront payés à partir du PRP. L’investisseur 1 perd l’équivalent de 60 USDC, l’investisseur 2 perd l’équivalent de 30 USDC.

Dans l’image ci-dessous, un certain nombre d’acteurs/participants sont mentionnés, les noms mentionnés sont écrits à titre d’exemple et il se peut que d’autres acteurs et/ou blockchain soient ajoutés. Dans cette image, les acteurs suivants sont mentionnés.