Installez un Safe Guard. Vos propriétaires, votre seuil et votre historique restent exactement les mêmes, mais chaque transfert exige en plus une approbation post-quantique, vérifiée sur la chaîne.
Un propriétaire signe le transfert dans le vrai Safe{Wallet}. Il ne s'exécute pas. L'Administrateur quantique lit le paiement sur l'appareil (jeton, montant, destinataire, fenêtre de validité, Safe et chaîne) et l'approuve avec une signature post-quantique à usage unique. Alors seulement, les fonds bougent.
Enregistré de bout en bout sur l'environnement de démonstration local : un vrai Safe, le vrai Safe{Wallet} et le Guard qui applique les règles sur la chaîne. L'appareil est le Ledger simulé, pas du matériel ; voir État pour l'avancement de l'application Ledger.
Voir en taille réelle · L'essayer vous-même →
Chaque propriétaire de Safe signe avec ECDSA. Un ordinateur quantique assez puissant casse ECDSA, pour tous vos signataires à la fois. Des actifs conservés dix ans ont besoin d'une signature qui survive à ce jour-là.
Il décide qui peut signer. Il ne peut rien si le schéma de signature lui-même tombe.
Elles n'empêchent pas une signature falsifiée sur la même courbe : la clé n'a jamais besoin de quitter l'appareil.
Un moteur de règles que la chaîne ne consulte pas peut être contourné. Le dernier mot doit se trouver sur la chaîne.
FermionGuard est un Safe Guard, le point d'accroche officiel de Safe avant chaque exécution. Les propriétaires continuent de signer comme aujourd'hui. Le Guard ne laisse passer la transaction que si elle porte aussi une approbation post-quantique correspondante.
Les mêmes propriétaires, le même seuil, les mêmes portefeuilles matériels. Protège contre les opérateurs malveillants, les appareils perdus et les défaillances internes.
Un Administrateur quantique désigné approuve chaque transfert sur un Ledger avec une clé XMSS. Protège contre les signataires compromis, les approbations rejouées, le siphonnage d'autorisations et les futures attaques quantiques.
Un opérateur met un transfert en file d'attente dans Safe{Wallet}. Les propriétaires signent comme d'habitude.
La Safe App FermionGuard le marque 🟡 autorisation quantique requise.
L'Administrateur vérifie le contenu, décodé à partir de deux sources indépendantes.
Le Ledger affiche chaque champ appliqué. Maintenez appuyé pour approuver.
La ligne passe au 🟢. N'importe qui peut l'exécuter ; le Guard vérifie et consomme l'approbation.
L'Administrateur voit exactement ce qu'il approuve
Une approbation désigne le Safe, la chaîne, le jeton, le destinataire, le montant et une fenêtre de validité. Si quelqu'un modifie ensuite la transaction en attente, l'approbation ne correspond plus et le Guard la refuse.
Pas de signature à l'aveugle : l'appareil affiche chaque champ que le Guard applique
FermionGuard est livré sous forme de Safe App dans Safe{Wallet} et d'application Ledger pour l'Administrateur. Des alertes de risque signalent les nouveaux destinataires, les montants inhabituels et les transactions que le Guard refuserait de toute façon, avant que quiconque ne signe.
Une paie à verser ? Un lot entier de jusqu'à 100 transferts ne demande qu'une seule approbation.
Pas de nouveau portefeuille, pas de nouvelle chaîne, pas de migration d'actifs. Quatre étapes, menées par vos propriétaires actuels au moyen de transactions Safe ordinaires.
Ajoutez FermionGuard dans Safe{Wallet}. Il vérifie la version et les modules de votre Safe avant toute modification.
La clé de l'Administrateur est générée dans le Ledger. Les propriétaires la confirment et cosignent son enregistrement.
Les propriétaires signent une transaction setGuard, comme toute autre transaction Safe.
Un transfert d'un montant infime parcourt tout le processus. Une fois confirmé, votre tableau de bord affiche Protégé ✓.
Ajoutez un contrôle cryptographique indépendant et fondé sur des normes à la conservation des actifs de vos clients.
Gardez votre circuit d'approbation, et faites qu'un signataire compromis ne suffise plus à déplacer des fonds.
Placez un contrôle public et temporisé sur les opérations qui comptent le plus : les changements de gouvernance.
Le Guard est le dernier veto sur la chaîne, et il est conçu pour qu'une clé perdue ou un bogue ne puisse jamais geler vos fonds.
Ledger perdu ? Les propriétaires seuls peuvent retirer le Guard après un compte à rebours public de 14 jours. Un appareil hors service ne bloque jamais le Safe.
Retirer le Guard ou changer de propriétaires exige une approbation et un compte à rebours public de 48 heures dont chaque propriétaire est averti.
Un Guard non modifiable, avec une pause rapide qui bloque tout en cas d'incident. Aucune porte dérobée d'administration.
Les modules Safe contournent les guards : l'inscription exige donc qu'aucun module ne soit activé, ou un module guard associé sur Safe 1.5+.
approve, permit et transferFrom sont refusés d'emblée, et les lots sont vérifiés opération par opération sur la chaîne.
Les propriétaires cosignent la racine publique complète de la clé sur leurs propres appareils, si bien qu'un site web compromis ne peut pas y substituer une autre clé.
Les changements de gouvernance sont lents et visibles ; les annuler est rapide
Un attaquant en possession du Ledger de l'Administrateur ne peut toujours pas déplacer de fonds sans les signatures de vos propriétaires, ni retirer le Guard sans un compte à rebours public de 48 heures que vos propriétaires peuvent annuler.
XMSS ne repose que sur des fonctions de hachage : la chaîne le vérifie donc directement, sans oracle ni serveur de confiance. Le vérificateur est une implémentation indépendante de la RFC 8391, et nous disons exactement jusqu'où va sa preuve : chaque primitive de la RFC, ainsi que les contrôles qui rejettent les entrées mal formées, sont vérifiés par machine pour toutes les entrées, face à une transcription ligne à ligne de la RFC. Leur composition dans la comparaison de la racine, qui accepte ou refuse finalement une signature bien formée, est justifiée à la main, vérifiée symboliquement pour une hauteur d'arbre de 2 et fixée par les vecteurs de la RFC pour h = 4, 10 et 20.
XMSS est à états : réutiliser une feuille à usage unique permettrait à un attaquant de falsifier des signatures. Le Ledger enregistre son compteur avant de délivrer une signature, et le contrat tient une table des feuilles utilisées qui annule toute réutilisation.
Parcourir les contrats → · Spécification du Guard → · Preuve formelle →
function _verifyAndConsumeXmss( bytes32 keyId, bytes32 digest, bytes calldata xmssSignature ) internal { XMSS.Signature memory sig = abi.decode(xmssSignature, (XMSS.Signature)); BitMaps.BitMap storage used = _usedLeaves[xmssRoot(keyId)]; // per KEY, not per registration if (used.get(sig.leafIdx)) revert LeafAlreadyUsed(keyId, sig.leafIdx); if (!XMSS.verify(digest, sig, publicKey(keyId), treeHeight(keyId))) revert InvalidXmssSignature(); // whole tx rolls back used.set(sig.leafIdx); // burn the one-time leaf emit LeafConsumed(keyId, sig.leafIdx, digest); }
La conception et le vérificateur post-quantique sont déjà publics. Les équipes en accès anticipé contribuent à façonner le reste.
Stan (Konstantin) Kladko : de la physique qui crée la menace quantique à la cryptographie qui doit y survivre.
Docteur de l'Institut Max Planck. A travaillé avec le prix Nobel Robert B. Laughlin sur les systèmes quantiques à Stanford. Director's Fellow au Laboratoire national de Los Alamos.
A dirigé un laboratoire accrédité par le NIST pour les tests de modules cryptographiques (CMVP), délivrant des certifications FIPS 140-2 et de sécurité face aux canaux auxiliaires.
Cofondateur et CTO de SKALE, qui a fait passer la cryptographie à seuil BLS du papier à un mainnet aligné sur Ethereum.
Non. Vous installez un Guard sur le Safe que vous avez déjà. Propriétaires, seuil, historique et adresses restent exactement les mêmes.
Vos propriétaires peuvent retirer le Guard eux-mêmes, sans clé quantique, après un compte à rebours public de 14 jours. Si la demande n'est pas légitime, ils peuvent l'annuler à tout moment pendant ce délai par une transaction Safe ordinaire. Un appareil perdu ne peut jamais bloquer définitivement votre Safe.
Chaque transfert demande une approbation supplémentaire de l'Administrateur sur un Ledger. Les lots, comme une paie de jusqu'à 100 transferts, ne demandent qu'une seule approbation pour l'ensemble.
Vérifier la signature post-quantique coûte environ 745 000 gas, payés une fois à la création de l'approbation (745 003 gas mesurés à h = 20). Le contrôle au moment de l'exécution n'est qu'une simple lecture.
Safe v1.3.0 et ultérieures. Le Safe ne doit avoir aucun module activé, car les modules contournent les guards, ou bien être sur Safe 1.5+ avec le module guard de FermionGuard installé lui aussi. Il ne doit pas non plus avoir de fallback handler : les jetons ERC-20 et l'ETH fonctionnent normalement, mais les fonctions de messages signés (Permit, ordres CowSwap, connexion) et la réception de NFT via safeTransferFrom ne sont pas encore prises en charge.
XMSS est une signature fondée sur le hachage et approuvée par le NIST (SP 800-208) : l'EVM peut donc la vérifier pour environ 1M de gas. Les schémas à base de réseaux comme ML-DSA et Falcon coûteraient aujourd'hui des dizaines de millions de gas à vérifier sur la chaîne.
Pas encore. Le vérificateur post-quantique est vérifié par machine face à la RFC 8391 dans la mesure décrite plus haut, et les contrats du Guard sont implémentés et testés, mais rien n'est encore audité ; l'application Ledger et la Safe App sont en développement, et un audit externe est requis avant tout déploiement sur le mainnet. Demandez un accès anticipé pour faire partie des premières équipes accompagnées.
Nous accueillons un premier groupe d'équipes qui détiennent des actifs sur Safe. Décrivez-nous votre configuration et nous vous recontacterons à l'ouverture des pilotes.
Ouvre un court formulaire GitHub public : n'y mettez rien de confidentiel.