クリア署名

多くのウォレットは、知らないコントラクトについてはいまも生のデータをそのまま表示します。そして「ブラインド署名」、つまり実際には読めない呼び出しを承認することは、ウォレットから資金を抜かれる経路のひとつです。Vela の答えがクリア署名です。署名の前に、取引をできるかぎり、あなたが理解できる形にデコードします。

何が表示されるか

生の calldata の代わりに、Vela は次のものを表示します。

意図 —— その取引が何をするのか。送る、承認、交換など。
中身 —— 関わる金額とアドレス。トークンの額は実際の単位で表示し、名前がわかる受取人は名前で表示します。
詳細 —— nonce、期限、生の calldata。いきなり目の前に突きつけるのではなく、必要なときに開けるようにしています。
リスクの目安 —— 危険な操作が目立つように色分けします。

しくみ（ERC-7730）

Vela は ERC-7730 のディスクリプターを使って、コントラクトの呼び出しと EIP-712 の型付きデータの両方をデコードします。ディスクリプターとは、あるコントラクトの関数が何を意味するのかを記した、小さく共有できる定義です。

Vela は次の順でディスクリプターを探します。

アプリに内蔵 —— 広く使われているコントラクトのディスクリプター。Uniswap、PancakeSwap、SushiSwap のルーター、WETH、Aave v3 のプール、1inch、Lido と wstETH、Seaport です。
Vela のチェーンデータサーバーから取得 —— 公開の ERC-7730 レジストリを再配信しているものです。
標準の形 —— ERC-20 トークン、ERC-721 と ERC-1155 の NFT、ERC-4626 のボールト、ERC-2612 の permit。これで、日常の操作のほとんどはデコードできます。

検証済みは、最初の出どころだけに使う言葉です。取引が検証済みと表示されるのは、その説明が、いま動かしているアプリに組み込まれたディスクリプターから来たときか、チェーンデータサーバーから来たうえで組み込みのものと完全に一致するとき（途中で何も書き換えられていない証拠になります）だけです。サーバーが返すそれ以外のものも、これまでどおりデコードして表示しますが、ディスクリプターサービスから来たもので、それを認証したものは何もない、という一行が添えられます。そのサービスには署名がないので、信頼性は運用している人の信頼性と同じです。これも、自分で動かせるようにしている理由のひとつです。

トークンの額は、そのトークンのオンチェーンの実際の小数点以下の桁数で整形します。桁数を確認できない場合は、18 桁と仮定して額を表示し、未検証と明示します。間違っているかもしれない数字が、確認済みの数字のように見えることはありません。

リスクレベル

デコードされた取引にはすべてリスクレベルが付き、危険なパターンが目立つようになっています。

注意 —— 承認や permit。資金を使う権限を渡す操作です。
危険 —— 本当に危ないもの。たとえば無制限のトークン承認。
ステーキングや預け入れのような日常的な操作は、それより低いリスクです。

「無制限」の承認は赤で表示され、上限を設定できます

無制限の額のオンチェーン承認は、あとで資金を抜かれる最もよくある経路のひとつです。dApp が「無制限」レベルの承認（approve、increaseAllowance、Permit2 の approve）を求めてきたとき、つまり dApp が「無制限」の意味で使う 2^200 以上（Permit2 では 2^152 以上）の額の場合、Vela はそれを赤で表示し、上限を提示します。選べるのは、具体的な額、あなたの残高（読み取れる場合）、または取り消し（increaseAllowance では選べません）です。どれも選ばなければ、dApp が組み立てたとおりの内容で送信されます。Permit2 は常設の承認を前提に設計されていて、スマートアカウントのバッチは同じトランザクションの中でその承認額を使うため、その使用額を下回る上限を設けるとバッチ全体が失敗するからです。バッチの中の無制限の承認にも、同じようにひとつずつ上限（具体的な額、または取り消し）を設けられます。送信前の最終チェックは生の calldata を読むので、承認画面に一度も表示されなかった無制限の承認が送信されることはありません。大きいが有限の額の承認（残高をはるかに上回る額でも）には注意が表示されます。署名による許可（EIP-2612 や Permit2 の署名）には上限を設けられません。送信するのは dApp で、dApp は自分の手元にあるコピーを使うからです。そのため、求められたとおりに署名するか、拒否するかのどちらかになります。無制限のものは赤で、有限のものは注意付きで表示されます。コレクション全体に対する NFT の setApprovalForAll を求めるリクエストは、アプリではまだ承認できません。

Vela がデコードできないとき

ERC-7730 のディスクリプターはないものの、その関数が公開のセレクターデータベースに載っている場合、Vela は汎用的にデコードし、注意のバナーの下にベストエフォート（デコードはできたが検証はされていない）と表示します。それもできない場合や、取引の一部しかデコードできない場合、Vela は理解したふりをしません。

これが重要な理由

セルフカストディとは、まずい取引を誰も代わりに取り消してくれないということです。身を守る手段はサポート窓口ではなく、承認する前に、何を承認するのかを理解することです。クリア署名は、それを示そうとする Vela の取り組みですが、限界もあります。表示しているアプリ以上に正直にはなれません。だからこそ独立した確認が重要になります。Vela のセキュリティモデルにおける位置づけはホワイトペーパーを参照してください。