Comment fonctionne la signature native au portefeuille en DeFi

Ce que signifie réellement la signature native au portefeuille

Sur une plateforme centralisée, votre compte est une ligne dans une base de données. Vous vous a uthentifiez par email et mot de passe. La plateforme détient vos fonds dans un portefeuille omnibus. Lorsque vous passez un ordre, vous envoyez une requête HTTP à leur serveur et leur faites confiance pour l'exécuter, la régler correctement et ne pas bloquer vos retraits.

La signature native au portefeuille est structurellement différente. Votre portefeuille Ethereum détient une clé privée. Cette clé signe un message cryptog raphique autorisant une action spécifique. La signature prouve que vous avez approuvé exactement ce qui a été signé — ni plus, ni moins. Personne ne peut la falsifier sans votre clé.

En DeFi, cela signifie que v os ordres sont autorisés par votre clé privée avant d'atteindre un moteur de correspondance. Le protocole reçoit un message signé, vérifie la signature et traite l'ordre. Il n'a pas besoin de faire confiance à votre i dentité. Les mathématiques s'en chargent.

C'est la distinction fondamentale entre une connexion CEX et un flux natif au portefeuille. L'un repose sur la couche d'authentification de la plateforme. L'autre repose sur une preuve cryptographique.

EIP-712 : la norme derrière les invites de signature lisibles

Les premiers portefeuilles Ethereum demandaient au x utilisateurs de signer des données hexadécimales brutes. Vous voyiez une chaîne comme 0x3d602d80600a3d3981f3... et deviez l'approuver. Presque personne ne pouvait vérifier ce qu'il autorisait réelle ment. C'était le problème de la signature aveugle.

EIP-712 a été introduit pour y remédier. Cette norme définit un format pour la signature de données structu rées typées, afin que les portefeuilles puissent afficher une ventilation lisible de ce qu'une signature autorise.

Données structurées typées

EIP-712 exige que chaque message s ignable soit conforme à un schéma défini. Le schéma spécifie les noms de champs, les types et les valeurs. Un ordre peut définir des champs comme asset, isBuy, limitPx, sz, reduceOnly et nonce. Lorsque vous signez, votre portefeuille lit le schéma et affiche chaque champ avec son libellé et sa valeur.

L'invite de signature n 'est pas un bloc hexadécimal. C'est un formulaire structuré qui reflète ce que vous avez réellement approuvé.

Séparation de domaine

EIP-712 inclut un séparateur de domaine — un has h encodant le nom de l'application, la version et l'ID de chaîne. Cela empêche une signature créée pour un protocole d'être rejouée sur un autre. Une signature générée pour Hyperliquid sur le mainnet ne peut être soum ise ailleurs ou rejouée sur le testnet.

Sans séparation de domaine, un site malveillant pourrait capturer une signature valide et la soumettre là où vous ne l'aviez pas prévu. Le séparateur de domaine ferme cett e porte.

Invites lisibles par l'humain

Comme le schéma est défini et le domaine explicite, un portefeuille compatible comme MetaMask ou Rabby affiche la demande de signature c omme une ventilation lisible. Vous voyez le nom du protocole, chaque champ et sa valeur. Vous pouvez vérifier l'actif, la direction, le prix et la taille avant de signer.

C'est ce qui rend la signature native au ditable au moment de l'exécution. Vous ne faites pas confiance à une interface pour décrire ce que vous faites. Vous lisez la charge utile réelle que votre clé autorisera.

Comment Hyperliquid utilise EIP-712 pour la signature d'ordres

Le carnet d'ordres d'Hyperliquid fonctionne sur sa propre L1, mais la couche d'autorisation utilise EIP-712. Lorsque vous passez un o rdre, les paramètres sont encodés en tant que charge utile de données structurées et présentés à votre portefeuille. Votre portefeuille signe la charge utile. Le message signé va au moteur de correspondance d'Hyperliq uid, qui vérifie la signature avant de traiter l'ordre.

Hyperliquid n'a jamais besoin de votre clé privée. Il reçoit un message signé et le vérifie par rapport à votre adresse publique. Signature valide, nonce c orrect — l'ordre est accepté.

Nonces et prévention des attaques par rejeu

Hyperliquid utilise des nonces pour empêcher les attaques par rejeu. Un nonce est un nom bre qui ne peut être utilisé qu'une seule fois par adresse. Chaque ordre signé en inclut un. Une fois ce nonce consommé par une soumission réussie, le même message signé ne peut être resoumis.

Sans nonces, un at taquant ayant capturé un ordre signé valide pourrait le resoumettre plus tard — réexécutant potentiellement un trade déjà terminé ou annulé. Les nonces ferment cette porte. La documentation Hyperliquid détaille les mécanismes de nonce pour quiconque développe sur le protocole.

Portefeuilles API et adresses d'agent

Hyper liquid prend en charge les portefeuilles API, parfois appelés portefeuilles d'agent — des adresses Ethereum distinctes que vous autorisez à signer des ordres pour votre portefeuille principal. L'autorisation est elle- même un message EIP-712 signé depuis votre portefeuille principal, accordant des permissions spécifiques à l'adresse de l'agent.

C'est crucial pour l'automatisation. Au lieu d'exposer la clé privée de votre port efeuille principal à un bot, vous générez une paire de clés distincte, l'autorisez comme agent et laissez l'automatisation signer avec cette clé. Votre clé principale reste hors ligne.

Les portefeuilles d'agent ont des permissions limitées. Ils peuvent placer et annuler des ordres. Ils ne peuvent pas retirer de fonds vers des adresses arbitraires. Cette séparation entre autorité de signature et autorité de retrait est une li mite de risque significative.

Ce que l'invite de signature vous montre avant l'exécution

Lorsque vous soumettez un ordre via une in terface native construite sur Hyperliquid, votre portefeuille affiche une demande de signature avant toute exécution. Le rendu exact dépend de votre logiciel, mais une implémentation EIP-712 conforme affichera quelque chose de structuré comme ceci :

• Protocole/domaine : le nom de l'application et le contexte de la chaîne
• Actif : le marché que vous tradez — ETH, BTC, etc.
• Direction : achat ou vente
• Prix limite : la limite de prix pour l'ordre
• Taille : la taille de la position dans l'actif de base
• Réducti on uniquement : si l'ordre ne peut que réduire une position existante
• Nonce : le numéro de séquence pour la protection contre le rejeu

Vous examinez ces champs avant de si gner. Si le prix ou la taille ne correspond pas à ce que vous avez saisi, rejetez la signature. Rien ne s'exécute sans votre approbation.

C'est la propriété de sécurité fondamentale ici. L'étape d'approbation es t explicite et lisible. Il n'y a pas d'appel en arrière-plan soumettant un ordre à votre insu. L'invite de signature est le garde-fou.

Signature déléguée : q u'est-ce que c'est et quand l'utiliser

Exiger une approbation manuelle pour chaque ordre est pratique pour le trading discrétionnaire. Pour les stratégies automatisées, c'est un goulot d'étranglement. Une strat égie devant réagir aux conditions du marché en quelques millisecondes ne peut attendre une fenêtre MetaMask.

La signature déléguée résout ce problème. Vous générez une paire de clés distincte, autorisez cette ad resse comme agent sur Hyperliquid en signant un message de délégation depuis votre portefeuille principal, et laissez votre couche d'automatisation signer les ordres avec la clé d'agent. La clé d'agent peut résider en mémoire ou dans une enclave sécurisée, accessible à votre automatisation sans exposer votre clé principale.

La délégation elle-même est un message EIP-712 signé une seule fois depuis votre portefeuille principa l. Il spécifie quelle adresse vous autorisez et ce qu'elle peut faire. Le moteur de correspondance d'Hyperliquid reconnaît alors cette adresse d'agent comme autorisée à agir en votre nom.

Quelques points à compr endre sur les portefeuilles d'agent :

• L'agent peut placer et annuler des ordres. Il ne peut pas initier de retraits vers des adresses externes.
• Si la clé d'agent est compromise, un attaquant peut tr ader sur votre compte mais ne peut pas vider votre collatéral vers un portefeuille arbitraire sans votre clé principale.
• Vous pouvez révoquer l'autorisation de l'agent à tout moment avec un autre message signé depuis votre portefeuille principal.

Cette architecture vous permet de séparer les clés de signature "chaudes" des clés de garde "froides". Votre portefeuille principal — qui contrôle les retraits — reste hors ligne. Votre portefeuille d'agent — qui contrôle le flux d'ordres — tourne dans votre pile d'automatisation.

Comment Stacked Markets présente le méca nisme de signature

Stacked Markets est un terminal de trading non-custodial construit sur le CLOB on-chain d'Hyperliquid. Il ne détient aucun de vos collatéraux, ne mutu alise rien et achemine vos ordres via le moteur d'Hyperliquid. Chaque ordre nécessite une approbation explicite du portefeuille avant exécution.

L'interface est construite autour du flux de signature, et non gre ffée dessus. Lorsque vous soumettez un ordre, une invite de signature en langage clair apparaît avant l'exécution. Cette invite reflète la charge utile EIP-712 réelle que votre portefeuille signera — actif, direction, prix, taille. Vous approuvez ou rejetez. Rien ne bouge sans votre signature.

Les ordres sont acheminés comme des ordres limites de type IOC avec slippage, et non comme de faux ordres au marché. La limite de pri x dans l'invite de signature est la limite réelle de votre exécution. Vous ne signez pas un ordre au marché pouvant être rempli à n'importe quel prix. Vous signez une limite avec un plancher ou un plafond de prix expl icite, et le CLOB d'Hyperliquid gère la correspondance.

Le terminal prend également en charge la signature déléguée pour les traders utilisant des flux automatisés. Vous liez une adresse de signataire à votre po rtefeuille principal, et le terminal signe les ordres en votre nom sans nécessiter d'approbation manuelle pour chaque trade. La délégation suit le même modèle EIP-712 décrit ci-dessus. Votre portefeuille principal aut orise le signataire. Le signataire gère le flux d'ordres. Les retraits restent protégés par votre clé principale.

Stacked Markets ne détient rien à aucun moment. Hyperliquid gère la correspondance, la marge et l e règlement. Votre PnL et votre financement sont vérifiables on-chain.

Des fonctionnalités d'automatisation et de copy-trading sont prévues mais pas encore en ligne. Le testnet est disponible sur testnet.stackedmarkets.com pour les traders souhaitant tester le flux de signature avant le mainnet.

Risques honnêtes à comprendre

Risque de signature aveugle. Toutes les interfaces n'implémentent pas EIP-712 correcteme nt. Certaines présenteront un hash brut et vous demanderont de le signer. Si vous ne pouvez pas lire ce que vous signez, vous faites une confiance totale à l'interface. Avant d'approuver quoi que ce soit, confirmez qu e votre portefeuille affiche des champs structurés — pas une chaîne hexadécimale brute. Si vous ne voyez qu'un hash, rejetez-le.

Perte de clé. Votre clé privée est la seule information d'identif ication qui compte. Perdez-la sans sauvegarde et vos fonds sont perdus. Aucune équipe de support ne peut les récupérer. Le stockage de la phrase de récupération et la gestion des clés sont entièrement sous votre respo nsabilité.

Phishing et usurpation de domaine. Un site malveillant peut imiter une interface légitime et présenter une invite de signature qui semble correcte mais encode des paramètres différent s. Vérifiez toujours le domaine dans votre navigateur avant de connecter votre portefeuille. Vérifiez que le séparateur de domaine dans l'invite de signature correspond au protocole que vous avez l'intention d'utilise r.

Compromission de la clé d'agent. Si vous utilisez la signature déléguée et que votre clé d'agent est exposée, un attaquant peut trader sur votre compte. Il ne peut pas retirer vers une adress e arbitraire, mais il peut ouvrir/fermer des positions et générer des pertes réelles. Gardez les clés d'agent dans des environnements sécurisés et faites-les tourner si vous suspectez une exposition.

Ris que de contrat intelligent et de protocole. La L1 et le moteur de correspondance d'Hyperliquid comportent leur propre profil de risque. Les bugs de protocole, les échecs d'oracle et les mécanismes de liquidat ion peuvent affecter vos positions de manières non liées à votre configuration de signature. Le règlement on-chain signifie que votre PnL est vérifiable — mais aussi que les pertes sont définitives.

Fraî cheur des données de l'interface. Signer une invite reflétant des données obsolètes est un risque d'exécution réel. Si le prix affiché dans l'interface est obsolète, la limite dans votre ordre signé peut ne p as refléter les conditions actuelles du marché. Stacked Markets affiche des indicateurs de fraîcheur et d'état de connexion pour signaler cela, mais vous devez toujours vérifier que les données sur lesquelles vous agi ssez sont actuelles avant de signer.

FAQ

Conclusion

La signature native n'est pas une fonctionnalité UX. C'est le mécanisme qui remet l'autorisation entre vos mains. E IP-712 rend cette autorisation lisible. Les nonces la rendent non-rejouable. Les portefeuilles d'agent la rendent compatible avec l'automatisation sans exposer votre clé principale.

Comprendre le fonctionnement de la couche de signature signifie que vous pouvez auditer ce que vous approuvez, reconnaître quand quelque chose semble anormal et structurer votre configuration de clés pour correspondre à votre tolérance au risque réelle.

Si vous souhaitez tester ce mécanisme dans un environnement réel avant d'engager du capital, le testnet est sur testnet.stackedmarkets.com.