Signature lisible

Beaucoup de portefeuilles affichent encore des données brutes pour tout contrat qu’ils ne reconnaissent pas, et la « signature à l’aveugle » — approuver des appels que l’on ne peut pas vraiment lire — est l’une des façons dont les portefeuilles se font vider. La réponse de Vela, c’est la signature lisible : avant que vous signiez, la transaction est décodée, autant que possible, en quelque chose que vous pouvez comprendre.

Ce que vous voyez

À la place de la calldata brute, Vela affiche :

L’intention — ce que fait la transaction : Envoyer, Approuver, Échanger, etc.
L’essentiel — les montants et les adresses concernés, avec les montants de jetons en unités réelles et les destinataires affichés par leur nom quand il en existe un.
Les détails — nonce, échéances et calldata brute, disponibles à la demande plutôt que jetés à la figure.
Une indication de risque, par code couleur, pour que les actions dangereuses ressortent.

Comment ça marche (ERC-7730)

Vela décode à la fois les appels de contrat et les données typées EIP-712 à l’aide de descripteurs ERC-7730 — de petites définitions partageables de ce que signifient les fonctions d’un contrat.

Vela cherche un descripteur dans cet ordre :

Intégré à l’app — des descripteurs pour des contrats très utilisés : les routeurs Uniswap, PancakeSwap et SushiSwap, WETH, le pool Aave v3, 1inch, Lido et wstETH, et Seaport.
Récupéré sur le serveur de données de chaîne de Vela, qui republie le registre public ERC-7730.
Formes standards — jetons ERC-20, NFT ERC-721 et ERC-1155, coffres ERC-4626 et permits ERC-2612 —, pour que la plupart des actions courantes se décodent quand même.

Vérifiée est réservé à la première source. Une transaction n’est marquée vérifiée que si la description vient d’un descripteur intégré à l’app que vous utilisez — ou du serveur de données de chaîne et qu’elle est identique à la copie intégrée, ce qui prouve que rien n’a été modifié en chemin. Tout le reste de ce que le serveur envoie est quand même décodé et quand même affiché, avec une ligne indiquant que cela vient du service de descripteurs et que rien ne l’a authentifié. Ce service n’est pas signé : il n’est donc fiable qu’autant que celui qui le fait tourner — c’est l’une des raisons pour lesquelles vous pouvez faire tourner le vôtre.

Les montants de jetons sont formatés avec les décimales réelles on-chain du jeton. Si Vela ne peut pas confirmer les décimales d’un jeton, il affiche le montant comme si le jeton en avait 18 et le signale comme non vérifié, pour qu’un chiffre faux n’ait jamais l’air d’un chiffre contrôlé.

Niveaux de risque

Chaque transaction décodée reçoit un niveau de risque, pour que les schémas dangereux ressortent :

Prudence pour les approbations et les permits — vous accordez un pouvoir de dépense.
Danger pour ce qui est vraiment risqué, comme une approbation de jeton illimitée.
Un risque moindre pour les actions de routine comme le staking ou un dépôt.

Une approbation « illimitée » s'affiche en rouge, avec un plafond proposé

Une approbation on-chain d'un montant illimité est l'une des façons les plus courantes de voir des fonds disparaître plus tard. Quand une dApp en demande une (approve, increaseAllowance ou l'approve de Permit2) au niveau « illimité » — 2^200 ou plus (2^152 pour Permit2), les valeurs qu'utilisent les dApps pour dire « illimité » —, Vela l'affiche en rouge et propose un plafond : un montant précis, votre solde (quand il peut être lu) ou — sauf pour increaseAllowance — une révocation. Si vous n'en choisissez aucun, elle est envoyée exactement telle que la dApp l'a construite : Permit2 est conçu autour d'une approbation permanente, et le lot d'un compte intelligent dépense cette allocation dans la même transaction, si bien qu'un plafond inférieur à cette dépense fait échouer tout le lot. Dans un lot, chaque approbation illimitée peut recevoir son propre plafond de la même façon (un montant ou une révocation). Une dernière vérification avant l'envoi lit la calldata brute, si bien qu'une approbation illimitée que l'écran d'approbation n'a jamais montrée ne peut pas partir. Une approbation finie mais élevée (même bien au-delà de votre solde) s'affiche avec un avertissement. Les permits signés (signatures EIP-2612 et Permit2) ne peuvent pas être plafonnés — la dApp soumet sa propre copie —, donc ils sont signés tels que demandés ou refusés : un permit illimité en rouge, un permit limité avec un avertissement. Une demande d'accorder un setApprovalForAll de NFT sur toute une collection ne peut pas encore être approuvée dans les apps.

Quand Vela ne parvient pas à décoder un appel

Quand aucun descripteur ERC-7730 n’existe mais que la fonction figure dans une base publique de sélecteurs, Vela décode l’appel de façon générique et le marque au mieux — décodé, mais non vérifié — sous une bannière de prudence. Si même cela échoue, ou si Vela ne peut décoder qu’une partie d’une transaction, il ne fait pas semblant de la comprendre.

Pourquoi c’est important

L’auto-conservation signifie que personne ne peut annuler une mauvaise transaction à votre place. La défense, ce n’est pas un service client — c’est de comprendre ce que vous approuvez avant de l’approuver. La signature lisible, c’est la façon dont Vela essaie de vous le montrer, et elle a ses limites : elle ne peut être plus honnête que l’app qui l’affiche, et c’est pourquoi une vérification indépendante compte. Voir le livre blanc pour sa place dans le modèle de sécurité de Vela.