DeFi et crypto-actifs : des protocoles et des applications dont les conditions et les risques se lisent avant chaque opération.
Smart contracts de protocole, staking, pools, interfaces, administration : nous concevons et développons des solutions DeFi lisibles pour leurs utilisateurs. Les activités financières réglementées restent celles de leurs opérateurs.
Illustration en six étapes, données fictives. 1. Le besoin : un pool de liquidité. 2. Sa représentation, POOL-DEF-0412, et l'empreinte du code déployé. 3. Un smart contract et trois règles : dépôt minimal requis, verrouillage de 30 jours, retrait selon les règles du contrat ; elles s'appliquent telles qu'elles sont écrites, erreurs comprises. 4. Les accès : wallet utilisateur, interface de l'application, tableau de bord. 5. Un dépôt dans le pool accepté ; un retrait avant échéance refusé. 6. Réseau, oracle de prix, indexeur : autant de dépendances. Une plateforme DeFi ne garantit ni rendement ni conformité réglementaire.
Scénario DeFi, six étapes
Besoin métier · Un actif, un produit, un processus à fiabiliser.Représentation · Le pool, ses parts et l'empreinte de son code.Smart contract · Les règles s'appliquent telles qu'elles sont écrites, erreurs comprises.Wallets & applications · Les accès des utilisateurs et de vos outils.Transactions & règles · Chaque opération est vérifiée, puis enregistrée.Écosystème · Réseau, oracle de prix, indexeur : autant de dépendances.
Illustration, données fictives. Une plateforme DeFi ne garantit ni rendement ni conformité réglementaire.
Un protocole, ce sont des règles économiques écrites dans du code : nous en dessinons chaque circulation avant de l'écrire.
Avant la première ligne de code, nous dessinons avec vous ce qui entre, ce qui sort, qui règle quoi et de quelles données le protocole dépend. Chaque point de risque y est situé, puis traité.
Autorisation trop large
Ce que nous prévoyons : Des autorisations limitées, expliquées dans l'interface avant la signature.
Faille du contrat
Ce que nous prévoyons : Tests des cas limites, relecture ; un audit indépendant si le projet le justifie.
Donnée externe erronée
Ce que nous prévoyons : Plusieurs sources, des bornes, et un comportement prévu en cas d'écart.
Liquidité insuffisante
Ce que nous prévoyons : Des règles de retrait lisibles avant le dépôt, pas après.
Pouvoirs d'administration
Ce que nous prévoyons : Approbations multiples, délais avant effet, pause encadrée.
Aucun de ces dispositifs ne supprime le risque. Ils le rendent visible, borné et assumé par ceux qui opèrent le protocole.
Ces règles économiques s'écrivent et se testent comme tout smart contract : chaque cas limite est prévu avant le déploiement.
Ce que nous développons, et ce qui ne relève pas de nous : vous savez qui répond de quoi dès le départ.
Nos prestations sont techniques. Les activités financières réglementées restent celles des opérateurs, dans le cadre qui leur est applicable.
Ce que nous développons
Smart contracts de protocole
Prêt, échange, coffre, distribution : les règles économiques, écrites et testées.
Staking et pools
Dépôts, parts, verrouillages, retraits : des conditions affichées avant l'engagement.
Interfaces
L'application décentralisée qui montre les conditions, les risques et l'état réel de chaque opération.
Administration
Tableaux de bord, paramètres, pause, suivi : des outils pour ceux qui opèrent le protocole.
Intégrations
Oracles de prix et protocoles existants, avec un comportement prévu s'ils échouent.
Ce qui ne relève pas de nous
- la conservation d'actifs pour le compte de tiers
- l'échange ou la négociation d'actifs pour le compte de clients
- le conseil en investissement
- toute promesse de rendement ou de liquidité
L'audit indépendant d'un protocole est un périmètre distinct, confié à un tiers. Nous en préparons le dossier.
Avant de confirmer une opération, l'utilisateur voit ce qu'il engage.
Calcite est un protocole de prêt fictif. L'utilisateur dépose 1 000 unités A en garantie et emprunte des unités B. Réglez l'emprunt, l'autorisation et le prix fourni par l'oracle : l'interface montre ce qui changerait, avant toute signature.
Protocole, unités et prix fictifs : aucune valeur, aucun réseau, aucune transaction.
Montant emprunté
en part de la valeur de la garantie ; 75 % est le plafond du protocole
Autorisation demandée
Prix de A fourni par l'oracle
Opération envisagée
Déposer 1 000 unités A en garantie et emprunter 600 unités B.
- Valeur de la garantie
- 1 000 unités B
- Montant emprunté
- 600 unités B
Ratio dette / garantie60 %
SaineSous 70 % : la position dispose d'une marge avant le seuil.
Ce qui se passerait, fait par fait
- Baisse de la valeur de la garantie
- Non
- Dégradation du ratio
- Non
- Franchissement du seuil de 80 %
- Non
- Déclenchement possible d'une liquidation
- Non
- Liquidation exécutée
- Non : rien n'est exécuté ici
Chaque fait est distinct : une baisse de valeur ne franchit pas toujours le seuil, et un seuil franchi rend une liquidation possible, sans l'exécuter.
- Portée de l'autorisation
- Le contrat pourra prélever 1 000 unités A, une seule fois. Rien de plus.
- Déconnecter le wallet de l'interface ne révoque pas l'autorisation : seule une révocation explicite y met fin.
- Donnée externe
- Prix actuel : 1 unité B par unité A. Le protocole agit sur cette valeur, qu'elle soit juste ou non.
- Conditions du protocole
- Plafond d'emprunt à 75 % de la valeur de la garantie ; seuil de liquidation à 80 % ; une partie de la garantie peut alors être vendue pour rembourser la dette.
- Risques
- Baisse de prix, liquidation, erreur de l'oracle, faille du contrat : la confirmation ne les supprime pas.
État réellement obtenuAucun : c'est une simulation. Une confirmation réelle ouvrirait la position décrite, sans garantie qu'elle le reste.
Les six combinaisons d'emprunt et de prix, et les deux portées d'autorisation.
| Emprunt | Prix actuel | Après une baisse de 20 % |
|---|---|---|
| 40 % | 40 % · saine | 50 % · saine |
| 60 % | 60 % · saine | 75 % · proche du seuil |
| 75 % | 75 % · proche du seuil | 93,75 % · liquidable |
- Montant exact : Le contrat pourra prélever 1 000 unités A, une seule fois. Rien de plus.
- Illimitée : Le contrat pourra prélever tout votre solde d'unités A, aujourd'hui et plus tard, jusqu'à ce que vous révoquiez l'autorisation. Une faille du contrat l'exposerait entièrement.
- Déconnecter le wallet de l'interface ne révoque pas l'autorisation : seule une révocation explicite y met fin.
- État réellement obtenu : Aucun : c'est une simulation. Une confirmation réelle ouvrirait la position décrite, sans garantie qu'elle le reste.
À retenir : une interface claire ne rend pas une opération sûre. Elle permet de la comprendre avant de signer : les pertes, la liquidation et les erreurs de protocole restent possibles.
Les types de signature et la gestion des autorisations côté utilisateur relèvent de nos intégrations de wallets.
Oracles, protocoles tiers, ponts : chaque défaillance a sa réponse prévue.
Un protocole DeFi s'appuie rarement sur lui seul. Chaque dépendance est une hypothèse : nous la nommons, et nous écrivons ce qui se passe si elle tombe.
Oracle de prix
- Si elle échoue
- Un prix faux, figé ou manipulé peut déclencher des liquidations injustifiées, ou en empêcher de nécessaires.
- Ce que nous prévoyons
- Plusieurs sources, des bornes de variation, une suspension si les écarts dépassent un seuil. Voir nos oracles et l'interopérabilité.
Protocole tiers
- Si elle échoue
- Un protocole intégré peut changer ses règles, être suspendu ou subir une faille qui se propage.
- Ce que nous prévoyons
- Des intégrations limitées et isolées, des plafonds d'exposition, une procédure de retrait de l'intégration.
Pont entre réseaux
- Si elle échoue
- Un pont qui cesse de fonctionner peut bloquer des actifs, ou laisser circuler des représentations sans contrepartie.
- Ce que nous prévoyons
- Ne recourir à un pont que si le projet l'exige, avec des montants plafonnés et un comportement prévu en cas d'arrêt.
Risques techniques, gouvernance et audit : chaque pouvoir sur le protocole est nommé, borné et tracé.
Un protocole peut être modifié, suspendu, paramétré. Qui le peut, avec quel délai et sous quel contrôle, se décide à la conception.
Tests et relecture
Cas limites, scénarios de marché extrêmes, revue du code avant chaque déploiement.
Paramètres du protocole
Seuils, plafonds, frais : qui les modifie, dans quelles bornes, avec quel délai avant effet.
Pouvoirs d'administration
Signatures multiples, rôles séparés, pause d'urgence encadrée et journalisée.
Audit indépendant
Un périmètre distinct, confié à un tiers, recommandé selon les montants et les risques ; nous en préparons le dossier.
Signatures multiples, délais, pause et mises à jour se conçoivent avec notre approche de la sécurité et de la gouvernance.
Le cadre réglementaire reste celui de l'opérateur : nous concevons un protocole qui lui permet de s'y conformer.
Concevoir un protocole n'est pas l'exploiter. Les activités réglementées relèvent de celui qui les exerce, dans le cadre applicable, dont le règlement MiCA, à analyser avec ses conseils.
Ce qui relève de l'opérateur
- la qualification juridique de ses activités et de ses jetons
- les agréments ou enregistrements éventuellement requis
- l'information des utilisateurs et la connaissance des clients
- la conservation, l'échange et le conseil, s'il les propose
Ce que nous apportons
- un protocole dont les règles sont documentées
- des interfaces qui affichent conditions et risques
- des paramètres et des pouvoirs traçables
- un dossier technique pour l'audit et pour vos conseils
Nous ne délivrons aucun avis juridique et n'affirmons aucune conformité réglementaire.
Questions fréquentes
Ce que nous demandent les porteurs de projets DeFi avant d'écrire la première règle.
Que comprend le développement d'une plateforme DeFi ?
Les smart contracts du protocole, les interfaces de l'application, l'intégration d'oracles ou de protocoles existants, les outils d'administration et le suivi en exploitation, selon le périmètre convenu. Chaque règle économique est écrite, testée et documentée avant le déploiement.
Peut-on garantir un rendement ou l'absence de perte ?
Non. Un protocole applique ses règles telles qu'elles sont écrites ; les variations de prix, la liquidité disponible, une donnée externe erronée ou une faille peuvent entraîner des pertes. Nous concevons des règles lisibles et des interfaces qui affichent ces risques, sans les supprimer.
Pourquoi éviter une autorisation illimitée dans un protocole DeFi ?
Elle permet au contrat de prélever tout le solde concerné, aujourd'hui et plus tard, jusqu'à sa révocation ; déconnecter son wallet ne la révoque pas. Une faille ou un abus l'exposerait entièrement. Nous privilégions des autorisations limitées au montant de l'opération, expliquées avant la signature.
Que se passe-t-il si l'oracle de prix d'un protocole se trompe ?
Le protocole agit sur le prix reçu, juste ou non : il peut liquider une position saine ou laisser ouverte une position qui ne l'est plus. Plusieurs sources, des bornes de variation et une suspension en cas d'écart se prévoient dès la conception, pas après un incident.
L'audit d'un protocole DeFi est-il inclus ?
Pas d'office. Un audit indépendant est un périmètre distinct, confié à un tiers et recommandé selon les montants en jeu et les risques. Nous préparons son dossier : documentation des règles, tests, scénarios limites et liste des pouvoirs d'administration.
Concevoir un protocole fait-il de nous un prestataire réglementé ?
Non. Nous développons la solution technique ; les activités réglementées, comme la conservation d'actifs pour le compte de tiers, l'échange ou le conseil, relèvent de leurs opérateurs, dans le cadre applicable, dont le règlement MiCA, à analyser avec vos conseils.
La fiche technique de votre protocole : chaque règle écrite avant le premier contrat.
Fiche technique du protocoleProtocole : à nommerRévision 0
Fiche technique du protocole
Art. 1. Fonctionnementà définir
Prêt, pool, coffre, staking : que fait le protocole ?
Art. 2. Utilisateursà définir
Qui dépose, qui emprunte, qui administre ?
Art. 3. Actifsà définir
Lesquels, sur quel réseau, émis par qui ?
Art. 4. Règles économiquesà définir
Plafonds, seuils, frais, verrouillages, liquidation.
Art. 5. Contratsà définir
Combien, modifiables ou non, testés comment ?
Art. 6. Dépendances externesà définir
Oracles, protocoles tiers, ponts, et leur comportement en cas d'échec.
Art. 7. Gouvernanceà définir
Qui modifie quoi, avec quel délai, sous quel contrôle ?
Art. 8. Risquesà définir
Lesquels sont acceptés, bornés, affichés aux utilisateurs ?
Art. 9. Exploitationà définir
Suivi, alertes, incidents, selon le périmètre convenu.
Ce qui ne relève pas de nous
La conservation d'actifs pour le compte de tiers, l'échange et le conseil en investissement. Le cadre applicable, dont MiCA, s'analyse avec vos conseils. L'audit indépendant est un périmètre distinct.
Un premier échange suffit pour situer votre projet : décrivez ce que doit faire le protocole, et pour qui.
Étudions votre projet DeFiAucun rendement, aucune liquidité, aucune absence de perte ni conformité réglementaire ne sont garantis par la conception d'un protocole.