ウォレットの署名要求は安全？eth_sign・EIP-712・SIWE・delegationの見分け方

ウォレットに「署名」と表示されても、すぐに資産が動くtransactionとは限りません。反対に、gasが表示されないから安全とも限りません。off-chainで作った署名が、後からtoken権限、注文、login session、account delegationへ使われる場合があるためです。

最初に、署名・transaction・approvalを別のものとして確認します。その後でmethod、origin、account、chain、contract、権限、nonce、期限を一つのrequestへ対応させます。一つでも説明できなければ署名せず、画面を閉じて自分で開いた公式siteへ戻ってください。

この記事で掲載するwallet画面はMetaMask公式docsのサンプルです。個人account、3MIKANのwallet、実資産は使わず、wallet接続、署名、transaction送信も行っていません。

署名・transaction・approvalは別の軸

用語	その場で作るもの	gas / broadcast	後から残り得るもの	例
署名	messageやstructured dataに対するsignerのproof	作成時は通常gasなし、chainへbroadcastしない	applicationが署名を提出・検証した後のsession、order、allowanceなど	personal_sign、EIP-712、SIWE、Permit
transaction	chainへ送るexecution requestへの署名	broadcast後、実行条件を満たせばgasとreceiptが発生	transfer、contract state、event、delegationなど	transfer、swap、approve、EIP-7702 type-4 transaction
approval	spenderへtoken使用権限を与えるという結果	approve transactionでもPermit署名でも作れる	token contractやPermit2に保存されたallowance	ERC-20 approve、ERC-2612 Permit、Permit2 AllowanceTransfer

「署名かtransactionか」はrequestの形、「approvalか」は権限のeffectです。したがって「署名だからapprovalではない」「gasが0だから資産へ影響しない」という判断はできません。

突然開いたら、まず止まる条件

次のどれかに当てはまる場合は、ConfirmやSignを押しません。

• 自分が始めていない操作で、request元のbrowser originを説明できない
• methodが不明、raw hashやbinaryだけで内容を読めない
• 選択中accountまたはchainが期待と違う
• contract、token、spender、delegateのaddressを公式情報と照合できない
• amountが空、不自然に大きい、unlimited、または単位を確認できない
• nonce、deadline、permission expirationがなく、再利用範囲を説明できない
• 「取消」「本人確認」「復旧」のためにseed phraseやprivate keyの入力を求められる

seed phraseとprivate keyは、署名を取り消すためにもsupportへ本人確認するためにも入力しません。検索広告やDMのlinkを使わず、自分でbookmarkまたは公式domainからsupportへ戻ります。

署名前に書き出す9項目

Issueの7項目に、request元と署名accountを加えた9項目を確認します。

項目	画面・requestで確認する値	不明なら何をするか
method / 目的	personal_sign、eth_signTypedData_v4、SIWE、Permit、EIP-7702など。loginか権限付与か	dappの説明ではなくrequest JSONやwallet表示を確認。raw / unknownなら拒否
origin / domain	browser origin、Request from、signed domain、URI	文字列の一部一致で済ませず、scheme・host・portを照合
account	署名するaddress、owner、authority	複数accountを切り替えた直後は特に確認
chain	chain ID、network	名前だけでなくchain IDを見る。0など広い適用範囲も確認
contract	verifyingContract、token、Permit2、delegate address	公式docs・explorerのverified source・deployment情報へ戻る
spender / delegate	資産を使うaddress、codeを委任するaddress	frontend名ではなくaddressとcodeの役割を確認
amount	token、decimals、数量、上限、recipient / witness	unlimitedや単位不明なら署名しない
nonce	message、token、Permit2、authorityのnonce	どこで消費され、再利用を何が止めるか確認
deadline	署名提出期限、権限期限、session期限	deadlineとexpirationを同じものとして扱わない

7形式を同じ表で分ける

形式	署名時のon-chain state / gas	主な用途と後続effect	replay・期限の境界	最低限見るfield
eth_sign	通常は署名だけ。wallet・client実装差が大きい	opaqueなdataやhashへの署名として扱われ得る	request自体に共通のnonce / deadline規則はない	method、payloadの意味、origin、account、wallet実装
personal_sign / ERC-191	署名だけ	人が読むmessage、login challenge、application独自authorization	messageへnonce・期限・domainを入れない限り共通規則はない	origin、account、message全文、domain、nonce、期限
EIP-712	typed dataへの署名だけ	order、permit、protocol actionなどを構造化	EIP-712自体はreplay protectionを提供しない	domain、chainId、verifyingContract、primaryType、message全文
SIWE / ERC-4361	ERC-191 messageへの署名だけ	server検証後にweb sessionを作る	domain、URI、chain ID、single-use nonce、issued / expiration time	Request from、domain、URI、account、chain ID、nonce、時刻
ERC-2612 Permit	signerはgasなし。第三者が提出可能	token contractのallowanceを設定	token nonceとdeadline	token / verifyingContract、owner、spender、value、nonce、deadline
Permit2	signerはgasなし。提出後に権限またはtransfer	AllowanceTransferまたはSignatureTransfer。token→Permit2 approvalは別層	ordered / unordered nonce、sigDeadline、allowance expirationなど方式別	Permit2、token、spender、amount、nonce、各期限、recipient / witness
EIP-7702 authorization	authorization単体ではなくtype-4 transactionの処理で反映	authority EOAへdelegate codeの実行入口を設定	authority nonce、chain ID、外側transaction。storage等は別に残る	authority、chain ID、delegate、nonce、外側transactionとcaller制約

公開検証データには、この7形式の検証用fieldとunsigned digestを保存しています。viem 2.56.0でローカル計算し、wallet、秘密鍵、署名、external RPC、contract call、transactionは使っていません。digest一致はencodingの再現にすぎず、origin、UI表示、contractの安全性、replay防止、同意を証明しません。

eth_signはmethod名だけで意味を決めない

MetaMaskのMIP-3は、同walletの従来のeth_signを任意hashのblind signingにつながるmethodとして廃止対象にし、現在の公式sign-data guideもdeprecatedとしています。一方、Ethereum.orgのnode JSON-RPC説明は同名methodにEthereum Signed Message prefixを記載しています。

この差があるため、eth_signをwallet横断で一つのdigest式や一つの表示へ一般化しません。request元、client、version、payload解釈を独立して確認できず、raw hashしか見えないなら拒否するのが安全側です。「loginのため」「gasはかからない」というdapp側の説明だけで押さないでください。

personal_signは読めるmessageでも作用を確認する

ERC-191はsigned dataの先頭を0x19で区別し、version 0x45をEthereum Signed Message形式へ割り当てます。MetaMaskの公式guideはpersonal_signをhuman-readable messageに使い、binary dataを表示させないよう案内しています。

ただし、読める文章なら無害という意味ではありません。次のような文面は、署名後にapplicationがauthorizationとして解釈できます。

• login challengeとしてserver sessionを発行する
• 規約・order・claimへ同意したproofとして保存する
• domainやnonceのない文章を別site・別時点で再利用する

message全文、request origin、署名accountを読み、domain、purpose、nonce、issued time、expirationが必要な用途なら本文へ入っているか確認します。見慣れた挨拶文でも、末尾や折りたたみ範囲を省略しません。

EIP-712は構造化するが安全を保証しない

EIP-712はdomain、types、primaryType、messageを分け、walletがfieldを構造化表示できるようにします。domain separatorには通常、name、version、chain ID、verifying contractが入ります。

ここで確認するのは見た目ではなく値です。

1. browserのrequest originと、walletのRequest from
2. 選択中networkとdomainのchainId
3. verifyingContractと公式deployment address
4. primaryTypeが示すaction
5. spender、delegate、recipient、token、amountを含むmessage全文
6. nonce、deadline、application側のused state

EIP-712 specificationは、同形式自体がreplay protectionを含まないと明記しています。domain separationが正しくても、applicationがnonceやused stateを検証しなければ再利用を止められません。詳しいdigest構造はEIP-712のdomain・nonce・deadlineを照合する記事で確認できます。

walletが表示したcontract名やsite名だけでなく、addressを最後まで照合します。security alertが出ないこと、requestがtyped dataであること、primary typeが見慣れていることは安全保証になりません。

SIWEはlogin用でもdomain・nonceを確認する

SIWE（Sign-In with Ethereum）はERC-4361のmessageをERC-191形式で署名し、serverが検証してweb authenticationへ使う規則です。token approvalそのものではありませんが、成功後に作られるsessionが何を操作できるかはapplicationのauthorization設計に依存します。

最低限、次を同じlogin requestへ対応させます。

• browser origin、message先頭のdomain、URI
• account、chain ID
• serverが今回だけ発行したnonce
• Issued At、Expiration Time、必要ならNot Before
• statementとresourcesがlogin以外の同意を混ぜていないか

MetaMask公式docsはSIWEを専用UIへ解析し、requesting siteとmessage domainが違う場合に警告する例を掲載しています。ただし利用者が明示的にoverrideできるため、警告機能だけに任せず、自分でdomainとURLを照合します。server側のnonce消費、session、CSRF対策はSIWEをnonceからsessionまで安全に実装する記事で分けています。

PermitとPermit2はgasなしでtoken権限になり得る

ERC-2612 PermitはEIP-712を使い、owner、spender、value、nonce、deadlineへ署名します。署名者がtransaction gasを払わなくても、仕様上は任意のcallerが有効な署名をtoken contractへ提出でき、allowanceとnonceが更新されます。

署名前にtoken contract、chain ID、owner、spender、value、nonce、deadlineを読みます。token名やsymbolは重複できるため、verifyingContractのaddressを公式deploymentと照合してください。

Permit2ではさらに層を分けます。

1. token contractからPermit2 contractへのERC-20 approval
2. Permit2内で特定spenderへ与えるdownstream permission、または1回のSignatureTransfer

AllowanceTransferではamount、expiration、ordered nonce、spender、sigDeadlineを分けます。SignatureTransferはpersistentなdownstream allowanceを残さない方式ですが、recipient、requested amount、unordered nonce、deadline、witnessなどのmessage内容を確認する必要があります。「Permit2だからone-time」「署名1回だからunlimitedではない」と決めつけません。

通常のERC-20 approvalを確認する入口はtoken approvalを安全に確認する記事、Permit / Permit2のstate保存先と期限は4方式のtoken権限を比較する記事に分けています。

EIP-7702 delegationはtyped dataとは別に読む

EIP-7702のauthorization tupleは、chain_id、delegate address、authority nonceとsignatureを含みます。署名対象hashは0x05 || rlp([chain_id, address, nonce])から作られ、EIP-712 typed dataではありません。有効なauthorizationがtype-4 transactionで処理されると、authority accountのcodeへdelegation indicatorが設定されます。

確認項目は次のとおりです。

• authorityが意図したEOAか
• chain_idが対象chainか。0なら複数chainへ適用できる範囲を理解したか
• delegate addressの現在code、verified source、proxy / upgrade権限
• authority nonceと、外側transactionのsender・call内容
• delegateが実行できるcall、session key、module、allowanceの範囲

delegationを後からclearしても、EOA storage、ERC-20 allowance、外部registry、session stateまで同時に消えるわけではありません。設定・差し替え・clear後の残存stateはEIP-7702 delegation lifecycleの記事で確認してください。

wallet画面に見えても、見えなくても確認する

2026-08-31にMetaMask公式docsのサンプルを確認した範囲では、typed data画面にNetwork、Request from、Interacting with、Primary type、Message、SIWE画面にURL、Chain ID、Nonce、Issuedなどが表示されます。元画像、取得URL、SHA-256、寸法、derived WebP、確認条件は制作時の検証記録にまとめています。

これはMetaMaskの公式サンプル表示を確認した証拠であり、すべてのwallet、version、locale、account type、Snap、security settingで同じ表示になる証拠ではありません。また、画面だけでは次を証明できません。

• browser extension自体やrequesting siteが改ざんされていないこと
• verifying contractやdelegate codeが安全で、将来upgradeされないこと
• nonceが未使用で、applicationが正しく消費すること
• spenderが署名後にどのtransactionを提出すること
• SIWE serverが適切なsessionとauthorizationを発行すること

walletの表示を第一の停止点にしつつ、contract address、official deployment、code、applicationの効果まで別に確認します。

署名後に不安になった時の順番

1. 署名を公開せず、request情報を保存する

origin、時刻、wallet / version、method、account、chain ID、messageまたはtyped data JSON、contract、spender / delegate、amount、nonce、deadline、画面captureを保存します。raw signatureそのものは、第三者が提出できる可能性があるためSNSや公開issueへ貼りません。

2. methodごとに残るstateを確認する

署名	確認先	停止・失効の考え方
SIWE / login	applicationのactive session、login履歴	公式siteからlogout・全session失効。元署名を一般に「revoke」できるとは限らない
order / typed action	applicationとverifying contractのnonce・cancel機能	protocol固有のcancelまたはnonce invalidationを一次情報で確認
ERC-2612 Permit	token allowance、nonce、deadline	提出済みならallowanceをrevoke / replace。未提出署名の失効方法はtoken実装ごとに確認
Permit2	token→Permit2 allowanceとPermit2 downstream state	2層を別々に確認し、公式手順でrevoke / nonce invalidationを行う
EIP-7702	account code、delegate、storage、allowance、session / module	delegationのreplace / clearだけで終わらせず、残存stateを保存先ごとに停止

disconnectはwebsiteからaccount接続を外す操作で、on-chain allowance、提出可能なPermit、delegation、server sessionを一括削除しません。

接続permission、SIWE session、ERC-20 / Permit2、session key / module、EIP-7702 delegationを保存場所・確認方法・失効transactionへ分ける手順は、DAppを切断しても残る権限の確認ガイドにまとめています。

Safeのproposalへ署名した場合は、wallet promptの確認に加えて、そのsignatureがどのSafe transaction hashとSafe nonceへ対応するかを保存します。Safeの取引が進まない時の確認手順で、off-chain confirmations、2-of-3 threshold、同一nonce競合、別のEthereum execution transactionを分けて確認できます。

3. on-chain effectとofficial incident情報を確認する

自分で開いたblock explorerでaddress、token allowance、transaction、eventを確認します。walletやprotocolの公式security channelにincident情報があるかを、bookmarkまたは公式siteから辿ります。検索結果の電話番号、DMを送ってくるsupport、remote-control app、seed phrase入力案内は使いません。

4. 秘密情報を渡さない

署名の取消、wallet同期、資産保護、本人確認を理由にしても、seed phrase、private key、keystore passwordを入力・送信しません。すでに入力した場合は、単なる署名問題ではなくwallet compromiseとして、信頼できる別端末・別walletを含む緊急対応へ切り替えます。

最終チェックリスト

• signature、transaction、approvalのどれを見ているか分けた
• methodと目的をrequest側で確認した
• browser origin、walletのRequest from、signed domain / URIを照合した
• accountとchain IDが意図どおりだった
• verifying contract、token、Permit2、spender、delegateをaddressで照合した
• amount、token decimals、上限、recipient / witnessを確認した
• nonce、deadline、permission expiration、used stateの役割を分けた
• 署名後のsession、allowance、order、delegationというeffectを説明できた
• 一つでも不明なら署名せず、自分で開いた公式siteへ戻った
• seed phrase・private key・raw signatureをsupportや公開投稿へ渡していない

wallet署名の安全確認は、method、origin / domain、account、chain、contract、spender / delegate、amount、nonce、deadline、後続effectを同じrequestへ対応させ、一つでも説明できなければ署名しないことです。

この記事にはwallet install、swap、取引所、signature、approvalを促すaffiliate CTAを置いていません。形式や製品の推奨ではなく、署名を止めて確認する順序を提供しています。