教育目的の情報であり、投資助言ではありません。デジタル資産の取引や署名により、取り戻せない損失が生じる可能性があります。
端的な答え
ガバナンス委任署名が安全なのは、デコードされたメッセージが意図した委任と完全に一致し、かつガバナンスコントラクトが十分なリプレイ保護を実施している場合に限られます。一般的な投票トークンの設計では、委任によって変わるのは署名者の投票力を行使できる人です。トークン残高を移転したり、トークンの使用承認を与えたりするものではありません。ただし、その署名が実際に何を行うかを最終的に決めるのは、デプロイ済みのコントラクトです。
オフチェーン署名はリレイヤーが送信できるため、署名者が Gas を支払わなくても、オンチェーンの状態変更を許可することになります。署名は、ログインや無害なウォレット接続要求ではなく、実行可能な指示として扱ってください。
仕組み
一般的な delegateBySig の流れは、次の四段階です。
- アプリケーションが、委任先アドレス、ノンス、有効期限を含む EIP-712 型付きデータを作成します。
- ウォレットが、型付きメッセージと EIP-712 ドメインに結び付けられたダイジェストへ署名します。
- どのアカウントでも、その署名をトークンコントラクトまたはガバナンスコントラクトへ中継できます。
- コントラクトが署名者を復元または検証し、ノンスと有効期限を確認して、新しい委任先を記録します。
EIP-712 ドメインには、name、version、chainId、verifyingContract を含めることができます。これらのフィールドによって、内容が同一でも、アプリケーション、バージョン、ネットワーク、コントラクトが異なるメッセージを分離できます。EIP-712 自体はリプレイ保護を提供しないことを明記しています。コントラクト側でノンスを消費するなど、各許可を一度しか使えない仕組みを設けなければなりません。また、有効期限が時間枠を制限するのは、コントラクトが実際にそれを確認する場合だけです。
署名前に、公式のガバナンス画面や文書、または独立して検証したコントラクトデータと照合し、次の項目をすべて確認してください。
primaryTypeとフィールド名が、Permit、トークン移転、注文、アカウント管理の許可ではなく、委任を表していること。verifyingContractが、使用中のchainId上にある意図したトークンコントラクトまたはガバナンスコントラクトであること。delegateeが選択した代表者のアドレスであること。表示名ではなく、アドレス全体で確認してください。nonceがコントラクトに記録された署名者の現在のノンスと一致し、expiryが目的の手続きに対して十分短いこと。- ウォレットが型付きデータを完全に表示していること。意味を独力で再現できない生のハッシュやブラインド署名を求められた場合は拒否してください。
実装はそれぞれ異なります。たとえば Compound の COMP コントラクトは、委任先、ノンス、有効期限をハッシュ化し、指定ノンスが署名者について保存されたノンスと等しいことを要求したうえで、そのノンスを増加させ、期限切れの署名を拒否します。OpenZeppelin の Votes インターフェースも delegateBySig、ノンス処理、有効期限チェックを提供しています。別のコントラクトに同じような名前の関数があっても、同じ保護を備えているとは限りません。
例
Mira は 10,000 票をアドレス 0xAB...1234 に委任しようとしています。ウォレットには、primaryType: Delegation、検証済みの投票トークンコントラクト、使用中のチェーン ID、delegatee: 0xAB...1234、現在のノンス、20 分後の有効期限が表示されています。別の信頼できる情報源でもアドレスを確認してから署名すると、リレイヤーがメッセージを送信し、コントラクトが委任イベントを発行します。Mira のトークン残高は自分のウォレットに残り、代表者はそのプロトコルの規則に従って対応する投票力を得ます。
ここで一点だけ変えてみましょう。ページが primaryType: Permit を要求してトークンの使用者を指定している、または verifyingContract が無関係のコントラクトである場合です。これは同じ委任指示ではありません。ボタンに「委任」と書かれ、署名者が Gas を支払わないとしても、代わりにトークンの使用を許可する可能性があります。Mira は拒否すべきです。
リスクと対策
- 委任先の誤り：アドレスポイズニング、ダイレクトメッセージ、コピーされた表示名によって、
delegateeが攻撃者の管理するアドレスへ置き換えられることがあります。公式の提案ページや代表者プロフィールでアドレス全体を確認してください。 - 操作の誤り：悪意ある画面が Permit など別の EIP-712 型を要求することがあります。
primaryType、すべてのフィールド、検証コントラクトを読み取ってください。ボタンの表示にはセキュリティ上の意味がありません。 - リプレイ：ノンス確認が弱い、または存在しない場合、署名が再利用されるおそれがあります。ドメインが意図したチェーンやコントラクトに結び付いていなければ、想定外の文脈で使われる可能性もあります。EIP-712 だけではリプレイ保護にならないため、実際の検証コードを確認してください。
- 長期間有効な署名：未使用の署名済みメッセージは、期限が切れるかノンスが無効になるまで実行可能なことがあります。有効期限は短くし、署名を公開しないでください。取り消す必要がある場合は、プロトコル文書に記載された無効化方法だけを使用してください。
- 誤解を招くウォレット表示：フィールドの省略、不明なドメイン、ブラインド署名では、十分な情報に基づく同意ができません。操作を中止し、メッセージ全体を表示できるウォレットまたはデコーダーで型付きデータ要求を調べてください。
- コントラクトアカウントの違い：スマートコントラクトウォレットは ERC-1271 で署名を検証することがあり、有効性がウォレットの状態や認可方針に左右される場合があります。EOA と同じ署名者復元を前提にせず、ウォレットとガバナンスコントラクトの双方が対応していることを確認してください。
- ガバナンス上の影響：委任によって投票力が集中したり、信頼できない委任先が自分の利益に反する投票をしたりする可能性があります。委任先の身元、投票履歴、利益相反、プロトコルの再委任手続きを確認してください。
送信後は、正しいチェーン上で取引を検証してください。送信先コントラクト、デコードされた関数、復元された署名者またはイベントに記録された署名者、新しい委任先、ノンスを確認します。リレイヤーの取引成功が示すのは、コントラクトが呼び出しを受理したことだけであり、署名の意図が安全だったことではありません。
署名したもののまだ送信されていない場合は、その署名の共有をやめ、プロトコル文書に記載された取り消しまたはノンス無効化の方法を確認してください。望まない委任が実行された場合は、公式コントラクトを通じて再委任し、新しい状態を検証します。委任だけで通常トークンの使用枠が作られることはないため、再委任と承認の取り消しを混同しないでください。Permit にも署名した場合や、シードフレーズまたは秘密鍵を漏らした場合は、より重大度の高い別のウォレット事故として対処してください。
よくある誤解
- 「Gas が不要なら権限も与えない。」 リレイヤーが Gas を支払い、署名が署名者の許可を与えることができます。
- 「EIP-712 ならすべての署名が安全になる。」 この規格は型付きデータのハッシュ化とドメイン分離を標準化しますが、リプレイ保護は含まず、表示された操作を利用者が本当に意図したかを検証することもできません。
- 「委任するとトークンが移転する。」 一般的な投票委任で移転または割り当てられるのは投票力であり、トークンの所有権ではありません。ただし、実際の効果を確定できるのは、デプロイ済みコントラクトとデコードされたメッセージだけです。
- 「オフチェーン署名はいつでも取り消せる。」 署名を取り消す汎用的な取引はありません。有効期限、ノンスの消費または無効化、再委任は、いずれもコントラクトごとに異なる仕組みです。
- 「委任先を変えれば以前の投票も消える。」 再委任はプロトコルの規則に従って将来または現在の投票力を変えますが、すでに投じた票を取り消したり、過去のスナップショットを変えたりできるとは限りません。
関連トピック
出典
- EIP-712：型付き構造化データのハッシュ化と署名 - Ethereum Improvement Proposals（参照日：2026-08-20）
- Comp.sol - Compound Finance（参照日：2026-08-20）
- ガバナンス API - OpenZeppelin（参照日：2026-08-20）
- ERC-1271：コントラクト向け標準署名検証方式 - Ethereum Improvement Proposals（参照日：2026-08-20）