# Foire aux questions ## C’est quoi les Adresses de récupération ? Les Adresses de récupération sont une ou plusieurs adresses configurées par le Propriétaire pour exécuter des actions de Récupération, avec un Seuil de confirmations défini par le Propriétaire. La Récupération peut aussi inclure (optionnellement) une authentification supplémentaire via un mot de passe. Les Adresses de récupération sont hashées avec le mot de passe et restent non associables à un contrat CryptoLegacy précis tant qu’elles ne sont pas utilisées on-chain. Les métadonnées d’actifs liées à la Récupération sont chiffrées par rôle de récupération. Les Adresses de récupération peuvent déchiffrer ces métadonnées à tout moment pour préparer des transactions de récupération. Le simple déchiffrement ne donne pas accès aux actifs et ne permet pas de transferts. Les Adresses de récupération peuvent annuler un vote des Garants en cours et des Périodes de contestation actives, et peuvent lancer le processus de Récupération on-chain prédéfini. Ce processus transfère d’abord les actifs vers le contrat CryptoLegacy, puis les envoie vers n’importe quelle adresse indiquée, strictement selon les règles configurées. *** ## Qui sont les Bénéficiaires ? Les Bénéficiaires sont des adresses désignées par le Propriétaire pour recevoir des actifs pendant la Période de distribution. Pour chaque Bénéficiaire, le Propriétaire définit une part, un Délai avant accès (optionnel) et une Période de distribution — et tout ça détermine comment et quand les actifs deviennent Disponibles à réclamer. Les métadonnées d’actifs liées aux Bénéficiaires sont chiffrées individuellement, Bénéficiaire par Bénéficiaire. Les Bénéficiaires n’ont aucune visibilité sur les soldes des wallets, les métadonnées des actifs, ni l’état du contrat tant que les conditions de distribution ne sont pas remplies. Si la Période d’inactivité de 6 mois expire, n’importe quel Bénéficiaire peut lancer une Période de contestation de 3 mois. Si cette Période de contestation n’est pas annulée, les Bénéficiaires peuvent déchiffrer les métadonnées chiffrées, déclencher le processus on-chain qui transfère les actifs vers le contrat CryptoLegacy, puis Réclamer les actifs progressivement selon leur calendrier configuré. Si des plugins approuvés sont activés, les Bénéficiaires peuvent aussi utiliser la logique de plugin prédéfinie pendant la Période de distribution. Toutes les actions des Bénéficiaires s’exécutent strictement selon les règles on-chain et ne donnent ni accès direct aux clés privées, ni contrôle illimité sur les actifs. *** ## Qui sont les Garants ? Les Garants sont des adresses autorisées à contourner la Période d’inactivité de 6 mois et à déclencher la distribution en votant, selon un Seuil de confirmations prédéfini. Une fois le seuil atteint, une Période de contestation configurée par le Propriétaire (jusqu’à 30 jours) peut s’appliquer. Pendant cette période, le Propriétaire ou une Adresse de récupération peut annuler le processus. Après la Période de contestation, n’importe quel Garant peut déclencher le processus on-chain qui transfère les actifs vers le contrat CryptoLegacy pour la distribution. Les Garants ne peuvent pas retirer les actifs vers leurs propres adresses ni les rediriger. Par défaut, les Bénéficiaires agissent comme Garants, avec un Seuil de confirmations de 3 sur 5 et une Période de contestation de 30 jours. *** ## Ça veut dire quoi Période normale, Période de contestation et Période de distribution ? Ce sont les états d’un contrat CryptoLegacy : * **Période normale** — Le contrat est actif, ne détient aucun actif, et nécessite une transaction on-chain tous les 6 mois pour confirmer l’activité du Propriétaire (Confirmation d’activité). Pendant cette période, le Propriétaire garde le contrôle total et gère les actifs directement dans ses wallets. * **Période de contestation** — Déclenchée quand la Période d’inactivité de 6 mois expire, ou quand les Garants votent pour contourner le délai selon le Seuil de confirmations configuré. Cette période dure jusqu’à 3 mois et peut être annulée par le Propriétaire ou une Adresse de récupération. * **Période de distribution** — Les métadonnées des actifs deviennent déchiffrables, et les Garants ou les Bénéficiaires peuvent déclencher le processus on-chain qui transfère les actifs vers le contrat CryptoLegacy. Les Bénéficiaires Réclament ensuite leur part progressivement selon le calendrier de distribution configuré. Les Adresses de récupération peuvent aussi exécuter le Flux de récupération pour transférer tous les actifs selon les règles du contrat. *** ## Mes Bénéficiaires ne connaissent pas le Web3, la crypto et la blockchain. C’est obligatoire ? Non. Les Bénéficiaires n’ont pas besoin d’expérience préalable en Web3 ou en blockchain pour participer au process de distribution. Ils suivent uniquement des parcours prédéfinis par le contrat, comme déchiffrer les métadonnées et Réclamer les actifs selon le calendrier configuré. La documentation et les indications dans l’interface sont là pour expliquer les étapes. Toutes les actions liées aux actifs s’exécutent automatiquement via le protocole, selon les règles on-chain. *** ## Quels sont les avantages de CryptoLegacy par rapport aux wallets multisig pour la récupération et l’héritage ? Les wallets multi-signature (multisig) sont faits pour le contrôle partagé, pas pour l’héritage. Ils demandent aux Bénéficiaires de détenir des clés de signature à l’avance, ce qui peut exposer les soldes trop tôt et rend la gestion des clés très sensible sur de longues périodes. CryptoLegacy suit une approche différente : * Les actifs restent dans les wallets du Propriétaire tant que les conditions de distribution ne sont pas remplies. Ça évite d’exposer les soldes trop tôt et d’avoir une garde partagée. * Les règles de distribution sont définies à l’avance et appliquées on-chain, pour une exécution claire et déterministe quand la distribution démarre. * Les fonds ne sont pas bloqués dans un wallet partagé, ce qui réduit le risque de verrouillage définitif à cause de clés perdues, inactives ou indisponibles. * La Récupération passe par un Flux de récupération séparé et prédéfini. Les Adresses de récupération peuvent exécuter une récupération complète selon les règles du contrat, sans avoir besoin d’un accès partagé aux fonds pendant la Période normale. Les deux modèles ne servent pas le même objectif : le multisig est centré sur l’accès partagé et la coordination, alors que CryptoLegacy est centré sur la distribution basée sur le temps, la récupération, et une séparation stricte des rôles entre Propriétaire, Garants, Adresses de récupération et Bénéficiaires. *** ## En quoi CryptoLegacy est différent du partage physique d’une phrase mnémonique ? Le partage physique d’une phrase mnémonique consiste à découper la phrase de récupération d’un wallet et à en distribuer des parties à plusieurs personnes pour un stockage longue durée. Cette approche demande à tout le monde de bien se coordonner, de comprendre son rôle, de conserver son “morceau” en sécurité pendant longtemps, et d’agir correctement au bon moment. La moindre erreur, perte, incompréhension ou absence de coopération peut bloquer l’accès aux actifs pour de bon. CryptoLegacy suit un autre modèle : * Aucun partage physique ou numérique de phrase mnémonique — les phrases de récupération et les clés privées ne sont jamais découpées, copiées ou distribuées. * Pas d’exigences de coordination sur le long terme — Bénéficiaires, Garants et Adresses de récupération n’ont pas besoin de stocker des secrets, mémoriser des procédures, ni se coordonner en dehors des règles prédéfinies. * Exécution basée sur des règles plutôt que sur la confiance — les transferts d’actifs et les actions de récupération passent par des processus on-chain prédéfinis, pas par la reconstruction d’une clé privée via un accord humain. * Flux de récupération dédié — la récupération est gérée par une logique de contrat explicite, ce qui évite d’avoir à “trancher” manuellement ou à faire confiance à quelqu’un au moment d’exécuter. Les deux approches ne gèrent pas les mêmes risques : le partage physique de phrase mnémonique repose sur le secret, la coordination et la confiance sur le long terme, alors que CryptoLegacy supprime totalement la distribution de secrets et applique la récupération et la distribution via des règles on-chain. *** ## Comment CryptoLegacy se compare à l’héritage légal ? L’héritage légal “classique” transfère une propriété juridique, mais en self-custody ça ne règle pas deux problèmes pratiques. D’abord, des clés privées ou des hardware wallets doivent finir par être stockés, transportés ou communiqués à quelqu’un, ce qui introduit forcément des risques de perte, de copie ou de mauvais usage. Ensuite, l’exécution dépend de procédures propres à chaque juridiction — tribunaux, intermédiaires et délais — ce qui peut être lent, contesté, ou difficile à coordonner entre plusieurs pays. CryptoLegacy suit un autre modèle : il ne s’appuie pas sur des intermédiaires pour gérer les clés. À la place, la Récupération et la distribution s’exécutent on-chain selon des règles prédéfinies, indépendamment des procédures judiciaires au moment du transfert. L’héritage légal et CryptoLegacy ne couvrent pas le même “niveau” : le système légal définit des droits, tandis que CryptoLegacy fournit un mécanisme déterministe pour exécuter des transferts sans exposer de clés privées. *** ## Comment CryptoLegacy se compare à l’héritage ou la récupération via MPC ? Dans les setups basés sur MPC, le contrôle des actifs est réparti entre plusieurs participants qui autorisent les actions ensemble. Quand on utilise MPC pour l’héritage, les Bénéficiaires deviennent, de fait, une partie du groupe MPC chargé d’approuver les transferts. En pratique, ça crée de l’ambiguïté. Ce n’est pas toujours clair qui initie la récupération, combien de participants doivent coopérer, ce qui se passe si certains Bénéficiaires sont indisponibles, ou comment les désaccords se règlent. L’exécution dépend d’une coordination off-chain, de la disponibilité des participants, et d’un comportement correct au moment exact où les actifs doivent être transférés. CryptoLegacy suit un autre modèle. Les Bénéficiaires n’ont pas besoin de coordonner l’usage de clés ni de participer à des validations off-chain. À la place, la Récupération et la distribution s’exécutent on-chain selon des règles prédéfinies, avec des rôles, des seuils et des conditions temporelles clairement définis à l’avance. Les deux approches reposent sur des hypothèses différentes : MPC suppose une coordination active entre participants, alors que CryptoLegacy part du principe que la coordination peut échouer et encode donc les règles d’exécution directement dans le protocole. *** ## Comment CryptoLegacy se compare au Shamir’s Secret Sharing ? Le Shamir’s Secret Sharing découpe une clé privée ou une phrase mnémonique en plusieurs fragments, avec un seuil de fragments nécessaire pour reconstruire le secret original. Dans un contexte d’héritage, ces fragments sont souvent distribués à des Bénéficiaires ou à des personnes de confiance pour un stockage longue durée. En pratique, ça crée des défis similaires au partage physique de phrase mnémonique. Les fragments doivent être stockés en sécurité pendant longtemps, les participants doivent rester disponibles, et quelqu’un doit finir par coordonner la reconstruction. Si des fragments sont perdus, retenus, ou assemblés de travers, les actifs peuvent devenir inaccessibles définitivement. L’exécution dépend d’une coordination humaine au moment exact où la récupération est nécessaire. CryptoLegacy suit un autre modèle. Les clés privées et les phrases mnémoniques ne sont jamais reconstruites ni révélées. Au lieu de réassembler un secret, la Récupération et la distribution s’exécutent on-chain selon des règles, des seuils et des conditions temporelles prédéfinis. Les Bénéficiaires n’ont pas besoin de détenir ou de combiner des fragments, et aucune coordination off-chain n’est requise au moment de l’exécution. Les deux approches reposent sur des hypothèses différentes : Shamir’s Secret Sharing suppose une disponibilité et une coopération sur le long terme, tandis que CryptoLegacy suppose que la coordination peut échouer et encode donc la logique d’exécution directement dans le protocole. *** ## Comment CryptoLegacy assure la sécurité des smart contracts ? CryptoLegacy utilise des smart contracts personnels qui ne détiennent pas de fonds pendant la Période normale, ce qui réduit la surface d’attaque avant que des conditions de distribution ou de Récupération soient déclenchées. La logique du contrat est volontairement minimale et n’exécute que des actions prédéfinies. Le protocole a passé des audits de sécurité indépendants, et toutes les opérations liées aux actifs sont encadrées par des conditions on-chain explicites plutôt que par une logique “discrétionnaire”. Les actifs restent dans les wallets du Propriétaire jusqu’à ce que la distribution ou la Récupération soit déclenchée selon les règles du contrat. Aucun actif n’est détenu ni géré par le protocole en dehors de ces parcours d’exécution prédéfinis. *** ## Comment CryptoLegacy assure la sécurité de l’interface (UI) ? L’interface de CryptoLegacy ne stocke pas de clés privées ni de données d’actifs sensibles, et ne participe pas à l’exécution des actifs. Toute la logique critique est appliquée par les smart contracts on-chain, pas par le frontend. L’interface hébergée est livrée avec des pratiques de sécurité web standard et des protections contre les attaques réseau les plus courantes. Et si vous voulez encore plus de contrôle, le frontend peut être auto-hébergé, ce qui réduit la dépendance à une infrastructure tierce sans changer le comportement des contrats. *** ## Que se passe-t-il si je n’envoie pas la transaction requise tous les six mois ? Si la Période d’inactivité de 6 mois expire, une Période de contestation de 3 mois peut être lancée. La contestation peut être initiée par les Bénéficiaires ou les Garants, selon le Seuil de confirmations configuré. Pendant la Période de contestation, le processus peut être annulé par le Propriétaire ou une Adresse de récupération. Si la Période de contestation se termine sans annulation, la Période de distribution démarre selon les règles prédéfinies du contrat. À ce moment-là, les Garants ou les Bénéficiaires peuvent déclencher le processus on-chain qui transfère les actifs vers le contrat CryptoLegacy. Les Bénéficiaires Réclament ensuite leur part progressivement selon le calendrier de distribution configuré, tandis que les Adresses de récupération peuvent exécuter le Flux de récupération pour transférer tous les actifs comme défini par le contrat. *** ## Je peux héberger le frontend de CryptoLegacy moi-même ? Oui. Le frontend de CryptoLegacy peut être auto-hébergé à partir du repo publié. L’auto-hébergement vous permet de faire tourner l’interface sur votre propre infra, comme IPFS, Arweave, ou un serveur privé, sans dépendre du frontend hébergé. L’auto-hébergement ne change ni le comportement des contrats ni la logique d’exécution. Toutes les actions critiques restent appliquées par les smart contracts on-chain, peu importe d’où l’interface est servie. *** ## Comment CryptoLegacy protège la confidentialité des Bénéficiaires et des actifs ? CryptoLegacy est conçu pour limiter la divulgation d’informations et retarder la visibilité jusqu’à ce que les conditions de distribution ou de Récupération soient remplies. * Chaque contrat CryptoLegacy utilise sa propre adresse unique, qui n’est pas directement liée au wallet du Propriétaire ni aux autres contrats. * Les adresses des Bénéficiaires, Garants et Adresses de récupération sont stockées sous forme de hash, ce qui empêche de les associer à un contrat précis tant qu’elles ne sont pas utilisées on-chain. * Les métadonnées liées aux actifs sont chiffrées par rôle et ne peuvent être déchiffrées que quand les conditions on-chain correspondantes sont satisfaites. * Pendant la Période normale, les actifs restent dans les wallets du Propriétaire. Le contrat ne détient aucun fonds et n’expose ni soldes ni données d’actifs avant l’exécution. La confidentialité dans CryptoLegacy est assurée par la séparation des rôles, des identités hashées, des métadonnées chiffrées et une exécution basée sur des règles — pas par de l’obfuscation “custodiale” ou du secret off-chain. *** ## Est-ce que les Bénéficiaires ou les Garants peuvent accéder aux données chiffrées à l’avance en inspectant la blockchain ou le code ? Les métadonnées chiffrées sont visibles publiquement on-chain et peuvent être analysées off-chain. Mais ces métadonnées ne peuvent pas être déchiffrées de façon utile sans les clés privées correspondantes, et même un déchiffrement réussi ne donne pas la capacité de déplacer des actifs. Tous les transferts restent encadrés par des conditions on-chain, des Seuils de confirmations, et des Flux d’exécution définis par le contrat. Inspecter le frontend, auto-héberger l’interface, ou relire le code source ne donne pas plus d’accès que ce qui est déjà visible publiquement on-chain. L’interface ne stocke pas de clés privées ni de données d’actifs en clair, et elle ne contourne pas les protections cryptographiques ou celles du contrat. CryptoLegacy ne compte pas sur l’obscurité ou des restrictions côté frontend pour la confidentialité. Il s’appuie sur le chiffrement, la séparation des rôles, et l’exécution on-chain basée sur des règles — en assumant que les données blockchain sont publiques par nature. *** ## Mais les autorisations et les données chiffrées sont on-chain — donc c’est techniquement accessible, non ? Oui. Les métadonnées chiffrées et les données d’autorisation sont visibles publiquement on-chain et peuvent être analysées off-chain. Mais le fait que ce soit techniquement disponible ne veut pas dire que c’est exploitable en pratique. Les données chiffrées ne peuvent pas être déchiffrées de façon utile sans les clés privées, et même un déchiffrement réussi ne permet pas de sortir les actifs des parcours d’exécution prédéfinis. CryptoLegacy part du principe que les données blockchain sont publiques par défaut, et se concentre sur un point clé : la visibilité ne doit jamais se transformer en autorité. La Récupération et la distribution ne peuvent s’exécuter que via des règles on-chain prédéfinies, peu importe l’analyse off-chain ou le reverse engineering. *** ## CryptoLegacy peut gérer des NFTs et d’autres protocoles ? CryptoLegacy est conçu pour être extensible via un système de plugins basé sur le Diamond Standard (EIP-2535). Cette architecture de plugins permet d’ajouter de la logique d’exécution sans modifier le comportement du cœur du contrat. Ça inclut le support de types d’actifs et d’interactions avec des protocoles au-delà de simples transferts de tokens. Au lancement, le système de plugins est déjà en place, et le support des NFTs et d’autres intégrations de protocoles est prévu via des plugins approuvés au fil du temps. L’enregistrement et l’exécution des plugins restent soumis à des règles prédéfinies et ne modifient pas la logique de distribution. *** ## Que se passe-t-il si une clé privée est compromise ? Si une clé privée est compromise pendant la Période normale, le Propriétaire peut mettre à jour la configuration du contrat selon les règles prédéfinies. Ça peut inclure le changement d’adresse du Propriétaire, la mise à jour des adresses des Bénéficiaires ou des Garants, ou l’ajustement de la config de Récupération. Une fois la Période de distribution commencée, le contrôle du Propriétaire est suspendu et ne peut pas être utilisé pour modifier l’exécution. À ce stade, les transferts se font strictement selon les règles de distribution ou de Récupération prédéfinies, indépendamment de la clé compromise. Les Bénéficiaires peuvent mettre à jour leurs adresses de réception pendant la Période de distribution, selon ce que permet la logique du contrat. Aucun rôle ne peut utiliser une clé compromise pour contourner des conditions on-chain ou modifier les Flux d’exécution. *** ## Que faire si mes clés sont potentiellement compromises et que je n’ai plus accès à mes appareils ou à mes backups ? Pendant la Période normale, des mécanismes de Récupération prédéfinis peuvent être utilisés selon la configuration du contrat. Les Garants peuvent déclencher le processus on-chain prédéfini qui transfère les actifs vers le contrat CryptoLegacy, sous réserve des Seuils de confirmations et de la Période de contestation configurée. Pendant la Période de contestation, le processus peut être annulé par le Propriétaire ou une Adresse de récupération. Les Adresses de récupération peuvent aussi exécuter le Flux de récupération selon les règles prédéfinies. Ce Flux transfère les actifs vers le contrat CryptoLegacy et permet ensuite de les envoyer comme défini par la configuration de récupération. Toutes les actions s’exécutent strictement selon les règles on-chain. Aucun rôle ne peut contourner les Seuils de confirmations, les délais, ou les conditions d’exécution. *** ## Je peux mettre le contrat en Pause / le retirer de la Pause ? Le contrat CryptoLegacy inclut un mécanisme de Pause qui bloque les transferts d’actifs et les autres actions d’exécution. Tant que le contrat est en Pause, les actifs ne peuvent pas être déplacés et le démarrage d’une Période de contestation est bloqué. Le Propriétaire peut quand même mettre à jour la configuration du contrat (paramètres des Bénéficiaires, config des Garants, paramètres de Récupération, et autres options hors exécution) selon les règles du protocole. La Période d’inactivité continue de s’écouler pendant que le contrat est en Pause. Pour éviter de passer en état “contestation”, le Propriétaire doit rafraîchir la Période d’inactivité de 6 mois en envoyant la transaction on-chain requise (et le Don DAO, si applicable). Si la Période d’inactivité a déjà expiré, une Période de contestation ne peut pas être lancée tant que le contrat est en Pause, mais peut être lancée immédiatement après la reprise. Retirer la Pause réactive l’exécution avec les mêmes conditions on-chain. Les Autorisations de tokens (approvals) peuvent être révoquées séparément à tout moment, indépendamment du mécanisme de Pause. *** ## Je peux personnaliser le calendrier de distribution des Bénéficiaires ? Oui. Pour chaque Bénéficiaire, le Propriétaire définit une part, un Délai avant accès (optionnel) et une Période de distribution. Ces paramètres déterminent quand la Réclamation d’actifs commence et comment les actifs deviennent Disponibles à réclamer au fil du temps. * **Délai avant accès** — la période d’attente avant qu’un Bénéficiaire puisse commencer à Réclamer les actifs. * **Période de distribution** — la durée pendant laquelle les actifs deviennent Disponibles à réclamer progressivement selon le calendrier configuré. Les paramètres de distribution peuvent être mis à jour par le Propriétaire pendant la Période normale. Une fois la Période de distribution commencée, ces paramètres sont figés et appliqués on-chain selon les règles configurées. *** ## Quels frais CryptoLegacy demande ? CryptoLegacy est soutenu via des dons à la DAO (Don DAO). Un don fixe est requis lors du déploiement d’un contrat personnel et lors du rafraîchissement de la Période d’inactivité au bon intervalle. Une option alternative “accès illimité” peut être utilisée selon la configuration du protocole, et couvre les déploiements de contrats ainsi que les mises à jour de timeout sur les chaînes supportées. *** ## C’est quoi le mécanisme de parrainage, et comment ça marche ? CryptoLegacy inclut un mécanisme de parrainage optionnel, pensé pour des introductions de confiance. Quand un code de parrainage est utilisé, une réduction prédéfinie s’applique à la personne qui déploie, et une allocation prédéfinie est attribuée au détenteur du code, selon les règles du protocole. Les codes de parrainage sont faits pour un usage privé, dans des contextes de confiance — pas pour une distribution publique ou des campagnes de croissance. Les adresses de paiement associées aux codes peuvent être mises à jour selon la configuration du protocole. *** ## Que se passe-t-il si l’équipe core ne peut plus supporter le produit ? CryptoLegacy ne dépend pas d’une implication continue d’une équipe core pour l’exécution des contrats. Une fois déployés, les contrats CryptoLegacy fonctionnent de façon autonome on-chain et ne dépendent pas de services centralisés pour exécuter la Récupération ou la distribution. Le frontend peut être auto-hébergé, et les contrats peuvent être utilisés directement on-chain, indépendamment d’une interface hébergée. La disponibilité du code et sa maintenance peuvent évoluer selon la gouvernance du projet, mais les contrats déjà déployés restent fonctionnels et appliquent leurs règles prédéfinies, même sans support continu de l’équipe. *** ## Pourquoi le code du contrat est public, mais sous copyright et pas sous licence open-source ? Le code du contrat CryptoLegacy est lisible publiquement pour permettre une revue indépendante et des audits. En parallèle, le code est distribué sous droit d’auteur (copyright) pour limiter la réutilisation non vérifiée, le clonage, ou le déploiement dans des contextes trompeurs ou risqués. L’objectif est de réduire le risque d’arnaques, de forks mal configurés, ou de déploiements non autorisés qui pourraient nuire aux utilisateurs. La licence et la disponibilité du code peuvent évoluer avec la gouvernance et la maturité du projet. Quelle que soit la licence, les contrats déjà déployés continuent de fonctionner de façon autonome et d’appliquer leurs règles on-chain. *** ## Pourquoi le code de l’UI est fermé et obfusqué ? L’interface CryptoLegacy n’est pas une “barrière de sécurité”. Elle ne stocke pas de clés privées, de métadonnées d’actifs déchiffrées, ni d’autorité d’exécution. Toute la logique critique est appliquée par les smart contracts on-chain. Le code UI est distribué sous une forme obfusquée pour réduire les risques de phishing, de frontends usurpés et de copies trompeuses qui pourraient pousser des utilisateurs à signer des transactions non voulues. L’obfuscation sert à limiter une réutilisation ou modification triviale de l’interface dans des contextes risqués, pas à remplacer la sécurité cryptographique ou celle du contrat. Les utilisateurs peuvent auto-héberger l’interface ou interagir directement avec les contrats on-chain. La disponibilité du code UI et sa licence peuvent évoluer selon la gouvernance du projet, mais les contrats déjà déployés restent entièrement auditables et appliquent leurs règles indépendamment du frontend.