Quand le portefeuille est sécurisé, mais que la clé de trading ne l’est pas : comprendre l’accès délégué de GRVT
@grvt_io En examinant le modèle d’autorisations de l’API de GRVT, un point a particulièrement retenu l’attention : empêcher les retraits n’est qu’une partie de la sécurité du compte.
Les clés d’API de trading de GRVT sont conçues avec des autorisations réservées au trading. Chaque clé est liée à une adresse Ethereum et signe des ordres à l’aide d’EIP-712, ce qui permet de trader sans accorder d’autorité de retrait.
Cette distinction est importante—mais elle ne supprime pas les risques.
Si une clé d’API autorisée pour le trading est compromise, un attaquant peut encore ouvrir des positions, augmenter l’effet de levier, consommer de la marge ou exposer le compte à une liquidation. Les fonds ne quitteront peut-être jamais le portefeuille, mais la valeur du compte peut tout de même être fortement affectée via des actions de trading autorisées.
Ceci est une interprétation du modèle d’autorisations documenté de GRVT, et non une affirmation selon laquelle GRVT ou son API aurait subi un incident de sécurité.
La leçon à retenir est simple : la sécurité de la conservation (custody) et la sécurité de l’autorité de trading sont deux couches de protection distinctes. La self-custody sécurise la propriété des actifs, tandis que la sécurité de l’accès délégué protège la manière dont ces actifs sont utilisés.
De solides pratiques opérationnelles—permissions du moindre privilège, environnements de signature isolés, supervision continue, révocation rapide des clés et rotation régulière des clés—contribuent à réduire l’impact si jamais une clé de trading est exposée.
Une clé d’API restreinte limite la surface d’attaque, mais n’élimine pas le risque économique.
Quelles mesures de sécurité supplémentaires pensez-vous que les plateformes de trading devraient fournir pour réduire l’impact de clés d’API de trading compromises ?
@grvt_io #grvt $EVAA $BSB $HEI