買幣
行情
現貨
合約BTC
理財
活動中心
福利中心
更多
0 費狂歡節
ERC-20: 什麼是 ERC-20?ERC-20 是 Ethereum 的代幣標準,為透過智能合約建立的可互換加密資產定義共通介面。可互換代表同一代幣的相同單位,依照代幣合約的計算規則可以互相替代。例如,普通 ERC-20 代幣的一個完整單位,依合約定義的屬性,與同種代幣的另一個完整單位相同。官方ERC-20 規範定義了用於查詢代幣供應量和餘額、轉移代幣,以及授權第三方使用代幣的函式。此標準也定義了標準化事件,ERC-20: 什麼是 ERC-20?ERC-20 是 Ethereum 的代幣標準,為透過智能合約建立的可互換加密資產定義共通介面。可互換代表同一代幣的相同單位,依照代幣合約的計算規則可以互相替代。例如,普通 ERC-20 代幣的一個完整單位,依合約定義的屬性,與同種代幣的另一個完整單位相同。官方ERC-20 規範定義了用於查詢代幣供應量和餘額、轉移代幣,以及授權第三方使用代幣的函式。此標準也定義了標準化事件,

ERC-20

2026/10/13 15:30
#Intermediate
Humanity
H$0.05815-0.34%
SynFutures
F$0.003113+6.20%
PX
PX$0.0113--%
TokenFi
TOKEN$0.001935+2.16%
Solana
SOL$106.64-0.93%

什麼是 ERC-20?

ERC-20 是 Ethereum 的代幣標準,為透過智能合約建立的可互換加密資產定義共通介面。

可互換代表同一代幣的相同單位,依照代幣合約的計算規則可以互相替代。

例如,普通 ERC-20 代幣的一個完整單位,依合約定義的屬性,與同種代幣的另一個完整單位相同。

官方ERC-20 規範定義了用於查詢代幣供應量和餘額、轉移代幣,以及授權第三方使用代幣的函式。

此標準也定義了標準化事件,讓錢包和應用程式能觀察轉移和核准變更。

ERC-20 是最終版 Ethereum Request for Comments 標準,也是 Ethereum 相容生態系統中可互換代幣的主要技術基礎。

此標準提升了互通性,因為錢包、智能合約、區塊鏈瀏覽器、託管系統和其他加密貨幣應用程式都能使用相同的基本方法支援多種代幣。

ERC-20 不會決定代幣價格、供應量政策、法律分類、用途、抵押品支持、治理權或投資品質。

ERC 代表什麼?

ERC 是 Ethereum Request for Comments 的縮寫。

ERC 描述開發者可在 Ethereum 智能合約和相關軟體中實作的應用層標準或慣例。

數字 20 是用來識別提出此可互換代幣介面的提案編號。

它不代表代幣數量、小數位數、支援的網路或合約函式數量。

ERC-20 也常稱為 EIP-20,因為該文件屬於 Ethereum 改進提案流程。

為什麼要建立 ERC-20?

在建立共通的可互換代幣標準之前,各智能合約可能會對餘額查詢、轉移和委派支出使用不同名稱和規則。

錢包必須為每種代幣撰寫自訂整合程式碼。

去中心化應用程式也無法安全假設兩個代幣合約支援相同操作。

ERC-20 建立了最低限度的共通介面,讓一個應用程式能與多種可互換代幣互動。

這種互通性有助於代幣餘額應用於支付、治理、借貸、流動性系統、金庫、遊戲、獎勵計畫和其他加密貨幣應用程式。

此標準刻意維持精簡,讓開發者可以加入專門功能,而不必變更基本介面。

ERC-20 的運作方式

ERC-20 代幣由部署在 Ethereum 或相容區塊鏈上的智能合約控制。

合約會記錄每個地址持有的代幣單位數。

合約也會記錄代幣總供應量,以及持有者授予支出者的授權額度。

有效轉移發生時,合約會減少傳送者的餘額,並增加接收者的餘額。

合約會發出

Transfer
事件,讓外部軟體觀察這筆轉移。

持有者核准支出者時,合約會更新授權額度並發出

Approval
事件。

區塊鏈節點會執行合約規則,並驗證每項已接受的狀態變更是否有效。

代幣合約不會維持獨立區塊鏈,因為它運作於所在網路的狀態和安全模型中。

ERC-20 核心函式

ERC-20 必要介面包含 6 個主要函式。

這些函式為

totalSupply
、
balanceOf
、
transfer
、
allowance
、
approve
和
transferFrom
。

標準也說明了選用的

name
、
symbol
和
decimals
中繼資料函式。

鑄造、銷毀、暫停、課稅、投票、凍結和供應量上限都不是核心介面的必要功能。

代幣可以透過自訂邏輯或標準化擴充功能加入這些功能。

totalSupply 函式

totalSupply
函式會傳回目前納入代幣供應量計算的代幣單位數。

其數值以代幣最小的內部單位表示。

此數值不會自動揭露可能存在的最大供應量。

即使目前總供應量遠低於宣稱的上限,合約仍可能允許日後鑄造更多代幣。

代幣也可能支援銷毀,進而降低目前總供應量。

使用者應檢視鑄造權限和供應量控制,而不是將

totalSupply
視為永久稀缺性的證明。

balanceOf 函式

balanceOf
函式會傳回特定地址登記的代幣餘額。

結果以代幣最小的內部單位表示。

錢包顯示的餘額通常會依代幣小數位設定,將此整數格式化後顯示。

此函式只會回報單一代幣合約中的餘額。

它不會包含在其他合約地址或其他網路上建立的同名代幣。

一些特殊代幣可能透過重基或其他計算邏輯改變餘額,且不會為每位持有者發出一般轉移事件。

transfer 函式

transfer
函式會將指定數量從呼叫者的餘額轉至接收者。

呼叫者必須有足夠的代幣才能完成操作。

成功轉移時,必須發出

Transfer
事件。

ERC-20 規範要求,零數量轉移必須視為一般轉移處理,並發出該事件。

依照標準,此函式會傳回布林值,表示操作是否成功。

應用程式不得假設不可能傳回

false
。

許多現代實作在失敗時會回復,而非傳回

false
,但整合方仍須考量特定代幣的行為。

approve 函式

approve
函式可讓代幣持有者設定支出者能從其餘額轉移多少代幣。

代幣不會立即轉給支出者。

合約會記錄授權額度,供支出者日後透過

transferFrom
使用。

核准適用於一位持有者、一位支出者和一個代幣合約。

在一個網路或代幣合約上的核准,不會自動授權在其他地方支出代幣。

使用者應將核准交易視為金融權限,而不是無害的錢包連線。

allowance 函式

allowance
函式會回報目前支出者獲授權可從持有者處轉移多少代幣。

支出者使用

transferFrom
後,該數值可能減少。

持有者可以透過另一筆核准交易更新此數值。

有些實作會將無號整數最大值視為無限核准,且在每次轉移後不一定會減少此數值。

只要支出者仍有存取權,且持有者仍有代幣餘額,無限核准就會持續構成風險。

使用者應檢查並撤銷不再需要的權限。

transferFrom 函式

transferFrom
函式可讓已核准的支出者將代幣從持有者轉給接收者。

支出者必須有足夠的授權額度,且持有者必須有足夠餘額。

除非實作將授權視為無限額度,否則成功呼叫通常會減少可用授權額度。

此函式必須為代幣轉移發出

Transfer
事件。

這種委派轉移模型讓智能合約可以收取款項、接受存入、鎖定抵押品,或執行其他已核准操作。

此模型也帶來風險,因為惡意或遭入侵的支出者可以使用剩餘授權額度,無須每次轉移都再次取得持有者核准。

ERC-20 事件

ERC-20 標準定義了

Transfer
和
Approval
事件。

事件是交易紀錄,可供鏈下應用程式有效率地索引。

錢包、分析工具、會計系統和區塊鏈瀏覽器會使用這些紀錄追蹤代幣活動。

解讀事件時,務必同時確認發出事件的合約地址。

惡意合約也可以使用熟悉的事件名稱,但不代表它是真實或有價值的代幣。

Transfer 事件

Transfer
事件會記錄傳送者、接收者和代幣數量。

一般轉移會使用非零的傳送者和接收者地址。

代幣建立通常會以從零地址轉移至接收者的方式表示。

代幣銷毀通常會以從持有者轉移至零地址的方式表示。

ERC-20 規範要求,實作建立代幣供應量時,必須為新建立的代幣發出從零地址開始的

Transfer
事件。

觀察到鑄造事件,不代表未來不可能繼續鑄造。

Approval 事件

Approval
事件會記錄持有者、支出者和授權額度。

應用程式可以使用此事件追蹤委派支出權限的變更。

核准本身不會轉移代幣或變更所有權。

它讓支出者可以在許可額度內使用

transferFrom
。

撤銷授權額度不會逆轉權限有效期間內已完成的代幣轉移。

ERC-20 名稱和代號

name
和
symbol
函式提供易讀的代幣資訊。

名稱可能用來描述資產,代號則是較短的顯示標籤。

這兩個函式在原始 ERC-20 規範中皆為選用功能。

名稱和代號並非唯一。

任何人都可以部署名稱和代號與其他資產相同的代幣。

錢包和使用者應確認完整合約地址和區塊鏈網路,而不是只依賴品牌名稱。

什麼是 ERC-20 小數位數?

選用的

decimals
函式會告訴應用程式,如何將代幣最小單位格式化為易讀的顯示方式。

使用 18 位小數的代幣,在標準顯示方式下會將內部整數數量除以 10 的 18 次方。

例如,若代幣使用 6 位小數,內部數量 1,000,000 單位就代表一枚代幣。

小數位數不會將區塊鏈餘額變成浮點數。

智能合約以整數執行代幣計算。

小數位數會影響顯示和面額,而非底層算術模型。

18 位小數相當常見,也是目前 OpenZeppelin ERC-20 實作的預設值,但 ERC-20 代幣也可以使用其他數值。

ERC-20 供應量模型

ERC-20 不規定代幣供應量必須如何建立。

固定供應量代幣可以在部署時鑄造全部供應量,且不提供日後鑄造函式。

設有上限的代幣可以允許持續鑄造,直到達到合約定義的最大供應量。

無上限代幣可以允許授權帳戶或協議流程建立額外單位,且不設永久上限。

演算法代幣可以依程式設定的條件調整供應量。

包裝代幣可以在底層資產存入時發行代幣,並在該資產提領時銷毀代幣。

官方 ERC-20 供應量指南說明,必須透過適當的鑄造機制,在基礎實作中加入供應量邏輯。

鑄造 ERC-20 代幣

鑄造會建立新的代幣單位,並增加總供應量。

ERC-20 核心介面未定義公開鑄造函式,也未規定誰可以呼叫此函式。

代幣可以限制只有管理員、治理流程、跨鏈橋、質押系統、金庫或合約定義的其他權限方才能鑄造。

不安全的鑄造權限可能稀釋現有持有者的權益,或破壞抵押品假設。

使用者應檢查是否可以鑄造、由誰控制、是否設有上限,以及實作是否可以升級。

宣稱代幣供應量固定時,應透過已部署合約邏輯和特權權限加以驗證。

銷毀 ERC-20 代幣

銷毀會消除代幣單位,通常也會降低總供應量。

核心標準不要求持有者必須擁有公開銷毀函式。

實作可以允許持有者銷毀自己的代幣,也可以允許已核准支出者透過授權額度銷毀代幣。

其他系統則只會在贖回、結算或協議操作期間銷毀代幣。

將代幣傳送至無法存取的地址,不一定等同於透過合約銷毀,因為回報的總供應量可能維持不變。

使用者在解讀供應量資料前,應檢查代幣實際的銷毀邏輯。

ERC-20 核准與授權額度競爭條件

直接將現有非零授權額度改為另一個非零數量,可能產生交易排序風險。

支出者可能在持有者的新核准交易確認前使用舊授權額度,之後又取得新的授權額度。

原始 ERC-20 規範指出,使用者介面應先將授權額度設為 0,再指定不同的非零數量。

代幣合約本身不應強制要求此操作順序,否則會降低與舊版應用程式的相容性。

透過精心設計的輔助函式調降或增加授權額度,可提升易用性,但各實作的支援程度不一。

使用者應避免留下超出應用程式合理需求的授權額度。

無限代幣核准

無限核准通常會將授權額度設為 256 位元無號整數可支援的最大值。

這種做法可減少每次互動前都必須提交新核准的需求。

但支出者也因此持續獲得支出此代幣目前和未來餘額的權限。

若支出者合約遭到利用、遭惡意升級,或由遭入侵的管理員控制,支出者就可能使用該授權額度轉走持有者的代幣。

使用者應權衡便利性,以及授予權限的金額和期間。

有限額度的核准可降低單一支出者遭入侵時可能造成的最高損失。

什麼是 ERC-2612 Permit?

ERC-2612 是一項擴充功能,允許 ERC-20 持有者透過簽署訊息建立授權額度。

其他帳戶或智能合約可以將已簽署的權限提交至鏈上。

這有助於將核准和應用程式操作整合成單一使用流程。

官方ERC-2612 permit 規範在 ERC-20 中加入

permit
、
nonces
和
DOMAIN_SEPARATOR
。

每次成功的 permit 都會使用一個 nonce,通常可防止同一簽章重複使用。

截止時間會限制簽章的有效期間。

Permit 支援是選用功能,不屬於原始 ERC-20 核心介面。

Permit 簽章風險

Permit 簽章可以授權代幣支出,即使簽署本身不會立即由持有者在鏈上提交交易。

網路釣魚網站可能將 permit 描述為登入、驗證或無害的免 Gas 費訊息。

支出者可以在之後提交有效的已簽署 permit,並在截止時間前使用由此產生的授權額度。

簽署前,使用者應檢查代幣、支出者、金額、網路、nonce 和到期時間。

錢包顯示不需支付 Gas 費,不代表簽章請求就是安全的。

合約錢包可能需要基本外部擁有帳戶模式以外的額外簽章驗證支援。

ERC-20 支援自動接收者回呼嗎?

ERC-20 核心轉移函式不要求接收方智能合約確認收到代幣。

因此,即使接收者合約沒有記錄或退回代幣的函式,轉移仍可能成功。

這可能導致資產困在不相容的合約中。

一般轉移後,ERC-20 也不會自動呼叫接收者程式碼。

ERC-1363 擴充功能加入了轉移並回呼,以及核准並回呼操作,供需要回呼行為的應用程式使用。

支援回呼的擴充功能會加入外部呼叫,因此必須檢查重入和接收者安全風險。

SafeERC20 與非標準代幣

ERC-20 規範指出,呼叫者必須處理傳回值為

false
的情況。

實際上,有些舊版或特殊代幣合約即使轉移成功,也不會傳回布林值。

其他實作則會在失敗時回復,而非傳回

false
。

假設代幣只有單一行為的直接介面呼叫,可能會失敗或錯誤解讀結果。

目前的 SafeERC20 工具會包裝代幣操作,並處理傳回 false 的代幣,以及部分不傳回任何值的代幣。

包裝工具可提升相容性,但無法讓惡意代幣在經濟層面變得安全。

轉帳收費代幣

轉帳收費代幣會在代幣移動時扣除費用。

接收者取得的代幣會少於傳送者或呼叫合約要求的數量。

協議若依要求轉入的數量記帳,而非依實際收到的數量記帳,可能會造成抵押不足。

若應用程式支援這種代幣行為,應比較轉移前後的代幣餘額。

若合約可升級或由管理員控制,費用規則也可能變更。

ERC-20 標準函式名稱不保證轉移結果固定不變。

重基 ERC-20 代幣

重基代幣會依合約定義的調整流程變更帳戶餘額。

balanceOf
顯示的餘額可能在持有者未發起一般轉移的情況下增加或減少。

正向重基會增加顯示餘額,負向重基則會降低餘額。

部分系統使用內部份額,並透過兌換率計算可見餘額。

假設餘額只會透過轉移變更的應用程式,可能會錯誤計算重基代幣。

使用者應了解代幣代表固定數量餘額,還是會變動的按比例請求權。

包裝 ERC-20 代幣

包裝 ERC-20 代幣透過智能合約或託管安排代表其他資產。

使用者可以存入底層資產,並取得相應的 ERC-20 單位。

贖回時通常會銷毀或退回包裝代幣,並釋出底層資產。

包裝代幣的價值取決於其支持機制是否可用且健全。

智能合約漏洞、託管失敗、跨鏈橋故障、抵押品遭凍結或計算錯誤,都可能破壞預期的對應關係。

符合 ERC-20 標準只能證明介面相容,不代表有足夠資產支持。

ERC-20 治理代幣

ERC-20 代幣可以擴充為代表鏈上治理系統的投票權。

投票可能依據目前餘額、委託餘額或歷史餘額快照計算。

目前的 ERC-20 實作函式庫包含 ERC-20 投票擴充功能,可用於委託和歷史投票權查詢。

持有治理代幣不一定會自動啟用投票權,因為有些系統要求先進行委託。

代幣投票也可能受到持有權集中、借入資產、投票率偏低和管理員權限影響。

ERC-20 核心標準不定義治理規則。

ERC-20 金庫份額

ERC-20 代幣可以代表代幣化金庫的份額。

每份額代表對金庫管理資產的按比例請求權,而非固定數量的底層代幣。

ERC-4626 代幣化金庫標準在 ERC-20 中加入標準化的存入、提領、鑄造、贖回和換算函式。

金庫份額的底層價值可能依策略績效、費用、損失和計算規則而增加或減少。

僅符合 ERC-20 標準,無法說明份額代幣由什麼支持,或如何贖回。

ERC-20 錯誤訊息

原始 ERC-20 標準早於 Solidity 自訂錯誤,因此沒有定義標準化的錯誤訊息。

不同代幣可能傳回

false
、以文字訊息回復、以自訂錯誤回復,或出現錯誤行為。

最終版 ERC-6093 標準為常見代幣操作失敗定義了結構化自訂錯誤。

例如餘額不足、傳送者無效、接收者無效、授權額度不足、核准者無效和支出者無效等錯誤。

標準化錯誤有助於錢包和應用程式以更一致的方式說明失敗原因。

ERC-6093 不會變更 ERC-20 核心介面,也不要求所有既有代幣都採用其錯誤機制。

ERC-20 使用 ERC-165 嗎?

原始 ERC-20 標準不要求 ERC-165 介面偵測。

應用程式不能假設呼叫

supportsInterface
就能識別所有 ERC-20 代幣。

軟體通常會透過合約 ABI、已驗證原始碼、已知代幣清單、登錄資料和直接函式測試來識別相容性。

存在熟悉的函式選擇器,不代表完全符合標準。

惡意合約可以模仿部分介面,同時執行有害或非預期行為。

ERC-20 與原生 ETH 的差異

ETH 是 Ethereum 的原生加密資產,本身並非 ERC-20 代幣。

Ethereum 帳戶可以透過協議層級的價值轉移傳送原生 ETH。

ERC-20 餘額則存在於個別智能合約中。

即使轉移的資產是 ERC-20 代幣,支付 Ethereum 交易手續費仍需要 ETH,除非另有系統代付或抽象化手續費。

需要代幣介面的應用程式可以建立 ERC-20 形式的 ETH,但這種包裝資產仍與原生 ETH 不同。

ERC-20 與 ERC-721 的差異

ERC-20 代表可互換餘額,ERC-721 則代表可個別識別的非同質化代幣。

ERC-20 帳戶持有可互換單位的數量。

ERC-721 帳戶持有不同的代幣 ID。

ERC-20 通常使用小數位格式,而一個 ERC-721 代幣通常以完整且獨特的單位轉移。

ERC-721 也包含安全轉移接收者檢查,而 ERC-20 核心標準沒有這項功能。

ERC-20 與 ERC-1155 的差異

ERC-20 透過每個合約介面管理一種可互換代幣。

ERC-1155 允許一個合約管理多個代幣 ID,並為各 ID 記錄不同餘額。

ERC-1155 的代幣 ID 可以代表可互換、半同質化或獨特資產。

ERC-1155 也定義了批次轉移操作和接收者回呼。

應採用哪一種標準,取決於專案需要的是單一可互換資產,還是由一個合約管理多種資產類型。

ERC-20 的常見應用場景

穩定價值代幣可以使用 ERC-20 代表與儲備、抵押系統或演算法機制相關聯的可轉移單位。

治理系統可以將 ERC-20 餘額或委託單位用作投票權。

區塊鏈遊戲可以使用 ERC-20 代幣作為可互換的遊戲貨幣、獎勵或資源。

金庫和質押系統可以發行 ERC-20 收據代幣,代表存入的部位。

包裝資產可以使用 ERC-20 代表對其他地方持有資產的請求權。

專案也可以使用此標準建立忠誠度點數、存取額度、支付單位或代幣化金融請求權。

此介面不會決定特定用途是否合法、是否有足額支持、是否去中心化或經濟上是否永續。

ERC-20 智能合約風險

ERC-20 實作可能在轉移、授權額度、鑄造、銷毀、課稅或存取控制邏輯中出現錯誤。

特權管理員可能可以暫停轉移、凍結餘額、封鎖地址、鑄造供應量、變更費用或升級合約。

代理合約升級可能在持有者取得代幣後改變代幣行為。

自訂代幣邏輯中的外部呼叫可能造成重入或阻斷服務風險。

即使代幣本身依照程式碼運作,錯誤整合仍可能導致資金損失。

符合標準有助於提升互通性,但不能取代稽核、測試、原始碼檢視和權限分析。

代幣核准網路釣魚

核准網路釣魚會試圖誘使使用者授權惡意支出者。

介面可能將此操作描述為驗證、連線、確認獎勵資格或復原帳戶。

核准確認後,支出者就能透過

transferFrom
在授權額度內轉走代幣。

Permit 簽章也可能產生類似權限,但受害者不必立即在鏈上提交核准交易。

使用者應確認每筆核准或 permit 的代幣合約、支出者地址、授權額度、網路和用途。

取消 ERC-20 授權時,絕不可將助記詞或私鑰輸入應用程式。

代幣轉移詐騙

詐騙者可以在未經持有者同意的情況下,將未知 ERC-20 代幣傳送至錢包。

代幣名稱、代號或中繼資料可能包含誤導性網站或宣稱。

與宣傳網站互動可能導致惡意核准或簽章。

攻擊者也可能建立外觀與使用者交易歷史地址相似的地址。

使用者應從可信紀錄複製已驗證地址,而不是只依據開頭和結尾字元相符來選擇目的地。

收到未知代幣,不代表錢包持有者需要與該代幣互動。

開發者如何實作 ERC-20

開發者通常應從經審查且持續維護的實作開始。

目前的 ERC-20 開發指南提供核心合約,以及 permit、上限、銷毀、暫停、投票、包裝、金庫和其他功能的擴充功能。

供應量建立方式應明確定義,並採用適當存取控制。

轉移自訂功能應維持餘額、供應量、事件和授權額度的不變條件。

開發者應測試零數量轉移、最大數值、餘額不足、授權額度不足、鑄造、銷毀、核准,以及涉及特殊地址的轉移。

若支援這些資產,也應測試傳回 false、不傳回值、轉帳收費、重基、暫停和支援回呼的代幣。

使用者如何評估 ERC-20 代幣

第一步是確認區塊鏈網路和完整代幣合約地址。

第二步是檢查目前供應量、最大供應量宣稱和鑄造權限。

第三步是檢視管理員、暫停、凍結、封鎖名單、費用和升級權限。

第四步是確認代幣是否由其他資產支持,以及如何贖回。

第五步是了解轉移費用、重基行為、限制和特殊錢包影響。

第六步是檢視稽核、已驗證原始碼和事故歷史,但不要將稽核視為保證。

第七步是檢查持有者集中度、可用流動性,以及可能導致流動性消失的條件。

第八步是了解需求或收益的實際來源,而不是只相信代幣品牌宣傳。

第九步是在使用不熟悉的智能合約前後檢查核准狀態。

第十步是在投入大量資金前,先以有限金額測試新代幣或合約。

ERC-20 轉移範例

假設 Alice 持有 500 單位 ERC-20 代幣,並想轉 75 單位給 Bob。

Alice 的錢包會確認區塊鏈、代幣合約、接收者地址、數量和交易手續費是否正確。

錢包會提交一筆呼叫代幣

transfer
函式的交易。

代幣合約會確認 Alice 至少持有 75 單位。

合約會將 Alice 的餘額降至 425 單位,並將 Bob 的餘額增加 75 單位。

合約會發出

Transfer
事件,記錄 Alice 的地址、Bob 的地址和轉移數量。

Ethereum 驗證者會將交易納入區塊,節點也會獨立驗證最終狀態變更。

交易確認後,錢包和應用程式就能從代幣合約讀取更新後的餘額。

ERC-20 核准範例

假設 Alice 希望某金庫合約代她存入 100 單位 ERC-20 代幣。

Alice 會先確認金庫合約地址,以及金庫將使用哪種代幣。

她呼叫

approve
,授予金庫 100 單位的授權額度。

代幣合約會記錄授權額度並發出

Approval
事件。

接著,Alice 呼叫金庫的存入函式。

金庫會使用

transferFrom
,將 100 單位從 Alice 轉入金庫。

完成轉移前,代幣合約會檢查 Alice 的餘額和金庫的授權額度。

轉移後,已使用的授權額度通常會依代幣實作方式減少。

常見的 ERC-20 錯誤

常見錯誤之一,是只憑代幣名稱或代號識別代幣。

另一個錯誤是以為每種 ERC-20 代幣都使用 18 位小數。

第三個錯誤是向不受信任的合約授予無限核准。

第四個錯誤是以為將錢包中斷連線就能撤銷代幣授權額度。

第五個錯誤是忽略代幣轉移的布林值結果或非標準行為。

第六個錯誤是以要求存入的數量記帳,而非以實際收到的數量記錄轉帳收費代幣存款。

第七個錯誤是將

totalSupply
視為永久供應量上限的證明。

第八個錯誤是以為符合 ERC-20 標準就能證明有抵押品支持或贖回價值。

第九個錯誤是未檢查支出者、金額和截止時間就簽署 permit。

第十個錯誤是將稽核或已驗證原始碼視為代幣不會發生問題的保證。

常見問題

ERC-20 代表什麼?

ERC-20 是 Ethereum 標準,為智能合約建立的可互換代幣定義共通函式和事件。

ERC-20 是加密貨幣嗎?

ERC-20 是技術標準,而實作此標準的個別合約可以建立加密貨幣代幣。

ERC-20 就是 Ethereum 嗎?

不是,Ethereum 是區塊鏈網路,而 ERC-20 是用於該網路上代幣的智能合約介面。

ETH 是 ERC-20 代幣嗎?

不是,ETH 是 Ethereum 的原生資產,本身不使用 ERC-20 合約介面。

ERC-20 代幣是可互換的嗎?

是,同一普通 ERC-20 代幣的相同單位,依合約的計算規則可以互相替代。

ERC-20 六個核心函式是什麼?

分別是

totalSupply
、
balanceOf
、
transfer
、
allowance
、
approve
和
transferFrom
。

ERC-20 定義哪些事件?

此標準定義了

Transfer
和
Approval
事件。

name、symbol 和 decimals 是必要項目嗎?

不是,這三種中繼資料函式在原始 ERC-20 規範中都是選用功能。

所有 ERC-20 代幣都使用 18 位小數嗎?

不是,18 位小數很常見,但每種代幣都可以使用不同的小數位數。

ERC-20 核准有什麼作用?

它會授予支出者權限,使其能在指定授權額度內轉移持有者的代幣。

transferFrom 有什麼用途?

它可讓已授權的支出者將代幣從持有者轉給接收者。

什麼是 ERC-20 無限核准?

這是將授權額度設為極大值,讓支出者可持續轉移代幣,而不必重複取得核准。

將錢包中斷連線會撤銷核准嗎?

不會,鏈上授權額度會持續有效,直到透過代幣合約變更,或因其他原因失效。

什麼是 ERC-20 permit?

Permit 是選用的 ERC-2612 簽署訊息,可建立或變更授權額度,而無須由持有者直接提交核准交易。

ERC-20 代幣可以鑄造嗎?

可以,只要實作包含鑄造機制,且有獲授權方或協議條件可以使用該機制。

ERC-20 代幣可以銷毀嗎?

可以,只要實作包含銷毀代幣單位的合約邏輯。

ERC-20 要求固定供應量嗎?

不要求,供應量政策由個別代幣實作決定。

ERC-20 轉移可以收取費用嗎?

可以,自訂代幣可以扣除轉移費用,雖然這不是核心標準要求的行為。

ERC-20 餘額可以在沒有轉移的情況下改變嗎?

可以,重基和其他自訂計算模型可能在沒有一般持有者轉移的情況下變更回報的餘額。

ERC-20 代幣可能卡在合約中嗎?

可能,核心轉移函式不要求接收合約確認其能處理或退回代幣。

ERC-20 支援 ERC-165 介面偵測嗎?

不支援,原始 ERC-20 規範不要求 ERC-165。

ERC-20 會保證代幣有資產支持嗎?

不會,此標準不會驗證儲備、抵押品、贖回權或償付能力。

符合 ERC-20 標準會讓代幣安全嗎?

不會,相容代幣仍可能具有危險權限、有缺陷的程式碼、薄弱的資產支持、流動性不足或惡意操作者。

使用者如何識別正確的 ERC-20 代幣?

使用者應透過可信來源確認區塊鏈網路和完整合約地址。

ERC-20 的主要優點是什麼?

其主要優點是透過共通介面提升互通性,讓許多加密貨幣錢包和智能合約都能理解。

結論

ERC-20 是 Ethereum 可互換智能合約代幣的基礎標準。

它定義了查詢供應量和餘額、轉移代幣,以及授予委派支出權限的共通方法。

其

Transfer
和
Approval
事件讓加密貨幣應用程式能監控代幣移動和權限。

選用中繼資料函式可提供代幣名稱、代號和小數位設定,但這些資訊無法證明代幣真偽。

此標準不會決定供應量如何建立、代幣是否有資產支持、由誰管理,或資產是否具有金融價值。

擴充功能可以加入簽署式 permit、投票、暫停、供應量上限、回呼、金庫功能、標準化錯誤和其他功能。

核准仍是使用者面臨的主要風險之一,因為惡意支出者可以透過

transferFrom
使用有效授權額度。

開發者必須處理傳回 false、不傳回值、轉移費用、重基、回呼、特殊小數位數和自訂限制。

使用者應確認合約地址、檢查權限、了解鑄造和升級權限,並調查代幣的資產支持和經濟設計。

ERC-20 相容性建立了共通的技術語言,但無法取代智能合約安全、謹慎審查交易或獨立金融研究。
ETF單週失血6.79億,花旗看多BTC至11.3萬!
ETF單週失血6.79億,花旗看多BTC至11.3萬!ETF單週失血6.79億,花旗看多BTC至11.3萬!
機構在賭什麼?