約24分で読めます

Magic Eden旧EVM利用者向け|残存承認の確認・取り消し手順

Magic Eden旧EVM利用者向け|残存承認の確認・取り消し手順
この記事の目次 10章

2024年2〜10月ごろにMagic Edenの旧EVM市場でNFTを出品・売買した可能性がある人は、まず署名不要の確認をしてください。対象は主にEthereum、Polygon、Baseです。サイト終了、出品取消、ウォレットの接続解除だけでは、ブロックチェーン上のNFT移転承認は消えません。

30秒で対象判定と対応の流れを確認

  • 対象候補:2024年2〜10月ごろ、Magic Eden旧EVM市場を使ったウォレットがある
  • 確認チェーン:Ethereum、Polygon、Baseを一つずつ確認する
  • 最初の操作:承認一覧を読み取るだけ。確認だけなら署名もガス代も不要
  • true/有効なら:Payment Processor V2への承認を取り消すオンチェーン取引を送る
  • 必要な残高:各チェーンのガス代用ネイティブ通貨。取消後はfalse/無効を再確認する

旧V2の承認先(operator)は、Limit Break公式のデプロイ一覧に掲載された0x9A1D00bEd7CD04BCDA516d721A596eb22Aac6834です。同資料ではEthereum、Base、Polygonを含む対応チェーンに同じV2アドレスが示されています。アドレスは省略表示でなく、コピー後に完全一致を確認してください。

チェーン旧V2 operator公式・検証入口
Ethereum0x9A1D00bEd7CD04BCDA516d721A596eb22Aac6834Limit Break公式デプロイ一覧/Etherscan
Polygon0x9A1D00bEd7CD04BCDA516d721A596eb22Aac6834Limit Break公式デプロイ一覧/PolygonScan
Base0x9A1D00bEd7CD04BCDA516d721A596eb22Aac6834Limit Break公式デプロイ一覧/BaseScan

注意:operatorは承認を受ける旧V2コントラクト、NFTコントラクトは各コレクションの契約アドレスです。NFTコントラクトは保有コレクションごとに異なるため、固定の一件を記事に載せることはできません。承認管理画面に表示されたコレクションを開き、公式コレクション情報とエクスプローラーで照合します。

この記事でいうEVMはEthereumと互換性のある実行環境、ownerはNFTを持つ「所有者アドレス」、operatorはNFTを動かせる「承認先アドレス」です。nonceは取引や注文を識別・無効化するための番号、tokenIdはコレクション内の個別NFT番号、ガス代は状態変更取引のネットワーク手数料を指します。

報道時点では2万3155点、570万ドル超相当のNFTがホワイトハットによって保護目的で退避されたとされています。これは保護時点の推定評価額で、全額が盗難・売却されたという確定損失ではありません。本稿はウォレット権限の安全対策を扱い、投資や特定サービスの利用を勧めるものではありません。

Magic Eden旧EVM市場で何が起きたのか

Magic Edenの旧EVM市場では、Limit Breakの取引プロトコル「Payment Processor V2」が使われていました。市場のフロント画面や注文受付が終了しても、利用者が過去にNFTコレクションへ設定したオペレーター承認は、別のオンチェーン状態として残り得ます。その残存承認が、古いコントラクトの問題と組み合わさり、保有NFTを動かせる経路になったことが今回の核心です。

対象は2024年2〜10月ごろの旧EVM市場利用者

The Blockが2026年9月25日に報じたMagic Edenの案内では、概ね2024年2月から10月に旧EVM市場で出品した利用者が確認対象とされています。案内された主要な確認先はEthereum、Polygon、Baseです。ここで大切なのは、「現在もMagic Edenを利用している人」ではなく、当時、対象チェーンで旧市場を使った可能性がある人という見方です。

記憶だけで対象外と決めず、当時使ったウォレットアドレス、チェーン、NFTコレクションを洗い出します。別ウォレットへ資産を移した場合でも、元のアドレスにNFTが再び入れば残存承認の影響を受ける可能性があるため、使用履歴のあるアドレス自体を確認するのが基本です。

2万3155点・570万ドル超は保護時点の推定評価額

報道された2万3155点、570万ドル超という数字は、ホワイトハットが危険にさらされたNFTを保護目的で移した規模です。「570万ドルの損失が確定した」「全NFTが売却された」と読むのは正確ではありません。NFTの評価額は価格算定方法や市場流動性でも変わるため、保護時点の推定値として扱う必要があります。

また、関連手法で660 WETHが危険にさらされ、退避が間に合わなかったとの報道もあります。これはNFTの保護件数・評価額とは別の話です。数字をまとめて一つの被害総額のように扱わず、資産の種類と状態を分けて理解してください。

V2とV3では緊急停止の可否が異なった

2026年9月25日のThe Blockなどの報道では、V3は停止された一方、V2には同様の停止機構がなく、承認取消や保護退避が焦点になったと整理されています。緊急停止はインシデント時の重要な防御層ですが、用意されていなければ後から管理画面を閉じるだけでコントラクトの実行可能性を消すことはできません。

市場が終了してもNFTの移転権限が消えない理由

まなぶ「サイトがなくなったなら、そこで渡した権限も一緒に消えるんじゃないんですか?」

クリプ「サイトの画面とブロックチェーン上の承認は別々なんだ。画面が閉じても、取消取引を送るまで承認が残る場合があるよ。」

NFT市場を使うとき、ブラウザ上では「接続」「出品」「署名」「承認」などが連続して見えます。しかし、技術的には同じ処理ではありません。ウェブサイトは操作の入口であり、承認状態はブロックチェーン上のNFTコントラクトが記録します。この管理場所の違いが、終了済みサービスの権限が残る理由です。

出品取消とオンチェーン承認の取消は別操作

出品は「この条件なら売る」という注文を表し、承認は「指定オペレーターがNFTを移転できる」という権限を表します。出品を取り消して買い手が注文を成立させられなくなっても、オペレーター承認まで自動でfalseになるとは限りません。注文一覧からNFTが消えたことだけを安全確認に使わないでください。

ウォレットの接続解除では権限を無効化できない

ウォレットの「接続済みサイト」から削除する操作は、そのウェブサイトがウォレットアドレスを読み取ったり、署名要求を表示したりする接続関係を切るものです。過去に成立したオンチェーン承認を書き換える操作ではありません。承認を変えるには通常、対象チェーンで取消取引を送信し、ブロックに取り込まれる必要があります。

注文署名を止めてもNFT承認が残る場合がある

EIP-712のような構造化データ署名は注文内容を人が確認しやすくする仕組みに使われますが、署名した注文とNFTコントラクトのオペレーター承認は別レイヤーです。注文のnonceを無効化したり、注文受付サーバーを止めたりしても、NFT側の承認状態を同時に変更しなければ残る場合があります。

setApprovalForAllが与える権限とリスク

まなぶ「“ForAll”って、ウォレットにあるNFT全部を一度に渡す意味ですか?」

クリプ「正確には、そのNFTコントラクトで自分が持つトークン全体への操作権限だよ。別コレクションまで一括で承認するわけではないんだ。」

setApprovalForAll(operator, true)は、NFT所有者が指定したオペレーターへ包括的な操作権限を与える関数です。市場は売買成立時にNFTを買い手へ移す必要があるため、この承認を求めることがあります。便利な反面、承認先が脆弱になったり想定外に操作されたりすると、個別の出品だけでなく対象範囲全体へ影響が広がり得ます。

ERC-721ではコレクション内の全NFTが対象になる

ERC-721の全件承認は、所有者とオペレーターの組み合わせで記録されます。承認されたオペレーターは、その所有者が同じERC-721コントラクトで保有するNFTを移転できる立場になります。ただし、ウォレット内のあらゆるNFTや暗号資産へ無制限にアクセスできるという意味ではありません。範囲は承認を記録したトークンコントラクト単位です。

個別NFTへの承認と全件承認も区別が必要です。個別承認は特定のtokenIdを対象にしますが、全件承認は当該コレクションで所有する複数NFTに及び得ます。確認画面で「すべてを承認」などと表示されたら、出品中の一点だけに限定された操作だと早合点しないことが重要です。

ERC-1155にも一括のオペレーター承認がある

ERC-1155は複数種類のトークンを一つのコントラクトで扱える標準で、ゲームアイテムなどにも利用されます。この標準にもオペレーターを一括承認する仕組みがあります。同じコントラクト内に複数のアイテムIDや複数数量が存在し得るため、承認範囲を画面上の一商品だけと誤解しないようにします。

承認には自動失効日がない

一般的なERC-721・ERC-1155の全件承認には、標準仕様上の自動失効日がありません。所有者がfalseへ変更する、別の移転によって所有者でなくなるなど、状態が変わらない限り残り得ます。長く使っていないdappほど、当時の承認先を忘れやすい点に注意が必要です。

「何年間使っていないから自然に切れているはず」という考え方は通用しません。承認状態は推測せず、チェーン上の現在値を照会して判断します。

署名なしで残存承認を確認する

三つの異なるブロックチェーン経路を、ウォレットから一つずつ虫眼鏡で調べる承認点検の立体イラスト
ウォレット、チェーン、NFTコントラクトの組み合わせごとに現在値を確認する。(AI生成によるイメージ)

確認対象を判断する軸は、利用時期、利用チェーン、ウォレットアドレス、旧V2コントラクトへの承認の四つです。いずれか一つの記憶だけで結論を出すのではなく、取引履歴と現在の承認状態を組み合わせて確認します。

旧EVM市場を利用した時期を確認する

まず、2024年2月から10月ごろにMagic Edenの旧EVM市場でNFTを出品・売買したかを振り返ります。ウォレットのトランザクション履歴、当時のメールやメモ、ブラウザ履歴などが手掛かりです。「売れなかった」「出品を取り消した」という場合も、承認操作をしていれば確認対象になり得ます。

Ethereum・Polygon・Baseをチェーン別に調べる

承認はチェーンごとに独立しています。Ethereumで取り消しても、PolygonやBaseの状態は自動で変わりません。同じ16進数のウォレットアドレスを使っていても、それぞれのネットワーク上に別の状態があります。対象チェーンはMagic Edenの案内を報じたThe BlockとDecryptがEthereum、Polygon、Baseとしています。operatorの文字列は上表のLimit Break公式デプロイ一覧とも照合してください。

承認管理画面で現在の状態を確かめる

  1. URLを手入力または公式ガイドから開き、Revoke.cashなどの承認管理画面に公開ウォレットアドレスを入力します。閲覧だけならウォレット接続は必須ではありません。
  2. ネットワークをEthereumにし、NFT承認の一覧を開きます。検索・絞り込みがあれば、上表のV2 operatorを完全な40桁の16進アドレスで照合します。
  3. Polygon、Baseへ切り替え、同じ確認を繰り返します。過去に複数ウォレットを使った人は、古い公開アドレスも同じ順で確認します。
  4. 表示された各NFTコレクションについて、有効な承認がなければ記録して終了、有効なら次章の取消へ進みます。

承認管理画面に何も出ない場合も、選択チェーンと入力アドレスを再確認してください。読み取り段階でシードフレーズ、秘密鍵、NFT送付を求めるページは正規の確認手順ではありません。

ERC-721やERC-1155では、isApprovedForAll(owner, operator)を使い、所有者が特定オペレーターを承認しているか照会できます。返り値がtrueなら承認中、falseなら全件承認は無効です。ここでowner、operator、NFTコントラクト、ネットワークのいずれかを間違えると、実態と異なる結果を見ることになります。

ブロックエクスプローラーの「Read Contract」や信頼できる承認確認サービスを使う方法があります。操作に慣れていない場合は、いきなり署名せず、まず読み取りだけで対象とアドレスを照合してください。読み取り照会には通常、状態変更のガス代は発生しません。

残っているNFT承認を安全に取り消す手順

NFTコレクションから旧オペレーターへ続く橙色の権限経路を切断し、盾付きスキャナーで解除を再確認する立体イラスト
対象を照合して権限経路を切り、取引成功後にfalseを読み直す。(AI生成によるイメージ)

まなぶ「“取消”ボタンを見つけたら、すぐ押せば安心ですか?」

クリプ「先にURL、チェーン、承認先アドレスを照合しよう。安全対策を装った偽サイトもあり得るから、署名内容まで確認してね。」

取消の基本は、正しい対象を特定し、対象ネットワークで承認をfalseにする取引を送り、完了後に再照会する流れです。具体的な画面名はウォレットやサービスの更新で変わるため、ボタン名を暗記するより、何を変更する取引なのかを理解することが大切です。

公式情報と完全なアドレスを照合する

検索広告やSNS返信のリンクから取消サイトへ入らず、Magic Eden、利用中のウォレット、ethereum.orgなど信頼できる公式導線を起点にします。確認するのは、NFTコントラクトのアドレス、承認先オペレーターのアドレス、チェーンです。名称やロゴは偽装できるため、文字列としてのアドレス照合が欠かせません。

trueなら取消取引を実行する

  1. 対象行の「Revoke」「取消」などのボタンを選び、ウォレットを接続します。
  2. ウォレット側でチェーン、呼び出し先NFTコントラクト、承認先operatorを確認します。
  3. 結果が旧V2 operatorへの承認を無効化する内容であることを確認し、ガス代を見て送信します。
  4. エクスプローラーでSuccessを確認し、同じ承認一覧を更新してfalse/無効/一覧から消えた状態を確かめます。

対象チェーンへ切り替え、承認管理画面またはNFTコントラクトの書き込み機能から取消取引を作成します。ERC-721・ERC-1155の全件承認なら、概念上は対象operatorに対するsetApprovalForAll(operator, false)です。ウォレット確認画面で、接続先ネットワーク、呼び出し先、関数やシミュレーション結果を確認します。

取消のために「新しい全件承認」を求められる、NFT送付を要求される、シードフレーズや秘密鍵の入力を求められる場合は中断してください。正規の取消取引にシードフレーズをウェブサイトへ入力する必要はありません。

ガス代とトランザクション完了を確認する

承認取消はチェーンの状態を書き換えるオンチェーン取引なので、通常は各ネットワークのネイティブ通貨によるガス代が必要です。残高不足や混雑で失敗した取引は取消完了になりません。ウォレットに表示された送信済みだけでなく、ブロックエクスプローラーで成功状態と対象アドレスを確認します。

取消後に承認状態を再照会する

取引成功後、同じNFTコントラクト、owner、operator、チェーンの組み合わせでisApprovedForAllを再照会します。falseになっていれば、その組み合わせの全件承認は解除されています。複数チェーン、複数ウォレット、複数コレクションがあれば、それぞれ確認が必要です。

承認取消で注意したい誤操作と影響

承認取消は有効な安全対策ですが、焦って偽サイトを使ったり、関係のない承認を一括で消して連携を止めたりする可能性があります。「全部消せば必ず安全」と単純化せず、対象を検証し、取消後の影響も理解して進めます。

取消を装うサイトで新しい署名をしない

事件発生時は、「緊急取消」「返還請求」を装ったフィッシングが現れやすくなります。URLの綴り、公式アカウントからの導線、コントラクトアドレスを複数の信頼できる情報で確認します。ウォレットの警告や取引シミュレーションで資産移転が示されたら、その意味を理解できるまで承認しないでください。

正当な出品やゲーム連携が止まる場合がある

承認を取り消すと、そのオペレーターを利用する正当な出品、ゲーム、レンタルなどもNFTを動かせなくなる場合があります。後で再利用するときは再承認とガス代が必要になることがあります。これは取消が失敗したのではなく、権限を無効化した結果です。

ホワイトハット保管を回収完了と断定しない

ホワイトハットへの保護移転は、攻撃者より先に資産を隔離する緊急対応です。しかし、元の所有者へ返還済みであること、返還条件が確定していること、保管中のあらゆるリスクが消えたことを自動的に意味しません。返還手順は関係者の公式案内を確認し、SNS上の非公式な「返還窓口」へ秘密情報を渡さないでください。

事業者向けの短い教訓

利用者向けの対応はここまでで完結です。事業者はサービス終了を画面停止だけで終えず、チェーン別のコントラクトと残存承認を棚卸しし、対象期間、検証済みアドレス、取消方法、返還窓口を継続して通知する必要があります。監視、緊急停止、保護資産の返還手順も終了計画に含めます。

また、署名画面では「このコレクション内の現在および将来保有するNFTを移転できる」のように結果を平易に示し、可能な範囲で権限を狭くします。期限付き・NFT単位の承認規格には提案段階のものもあり、既存の残存承認を自動で解消するものではありません。旧版から移行するときは、旧アドレスの取消案内を新バージョンの告知と分けて実施します。

事業者が細粒度承認を採用するときも、操作回数を増やせば自動的に安全になるわけではありません。利用者が毎回内容を読まずに承認するようになれば、確認疲れが新たな問題になります。高い影響を持つ承認だけを明確に区別し、通常操作と危険度の高い操作で表示や確認手順を変える設計が必要です。

さらに、コントラクトをアップグレードしただけでは旧版の承認は消えません。新しい市場へ移行した時点で、旧版のアドレス、残存承認の調査方法、取消期限を利用者に知らせ、移行後も一定期間は監視と問い合わせ対応を続けます。「新バージョンは安全」という説明と「旧バージョンへの承認を消す」という対応は別々に実施すべきです。

複数ウォレットは確認記録を残す

複数のウォレットやチェーンを使っていると、どこまで確認したか分からなくなりがちです。ウォレットの秘密情報ではなく、公開アドレス、確認日、チェーン、NFTコントラクト、operator、照会結果、取消取引ハッシュを表に残すと、抜け漏れを減らせます。取引ハッシュは公開情報ですが、アドレスとの紐づけを他人へ共有すると保有履歴を推測される可能性があるため、記録の公開範囲には注意します。

確認時点でfalseでも、後日同じサービスを利用して再承認すれば状態はtrueへ戻ります。そのため「一度確認したから永久に安全」という証明にはなりません。新しいdappを使った後、長期間利用していないサービスが増えたとき、セキュリティ事故が公表されたときなど、自分なりの見直しのきっかけを決めておくと管理しやすくなります。

一方、毎日すべてのチェーンを確認する必要があると一律にはいえません。保有資産、利用頻度、承認先の数によって負担とリスクは異なります。重要なのは、承認した事実を忘れたまま放置しないことと、緊急情報を見たときに対象アドレスをすぐ確認できる状態にすることです。

読み取り結果を間違えないための見方

isApprovedForAllがfalseだったとしても、「ウォレットに一切の承認がない」とは限りません。この関数が答えるのは、指定したNFTコントラクトにおいて、指定ownerが指定operatorへ全件承認を与えているかという一点です。別operator、別コレクション、個別tokenIdへの承認、ERC-20のallowanceは別に確認します。

反対にtrueと表示されても、それだけで直ちに盗難が起きたことを意味しません。trueは権限が有効であることを示し、その権限が正当なサービス運用に必要な場合もあります。承認先の正体、現在も使うサービスか、コントラクトに既知の問題があるかを確認したうえで、維持か取消かを判断します。今回の旧V2問題のように公式から取消案内が出た対象は、その案内を優先して検討します。

ブロックエクスプローラーには、プロキシの実装先、検証済みソース、似た名称のコントラクトなど多くの情報が表示されます。名前だけで対象を選ばず、公式が示した完全なアドレスと一致するかを確認してください。先頭と末尾の数文字だけを見る方法は日常的には便利でも、攻撃者が似た見た目のアドレスを用意する「アドレス・ポイズニング」への耐性が低いため、重要な操作では完全一致を確かめます。

ウォレットを移せば解決するとは限らない

NFTを新しいウォレットへ移すと、旧ウォレットのownerに対する全件承認は、新しい所有者の権限として引き継がれるわけではありません。しかし、移転作業そのものに危険な承認先を使ったり、秘密鍵が漏えいしたウォレットで操作を続けたりすれば、別のリスクが残ります。また、NFTが将来旧ウォレットへ戻れば、旧ownerとoperatorの承認状態がまだtrueである限り影響を受ける可能性があります。

したがって、単なる資産移動を承認取消の完全な代替と考えないほうが安全です。問題が承認だけなのか、秘密鍵やシードフレーズの漏えいも疑われるのかで対応は変わります。今回の記事は残存承認を扱っています。秘密鍵の漏えいが疑われる場合は、承認点検だけで十分とせず、利用中のウォレット提供元など信頼できる公式サポートの安全手順を確認してください。

取消操作を行う前の最終チェック

署名前には、少なくとも五つを確認します。第一に開いているページが公式導線か、第二に選択中のチェーンが対象と一致するか、第三にNFTコントラクトが正しいか、第四に取消対象のoperatorが正しいか、第五に取引結果が承認をfalseへ変える内容かです。ウォレットのシミュレーションが利用できる場合は、想定外のNFT移転やトークン送付が表示されていないかも見ます。

操作中に不安を感じたら、急いで署名する必要はありません。ブラウザタブを閉じ、公式情報を別経路から再確認できます。ただし、インシデントが進行中なら放置にもリスクがあります。焦って非公式窓口を使うのではなく、検証可能な公式アドレスと標準的な取消手段に絞って迅速に確認することが大切です。

取引がpendingのままの場合、同じ操作を何度も送るとnonceや手数料の管理が複雑になることがあります。ウォレットが提供する高速化やキャンセルの説明を確認し、状態を理解せずに別サイトで追加署名を重ねないでください。失敗と表示された取引は状態を書き換えていないのが一般的なので、再送前にエクスプローラーで実行結果を確かめます。

サービス終了を一つの運用プロジェクトとして扱う

NFT市場の終了は、ウェブサーバーを止める一日だけの作業ではありません。終了決定、利用者通知、新規承認の停止、注文無効化、残存承認の可視化、取消支援、監視、問い合わせ対応、インシデント対応、最終報告までを連続したプロジェクトとして管理します。各作業には責任者と期限を置き、終了後もオンチェーン活動を観測する期間を設けます。

利用者通知では、「危険なので取り消してください」だけでなく、なぜサイト終了で消えないか、どのチェーンとアドレスが対象か、読み取り確認だけの場合と状態変更取引の場合で何が違うかを説明します。対象外の利用者が偽サイトへ誘導されないよう、対象条件と非対象条件も明記します。更新があれば古い投稿を放置せず、最新版への導線を一本化します。

保護移転が必要な緊急時には、保管アドレス、実行根拠、対象選定、返還条件、手数料、問い合わせ窓口を可能な範囲で透明化します。ただし、攻撃者へ対策を知らせることで被害が拡大する局面もあるため、公表時期はインシデント対応の判断が必要です。事後には独立した検証ができる情報を残し、「善意で保護した」という説明だけに依存しない体制が望まれます。

この事例から得られる一般的な教訓

この問題はMagic Edenだけを避ければ終わる話ではありません。NFT市場、ゲーム、レンタル、担保サービスなど、NFT移転のために全件承認を使うあらゆるdappで、同じ「フロント終了後も権限が残る」という構造が生じ得ます。サービスの知名度や現在の画面の有無ではなく、チェーン上にどんな権限が記録されているかを基準に考えます。

また、スマートコントラクトが改ざんされにくいことと、常に安全であることは同義ではありません。意図したコードがそのまま動き続ける性質は、設計上の欠陥や古い権限も残り続ける可能性を含みます。変更不能性だけを安心材料にせず、停止や移行、権限取消といった運用面を含めて安全性を評価する必要があります。

利用者にとっての現実的な原則は、署名前に範囲を理解し、利用後は不要な承認を見直し、事故時には公式アドレスと現在値を検証することです。事業者にとっては、最小権限、明確な表示、監視、緊急対応、終了時の残存権限解消を最初から製品要件に含めることです。どちらか一方だけへ責任を押しつけても、オンチェーン権限の長期リスクは減らせません。

検証情報と更新方針

最終検証:2026年9月27日(JST)。責任編集部がLimit Break公式デプロイ一覧、Ethereum標準仕様、ウォレット公式ガイド、事件報道を照合しました。対象期間・返還状況など当事者の更新で変わり得る情報は、関係者の公式発表を優先してください。本稿は一般的な安全情報であり、個別ウォレットの完全な安全や資産回収を保証するものではありません。公式アドレスや手順に変更が確認された場合は本文と更新日を改訂します。

まとめ

Magic Eden旧EVM市場の問題は、ウェブサービスの終了とブロックチェーン上の権限終了が一致しないことを示しました。2024年2〜10月ごろに旧市場を利用した可能性がある人は、Ethereum、Polygon、Baseなど該当チェーンを分け、正しいNFTコントラクトと旧V2オペレーターの組み合わせを確認してください。

確認の要点は、公式情報からアドレスを照合すること、isApprovedForAllで現在値を見ること、必要ならfalseへ変更する取引を送り、成功後に再照会することです。取消を装う偽サイトや返還詐欺には注意し、分からない署名を急いで承認しないでください。

また、2万3155点・570万ドル超は保護退避されたNFTの規模と推定評価額で、同額の確定損失を意味しません。事実の状態を区別しながら、自分のウォレットに残る権限を一件ずつ確認することが、現実的な対応です。

FAQ

よくある質問

クリプ先生、対象NFTをもう売ったなら確認しなくていいの?

今の保有がゼロでも、当時使ったウォレットは確認しておこう。NFTが将来そのウォレットへ戻ると、ownerとoperatorの承認がtrueのままなら影響を受ける可能性があるよ。

クリプ先生、ウォレットが複数あるときは、どれから確認すればいい?

2024年2〜10月ごろにMagic Eden旧EVM市場で使った可能性が高いアドレスからだよ。各アドレスでEthereum、Polygon、Baseを順に見て、確認日と結果をメモすると抜けにくいんだ。

クリプ先生、取消取引が失敗したら承認は消えていますか?

失敗した取引は通常、状態を変更していないよ。エクスプローラーでFailedやRevertedになっていたら、原因とガス残高を確認してから再送し、最後にfalseを読み直そう。

クリプ先生、pendingのままなら同じ取消を何度も送っていい?

むやみに重ねないほうがいいよ。nonceの順番や手数料が複雑になるから、まずウォレットの高速化・キャンセル案内とエクスプローラーの状態を確認しよう。

クリプ先生、個別NFTの承認と「すべて承認」はどう違うの?

個別承認は特定のtokenIdだけ、setApprovalForAllは同じNFTコントラクト内でそのownerが持つNFT全体に及び得るんだ。確認画面で承認の種類も見分けてね。

クリプ先生、承認一覧に何も表示されなければ安全ですか?

選んだチェーンと公開アドレスが正しいかを先に確かめよう。一つの画面だけでなく、必要ならNFTコントラクトのisApprovedForAllでも同じownerとoperatorを読み取ると確実だよ。

クリプ先生、取消後にサービスをまた使うとどうなるの?

必要な権限をもう一度求められる場合があるよ。再承認すればtrueへ戻るので、署名前に範囲と承認先を確認し、使い終わったらまた見直そう。

Sources

参考・出典

  1. Magic Eden legacy approvals leave $5.7 million in NFTs exposed to exploit before rescue The Block
  2. payment-processor-v2 Limit Break / GitHub
  3. Payment Processor V2 Documentation Limit Break
  4. ERC-721: Non-Fungible Token Standard Ethereum Improvement Proposals
  5. ERC-721 Non-Fungible Token Standard ethereum.org
  6. ERC721 OpenZeppelin
  7. ERC-1155: Multi Token Standard Ethereum Improvement Proposals
  8. How to revoke smart contract access to your crypto funds ethereum.org
  9. How to revoke smart contract allowances/token approvals MetaMask Help Center
  10. What Are Token Approvals? Revoke.cash
  11. Smart contract security ethereum.org
  12. Utils: Pausable OpenZeppelin
  13. Clear Signing: Making Transaction Approvals Safer on Ethereum Ethereum Foundation Blog
  14. ERC-8255: Expiring Token Approvals Ethereum Improvement Proposals
  15. ERC-6464: Multi-operator, per-token ERC-721 approvals Ethereum Improvement Proposals
  16. EIP-712: Typed structured data hashing and signing Ethereum Improvement Proposals
  17. ERC-2981: NFT Royalty Standard Ethereum Improvement Proposals
  18. ERC-6809: Non-Fungible Key Bound Token Ethereum Improvement Proposals
  19. Whitehat Races Malicious Actors to Secure 23,155 NFTs Exposed by Dead Marketplace's Lingering Permissions Verse Press
  20. How 0xQuit Rescued 23,155 NFTs Worth $5.7 Million From the Limit Break Exploit Gizmo Times
  21. Magic Eden Users Face NFT Risk After Payment Processor Exploit Coin360
  22. Magic Eden Exploit: 0xQuit Rescues 23,155 NFTs Overnight AirdropAlert
  23. ERC-927: Generalised authorisations Ethereum Improvement Proposals
  24. Contract Deployments Limit Break / AppTokens

Latest

新着記事

  1. 01 技術解説 SuiのBitcoin金融基盤「Hashi」とは?mainnet 1.0とhBTCの仕組み 2026年11月1日
  2. 02 実践ガイド Chain.comのOnyx移行期限は2026年10月31日|自動移行の対象と対応 2026年10月31日
  3. 03 実践ガイド Stellar版Curve Financeとは?StableSwapベータの交換・LP機能とリスク 2026年10月31日
  4. 04 技術解説 DTCCの証券トークン化サービスとは?対象範囲・24時間移転・利用条件を整理 2026年10月31日