トークンのApproval、Allowance、Permit：実際に何に署名しているのか

トークン承認（approval）とは、ERC-20トークンコントラクトの内部に保存されるオンチェーンの許可——allowance——であり、特定のコントラクトが、あなたのトークンを特定の量まで、後からいつでも、再度あなたに尋ねることなく使ってよい、と記録するものです。これはapprove()トランザクションによって作られ、それを与えたときのやり取りよりも長く生き続けます。ウェブサイトは消えても、allowanceは残るのです。Permit（EIP-2612）はその別建てのトランザクションを、dAppが自身のアクションと一緒に提出するオフチェーン署名に置き換えます。Permit2は、EIP-2612を一度も実装しなかったトークンにも、同じ期限付き・金額限定のモデルを広げます——つまり、いまや署名ひとつが支出権限を手渡しうるということであり、署名リクエストはかつて承認が受けていたのと同じ厳しさで精査されるべきです。防御策は地味です。無制限ではなく限定額を承認すること、そして使わなくなったallowanceを取り消すこと。WATSのような完全にノンカストディアルなウォレットでは——鍵を持つのはあなたで、WATSが鍵を持つことは決してありません——承認もPermit署名も取り消しも、あなた自身の鍵が署名しない限り起こりません。しかもネットワーク手数料はひとつのトークンATSで課金されるため、そのチェーンのネイティブガストークンがないという理由で掃除のトランザクションが先送りになることもありません。

dAppはなぜ承認を求めるのか

ERC-20トークンには、Web3のUXの半分を形作っている特性があります。スマートコントラクトは、たとえあなたが望んでいても、あなたのアドレスからトークンを勝手に取ることができないのです。あなたのUSDCをスワップするDEXは、まず明示的な許可を必要とします。だからこそ多くの操作が2段階になります——まずapproveトランザクション、それから実際のスワップや入金です。承認は形式的なものではありません。恒常的な支出権限の付与であり、それを与えたトランザクションよりも長く生き続けます。

approve()が実際に与えるもの

承認に署名すると、トークンコントラクトはallowanceを記録します。アドレスX（dAppのコントラクト）は、そのallowanceが使い切られるか、引き下げられるか、取り消されるまで、いつでもあなたのトークンを最大N個まで使えるという記録です。重要な性質は2つ。第一に、allowanceはトークンコントラクトの中に存在し、与えられるのはあなたが承認したコントラクトであって、訪れたウェブサイトではありません——UIが消えても許可は残ります。第二に、支出の瞬間にあなたの関与は一切不要です。一度付与されれば、承認されたコントラクトは、あなたの追加署名なしに、その後のどのトランザクションでもトークンを引き出せます。それこそが承認を便利にしているものであり——そのまま攻撃面にしているものでもあります。

無制限承認：便利さと、恒久的なリスク

承認のたびにガスがかかるため、多くのdAppは二度と承認せずに済むよう、事実上無制限のallowanceを要求します。便利さは本物ですが、引き換えも本物です。あるコントラクトへの無制限のallowanceは、そのトークンの全残高が永遠にそのコントラクトのセキュリティに依存することを意味します。コントラクトが何年も後に悪用されたら——あるいは最初から悪意あるものだったら——攻撃者にあなたの鍵も署名も必要ありません。あなたが与えたallowanceで十分なのです。最大級のウォレット・ドレイン事件の多くは鍵の窃取ではなく、古い承認の換金でした。

PermitとPermit2：署名による承認

現代的な改良がPermit（EIP-2612）です。オンチェーンのapproveトランザクションの代わりに、dAppが自身のアクションと一緒に提出するオフチェーンのメッセージに署名します——2回のトランザクションが1回に、承認用の別途ガスは不要、しかも許可には期限を設定できます。Permit2はこの考え方をEIP-2612を実装していないトークンにも一般化し、共有の承認ハブとして機能します。まずPermit2コントラクト自体に通常のオンチェーン承認を1回だけ行い、以後は各dAppが、それぞれの金額と有効期限を持つ署名によって認可される、という仕組みです。この取引条件は正確に押さえておく価値があります——Permit2は承認を廃止するのではなく、一箇所に集約します。したがって、Permit2に与えた恒常的なallowance自体が、管理し続けるべき承認なのです。これらは本物の改善ですが、何が変わったかに注意してください。かつてトランザクションが担っていた仕事を、いまや署名が担っています。誤ったPermitメッセージに署名させるフィッシングサイトは、悪意ある承認と同じ結果を得ます——だからこそ署名する内容を読むことが、これまで以上に重要なのです。

攻撃面：ドレイナーと放置されたallowance

承認の悪用には2種類あります。能動型：ドレイナーサイトが本物のdAppになりすまし、「クレーム」や「ウォレット認証」といった無害そうな操作を装って承認（またはPermit署名）を要求します。受動型：何年も前に正当なコントラクトへ与えたallowanceが、そのコントラクトや管理者キー、アップグレード経路が侵害されるまで眠り続けます。どちらも、接続して承認するフローをWeb3のセキュリティ上最も重要な瞬間として扱うべき理由です——安全なやり方はウォレットをdAppに安全に接続する方法で解説しています。

実際に効く承認の衛生習慣

3つの習慣でリスクの大半をカバーできます。dAppが許すなら、特に大きな残高では限定額を承認する——後で追加の承認をするのは安い保険です。信頼できる承認チェッカーで定期的にallowanceを確認・取り消しし、もう使わないものは除去すべき死荷重として扱う——取り消しとは、allowanceをゼロに戻すそれ自体がオンチェーンのトランザクションなので、他と同じようにガスがかかり、あなたの署名を必要とします。そして本気の資産は、承認に一切署名しないアドレスに、アクティブなdApp用ウォレットと分けて保管する。より多層的な習慣はウォレットセキュリティのベストプラクティスにあります。

WATSの位置づけ

承認とは署名であり、署名はウォレットの領分です。WATSは完全にノンカストディアルです——鍵を持つのはあなたで、WATSが鍵を持つことは決してありません——だからすべての承認、Permit署名、取り消しは、Chrome拡張機能、モバイルアプリ、あるいはHot Walletから、Ethereum、Arbitrum、Optimism、Base、Polygon、BNB Chain、Solana、TONを横断して、あなたの鍵が署名したときにのみ実行されます。それは同時に、どんなウォレットにもできることの正直な限界も示しています。ウォレットはリクエストを表示できますが、その支出者と金額が本当にあなたの意図したものかを判断できるのは、あなただけです。

手数料の側は、古いallowanceを放置するもうひとつのよくある言い訳を取り除きます。WATSでは、承認や取り消しのトランザクションを含むすべての操作が、各チェーンのネイティブガストークンではなく、ひとつのトークンATSで課金されます——EVMではERC-4337ペイマスター、SolanaとTONでは同等のフィーペイヤー／リレイヤーを通じて。これは割引ではありません。ネットワークには支払われるべきものが支払われ、原価も変わりません。変わるのは、どのトークンで支払うかだけです。徴収されたATSは1億の供給量から3,000万のフロアに向かってバーンされ、ATSはLayerZeroのOFTなので、ひとつの残高がサポート対象のすべてのチェーンをカバーします。WATSは、ERC-4337とOFTによる単一トークン手数料をこのバーンと組み合わせた最初で唯一のウォレットです——詳細はATS手数料ページへ。

つまり、この記事の実践版は短いルーティンです。限定額の承認を優先する。Permit署名が実際に何を認可するのかを、署名する前に読む。そして四半期に一度、承認チェッカーを開いて、もう使わない支出者を一掃する。具体的な一歩は、そのルーティンを、あなたと鍵のあいだに決して割り込まないウォレットから実行することです。WATSのHot Wallet、Chrome拡張機能、モバイルアプリでは、すべての承認とすべての取り消しは、あなた自身の鍵が署名したからこそ存在します——WATSが鍵を持つことは決してありません——そして取り消しの費用は、そのチェーンがたまたま要求するネイティブガストークンではなく、ATSで支払われます。