## Contrats ### Pool Factory La `PoolFactory` est responsable de la création de pools. Pour l'instant, nous aurons un administrateur qui sera en charge de définir les collections ainsi que les TVP (Taux de Valeur Prêtée) que nous soutenons. Peut-être qu'à l'avenir nous serons totalement décentralisés et laisserons les gens créer les pools qu'ils souhaitent. ### Pool #### Paramètres des Pool - TVP requis pour obtenir des prêts - Collection - Adresse de `NFTFilter` pour vérifier le dernier prix plancher et si nous soutenons cette collection spécifique - `NFTCollateralFactory` afin de créer des collatéraux NFT - Frais de protocole #### Ticks et Gestion de Liquidité Les ticks sont des valeurs non signées, de 152 bits, qui codent les conditions de la liquidité. Il comprend : - limite de prêt - durée (en jours) - taux (en bps - pour cent) ``` Agencement des Bits de Tick +--------------------------------------------------------+ | 152 | +--------------------------------------|-------|---------+ | 120 | 16 | 16 | | Limite | Dur. | Taux | +--------------------------------------------------------+ ``` ``` # Tick 6 (50 ETH, 7 jours, 50%) 5 (40 ETH, 7 jours, 50%) 4 (30 ETH, 14 jours, 30%) 3 (15 ETH, 30 jours, 30%) 2 (5 ETH, 30 jours, 10%) 1 (2.5 ETH, 30 jours, 10%) ``` Pour assembler un prêt de 30 jours, les ticks 1, 2, 3 peuvent être utilisés pour créer un prêt de 15 ETH qui est organisé comme suit : [2.5 ETH de #1, 2.5 ETH de #2, 10 ETH de #3]. L'intérêt pour le prêt serait déterminé par les niveaux de taux d'intérêt de 10%, 10% et 30% appliqués à la somme utilisée de chaque tick et à la durée du prêt. Les ticks 4, 5, 6 ne sont pas éligibles pour ce prêt, car la durée du prêt dépasse leur durée maximale. De même, un prêt de 14 jours peut être assemblé à partir des ticks 1-4, et un prêt de 7 jours à partir des ticks 1-6. Des ticks de plus longue durée peuvent être utilisés pour des prêts de plus courte durée #### Remboursement de Tick Lorsque les prêts sont remboursés ou liquidés, l'argent restauré à un tick est utilisé pour d'abord honorer tous les remboursements programmés, puis le reste est mis à disposition pour de nouveaux prêts. Cela garantit que le remboursement d'un utilisateur retire son dépôt de toute activité de prêt future. Les remboursements sont accordés sur le principe du premier arrivé, premier servi au sein d'un tick. Les remboursements programmés peuvent être exécutés sur plusieurs événements de produit (par exemple prêt remboursé ou garantie liquidée), lors desquels des lots d'actions sont convertis à différents prix à mesure que la valeur du tick change. Dans le cas où un tick devient insolvable en raison d'une liquidation, les actions de remboursement sont converties en un montant nul. #### Ticks hors chaîne et Reçus de Prêt Les ticks sont sélectionnés hors chaîne et fournis à l'API de prêt lors de l'origination d'un prêt. Cela évite les coûts de gaz associés à de nombreuses recherches de stockage, et permet également une optimisation hors chaîne complexe des ticks utilisés. Cela signifie également qu'il est possible pour les emprunteurs de créer des prêts sous-optimaux, en utilisant trop peu de ticks ou des ticks plus coûteux (par exemple, des tranches de taux d'intérêt plus élevées) que nécessaire. La `Pool` garantit que les fonds d'un tick ne sont pas utilisés au-delà de sa limite de prêt ou de sa durée maximale, et que le prêt est tarifé selon la tranche de taux d'intérêt associée. #### Modèle de Taux d'Intérêt Pondéré Les modèles de taux d'intérêt ont deux rôles : - déterminer le taux d'intérêt global d'un prêt en fonction des ticks utilisés - distribuer cet intérêt aux ticks utilisés. Il détermine le taux d'intérêt d'un prêt en calculant la moyenne de tous les taux de tick, pondérée par le montant utilisé pour chaque tick. Par exemple, si un prêt de 20 ETH utilisait 5 ETH à 10%, 10 ETH à 10% et 10 ETH à 30%, le taux d'intérêt moyen pondéré serait de (5 * 10% + 10 * 10% + 10 * 30%)/20 soit 22,5%. #### Frais d'Administration Les frais d'administration sont perçus sur les remboursements de prêts, en tant que pourcentage fixe de l'intérêt total du prêt. Seuls les prêts remboursés avec succès contribuent aux frais d'administration. ### NFTFilter Les `NFTFilter` sont responsables de : - valider que la collection est supportée - vérifier que le marché où le NFT sera acheté est supporté - s'assurer grâce aux mises à jour de l'Oracle que le prix plancher est pertinent - vérifier que le prix plancher a été mis à jour récemment (à déterminer mais par exemple pas plus de 12 heures auparavant) ### NFTWrapFactory La `NFTWrapFactory` est en charge de créer des `NFTWrap` ERC721 enveloppés. 1 contrat intelligent NFTWrap par collection. ### NFTWrap Smart contract qui est unique pour chaque collection et qui sera utilisé pour émettre des NFT enveloppés à un `tokenID` spécifique. Il aura une fonction de destruction appelable par la `Pool` par laquelle il est frappé. ## English Auction Liquidator Lorsqu'un prêt n'est pas remboursé, il sera liquidé par la `Pool`, qui transférera le NFT au liquidateur. La `EnglishAuctionLiquidator` commence une enchère pour le collatéral avec la première offre sur le collatéral. L'enchère dure pendant la durée de l'enchère configurée lors de l'initialisation. Si une offre plus élevée apparaît dans une fenêtre d'extension de temps avant la fin de l'enchère, le contrat prolonge l'enchère par une extension de temps, tous deux également configurés lors de l'initialisation. Enfin, lorsque l'enchère se termine, le meilleur enchérisseur peut réclamer le NFT. ## APIs ### Oracles L'Oracle sera en charge de récupérer les prix plancher des collections de NFT que nous supportons en interrogeant les APIs des marchés d'Opensea et de LooksRare. Nous déterminerons la fréquence à laquelle nous mettrons à jour les prix au niveau du contrat NFTFilter. Cela dépendra probablement de l'ampleur des mouvements de prix. Par exemple, si le prix plancher a bougé de 5 pour cent, nous mettrons à jour le contrat NFTFilter. Nous aurons aussi une contrainte de temps comme une mise à jour minimum 1 fois toutes les 12 heures. Je dois parler à Antoine et Maxim de la stack tech (préférence personnelle pour une stack TypeScript - nest.js) ### Indexeur Il sera en charge d'indexer tous les événements émis par le contrat. Par exemple, nouvelle génération de prêt, remboursement de prêt, fin de prêt, liquidation de NFT etc.... (préférence personnelle pour une stack TypeScript - de l'experience en indexeur donc possiblement peut m'en occuper une fois les contrats finalisés) ### Souscription API en charge de l'enregistrement de nouveaux clients, l'envoi d'e-mails aux initiateurs de prêts. Leur rappeler les paiements à venir etc... (préférence personnelle pour la stack TypeScript - nest.js)