DAppを切断しても権限は消えない？approval・session key・delegationの解除を比較

DAppの画面で「Disconnect」を押しても、tokenのallowance、serverのlogin session、smart accountのmodule、EIP-7702 delegationまで一括で消えるとは限りません。これらは保存場所も、読む方法も、失効に必要な操作も別だからです。

最初に確認するのは、ボタンの表示ではなく、どのchain・account・origin・contractに、どの権限層が残っているかです。緊急時に未知のrevoke siteへ接続したり、検索結果やDMから追加署名を求められたりしても応じません。この記事の確認途中には広告やaffiliate CTAを置いていません。

先に固定する値

操作を増やす前に、調査メモへ次を保存します。

• wallet名とversion、browser profile、site origin
• account address、chain ID、確認block、RPCまたはExplorer
• token、Permit2、smart account、module、delegate implementationのaddress
• 元のapproval・module追加・delegation設定transactionが分かる場合はtx hash
• disconnect、logout、revoke、module削除、delegation変更を行った時刻

同じaddress文字列でもchainが違えば別stateです。walletのaccount permissionはorigin単位、web sessionはdomain・cookie・server単位、allowanceはtoken contractとowner / spender単位で確認します。addressやchainが固定できない状態でwrite操作へ進みません。

「接続」は六つの層に分ける

以下は「切断」という一語を、保存場所・read-only確認・失効方法・transaction要否へ分解した比較です。walletやaccount実装によってmethod名は変わるため、対象versionの公式手順を優先します。

walletのsite permissionはaccount公開範囲の管理

EIP-2255は、originからwallet permissionを要求・取得するinterfaceを定義します。MetaMaskではwallet_getPermissionsで現在originへ許可されたpermissionを取得でき、browser extensionではwallet_revokePermissionsで現在originのpermissionを一件ずつ取り消せます。これはwallet固有の対応状況を確認して使うmethodで、全walletに同じAPIがあるとは限りません。

connected siteを外すと、そのsiteからaccountへアクセスするpermissionは止められます。しかし、過去に送信済みのtransactionを巻き戻したり、token contractのallowanceを更新したりはしません。token approvalを確認・解除する基礎手順でも、connectionとon-chain approvalを別に扱っています。

確認後は、walletのconnected sites一覧を再読み込みし、対象originとaccountが消えたことを確認します。browser profileやwallet instanceが複数ある場合は、操作したinstanceを記録します。

SIWEの署名とlogin sessionは別

ERC-4361のSign-In with Ethereumは、addressでoff-chain authenticationを行うmessage形式です。署名検証後にcookieやserver sessionをどう作り、いつinvalidにするかはservice側の実装です。walletをdisconnectしても、すでに作成されたserver sessionが自動logoutされる保証はありません。

siteの公式logoutを行い、認証済みendpointが未認証へ変わったこと、session一覧がある場合は対象deviceが消えたこと、cookieやtokenのexpiryが想定どおりであることを確認します。署名messageのdomain、URI、chain ID、nonce、issued-at、expiration-timeを読む方法はSIWEのdomain・nonce・sessionを確認する手順を参照してください。

logout後もserver側sessionが有効なら、wallet permissionではなくserviceのsession invalidation問題としてsupportへ渡します。seed phraseやprivate keyをsupportへ送る必要はありません。

ERC-20 approvalはtoken contractのstate

ERC-20のapprove(spender, value)は、token contractにownerとspenderのallowanceを保存します。allowance(owner, spender)で現在値をread-only確認でき、spenderは範囲内でtransferFromを呼べます。siteのconnectionを外してもこのmappingは変わりません。

解除する場合はchain、token contract、owner、spenderを再確認し、対象token contractでallowanceを0へ更新します。walletやExplorerの「Revoke」ラベルではなく、送信先が正しいtoken contractで、calldataのspenderとvalueが意図どおりか確認します。token実装やUIによって操作手順が異なるため、公式walletまたはprotocolの案内へ戻ります。

mining後は次を一件の証拠として保存します。

1. transaction hash、chain ID、block number
2. receiptのstatusと実際のto
3. Approval logのowner、spender、value
4. confirmation後のallowance(owner, spender)

receiptが成功でも、別token・別spenderを更新していれば目的の権限は残ります。最後のreadが0になったかを確認します。

permitとPermit2は署名・nonce・allowanceを分ける

ERC-2612のpermit署名は、作成しただけではchain stateを変えません。第三者が期限内に正しいnonceでtransactionへ載せ、permitが成功するとallowanceが更新され、ownerのnonceが1進みます。未使用署名をwallet disconnectだけで無効化する標準methodはありません。期限、現在nonce、spender、value、対象tokenを確認し、そのtoken実装の公式手順に従います。

Permit2は二つの経路を持ちます。

• AllowanceTransfer: tokenからPermit2 contractへのapprovalと、Permit2内のtoken・spender別allowance、amount、expiration、nonceを分ける
• SignatureTransfer: signature nonceを使う一回限りのtransfer permission。未使用nonceのinvalidation方法は公式実装で確認する

Permit2内のspender allowanceだけを0にしても、token→Permit2 contractのERC-20 allowanceが別に残る場合があります。反対に、token→Permit2 approvalを変えても、保存済みPermit2 recordの意味を調べずに「すべて失効」と断定しません。ERC-20・permit・Permit2の権限境界で、署名時点とon-chain反映時点をさらに分けています。

smart accountのsession key・moduleは実装固有

session keyは一つの共通規格名ではありません。key address、validity period、target、selector、spending limitなどがsmart account本体、validator、module、policy contractのいずれかへ保存されます。まずaccount implementationとversionを固定し、公式sourceやdocsから正しいgetterとdisable経路を特定します。

Safeのmoduleはaccount内のregistryで有効化され、module経路からtransactionを実行できます。通常のowner transactionとは別のauthorization pathになり得るため、wallet siteをdisconnectしただけでは無効になりません。module address、code、enabled state、guardやpolicy、追加transactionを確認し、削除はowner-authorized transactionとして扱います。

解除後は、disable/remove transactionのreceiptとeventだけでなく、同じblock以後のgetterやmodule paginationで対象addressが無効になったことを確認します。session keyならkeyのenabled flag、validity、permission recordを再読します。UIから行が消えただけではchain stateの証拠にしません。

EIP-7702 delegationはEOAのcode state

EIP-7702では、authority EOAのcodeが0xef0100 || addressという23-byte delegation indicatorになり、呼び出し時に指定implementationのcodeがEOA contextで実行されます。validなauthorizationが処理されるとdelegationはtransaction実行結果とは独立してpersistentです。siteをdisconnectしてもeth_getCodeは変わりません。

解除は、authorityがzero addressをtargetにしたauthorizationをtype 0x04 transactionへ含め、delegation indicatorをclearする手順です。別implementationへのchangeはclearではありません。chain ID、authority、authorization nonce、delegate address、carrier transactionを確認し、対象walletが公式に対応する方法だけを使います。

clear後はconfirmation済みblockでeth_getCode(authority)を再取得します。ただし、delegationをclearしてもEOA storage、token allowance、session key record、server sessionは同時には消えません。EIP-7702のset・change・clearとstorage lifecycleで、delegation codeとEOA側stateが独立して残るlocal再現を確認できます。

ローカル環境でdisconnect後の残存を再現

Foundryのローカルchainを使い、外部RPC・wallet・実資産へ触れずに、chain ID 31337で次を再現しました。

local phase	site connection	token allowance	session key / module	EIP-7702 code
setup完了	connected	250	enabled	delegate A
disconnect直後	disconnected	250	enabled	delegate A
allowance revoke後	disconnected	0	enabled	delegate A
session/module disable後	disconnected	0	disabled	delegate A
delegation clear後	disconnected	0	disabled	empty

このローカル再現では、disconnectはoff-chainの接続状態だけをfalseへ変えます。その直後もtoken contractのallowance、authority EOAのstorageにあるsession key・module flag、authority codeのdelegation indicatorが残りました。その後、各layerの明示的なstate changeだけが対応stateを変え、他layerを自動変更しないことも確認しました。

公開検証JSONには、使用した架空address、各phaseの期待state、read方法、失効後の確認項目を掲載しています。公開key、real wallet、remote RPC、署名prompt、資産移動は使っていません。

解除後はreceiptとstateを組にする

権限ごとに次の順を繰り返します。

1. chain、account、origin、contract、spenderまたはdelegateを固定する
2. write前のstateをread-onlyで保存する
3. 対象実装の公式手順で一つのlayerだけ失効する
4. transactionならhash、receipt、event、confirmation blockを保存する。logoutならresponseとsession再確認を保存する
5. 同じ保存先をもう一度readし、期待する値へ変わったことを確認する
6. 他layerも再読し、残存permissionを次の調査対象へ回す

判断基準は、disconnectの完了表示ではなく、各権限層の保存先をread-onlyで再確認することです。複数のrevokeをまとめて送る前に、どの操作がどのstateを変えるかを一行ずつ対応させます。

署名要求が出たときの停止条件

revoke、disable、clearという名称でもtransactionやtyped-data signatureを要求する場合があります。次に該当すれば署名せず停止します。

• chain、verifying contract、token、spender、delegate、moduleが記録した値と違う
• unlimited amount、未知のbatch、delegatecall、module追加など解除と逆方向の権限が含まれる
• 公式domainやwallet内導線ではなく、検索広告、DM、remote supportから開いた
• seed phrase、private key、screen sharing、remote access、先払いを要求される
• transactionのシミュレーションとcalldataの意味を説明できない

typed dataのdomain、chain ID、contract、nonce、deadline、spenderを読む手順は危険な署名要求を見分ける確認項目を参照してください。実際の不正送金やseed侵害が疑われる場合は、revokeだけで解決すると判断せず、追加署名を止めて証拠を保存し、wallet・protocol・取引所の公式窓口へ相談します。

確認checklist

• walletのorigin別site permissionを確認した
• siteのlogout後にserver sessionを再確認した
• token contractごとにowner・spender・allowanceを読んだ
• permit / Permit2のnonce、expiration、amount、二段階のallowanceを分けた
• smart account implementation、module、session key、policyを特定した
• EIP-7702 authorityのcode、delegate、nonce、storageを確認した
• state-changing操作の前後でchain・address・blockを保存した
• receipt・eventだけでなく対象stateを再読した
• seed phraseやprivate keyを入力・共有していない
• 残る別layerを「disconnect済み」という表示だけで安全と判断していない

切断、logout、allowance revoke、permit invalidation、module disable、delegation clearは、それぞれ別の操作です。一つのボタンへ期待を集めず、保存場所ごとに「読む→一つだけ失効→同じ場所を再読する」を繰り返してください。