---
title: "USDC 入帳確認 2026：鏈別與賞金驗證方法"
locale: zh-hant
category: how_to
category_name: "操作教學"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/usdc-deposit-verification-2026-chain-contract-transfer-bounty
published_at: 2026-10-23T22:01:25+09:00
---

# USDC 入帳確認 2026：鏈別與賞金驗證方法

> USDC 入帳須透過鏈別、官方合約、收款地址及數量均相符的轉帳紀錄確認。檢查交易是否成功及最終性後，再與賞金支付承諾、退款及自有帳戶間轉帳區分。

## Key Points

- 確認約定收款的鏈別與官方 USDC 合約地址。
- 在您的錢包或收款服務中，確認所選鏈別的收款地址。
- 在該鏈的區塊鏈瀏覽器中，核對交易是否成功及 Transfer 事件。
- 確認交易所在區塊的最終性。
- 與工作報酬對應後，將退款、自有帳戶間轉帳及重複紀錄另行分類。

USDC 入帳須透過約定鏈上的官方代幣轉帳來確認。收款地址與數量都必須相符。也請另外確認交易是否成功及區塊最終性。不能只憑公告的報酬金額或雜湊值，就認定懸賞報酬已支付。

請到 Circle、Ethereum、Base 的官方文件再次核對地址與鏈 ID。（核對值 Ethereum Mainnet：鏈 ID 1，USDC 合約 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48。Base Mainnet：鏈 ID 8453 0x2105 ，USDC 合約 · 來源 developers.circle.com · 2026-10-23 核對）

## 各鏈的 USDC 合約地址與鏈 ID

Ethereum 與 Base 的 USDC 使用不同的合約地址。鏈 ID 是用來區分網路的編號。代幣合約地址用來識別該鏈上的代幣。收款地址則是接收款項的錢包或帳戶地址。

撰寫與文件核對日期為 2026年10月23日。下表適用於主網上由 Circle 發行的 USDC。主網是使用具有實際價值資產的網路。

| 網路 | 鏈 ID，十進位 | 鏈 ID，十六進位 | 官方 USDC 合約地址 | 區塊鏈瀏覽器 |
|---|---:|---|---|---|
| Ethereum Mainnet | 1 | `0x1` | `0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48` | Etherscan |
| Base Mainnet | 8453 | `0x2105` | `0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913` | BaseScan |

合約地址的依據是 [Circle 的 USDC contract addresses](https://developers.circle.com/stablecoins/usdc-contract-addresses)。Ethereum 鏈 ID 已載明於 [EIP-155](https://eips.ethereum.org/EIPS/eip-155)。Base 鏈 ID 可在 [Base 的 eth_chainId 文件](https://docs.base.org/base-chain/api-reference/ethereum-json-rpc-api/eth_chainId)中確認。

即使收款地址字串相同，只要鏈不同，就是獨立的紀錄。Ethereum 的入帳不會自動併入 Base 餘額。請勿將 Sepolia 等測試網上的 USDC 計入實際款項。

## 確認收款地址與交易的順序

先確定付款條件，就比較不容易將其他交易誤認為款項。這個流程只是讀取公開交易紀錄。查詢區塊鏈瀏覽器不需要連接錢包或簽署。

1. 確認付款協議中的網路與代幣。請區分公告中以美元標示的金額與實際要支付的 USDC 數量。
2. 從收款錢包複製該網路的收款地址。若使用交易所，請以該服務的入金畫面為準。也請確認服務支援的網路。
3. 在 Circle 的 Mainnet 表格中找到該鏈的合約地址。不要只憑代幣名稱或標誌判斷。
4. 在該鏈的區塊鏈瀏覽器搜尋 txHash。txHash 是用來尋找交易的識別值。若沒有搜尋結果，請再次核對網路與雜湊值。
5. 確認交易詳情中的狀態與代幣轉帳紀錄。接著在 Logs 分頁核對實際的 Transfer 事件。

查不到的雜湊值還不能作為入帳證據。不過，也不能只因查詢失敗，就斷定對方詐騙。請先檢查是否選錯鏈，或複製雜湊值時發生錯誤。

## Transfer 事件中需要確認的項目

是否收到款項，應以 USDC 合約留下的 Transfer 事件判定。交易頁面上方的 To 可能是被呼叫的合約。請在事件中的 `to` 確認接收代幣的地址。

ERC-20 標準對轉帳事件的規定如下。

> 代幣轉移時必須觸發，包括數量為零的轉移。
>
> 來源：ERC-20: Token Standard，Transfer 項目

這項規定也包括數量為 0 的轉帳。因此，不能只因事件存在，就認定已支付有償報酬。原文可在 [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) 查閱。

| 確認項目 | 讀取位置 | 通過標準 |
|---|---|---|
| 交易執行結果 | Status 或收據中的 `status` | Success 或 `0x1` |
| 發出日誌的合約 | 日誌中的 `address` | 與該鏈的官方 USDC 合約一致 |
| 事件種類 | 事件名稱與簽章 | `Transfer(address,address,uint256)` |
| 代幣發送地址 | 事件中的 `from` | 能與付款依據建立關聯的來源 |
| 代幣接收地址 | 事件中的 `to` | 與事先確認的完整收款地址一致 |
| 實際數量 | 事件中的 `value` | 套用小數位數後的數量符合付款條件 |
| 收錄區塊 | `blockNumber`、`blockHash` | 與目前鏈上相同高度區塊的雜湊值一致 |
| 最終性 | 該區塊的確定狀態 | 依下方最終性流程另行確認 |

也有由代付合約發送代幣的情況。因此，交易發送者與雇主的地址不一定相同。請一併核對工作編號與付款明細。無法只憑地址確定實際付款者的身分。

### 如何讀取原始日誌

原始日誌中的地址與數量都經過編碼。`topics[0]` 是事件簽章的雜湊值。標準 USDC Transfer 的發送地址位於 `topics[1]`。接收地址則包含在 `topics[2]` 中。

- 地址：將該 topic 的最後 20 位元組解讀為地址。
- 數量：將 `data` 解讀為無號整數。
- 小數位數：依官方合約的 `decimals()` 值換算數量。
- 授權事件：`Approval` 是使用權限的授權紀錄。

Ethereum 與 Base 上的這些 USDC 使用 6 位小數。將原始數量除以 1,000,000，即可換算為 USDC 單位。不要直接套用 ETH 的小數位數。日誌畫面的結構可在 [Etherscan 的 Event Logs](https://info.etherscan.com/what-is-event-logs/) 中確認。

## 交易成功與最終性的差異

Success 表示交易執行成功，不代表區塊已最終確定。最終性是指依共識規則，區塊已確定的狀態。本文所稱最終確認的入帳，是已連同最終性一併檢查的紀錄。

| 網路 | 可先觀察到的狀態 | 最終確認標準 |
|---|---|---|
| Ethereum | 交易已收錄於區塊且執行成功 | 交易區塊位於 finalized 範圍內 |
| Base | 預先確認或收錄於 L2 區塊 | 該 L2 區塊達到 L1 批次最終性 |

Base 內部轉帳與提領至 Ethereum 的流程不同。不要將提領等待期直接套用於 Base 內部入帳。Base 區分區塊收錄與 L1 批次最終性。依據為 [Base 的 Transaction Finality](https://docs.base.org/specifications/transactions/transaction-finality)。

### 區塊鏈瀏覽器未明確顯示最終性時

若未顯示最終性，可以暫緩確認。開發者可透過該鏈可信的 RPC 重新驗證。RPC 是向區塊鏈節點請求資料的介面。

1. 使用 `eth_chainId` 確認連線的鏈。
2. 使用 `eth_getTransactionReceipt` 讀取收據。確認 `status`、日誌、區塊編號與區塊雜湊值。
3. 使用 `eth_getBlockByNumber` 查詢同一個區塊編號。核對回傳的雜湊值是否與收據中的 `blockHash` 相同。
4. 將 `finalized` 與 `false` 傳入 `eth_getBlockByNumber`。確認回傳的區塊高度是否大於或等於交易區塊高度。Base 交易請以 Base RPC 的 finalized 區塊為基準比較。

若收據為 `null`，就無法透過該回應確認交易是否已被收錄。不支援 finalized 查詢的回應，也不要用來判定成功。不能將 `latest` 或單純的確認數解讀成 finalized。方法說明見 [Ethereum JSON-RPC](https://ethereum.org/developers/docs/apis/json-rpc/) 與 [Base 區塊查詢文件](https://docs.base.org/base-chain/api-reference/ethereum-json-rpc-api/eth_getBlockByNumber)。

## 計算範例：模擬 100 USDC 入帳

以下是模擬驗證範例，並非實際付款案例。假設付款條件為 Base 上的 100 USDC。地址與日誌編號是為了說明而建立的數值。請勿將範例地址當作實際收款地址。

| 項目 | 模擬範例值 |
|---|---|
| 鏈 | Base Mainnet，鏈 ID 8453 |
| 發出日誌的合約 | `0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913` |
| 代幣發送地址 | `0x2222222222222222222222222222222222222222` |
| 約定的收款地址 | `0x1111111111111111111111111111111111111111` |
| Transfer 的接收地址 | `0x1111111111111111111111111111111111111111` |
| 原始數量 | 100,000,000 最小單位 |
| 小數位數 | 6 位 |
| 換算數量 | 100,000,000 ÷ 1,000,000 = 100 USDC |
| 交易狀態 | `status = 0x1` |
| 交易識別碼 | H，代替實際 txHash 的符號 |
| 日誌位置 | `logIndex = 7`，模擬值 |
| 最終性 | 假設交易區塊已位於 finalized 範圍內 |

在這些條件下，收到的數量為 **100 USDC**。假設也已確認 H 的區塊雜湊值一致。仍須另外提供依據，將其連結為外部付款者支付的工作款項。

若接收地址是其他地址，就不能認定為自己的入帳。若公告只寫 100 美元，付款數量也需要另行確認。收到 100 USDC 不代表收到 100 美元現金。

## 各懸賞狀態的入帳證據比較

請分別記錄懸賞的進度狀態與錢包入帳狀態。懸賞是針對指定工作提供的報酬。以下分類是用來管理付款證據的標準，不能取代法律上債權或稅務上營收的認定。

| 已確認的內容 | 能證明的範圍 | 入帳管理狀態 |
|---|---|---|
| 公告中的 100 美元 | 公告所列的報酬條件 | 審核付款承諾 |
| 接案邀請或獲選訊息 | 工作邀請或獲選事實 | 接案階段 |
| 工作完成、驗收通過 | 平台上的工作進度狀態 | 付款與否另行確認 |
| 託管入金 | 資金移至獨立保管地址 | 本人收款前 |
| ERC-20 Approval | 指定對象的代幣使用權限 | 並非代幣轉帳證據 |
| 有 txHash，但轉至其他地址 | 向該地址的轉帳 | 並非本人入帳 |
| 成功轉至本人地址，最終性未確認 | 已執行的轉帳 | 等待最終性 |
| 最終確認轉入本人地址的外部款項 | 鏈上收款事實 | 確認與工作款項的關聯 |
| 最終入帳與工作付款明細相符 | 可連結至該工作的收款證據 | 確認收到款項 |

託管是在條件達成前，將資金另行保管的方式。不能只憑保管事實，就認定已支付至本人錢包。平台的核准與 ERC-20 的 Approval 也是不同概念。

即使是最終入帳，也請連結工作編號或請款單。單憑交易紀錄，無法得知付款目的。也請核對付款日期，避免與其他相同數量的入帳混淆。

## 誤計為新工作款項的常見錯誤

不要將所有進入錢包的 USDC 都加總為新工作款項。收款事實與經濟目的應分別記錄。以下檢查清單是整理營運用入帳帳本的標準。

- 退款：先前支出退回的金額，請連結至原始支出。
- 自行轉帳：區分本人管理的錢包之間的資金移動。
- 跨鏈橋移轉：將本人資產的跨鏈移動與新客戶付款分開。
- 垃圾代幣：應確認官方合約地址，而不是只看 USDC 名稱。
- 跨鏈橋映射代幣：若合約不同，請與 Circle 發行的 USDC 分開記錄為不同資產。
- 數量為 0 的事件：即使有 Transfer，也不要計入有償付款。
- 重複查詢：不要將同一事件在區塊鏈瀏覽器與 API 中各計入一次。
- 重複使用憑證：已連結至其他工作的入帳，不要再次分配。
- 自行循環轉帳：一併確認同一筆交易中的轉出與重新入帳。
- 事後退還：若已退還收到的款項，請連結至原始收款紀錄。

### 防止重複的記錄項目

可用 `chainId + txHash + logIndex` 區分事件。同一筆交易可能包含多個轉帳事件。因此，若只憑 txHash 將所有事件合併為一筆，可能造成遺漏。

| 儲存項目 | 記錄目的 |
|---|---|
| 鏈 ID、代幣合約地址 | 識別網路與資產 |
| txHash、logIndex | 區分轉帳事件 |
| blockNumber、blockHash | 重新驗證收錄區塊 |
| 發送地址、接收地址 | 確認資金移動方向 |
| 原始數量、decimals、USDC 數量 | 重現單位換算 |
| 區塊時間、確認時間、時區 | 區分轉帳時間與驗證時間 |
| 最終性狀態 | 區分待確認紀錄與最終紀錄 |
| 工作編號、請款單、付款明細 | 連結入帳目的 |
| 退款、自行轉帳、重複分類 | 避免高估新工作款項 |

若在達到最終性前發生區塊重組，請重新驗證紀錄。已移除的日誌必須從原先的暫定統計中排除。請分開管理工作款項合計與錢包餘額。餘額也會反映先前持有的資產或後續轉出。

## 5 分鐘驗證表

此表整理了約 5 分鐘內要確認的項目，並不保證區塊鏈最終性的完成時間。無法確認的項目，請保留為待確認。

| 順序 | 檢查問題 | 應留下的結果 |
|---:|---|---|
| 1 | 是否知道付款條件中的鏈與數量？ | 約定的網路、USDC 數量 |
| 2 | 收款服務是否支援該鏈？ | 收款地址、是否支援 |
| 3 | 日誌中的合約是否與 Circle 地址相同？ | 是否符合官方合約 |
| 4 | 交易是否成功，且已轉至自己的地址？ | 狀態、Transfer 接收地址 |
| 5 | 是否正確換算原始數量？ | 實際 USDC 數量 |
| 6 | 是否確認收錄區塊與最終性？ | 區塊雜湊值、確定狀態 |
| 7 | 是否能連結為該工作的外部付款？ | 工作編號、付款依據 |
| 8 | 是否已分開處理退款、自行轉帳與重複項目？ | 分類結果、事件識別碼 |

首次確認時，付款依據可能不足。此時請要求提供缺少的鏈名稱或 txHash。若轉至其他地址，請具體告知不符的項目。

## 常見問題

### 只要收到 txHash，就算入帳完成嗎？

無法只憑雜湊值確認入帳完成。即使交易成功，也可能使用了其他收款地址。請一併確認合約、收款地址、數量與最終性。

### 顯示 Success，但看不到錢包餘額時該怎麼辦？

請先核對事件中的接收地址與官方合約。若相符，再確認所選網路與代幣顯示。收款服務的內部入帳狀態也需要另行確認。

### 可以在 Ethereum 上查找 Base 入帳嗎？

Base 交易請在 Base 區塊鏈瀏覽器查詢。即使使用相同地址，各鏈的紀錄仍是分開的。不要只憑 Ethereum 的搜尋結果，判定 Base 尚未入帳。

### 交易頁面上方顯示 0 ETH，就代表沒有入帳嗎？

顯示 0 ETH 並不是 USDC 未轉出的證據。交易的 ETH 數量與 ERC-20 代幣數量是分開的。請確認 Transfer 事件中的 USDC 數量。

### 最終確認的外部入帳就是新營收嗎？

不能只憑外部入帳，就認定為新工作的營收。它可能是退款，或其他用途的匯款。請透過請款單與付款明細連結入帳目的。

### 可以根據入帳確認結果計算稅款嗎？

這個流程用來確認鏈上收款證據，並不判斷個人的納稅結果。韓國稅務資訊請參閱國稅廳的[綜合所得稅概要](https://www.nts.go.kr/nts/cm/cntnts/cntntsView.do?cntntsId=7664&mi=2224)。

## FAQ

### 確認 USDC 入帳需要什麼？
請先確認約定收款的鏈和 USDC 數量。還需要收款地址和 txHash。請核對官方合約的 Transfer 事件與交易最終性。

### Ethereum 和 Base 的 USDC 合約地址相同嗎？
兩者不同。請在 Circle 的 USDC contract addresses 查看各鏈的合約地址。請勿僅憑錢包中的 USDC 名稱或標誌，就判定為同一資產。

### Ethereum 和 Base 的鏈 ID 是什麼？
Ethereum Mainnet 的鏈 ID 是 1。Base Mainnet 的鏈 ID 是 8453。RPC 的 eth_chainId 回應分別為 0x1 和 0x2105。

### 有 txHash 就代表賞金已支付嗎？
txHash 是用來查找交易的識別值。要作為款項已支付給您的證據，必須核對收款地址。也請確認官方合約、數量、交易是否成功及最終性。

### Success 和 finalized 有什麼不同？
Success 表示交易執行成功。finalized 表示區塊已最終確定。即使轉帳成功，也請另行檢查最終性。

### 為什麼 100 枚 USDC 在原始日誌中顯示為 100000000？
Ethereum 和 Base 上的該 USDC 使用 6 位小數。將原始數量 100,000,000 除以 1,000,000，就是 100 USDC。瀏覽器已換算的數量，請勿再次相除。

### 應該看交易頂部的 To，還是 Transfer 的 to？
請在 Transfer 事件的 to 中確認代幣收款地址。交易頂部的 To 可能是代幣合約或付款合約。請將完整地址與事先確認的收款地址核對。

### 公告中的 100 美元和 100 USDC 入帳是同一個意思嗎？
公告中的 100 美元是標示的報酬條件。實際應支付的代幣數量，必須依付款協議確認。收到 100 USDC 並不代表收到 100 美元現金。

### 託管入金或 Approval 是收到款項的證據嗎？
託管入金顯示的是款項轉入另一個保管地址。ERC-20 Approval 是核准代幣使用權限。請另行確認是否實際轉入您本人的收款地址。

### 如何避免 USDC 入帳紀錄重複？
請一併記錄鏈 ID、txHash 和 logIndex。請勿透過多個查詢管道重複加總同一事件。也請檢查是否重複使用已分配給其他工作的入帳款項。

### 退款或本人錢包之間的轉帳，也算是新工作的款項嗎？
請將退款和自有錢包間的轉帳，與新工作的款項分開分類。僅憑鏈上轉帳的事實，無法得知付款目的。請將其與原始支出或轉帳紀錄連結。

### USDC 入帳確認能在 5 分鐘內完成嗎？
5 分鐘驗證表是整理檢查順序的工具。網路達到最終性或服務更新顯示所需的時間可能更長。尚未確認的項目，請記錄為待確認。

## Sources

- [Circle 文件：USDC 合約地址](https://developers.circle.com/stablecoins/usdc-contract-addresses)
- [EIP-155：簡易重放攻擊防護，Ethereum Mainnet 鏈 ID](https://eips.ethereum.org/EIPS/eip-155)
- [Base 文件：eth_chainId](https://docs.base.org/base-chain/api-reference/ethereum-json-rpc-api/eth_chainId)
- [ERC-20：代幣標準，Transfer·Approval·decimals](https://eips.ethereum.org/EIPS/eip-20)
- [Etherscan 資訊中心：事件日誌](https://info.etherscan.com/what-is-event-logs/)
- [Etherscan 資訊中心：探索合約地址](https://info.etherscan.com/explore-contract-address/)
- [Ethereum：JSON-RPC API，查詢收據、日誌與 finalized](https://ethereum.org/developers/docs/apis/json-rpc/)
- [Ethereum 執行 API：eth_getTransactionReceipt](https://ethereum.github.io/execution-apis/api/methods/eth_getTransactionReceipt/)
- [Base 文件：交易最終確定性](https://docs.base.org/specifications/transactions/transaction-finality)
- [Base 文件：eth_getBlockByNumber](https://docs.base.org/base-chain/api-reference/ethereum-json-rpc-api/eth_getBlockByNumber)
- [Ethereum：網路，各網路的餘額與交易記錄](https://ethereum.org/developers/docs/networks/)
- [Etherscan：USDC 代幣合約，顯示小數點後 6 位](https://etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48?a=0x1aadee97df948a9676cdd16aadc4477ecd06a8c7)
- [國稅廳：綜合所得稅概述](https://www.nts.go.kr/nts/cm/cntnts/cntntsView.do?cntntsId=7664&mi=2224)

## Images

![一名中年男子坐在陽光灑落的家中餐桌旁，專注查看平板電腦與手機螢幕。](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIwMTQsInB1ciI6ImJsb2JfaWQifX0=--66d015359c342f46f8ea28a40eeea1097d8934ce/ai-46cc85be.webp)
![一名穿著紫色針織外套的女子將重複的交易明細放入獨立托盤，旁邊放著帳本與另一份明細。](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIwMjEsInB1ciI6ImJsb2JfaWQifX0=--66077c8a3224c10d76b04cac8d68545ca56f659c/ai-d2b7055c.webp)