ERC-721インターフェース

ERC-721インターフェースとは？

ERC-721インターフェースは、Ethereumおよび互換性のあるブロックチェーンネットワーク上で非代替性トークンを表し、移転するために使用される、スマートコントラクトの関数とイベントを標準化したものです。

非代替性トークン（NFT）は、同一の単位と交換可能な数量ではなく、固有の識別情報を持つトークンを表します。

公式のERC-721仕様では、ウォレット、アプリケーション、スマートコントラクト、ブロックチェーンツールがNFTの所有権を確認し、標準化された送金を実行する方法を定めています。

このインターフェースは、NFTが何を表すのか、その価値、またはリンク先のコンテンツが本物かどうかを決定するものではありません。

異なる暗号資産アプリケーションがNFTコントラクトと連携するための共通の技術仕様を定めます。

ERC-721規格はEthereum Improvement ProposalのプロセスでFinalステータスに到達しており、固有のブロックチェーン資産向けの主要な規格の一つとして利用されています。

ERC-721は、デジタルコレクティブル、ゲームアイテム、会員資格証明、仮想土地、イベントチケット、ドメインのような資産、金融ポジション、トークン化された記録などに利用できます。

インターフェースが重要な理由

スマートコントラクトのインターフェースは、互換性のあるソフトウェアがコントラクトに備わっていることを期待する外部関数やイベントを定義します。

共通のインターフェースがなければ、NFTプロジェクトごとに異なる関数名や送金ルールが使われる可能性があります。

その場合、ウォレットや分散型アプリケーションには、コレクションごとに専用のコードが必要になります。

ERC-721インターフェースにより、ソフトウェアは

、、、などの一般的な関数を呼び出せます。

また、オフチェーンシステムがNFTの移転と承認を追跡するためのイベントも標準化します。

コントラクトはERC-721との互換性を保ちながら、コア規格以外の関数を追加できます。

インターフェースへの準拠は相互運用性を高めますが、コントラクトの安全性や、すべてのアプリケーションが独自機能に対応していることを保証するものではありません。

ERC-721トークンが非代替性である理由

ERC-721の各トークンには、トークンIDと呼ばれる一意の符号なし整数が割り当てられています。

トークンは、ブロックチェーンネットワーク、コントラクトアドレス、トークンIDの組み合わせによって完全に識別されます。

あるコントラクトのトークンID 100は、別のコントラクトのトークンID 100とは無関係です。

規格では、トークンIDが0から始まること、順番に増えること、予測可能なパターンに従うことは求められていません。

アプリケーションは、存在するIDを推測せず、すべてのトークンIDを不透明な識別子として扱ってください。

コアERC-721所有権モデルでは、有効な各トークンIDに同時に1人の所有者が存在します。

NFTは完全な1つのトークンとして移転できますが、分割所有には基本インターフェース以外の別のコントラクトまたはトークン構造が必要です。

ERC-721コアインターフェースID

ERC-721のコアインターフェースは、ERC-165を通じて

という値で識別されます。

互換性のあるコントラクトは、この識別子を指定して

を呼び出されたとき、を返す必要があります。

ERC-165インターフェース検出規格では、インターフェースに含まれる関数セレクターにXORを適用してインターフェース識別子を計算します。

ERC-165を使うと、アプリケーションは連携を試みる前に、どの標準インターフェースに対応しているとコントラクトが申告しているかを確認できます。

肯定的な応答は互換性の確認に役立ちますが、すべての関数が正しく実装されていることを独立して証明するものではありません。

価値のある資産を扱うアプリケーションでは、コードレビュー、テスト、トランザクションのシミュレーションも必要になる場合があります。

ERC-721の主なインターフェース関数

必須のERC-721インターフェースには、所有権照会、送金、承認管理の各関数が含まれます。

主な関数は、

、、、、、、、です。

準拠する実装は、承認チェックや失敗条件など、規格で定められた動作に従う必要があります。

ミント、バーン、ロイヤリティ、供給上限、価格設定、コレクション管理は、コアインターフェースで完全には定義されていません。

通常、プロジェクトはこれらの機能に別のロジックを追加します。

balanceOf関数

関数は、1つのERC-721コントラクト内で、あるアドレスが所有するNFTの数を返します。

分割可能なトークン数量やNFTの金銭的価値を返すものではありません。

あるアドレスが同じコレクションのトークンID 4、19、83を所有している場合、その残高は3です。

規格上、ゼロアドレスへの照会は失敗しなければなりません。

この関数では、アドレスがどの特定のトークンIDを所有しているかは分かりません。

そのIDを調べるには、送金イベントのインデックス化や、任意のenumerableインターフェースが必要になる場合があります。

ownerOf関数

関数は、特定のトークンIDの現在の所有者を返します。

存在するトークンについて、返される所有者はゼロアドレスであってはなりません。

無効または存在しないトークンの照会は、規格上失敗しなければなりません。

コントラクトに記録された所有権により、そのNFTに関する基本的な移転権限が決まります。

ただし、著作権、商標権、実物資産、その他の法的権利の所有を必ずしも証明するものではありません。

そうした権利は、プロジェクトの規約、適用法、外部記録によって決まります。

transferFrom関数

関数は、権限と所有権を確認したうえで、NFTをあるアドレスから別のアドレスへ移転します。

呼び出し元は、所有者、個別に承認されたアドレス、または所有者が承認したオペレーターでなければなりません。

アドレスは、そのNFTの現在の所有者と一致する必要があります。

受取人にゼロアドレスを指定することはできません。

この関数では、受取側のスマートコントラクトがNFTを処理できることを確認する必要はありません。

互換性のないコントラクトに

でNFTを送ると、永久にアクセスできなくなる可能性があります。

不明なコントラクトにNFTを送る場合、ユーザーと開発者は通常、安全な送金方法を優先してください。

safeTransferFrom関数

ERC-721では、

に2つのオーバーロード版が定義されています。

一方は、送信者、受取人、トークンIDを指定します。

もう一方は、アプリケーション固有のデータを含められるbytesフィールドも追加します。

どちらの関数も通常の所有権と承認のチェックを実行します。

受取人がスマートコントラクトの場合、送金処理でそのコントラクトの

が呼び出されます。

受取人は所定のセレクターを返さなければならず、返さない場合は送金全体がリバートされます。

この受取人チェックにより、NFTを管理できないコントラクトへの送金を防げる可能性が高まります。

ただし、受取コントラクトの信頼性や、後からNFTを出金できることを証明するものではありません。

IERC721Receiverとは？

は、でNFTを受け取るスマートコントラクトが実装するインターフェースです。

必須関数は

です。

この関数には、オペレーター、以前の所有者、トークンID、任意のデータが渡されます。

受取に成功すると関数セレクターを返します。一般的には

で表されます。

返り値が誤っている場合や呼び出しがリバートした場合、安全な送金は失敗します。

最新のERC-721実装ドキュメントには、受取インターフェースと、安全な送金を受け入れる必要があるコントラクト向けの基本的なホルダーユーティリティが含まれています。

受取コントラクトは、コールバックを重要な会計処理に使用する前に、呼び出し元のNFTコントラクトを確認してください。

ERC-721受取コールバックのリスク

コントラクトへの安全な送金では、受取人への外部呼び出しが発生します。

元のトランザクションが終了する前に、受取人が追加のコードを実行する可能性があります。

送金元のアプリケーションで内部状態の更新が完了していない場合、リエントランシーが発生する可能性があります。

悪意のある受取人は、コールバック中に元のコントラクトの別の関数を呼び出そうとする場合があります。

Solidityのスマートコントラクトのセキュリティガイダンスでは、設計上可能な場合、外部とのやり取りを行う前にチェックと重要な状態変更を完了することが推奨されています。

開発者は、受取人のコールバックを無害だと思い込まず、悪意のある受取コントラクトを使って安全なNFT送金をテストしてください。

approve関数

関数を使うと、特定のNFTを移転する権限を1つのアドレスに与えられます。

通常、この承認を付与できるのは、トークン所有者または承認済みオペレーターです。

承認されたアドレスが所有者になるわけではありません。

指定されたトークンIDを移転する権限を得ます。

NFTの移転時には、通常、トークンごとの承認は解除されます。

にゼロアドレスを指定すると、既存の承認を解除できます。

有効な承認を持つ攻撃者は、所有者から再度署名を受けなくてもNFTを移転できるため、承認先のアドレスを確認してください。

getApproved関数

関数は、1つのトークンIDに現在承認されているアドレスを返します。

トークンごとの承認がない場合、通常はゼロアドレスを返します。

この関数は、有効なNFTに対してのみ適用されます。

所有者のコレクション全体を対象とするオペレーター承認は報告しません。

他のアドレスがトークンを移転できるかを判断する際、アプリケーションは

も確認してください。

setApprovalForAll関数

関数を使うと、呼び出し元がそのコントラクト内で所有するすべてのERC-721トークンについて、オペレーターの権限を付与または解除できます。

承認されたオペレーターは、保有者が現在所有するNFTだけでなく、後から同じコレクションで受け取るNFTも移転できます。

この権限は、1つのトークンIDに対する承認より広範です。

複数のNFTを管理するアプリケーションが、NFTごとに個別の承認を求めずに済むよう、一般的に利用されています。

悪意のあるオペレーターは、権限が有効な間に対象となるすべてのNFTを移転できます。

ウォレットは、コレクションのアドレスとオペレーター承認の範囲を明確に表示してください。

isApprovedForAll関数

関数は、特定の所有者について、オペレーターがコレクション全体を対象とする権限を持つかどうかを返します。

トークン数量ではなく、真偽値を返します。

オペレーター権限は、それを付与したERC-721コントラクト内でのみ有効です。

あるNFTコレクションでの承認が、別のコレクションに自動的に適用されることはありません。

ユーザーは有効なオペレーター権限を定期的に確認し、不要な権限を取り消してください。

ERC-721のイベント

コアERC-721インターフェースでは、

、、イベントが定義されています。

これらのイベントログにより、ウォレット、インデクサー、分析システム、ブロックチェーンエクスプローラーは、標準化されたNFTの活動を追跡できます。

イベントを使うと、オフチェーンソフトウェアが所有権と権限の履歴を再構築できます。

コントラクトイベントは実行中にコントラクトが出力した内容を示しますが、アプリケーションはトランザクションが成功し、想定したコントラクトから発行されたことも確認してください。

Transferイベント

イベントには、以前の所有者、新しい所有者、トークンIDが記録されます。

通常の送金では、送信元と受取先のアドレスはゼロアドレスではありません。

ミントは通常、ゼロアドレスから最初の所有者への送金イベントを発行して表します。

バーンは通常、所有者からゼロアドレスへの送金イベントを発行して表します。

ERC-721インターフェースでは、こうしたライフサイクルの追跡に使えるイベントパターンが定められていますが、公開ミント関数やバーン関数は定義されていません。

NFTがミントされたことを示すイベントがあっても、コレクションの供給量が固定されていることや、ミント権限が制限されていることの証明にはなりません。

Approvalイベント

イベントは、特定のトークンIDに対する承認を記録します。

所有者、承認されたアドレス、トークンIDが含まれます。

アプリケーションは、このイベントを利用してトークンごとの移転権限の変更を追跡できます。

所有者は変わらないため、このイベントを所有権の移転と混同しないでください。

ApprovalForAllイベント

イベントは、所有者がオペレーターを有効化または無効化したかを記録します。

所有者、オペレーター、承認状態が含まれます。

1つのオペレーター承認が、所有者のそのコレクション内のすべてのNFTに影響する可能性があるため、このイベントの監視は重要です。

権限取り消しイベントが発行されても、承認が有効だった期間にすでに実行された移転は取り消されません。

任意のERC-721メタデータインターフェース

メタデータ拡張では、

、、が追加されます。

そのERC-165インターフェースIDは

です。

公式仕様ではこの拡張は任意ですが、多くのNFTコントラクトが実装しています。

関数は、コレクションを説明する名称を返します。

関数は、コントラクト開発者が選んだ短い識別子を返します。

関数は、特定のトークンIDに関連付けられたURIを返します。

コレクション名とシンボルは一意ではないため、真正性の確認にこれらだけを使用しないでください。

tokenURIの仕組み

関数は通常、JSON形式のメタデータドキュメントを指します。

このドキュメントには、表示名、説明、画像の場所、アニメーション、プロジェクト固有の属性などを含められます。

URIには、HTTPSアドレス、分散型コンテンツ識別子、オンチェーンデータURIを使用できます。

公式のERC-721規格では、メタデータの変更が認められています。

そのため、コントラクトまたはプロジェクトがより強い不変性を保証していない限り、ミント後にNFTの表示内容が変更される場合があります。

最新のERC-721開発ガイドでは、オフチェーンメタデータは保存場所を管理する主体によって変更される可能性があると説明されています。

トークンの所有権があっても、外部画像やファイルが永久に利用できるとは限りません。

任意のERC-721 Enumerableインターフェース

enumerable拡張を使うと、オンチェーンの照会によってアプリケーションがトークンIDを検出できます。

そのERC-165インターフェースIDは

です。

、、が追加されます。

関数は、コントラクトが追跡している現在有効なトークン数を返します。

インデックス関数を使うと、総供給量または1人の所有者の保有分からトークンIDを取得できます。

追加の所有権インデックスを維持するとストレージ書き込みとガス消費量が増えるため、列挙機能は任意です。

代わりに、多くのアプリケーションはオフチェーンで

イベントをインデックス化し、NFTの保有状況を再構築します。

ミントとバーン

コアERC-721インターフェースでは、公開ミント関数を必須としていません。

ミントが自由参加、制限付き、スケジュール制、上限付き、永久停止のどれに該当するかは、各プロジェクトが決定します。

規格では、公開バーン関数も必須ではありません。

バーンでは、コントラクトの実装に従って有効な所有権記録からトークンが削除されます。

誰がNFTをミントまたはバーンできるか、また管理者が他のアカウントのトークンに影響を与えられるかを確認してください。

送金インターフェースに準拠しているからといって、トークン供給量が固定されているとは限りません。

ERC-721インターフェースとERC-721実装の違い

インターフェースは、互換性に必要な外部動作を定義します。

実装には、実際のストレージ、承認、送金、ミント、メタデータ、管理者ロジックが含まれます。

同じERC-721インターフェースに対応する2つのコントラクトでも、内部設計は大きく異なる場合があります。

一方の実装は不変で、もう一方はアップグレード可能なプロキシを通じて動作する場合があります。

供給量が固定された実装もあれば、管理者が無制限にミントできる実装もあります。

メタデータをオンチェーンに保存する実装もあれば、変更可能なサーバーを参照する実装もあります。

インターフェースへの対応を完全なセキュリティ評価とみなさず、実装そのものを確認してください。

ERC-721とERC-20の違い

ERC-20は代替可能な残高を表し、ERC-721は個別に識別されるトークンを表します。

ERC-20のアカウントは、250単位のような分割可能な数量を保有できます。

ERC-721のアカウントは、異なるトークンIDの保有数を管理します。

ERC-721の

関数が返すのは、1つのトークンIDの数量ではなく、アカウントが所有するNFTの数です。

各トークンは通常、完全な1単位として移転されるため、ERC-721では小数桁のフィールドは必須ではありません。

承認の方法も異なります。ERC-721では、1つのトークンの承認と、コレクション全体に対するオペレーター権限に対応しています。

ERC-721とERC-1155の違い

ERC-721は、個別に識別される非代替性トークンを中心とした規格です。

ERC-1155では、1つのコントラクトで代替可能、準代替可能、非代替性の資産を含む複数のトークンIDを管理できます。

ERC-1155のアカウントは、1つのトークンIDを複数単位保有できます。

ERC-721のトークンIDには1人の所有者が存在し、各アカウントの残高として数量を管理することはありません。

最適な規格は、資産モデル、送金パターン、一括操作の必要性、アプリケーション要件によって異なります。

ロイヤリティとERC-721インターフェース

コアERC-721インターフェースでは、クリエイターへのロイヤリティは定義されていません。

別のロイヤリティインターフェースを使うと、推奨される支払先と支払額を伝えられます。

ロイヤリティ情報があっても、すべての送金システムに支払いを自動的に強制できるわけではありません。

ロイヤリティを掲げるコレクションは、その情報の計算方法や変更可能性を説明する必要があります。

ERC-721のNFTに永久的または法的強制力のあるロイヤリティ権が含まれると思い込まないでください。

ERC-721承認に関するセキュリティリスク

NFT保有者にとって、承認を悪用するフィッシングは特に重要なリスクの一つです。

悪意のあるウェブサイトが、署名の内容をアカウント確認やコレクションへのアクセスと説明しながら、

を要求する場合があります。

承認後、オペレーターは所有者から新たな承認を受けずに、対象となるすべてのNFTを移転できます。

特定のトークンに対する承認も、そのNFTを盗む権限につながる可能性があります。

署名する前に、オペレーターのアドレス、NFTコントラクト、権限の種類、ネットワークを確認してください。

ウォレットとウェブサイトの接続を解除しても、すでにオンチェーンに記録された承認は取り消されません。

安全でない送金のリスク

関数を使うと、復旧手段を持たないコントラクトへNFTを送れる場合があります。

受取コントラクトがNFTを返送できなくても、トランザクション自体は成功する可能性があります。

この問題が、コントラクトへの送金で

が推奨される理由です。

ただし、安全な受取で確認できるのは、コントラクトが所定のコールバック値を返したことだけです。

受取人に正当な出金手段があることを保証するものではありません。

メタデータと真正性に関するリスク

誰でも、よく知られたコレクション名やシンボルを使ってERC-721コントラクトをデプロイできます。

コレクションを識別するうえで最も重要な技術情報は、コントラクトアドレスです。

メタデータには、誤解を招く名称、複製されたアートワーク、安全でない外部リンク、利用できないファイルが含まれる場合もあります。

プロジェクトの管理者が管理するトークンURIは、後から異なるコンテンツを指すように変更される場合があります。

オンチェーンの所有権だけでは、作成者の身元や知的財産権は独立して確認できません。

信頼できる情報源を通じて、コレクションのアドレスとプロジェクト情報を確認してください。

アップグレード可能なコントラクトのリスク

ERC-721実装は、アップグレード可能なプロキシの背後で動作する場合があります。

権限を持つ管理者が、ユーザーによるNFT取得後に送金ルール、メタデータロジック、ミント権限、その他の動作を変更できる可能性があります。

アップグレードでバグを修正できる場合がある一方、ガバナンスや鍵の侵害に関するリスクも生じます。

アップグレード権限、タイムロック、マルチシグ管理、管理者ロールを確認してください。

ERC-721インターフェースへの対応だけでは、実装に含まれるすべての特権関数は分かりません。

開発者がERC-721を実装する方法

開発者は、強い理由もなく機密性の高い所有権ロジックを独自に書き直すのではなく、レビュー済みで積極的に保守されている実装を利用してください。

最新のOpenZeppelin ERC-721 APIには、コア機能、メタデータ、enumerable、一時停止可能、バーン可能、ロイヤリティ、投票、受取人関連のコンポーネントが用意されています。

ミント権限は、コレクションで公開されている供給方針に従って制限してください。

NFTをスマートコントラクトへ直接ミントできる場合、安全なミントの利用を検討してください。

受取人のコールバックは、リエントランシーを引き起こす可能性がある外部呼び出しとして扱ってください。

テストでは、所有権、承認、オペレーター権限、安全な受取人、悪意のある受取人、バーン、無効なトークンID、権限のない送金を確認してください。

実装するすべての拡張について、インターフェース検出が正しい値を返すかもテストしてください。

アプリケーションがERC-721対応を検出する方法

アプリケーションは、コアERC-721インターフェースIDを指定して

を呼び出せます。

が返された場合、コントラクトはそのインターフェースを実装していると申告しています。

メタデータまたはenumerableインターフェースのIDを個別に確認することもできます。

関数名だけから推測するより、インターフェース検出の方が信頼性は高くなります。

ただし、実装の不備や悪意のあるコントラクトが、不正確な情報を返す場合があります。

すべてのコントラクトが規格に準拠していると思い込まず、呼び出しの失敗や予期しない動作を安全に処理してください。

ERC-721の送金例

AliceがERC-721コントラクト内のトークンID 42を所有しているとします。

コントラクトの

関数は、トークンID 42の所有者としてAliceのアドレスを返します。

AliceはNFTをスマートコントラクトへ送ることにしました。

Aliceのウォレットは、Aliceのアドレス、受取コントラクト、トークンID 42を指定して

を呼び出します。

NFTコントラクトは、Aliceがそのトークンを所有し、移転権限を持つことを確認します。

所有権を更新し、受取人の

を呼び出します。

受取人はNFTコントラクト、オペレーター、以前の所有者、トークンIDを確認します。

受取人が正しいセレクターを返すと送金が完了し、

イベントが発行されます。

受取人がコールバックを拒否すると、トランザクション全体がリバートされ、Aliceが引き続き所有者となります。

ERC-721インターフェースでよくある間違い

よくある間違いの一つは、コレクション名だけでNFTコントラクトを一意に識別できると思い込むことです。

別の間違いは、

を1つのトークンIDの数量として扱うことです。

3つ目は、不明なスマートコントラクトへNFTを送る際に

を使うことです。

4つ目は、オペレーターのアドレスを確認せずに、コレクション全体を対象とする承認を付与することです。

5つ目は、ウォレットの接続を解除すればオンチェーンの承認も取り消されると思い込むことです。

6つ目は、トークンURIを確認せず、メタデータが永久にオンチェーンに保存されていると考えることです。

7つ目は、ERC-721にロイヤリティが必須で含まれていると思い込むことです。

8つ目は、すべてのERC-721コントラクトがenumerableに対応していると思い込むことです。

9つ目は、受取人コールバック中のリエントランシーを無視することです。

10個目は、ERC-165への対応を、実装の安全性や真正性の証明として扱うことです。

よくある質問

ERC-721インターフェースとは何ですか？

ERC-721インターフェースは、非代替性トークンの所有権、承認、送金を追跡するための関数とイベントを標準化したものです。

ERC-721インターフェースIDとは何ですか？

ERC-721コアインターフェースIDは

です。

ERC-721コントラクトのbalanceOfは何を返しますか？

そのコントラクトの異なるNFTを、あるアドレスがいくつ所有しているかを返します。

ownerOfは何をしますか？

有効なトークンIDの現在の所有者を返します。

transferFromとsafeTransferFromの違いは何ですか？

は受取コントラクトがERC-721受取人コールバックに対応しているか確認しますが、は確認しません。

onERC721Receivedとは何ですか？

安全な送金でNFTを受け取れることを確認するため、スマートコントラクトが実装するコールバックです。

安全なNFT送金が失敗することはありますか？

はい。承認チェックに失敗した場合や、受取コントラクトが所定のコールバックセレクターを返さない場合は失敗します。

approveは何をしますか？

特定のNFTを1つのアドレスが移転できるよう承認します。

setApprovalForAllは何をしますか？

そのERC-721コントラクト内で、呼び出し元が所有するすべてのNFTをオペレーターが管理できるようにします。

オペレーター承認は自動的に期限切れになりますか？

いいえ。標準的なコレクション全体の承認は、所有者が取り消すか、コントラクトが追加の独自ルールを適用するまで有効です。

NFTを移転すると、そのトークン固有の承認は解除されますか？

はい。通常のERC-721実装では、送金時にそのトークンに関連付けられた承認が解除されます。

ERC-721ではメタデータが必須ですか？

いいえ。メタデータインターフェースは任意ですが、ほとんどのNFTコレクションが実装しています。

ERC-721メタデータインターフェースIDとは何ですか？

メタデータ拡張のインターフェースIDは

です。

ERC-721 enumerableインターフェースIDとは何ですか？

enumerable拡張のインターフェースIDは

です。

すべてのERC-721コントラクトはtotalSupplyに対応していますか？

いいえ。

は任意のenumerable拡張に含まれます。

ERC-721ではミント関数が必須ですか？

いいえ。コアインターフェースでは、ユーザーや管理者がNFTをどのようにミントするかは定義されていません。

ERC-721ではバーン関数が必須ですか？

いいえ。バーンは必須のコア関数ではなく、実装に含まれる機能です。

ERC-721はロイヤリティを強制しますか？

いいえ。ロイヤリティはコアERC-721インターフェースの対象外であり、別のロジックまたは規格が必要です。

ERC-721のメタデータは変更できますか？

はい。実装がより強い不変性を保証していない限り、規格ではトークンURIの変更が認められています。

ERC-721への準拠はNFTの真正性を証明しますか？

いいえ。誰でも互換性のあるコントラクトをデプロイできるため、ユーザーはコントラクトアドレスと発行者を個別に確認する必要があります。

まとめ

ERC-721インターフェースは、Ethereum互換アプリケーションで非代替性トークンに使われる、共通の所有権、承認、送金、イベントのルールを提供します。

コアインターフェースIDは

で、コントラクトはERC-165インターフェース検出を通じて対応状況を示します。

必須関数により、アプリケーションは残高と所有者を確認し、移転権限を承認し、固有のトークンIDを移転できます。

安全な送金関数は、ERC-721受取人コールバックを必須とすることで、互換性のないコントラクトへの誤送金を減らします。

このコールバックには外部呼び出しが伴うため、開発者はリエントランシーリスクに慎重に対処する必要があります。

メタデータとenumerableは任意のインターフェースであり、それぞれ固有の識別子と追加のガスまたは信頼上の検討事項があります。

この規格では、ミント権限、バーン権限、ロイヤリティ、供給上限、メタデータの永続性、法的所有権、コレクションの真正性は定義されていません。

ユーザーはNFTを利用する前に、コントラクトアドレスを確認し、オペレーター承認を見直し、メタデータの保存方法を調べ、アップグレード権限を把握してください。

開発者は保守されている実装を使い、すべての承認経路をテストし、NFT受取人のコールバックを悪意のあるコードである可能性を考慮して扱う必要があります。

ERC-721インターフェースを理解すると、標準化されたNFTの互換性と、個別のコレクションが持つ幅広い経済的、法的、セキュリティ上の特性を区別しやすくなります。