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 代幣都有一個稱為 token ID 的唯一無號整數。

代幣由其所在的區塊鏈網路、合約地址與 token ID 組合而完整識別。

某個合約中的 token ID 100，與另一個合約中的 token ID 100 毫無關聯。

標準不要求 token ID 從 0 開始、依序增加，或遵循可預測的模式。

應用程式應將每個 token ID 視為不透明識別碼，而非猜測哪些 ID 存在。

依核心 ERC-721 所有權模型，每個有效 token ID 同一時間只有一位持有人。

NFT 可以作為一個完整代幣轉移；分割所有權則需要使用基本介面以外的獨立合約或代幣結構。

ERC-721 核心介面 ID

ERC-721 核心介面透過 ERC-165 以

識別。

相容合約在以此識別碼呼叫

時，應回傳 。

ERC-165 介面偵測標準會對介面所含函式選擇器執行 XOR，計算介面識別碼。

ERC-165 讓應用程式能在嘗試互動前，詢問合約宣稱支援哪些標準化介面。

回傳肯定結果有助於確認相容性，但無法單獨證明所有函式都已正確實作。

處理有價資產時，應用程式可能還需要進行程式碼審查、測試與交易模擬。

ERC-721 核心函式

必要的 ERC-721 介面包含所有權查詢、轉帳與核准管理函式。

主要函式包括

、、、、、、 與 。

相容實作必須遵循標準規定的行為，包括授權檢查與失敗條件。

鑄造、銷毀、版稅、供應量上限、定價與系列管理並未由核心介面完整定義。

專案通常會為這些功能加入獨立邏輯。

balanceOf

函式

函式會回傳某個地址在單一 ERC-721 合約中持有的 NFT 數量。

它不會回傳可分割的代幣數量，也不會顯示 NFT 的財務價值。

若某地址持有同一系列中的 token ID 4、19 與 83，其餘額就是 3。

標準規定，查詢零地址時必須失敗。

此函式不會顯示該地址持有的具體 token ID。

若要找出這些 ID，可能需要索引轉帳事件，或使用選用的 Enumerable 介面。

ownerOf

函式

函式會回傳特定 token ID 目前的持有人。

若代幣存在，回傳的持有人不得為零地址。

依標準，查詢無效或不存在的代幣必須失敗。

合約記錄的所有權會決定與該 NFT 相關的核心轉移權限。

但這不一定能證明著作權、商標、實體財產或其他法律權利的所有權。

相關權利取決於專案協議、適用法律與外部紀錄。

transferFrom

函式

函式會在檢查授權與所有權後，將 NFT 從一個地址轉移至另一個地址。

呼叫者必須是持有人、獲得該代幣個別核准的地址，或持有該持有人授權的操作者。

地址必須與 NFT 目前的持有人相符。

接收者不得為零地址。

此函式不要求接收智能合約確認自己能處理 NFT。

透過

將 NFT 傳送至不相容的合約，可能導致 NFT 永久無法存取。

將 NFT 傳送至未知合約時，使用者與開發者通常應優先使用安全轉帳。

safeTransferFrom

函式

ERC-721 定義兩種多載版本的

。

其中一種版本包含寄件者、接收者與 token ID。

另一種版本則額外加入可承載應用程式專用資料的位元組欄位。

兩種函式都會進行一般的所有權與授權檢查。

若接收者是智能合約，轉帳流程會呼叫該合約的

。

接收者必須回傳預期的選擇器，否則整筆轉帳會回退。

此接收者檢查可降低 NFT 傳送至無法管理 NFT 的合約的風險。

但它不能證明接收合約值得信任，也不能保證日後可以從中提領 NFT。

什麼是 IERC721Receiver？

是智能合約在希望透過 接收 NFT 時所實作的介面。

其必要函式為

。

該函式會接收操作者、先前持有人、token ID 與選用資料。

成功的接收者會回傳其函式選擇器，通常表示為

。

若回傳值不正確或呼叫回退，安全轉帳就會失敗。

目前的ERC-721 實作說明文件提供接收者介面，以及供需要接收安全轉帳的合約使用的基本持有者工具。

接收者在使用回呼更新重要帳務前，應先驗證呼叫者是哪個 NFT 合約。

ERC-721 接收者回呼風險

安全轉帳至合約時，會對該接收者執行外部呼叫。

接收者可以在原始交易結束前執行其他程式碼。

若傳送方應用程式尚未完成內部狀態更新，就可能形成重入途徑。

惡意接收者可能在回呼期間嘗試呼叫原始合約中的其他函式。

Solidity 的智能合約安全指南建議，只要預期設計允許，就應在外部互動前完成檢查與重要狀態更新。

開發者應使用惡意接收者合約測試安全 NFT 轉帳，而非假設回呼沒有危險。

approve

函式

函式會授予一個地址轉移特定 NFT 的權限。

通常只有代幣持有人或獲授權的操作者可以授予此核准。

獲核准地址不會因此成為持有人。

它取得的是轉移指定 token ID 的權限。

NFT 轉移後，該代幣的個別核准通常會清除。

以零地址呼叫

可以清除現有核准。

使用者應確認獲核准地址，因為持有有效核准的攻擊者可以在不取得持有人再次簽署的情況下轉移 NFT。

getApproved

函式

函式會回傳目前獲核准轉移某個 token ID 的地址。

若沒有任何地址取得該代幣的個別核准，通常會回傳零地址。

此函式只適用於有效存在的 NFT。

它不會回報涵蓋持有人整個系列餘額的操作者核准。

判斷其他地址是否可以轉移代幣時，應用程式也應檢查

。

setApprovalForAll

函式

函式會授權或移除某個操作者在該合約中管理呼叫者所有 ERC-721 代幣的權限。

獲核准的操作者可以轉移現有 NFT，也可以轉移持有人之後從同一系列取得的 NFT。

此權限範圍比核准單一 token ID 更廣。

當應用程式需要管理多個 NFT，而不想逐一要求核准時，通常會使用此功能。

只要權限仍然有效，惡意操作者就可能轉移所有受影響的 NFT。

錢包應清楚顯示系列地址與操作者核准的權限範圍。

isApprovedForAll

函式

函式會回報某操作者是否取得特定持有人的系列層級權限。

它回傳布林值，而不是代幣數量。

操作者權限只適用於授予權限的 ERC-721 合約。

某個 NFT 系列中的核准不會自動套用至其他系列。

使用者應定期檢查有效的操作者權限，並撤銷不再需要的權限。

ERC-721 事件

ERC-721 核心介面定義

、 與 事件。

這些事件記錄讓錢包、索引器、分析系統與區塊鏈瀏覽器能追蹤標準化 NFT 活動。

事件有助於鏈下軟體重建所有權與權限歷史。

合約事件可證明合約在執行期間發出了什麼資料，但應用程式仍須確認交易已成功，且事件來自預期合約。

Transfer

事件

事件會記錄先前持有人、新持有人與 token ID。

一般轉帳的寄件者與接收者地址都不是零地址。

鑄造通常會透過發出從零地址轉移至首位持有人的事件表示。

銷毀通常會透過發出從持有人轉移至零地址的事件表示。

ERC-721 介面未定義公開鑄造或銷毀函式，儘管上述事件模式可用於追蹤代幣生命週期。

事件顯示 NFT 已鑄造，不代表系列供應量固定或鑄造權限受到限制。

Approval

事件

事件會記錄某個 token ID 的核准。

事件包含持有人、獲核准地址與 token ID。

應用程式可用此事件追蹤單一代幣轉移權限的變化。

此事件不應與所有權轉移混淆，因為持有人並未改變。

ApprovalForAll

事件

事件會記錄持有人是否啟用或停用某個操作者。

事件包含持有人、操作者與核准狀態。

監控此事件很重要，因為單一操作者核准可能影響持有人在該系列中持有的所有 NFT。

撤銷事件不會逆轉授權有效期間已執行的轉帳。

ERC-721 選用中繼資料介面

中繼資料擴充功能加入

、 與 。

其 ERC-165 介面 ID 為

。

官方規格將此擴充功能列為選用，但許多 NFT 合約都有實作。

函式會回傳系列的描述性名稱。

函式會回傳合約開發者選擇的簡短識別碼。

函式會回傳與特定 token ID 相關聯的 URI。

系列名稱與符號不具唯一性，因此不應作為唯一的真偽驗證方式。

tokenURI

的運作方式

函式通常會指向 JSON 中繼資料文件。

文件可能包含顯示名稱、描述、圖片位置、動畫與專案專用屬性等欄位。

URI 可使用 HTTPS 位址、去中心化內容識別碼，或鏈上資料 URI。

ERC-721 官方標準允許中繼資料變更。

這表示除非合約或專案提供更強的不變性保證，否則 NFT 顯示的內容可能在鑄造後變更。

目前的ERC-721 開發指南指出，控制鏈下中繼資料儲存位置的一方可以變更其內容。

擁有代幣不會自動確保外部圖片或檔案永久可用。

ERC-721 選用 Enumerable 介面

Enumerable 擴充功能可讓應用程式透過鏈上查詢尋找 token ID。

其 ERC-165 介面 ID 為

。

它加入

、 與 。

函式會回傳合約追蹤的目前有效代幣數量。

索引函式可讓呼叫者從完整供應量或某位持有人的持倉中取得 token ID。

Enumeration 為選用功能，因為維護額外的所有權索引會增加儲存寫入與 Gas 消耗。

許多應用程式會改用鏈下索引，根據

事件重建 NFT 持有資料。

鑄造與銷毀

ERC-721 核心介面不要求提供公開鑄造函式。

每個專案都會自行決定鑄造是開放、受限、排程、設有上限，還是永久停用。

標準也不要求提供公開銷毀函式。

銷毀會依合約實作，從有效所有權紀錄中移除代幣。

使用者應確認誰可以鑄造或銷毀 NFT，以及管理員是否能影響其他帳戶持有的代幣。

符合轉帳介面標準不代表代幣供應量固定。

ERC-721 介面與 ERC-721 實作

介面定義相容性所需的外部行為。

實作則包含實際的儲存、授權、轉帳、鑄造、中繼資料與管理邏輯。

兩個合約可以支援相同的 ERC-721 介面，內部設計卻大不相同。

其中一種實作可能不可變；另一種則可能透過可升級代理合約運作。

其中一種可能供應量固定；另一種則允許管理員無限鑄造。

其中一種可能將中繼資料儲存在鏈上；另一種則指向可變更的伺服器。

使用者應檢視實際實作，而非將介面支援視為完整的安全評估。

ERC-721 與 ERC-20

ERC-20 表示同質化餘額，ERC-721 則表示各自具有識別資訊的代幣。

ERC-20 帳戶可以持有 250 個單位等可分割數量。

ERC-721 帳戶持有的是不同 token ID 的數量。

ERC-721 的

函式會回報帳戶持有的 NFT 數量，而非某個 token ID 的代幣數量。

ERC-721 不要求小數位欄位，因為每個代幣通常以完整單位轉移。

核准方式也不同：ERC-721 支援核准單一代幣，或授予操作者系列層級的控制權。

ERC-721 與 ERC-1155

ERC-721 著重於各自具備識別資訊的非同質化代幣。

ERC-1155 允許單一合約管理多個 token ID，包括同質化、半同質化與非同質化資產。

ERC-1155 帳戶可以持有同一 token ID 的多個單位。

ERC-721 token ID 只有一位持有人，不會為每個帳戶記錄該代幣的數量餘額。

最合適的標準取決於資產模型、轉帳模式、批次操作需求與應用程式要求。

版稅與 ERC-721 介面

ERC-721 核心介面未定義創作者版稅。

獨立的版稅介面可以提供建議的收款對象與金額。

版稅資訊不會自動強制所有轉帳系統支付版稅。

宣稱有版稅的系列應說明資訊如何計算，以及是否可以變更。

使用者不應假設 ERC-721 NFT 一定包含永久或可強制執行的版稅權利。

ERC-721 核准權限的安全風險

核准詐騙是 NFT 持有者面臨的重大風險之一。

惡意網站可能要求呼叫

，卻將簽署操作描述為帳戶驗證或系列存取。

核准生效後，操作者可能無須再次取得持有人授權，就轉移所有受影響的 NFT。

代幣個別核准也可能允許竊取指定 NFT。

簽署前，使用者應檢查操作者地址、NFT 合約、權限類型與網路。

將錢包與網站中斷連線，不會撤銷已記錄在鏈上的核准。

不安全轉帳風險

函式可能將 NFT 傳送至沒有復原機制的合約。

即使之後沒有人能讓接收合約再將 NFT 轉出，交易仍可能成功。

因此，向合約轉帳時通常優先使用

。

不過，安全接收只能證明合約回傳了預期的回呼值。

這不能保證接收者具備有效的提領途徑。

中繼資料與真偽風險

任何人都可以部署採用熟悉系列名稱或符號的 ERC-721 合約。

合約地址是識別系列最重要的技術資訊。

中繼資料也可能包含誤導性名稱、抄襲作品、不安全的外部連結或無法取得的檔案。

由專案管理員控制的 token URI 日後可能會指向不同內容。

鏈上所有權本身無法驗證創作者身分或智慧財產權。

使用者應透過權威來源確認系列地址與專案資訊。

可升級合約風險

ERC-721 實作可能透過可升級代理合約運作。

獲授權的管理員可能在使用者取得 NFT 後，變更轉帳規則、中繼資料邏輯、鑄造權限或其他行為。

升級可以修補錯誤，但也會帶來治理與金鑰遭入侵的風險。

使用者應檢查升級權限、時間鎖、多重簽章控制與管理員角色。

ERC-721 介面支援狀態不會揭露實作中的所有特權函式。

開發者應如何實作 ERC-721

開發者應優先採用經審查且積極維護的實作，而非在沒有充分理由的情況下重新撰寫敏感的所有權邏輯。

目前的OpenZeppelin ERC-721 API提供核心、中繼資料、enumerable、暫停、可銷毀、版稅、投票與接收者相關元件。

鑄造權限應依系列公開說明的供應量政策加以限制。

若 NFT 可能直接鑄造至智能合約，應考慮使用安全鑄造。

應將接收者回呼視為可能觸發重入行為的外部呼叫。

測試應涵蓋所有權、核准、操作者權限、安全接收者、惡意接收者、銷毀、無效 token ID 與未經授權的轉帳。

開發者也應測試介面偵測是否為所有已實作的擴充功能回傳正確值。

應用程式如何偵測 ERC-721 支援

應用程式可以使用核心 ERC-721 介面 ID 呼叫

。

若回傳值為

，表示合約宣稱實作該介面。

應用程式可以另外檢查中繼資料或 Enumerable 介面 ID。

介面偵測比單靠猜測函式名稱更可靠。

不過，撰寫不良或具欺騙性的合約可能回傳不正確資訊。

應用程式應安全處理呼叫失敗與非預期行為，而非假設所有合約都符合標準。

ERC-721 轉帳範例

假設 Alice 在某個 ERC-721 合約中持有 token ID 42。

該合約的

函式會回傳 token ID 42 的持有人地址為 Alice。

Alice 決定將 NFT 傳送至智能合約。

她的錢包會呼叫

，並傳入 Alice 的地址、接收合約與 token ID 42。

NFT 合約會驗證 Alice 是否為代幣持有人，以及她是否獲授權進行轉帳。

合約會更新所有權，並呼叫接收者的

。

接收者會檢查 NFT 合約、操作者、先前持有人與 token ID。

若接收者回傳正確選擇器，轉帳就會完成，並發出

事件。

若接收者拒絕回呼，整筆交易就會回退，Alice 仍為持有人。

常見的 ERC-721 介面錯誤

常見錯誤之一，是以為系列名稱可以唯一識別 NFT 合約。

另一個錯誤是將

視為單一 token ID 的數量。

第三個錯誤是在傳送至未知智能合約時使用

。

第四個錯誤是未檢查操作者地址，就授予系列層級的核准權限。

第五個錯誤是以為將錢包中斷連線就會撤銷鏈上核准。

第六個錯誤是未檢查 token URI，就認為中繼資料永久儲存在鏈上。

第七個錯誤是以為 ERC-721 強制要求支付版稅。

第八個錯誤是以為所有 ERC-721 合約都支援 enumeration。

第九個錯誤是忽略接收者回呼期間的重入風險。

第十個錯誤是將 ERC-165 支援視為實作安全或真實的證明。

常見問題

什麼是 ERC-721 介面？

ERC-721 介面是一組標準化函式與事件，用於追蹤非同質化代幣的所有權、核准與轉帳。

ERC-721 介面 ID 是什麼？

ERC-721 核心介面 ID 為

。

ERC-721 合約的 balanceOf 會回傳什麼？

它會回傳某地址在該合約中持有的不同 NFT 數量。

ownerOf 的功能是什麼？

它會回傳有效 token ID 目前的持有人。

transferFrom 與 safeTransferFrom 有什麼差異？

會檢查接收合約是否支援 ERC-721 接收者回呼； 則不會。

什麼是 onERC721Received？

這是智能合約透過安全轉帳接收 NFT 時，用來確認能夠接收 NFT 的回呼函式。

安全 NFT 轉帳可能失敗嗎？

可能。若授權檢查失敗，或接收合約未回傳預期的回呼選擇器，轉帳就會失敗。

approve 有什麼作用？

它會授權一個地址轉移某個特定 NFT。

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 中繼資料可以變更嗎？

可以。除非實作提供更強的不變性保證，否則標準允許變更 token URI。

符合 ERC-721 標準能證明 NFT 真實嗎？

不能。任何人都能部署相容合約，因此使用者必須另外驗證合約地址與發行者。

結論

ERC-721 介面為 Ethereum 相容應用程式中的非同質化代幣，提供共通的所有權、核准、轉帳與事件規則。

其核心介面 ID 為

，合約會透過 ERC-165 介面偵測發布此資訊。

必要函式讓應用程式能查詢餘額與持有人、核准轉移權限，並移動唯一 token ID。

安全轉帳函式要求 ERC-721 接收者回呼，可降低 NFT 意外轉移至不相容合約的風險。

此回呼也會形成外部呼叫與重入風險，開發者必須謹慎處理。

中繼資料與 Enumeration 是選用介面，各自具有不同識別碼，也涉及額外 Gas 或信任考量。

此標準未定義鑄造權限、銷毀權利、版稅、供應量上限、中繼資料永久性、法律所有權或系列真偽。

使用者與 NFT 互動前，應驗證合約地址、檢查操作者核准、確認中繼資料的儲存方式，並了解升級權限。

開發者應採用持續維護的實作、測試所有授權流程，並將 NFT 接收者回呼視為可能帶有惡意的程式碼。

了解 ERC-721 介面，有助於加密貨幣使用者區分標準化 NFT 相容性，以及個別系列更廣泛的經濟、法律與安全特性。