---
title: "USDC Deposit Verification 2026: Chain and Bounty Checks"
locale: en
category: how_to
category_name: "How-to"
translation_status: reviewed
license: cc_by
author: "Injoys Editorial Team"
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 Deposit Verification 2026: Chain and Bounty Checks

> Confirm USDC deposits using transfer records that match the chain, official contract, recipient address, and amount. Check transaction success and finality, then distinguish deposits from bounty payment promises, refunds, and self-transfers.

## Key Points

- Confirm the agreed payment chain and official USDC contract address.
- Confirm the recipient address on the selected chain in your wallet or with the receiving service.
- Cross-check transaction success and Transfer events in the explorer for that chain.
- Check the finality of the block containing the transaction.
- Link the payment to the work, then classify refunds, self-transfers, and duplicate records separately.

Confirm a USDC deposit by checking for a transfer of the official token on the agreed chain. The recipient address and amount must match. Check transaction success and block finality separately as well. The reward amount in a posting or a hash alone is not enough to establish that a bounty has been paid.

Double-check addresses and chain IDs in the official Circle, Ethereum, and Base documentation. (Verified values: Ethereum Mainnet: chain ID 1, USDC contract 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48. Base Mainnet: chain ID 8453 0x2105 , USDC contract · Source: developers.circle.com · Checked on 2026-10-23)

## USDC Contract Addresses and Chain IDs by Chain

USDC on Ethereum and Base uses different contract addresses. A chain ID is a number that identifies a network. A token contract address identifies a token on that chain. A recipient address is the address of the wallet or account that will receive payment.

This article was written and the documentation checked on October 23, 2026. The table below covers Circle-issued USDC on mainnet. A mainnet is a network that uses assets with real value.

| Network | Chain ID, decimal | Chain ID, hexadecimal | Official USDC contract address | Explorer |
|---|---:|---|---|---|
| Ethereum Mainnet | 1 | `0x1` | `0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48` | Etherscan |
| Base Mainnet | 8453 | `0x2105` | `0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913` | BaseScan |

The contract addresses are based on [Circle's USDC contract addresses](https://developers.circle.com/stablecoins/usdc-contract-addresses). The Ethereum chain ID is specified in [EIP-155](https://eips.ethereum.org/EIPS/eip-155). The Base chain ID can be checked in [Base's eth_chainId documentation](https://docs.base.org/base-chain/api-reference/ethereum-json-rpc-api/eth_chainId).

Even an identical recipient address string has separate records on different chains. A deposit on Ethereum is not automatically added to a Base balance. Do not count USDC on testnets such as Sepolia as actual payment.

## Steps for Checking the Recipient Address and Transaction

Establishing the payment terms first makes it harder to mistake another transaction for payment. This process involves reading public transaction records. You do not need to connect a wallet or sign anything to look up a transaction in an explorer.

1. Check the network and token in the payment agreement. Distinguish the dollar amount shown in the posting from the actual amount of USDC to be paid.
2. Copy the recipient address for that network from the receiving wallet. If you use an exchange, use that service's deposit screen as your reference. Also check which networks the service supports.
3. Find the contract address for that chain in Circle's Mainnet table. Do not rely on the token name or logo alone.
4. Search for the txHash in that chain's explorer. A txHash is an identifier used to find a transaction. If there are no search results, check the network and hash again.
5. Check the status and token transfer records in the transaction details. Then compare them with the actual Transfer event in the Logs tab.

A hash that cannot be found is not yet evidence of a deposit. However, a failed lookup alone does not prove that the other party is committing fraud. First check for the wrong chain or an error in copying the hash.

## What to Check in a Transfer Event

Determine whether tokens were received by checking the Transfer event emitted by the USDC contract. The To field at the top of the transaction may be the contract that was called. Check the `to` field within the event for the address that received the tokens.

The ERC-20 standard defines the transfer event as follows.

> MUST trigger when tokens are transferred, including zero value transfers.
>
> Source: ERC-20: Token Standard, Transfer section

This rule includes transfers with an amount of 0. Therefore, the existence of an event alone must not be accepted as evidence of payment. The original text is available in [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20).

| Item to check | Where to read it | Passing criterion |
|---|---|---|
| Transaction execution result | Status or `status` in the receipt | Success or `0x1` |
| Contract that emitted the log | `address` in the log | Matches the official USDC contract on that chain |
| Event type | Event name and signature | `Transfer(address,address,uint256)` |
| Token sender address | `from` in the event | A source that can be linked to the supporting payment records |
| Token recipient address | `to` in the event | Matches the entire recipient address checked in advance |
| Actual amount | `value` in the event | The amount after applying decimal places matches the payment terms |
| Containing block | `blockNumber`, `blockHash` | Hash matches the block at the same height on the current chain |
| Finality | Finalization status of that block | Checked separately using the finality procedure below |

A payment-processing contract may send the tokens. The transaction sender and the employer's address are therefore not always the same. Compare the job number and payment details as well. An address alone cannot establish the actual payer's identity.

### How to Read Raw Logs

Addresses and amounts are encoded in raw logs. `topics[0]` is the hash of the event signature. The sender address for a standard USDC Transfer is in `topics[1]`. The recipient address is in `topics[2]`.

- Address: Interpret the last 20 bytes of the relevant topic as an address.
- Amount: Interpret `data` as an unsigned integer.
- Decimal places: Convert the amount using the official contract's `decimals()` value.
- Approval event: `Approval` records permission to use tokens.

The USDC contracts on Ethereum and Base listed here use 6 decimal places. Divide the raw amount by 1,000,000 to read it in USDC units. Do not apply ETH's decimal places. The layout of the log display is explained in [Etherscan's Event Logs](https://info.etherscan.com/what-is-event-logs/).

## The Difference Between Transaction Success and Finality

Success means the transaction executed successfully. It does not mean the block has been finalized. Finality is the state in which a block is final under the consensus rules. In this article, a fully confirmed deposit is a record whose finality has also been checked.

| Network | Status that can be observed first | Final confirmation criterion |
|---|---|---|
| Ethereum | Transaction included in a block and successful | Transaction block falls within the finalized range |
| Base | Preconfirmation or inclusion in an L2 block | The relevant L2 block reaches L1 batch finality |

Transfers within Base and withdrawals to Ethereum follow different procedures. Do not apply the withdrawal waiting period directly to deposits within Base. Base distinguishes block inclusion from L1 batch finality. The source is [Base's Transaction Finality](https://docs.base.org/specifications/transactions/transaction-finality).

### When Finality Is Not Clear in the Explorer

If finality is not shown, you can leave the confirmation status pending. Developers can recheck it through a trusted RPC for that chain. RPC is an interface for requesting data from a blockchain node.

1. Check the connected chain using `eth_chainId`.
2. Read the receipt using `eth_getTransactionReceipt`. Check `status`, the logs, the block number, and the block hash.
3. Query the same block number using `eth_getBlockByNumber`. Check whether the returned hash matches the receipt's `blockHash`.
4. Pass `finalized` and `false` to `eth_getBlockByNumber`. Check whether the returned block height is at least the transaction block height. For Base transactions, compare against the finalized block from the Base RPC.

If the receipt is `null`, that response cannot confirm inclusion. Do not use a response that does not support finalized queries to mark the check as successful, either. Do not reinterpret `latest` or a simple confirmation count as finalized. The methods are explained in [Ethereum JSON-RPC](https://ethereum.org/developers/docs/apis/json-rpc/) and [Base's block query documentation](https://docs.base.org/base-chain/api-reference/ethereum-json-rpc-api/eth_getBlockByNumber).

## Calculation Example: A Synthetic 100 USDC Deposit

The following is a synthetic verification example, not an actual payment case. Assume the payment terms are 100 USDC on Base. The addresses and log index are made-up values for illustration. Do not use the example address as an actual recipient address.

| Item | Synthetic example value |
|---|---|
| Chain | Base Mainnet, chain ID 8453 |
| Contract that emitted the log | `0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913` |
| Token sender address | `0x2222222222222222222222222222222222222222` |
| Agreed recipient address | `0x1111111111111111111111111111111111111111` |
| Recipient address in Transfer | `0x1111111111111111111111111111111111111111` |
| Raw amount | 100,000,000 smallest units |
| Decimal places | 6 places |
| Converted amount | 100,000,000 ÷ 1,000,000 = 100 USDC |
| Transaction status | `status = 0x1` |
| Transaction identifier | H, a symbol standing in for an actual txHash |
| Log position | `logIndex = 7`, a synthetic value |
| Finality | Assume the transaction block falls within the finalized range |

Under these conditions, the amount received is **100 USDC**. Assume that the block hash match for H has also been checked. Separate evidence is needed to link it to payment for work from an external payer.

If the recipient address is a different address, do not count it as your deposit. If the posting only stated 100 dollars, the payment amount must also be checked separately. Receiving 100 USDC does not mean receiving 100 dollars in cash.

## Comparing Deposit Evidence by Bounty Status

Record the bounty's progress and the wallet's deposit status separately. A bounty is a reward attached to a specified task. The categories below are criteria for managing payment evidence. They do not replace a determination of legal claims or revenue for tax purposes.

| What was checked | What it proves | Deposit tracking status |
|---|---|---|
| 100 dollars in the posting | Reward terms shown in the posting | Reviewing payment promise |
| Job offer or selection message | A work offer or the fact of selection | Job award stage |
| Work completed and review approved | Work progress on the platform | Payment must be checked separately |
| Escrow deposit | Funds moved to a separate holding address | Not yet received by you |
| ERC-20 Approval | Permission for a designated party to use tokens | Not evidence of a token transfer |
| txHash exists, but transfer is to another address | A transfer to that address | Not your deposit |
| Successful transfer to your address, finality unchecked | An executed transfer | Awaiting finality |
| Fully confirmed external deposit to your address | On-chain receipt | Check the link to payment for work |
| Final deposit matches the job's payment details | Evidence of receipt linked to that job | Payment receipt confirmed |

Escrow is a way of holding funds separately until conditions are met. The fact that funds are being held does not mean they have been paid to your wallet. Platform approval and ERC-20 Approval are also different concepts.

Link a job number or invoice even to a final deposit. Transaction records alone do not reveal the payment's purpose. Compare the payment date as well to avoid confusing it with another deposit of the same amount.

## Common Mistakes When Counting New Work Payments

Do not add up all USDC entering your wallet as payment for new work. Receipt and economic purpose are separate fields. The checklist below provides criteria for organizing an operational deposit ledger.

- Refunds: Link returned amounts to the original expense.
- Self-transfers: Distinguish transfers between wallets you control.
- Bridge transfers: Separate movements of your own assets between chains from new customer payments.
- Spam tokens: Check the official contract address rather than the USDC name.
- Bridged representation tokens: If the contract differs, record them as assets separate from Circle-issued USDC.
- 0-amount events: Do not count them as payment even if there is a Transfer.
- Duplicate lookups: Do not count the same event once from the explorer and again from the API.
- Reused evidence: Do not reassign a deposit already linked to another job.
- Self-circulation: Check both outgoing and returning funds in the same transaction.
- Subsequent returns: If you returned a payment you received, link it to the original receipt record.

### Fields to Record to Prevent Duplicates

Events can be distinguished using `chainId + txHash + logIndex`. A single transaction can contain multiple transfer events. Combining all events into one record based only on txHash can therefore cause omissions.

| Field to store | Purpose |
|---|---|
| Chain ID, token contract address | Identify the network and asset |
| txHash, logIndex | Distinguish transfer events |
| blockNumber, blockHash | Recheck the containing block |
| Sender address, recipient address | Check the direction of fund movement |
| Raw amount, decimals, USDC amount | Reproduce the unit conversion |
| Block time, verification time, time zone | Distinguish transfer time from verification time |
| Finality status | Distinguish pending records from final records |
| Job number, invoice, payment details | Link the deposit to its purpose |
| Refund, self-transfer, and duplicate classifications | Prevent overstating payments for new work |

Recheck records if a block reorganization occurs before finality. Removed logs must be excluded from the existing provisional total. Track total work payments separately from the wallet balance. The balance also reflects earlier holdings and subsequent withdrawals.

## 5-Minute Verification Checklist

This table lists items to check over about 5 minutes. It does not guarantee that blockchain finality will be reached within that time. Leave any item you cannot verify as pending.

| Step | Check question | Result to record |
|---:|---|---|
| 1 | Do you know the chain and amount in the payment terms? | Agreed network and USDC amount |
| 2 | Does the receiving service support that chain? | Recipient address and support status |
| 3 | Does the log's contract match the Circle address? | Whether the official contract matches |
| 4 | Did the transaction succeed and transfer tokens to your address? | Status and Transfer recipient address |
| 5 | Did you convert the raw amount correctly? | Actual USDC amount |
| 6 | Did you check the containing block and finality? | Block hash and finalization status |
| 7 | Can it be linked to an external payment for that job? | Job number and supporting payment evidence |
| 8 | Did you separate refunds, self-transfers, and duplicates? | Classification result and event identifier |

The first check may not provide enough payment evidence. If so, request the missing chain name or txHash. If the transfer went to another address, explain the specific mismatch.

## Frequently Asked Questions

### Is a deposit complete once I receive a txHash?

A hash alone cannot confirm that a deposit is complete. Even a successful transaction may have a different recipient address. Check the contract, recipient address, amount, and finality together.

### What if the status is Success but I cannot see the wallet balance?

First compare the event's recipient address and the official contract. If they match, check the selected network and token display. The receiving service's internal crediting status must also be checked separately.

### Can I look for a Base deposit on Ethereum?

Look up Base transactions in a Base explorer. Records are separate for each chain even if the same address is used. Do not conclude that a Base deposit is missing based only on Ethereum search results.

### If 0 ETH appears at the top of the transaction, does that mean no deposit was made?

A 0 ETH display is not evidence that no USDC was transferred. The transaction's ETH amount and ERC-20 token amount are separate. Check the USDC amount in the Transfer event.

### Is a fully confirmed external deposit new revenue?

An external deposit alone cannot establish new revenue from work. It could be a refund or a transfer for another purpose. Use invoices and payment details to link the deposit to its purpose.

### Can I calculate taxes based on deposit verification results?

This procedure is for checking evidence of on-chain receipt. It does not determine an individual's tax outcome. For Korean tax guidance, see the National Tax Service's [Overview of Global Income Tax](https://www.nts.go.kr/nts/cm/cntnts/cntntsView.do?cntntsId=7664&mi=2224).

## FAQ

### What do I need to verify a USDC deposit?
First, confirm the chain and the amount of USDC you agreed to receive. You also need the receiving address and txHash. Cross-check the official contract's Transfer event and the transaction's finality.

### Are the USDC contract addresses on Ethereum and Base the same?
They are different. Check the contract address for each chain in Circle's USDC contract addresses. Do not assume it is the same asset based only on the USDC name or logo in your wallet.

### What are the chain IDs for Ethereum and Base?
The chain ID for Ethereum Mainnet is 1. The chain ID for Base Mainnet is 8453. The RPC eth_chainId responses are 0x1 and 0x2105, respectively.

### Does having a txHash mean the bounty has been paid?
A txHash is an identifier used to find a transaction. To serve as proof that you were paid, it must be checked against your receiving address. Also verify the official contract, amount, transaction success, and finality.

### What is the difference between Success and finalized?
Success means the transaction executed successfully. finalized indicates that the block has reached finality. Check finality separately even for a successful transfer.

### Why does 100 USDC appear as 100000000 in the raw logs?
The USDC in question on Ethereum and Base uses 6 decimal places. Dividing the raw amount of 100,000,000 by 1,000,000 gives 100 USDC. Do not divide an amount again if the explorer has already converted it.

### Should I check the To at the top of the transaction or the to in Transfer?
Check the token's receiving address in the Transfer event's to field. The To at the top of the transaction may be a token or payment contract. Compare the entire address against the receiving address you verified beforehand.

### Does 100 dollars in the posting mean the same thing as a deposit of 100 USDC?
The 100 dollars in the posting is the stated reward amount. You must check the payment agreement for the actual number of tokens to be paid. Receiving 100 USDC does not mean receiving 100 dollars in cash.

### Is an escrow deposit or Approval proof of receiving payment?
An escrow deposit shows a transfer to a separate holding address. ERC-20 Approval grants permission to use tokens. Separately verify the actual transfer to your receiving address.

### How do I prevent duplicate USDC deposit records?
Record the chain ID, txHash, and logIndex together. Do not count the same event multiple times from different lookup sources. Also check for reuse of deposits already assigned to other tasks.

### Do refunds or transfers between my own wallets also count as payment for new work?
Classify refunds and transfers between your own wallets separately from payments for new work. An on-chain transfer alone does not reveal the purpose of the payment. Link it to the original spending or transfer record.

### Can USDC deposit verification be completed within 5 minutes?
The 5-minute checklist is a tool that lays out the order of checks. The network may take longer to reach finality, or the service may take longer to show the deposit. Mark any unverified items as pending.

## Sources

- [Circle Docs: USDC contract addresses](https://developers.circle.com/stablecoins/usdc-contract-addresses)
- [EIP-155: Simple replay attack protection, Ethereum Mainnet chain ID](https://eips.ethereum.org/EIPS/eip-155)
- [Base Documentation: eth_chainId](https://docs.base.org/base-chain/api-reference/ethereum-json-rpc-api/eth_chainId)
- [ERC-20: Token Standard, Transfer·Approval·decimals](https://eips.ethereum.org/EIPS/eip-20)
- [Etherscan Information Center: Event Logs](https://info.etherscan.com/what-is-event-logs/)
- [Etherscan Information Center: Explore a Contract Address](https://info.etherscan.com/explore-contract-address/)
- [Ethereum: JSON-RPC API, receipt, log, and finalized queries](https://ethereum.org/developers/docs/apis/json-rpc/)
- [Ethereum Execution APIs: eth_getTransactionReceipt](https://ethereum.github.io/execution-apis/api/methods/eth_getTransactionReceipt/)
- [Base Documentation: Transaction Finality](https://docs.base.org/specifications/transactions/transaction-finality)
- [Base Documentation: eth_getBlockByNumber](https://docs.base.org/base-chain/api-reference/ethereum-json-rpc-api/eth_getBlockByNumber)
- [Ethereum: Networks, balances and transaction history by network](https://ethereum.org/developers/docs/networks/)
- [Etherscan: USDC Token Contract, displayed to 6 decimal places](https://etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48?a=0x1aadee97df948a9676cdd16aadc4477ecd06a8c7)
- [National Tax Service: Overview of Global Income Tax](https://www.nts.go.kr/nts/cm/cntnts/cntntsView.do?cntntsId=7664&mi=2224)

## Images

![A middle-aged man carefully reviews tablet and smartphone screens at a sunlit table at home.](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIwMTQsInB1ciI6ImJsb2JfaWQifX0=--66d015359c342f46f8ea28a40eeea1097d8934ce/ai-46cc85be.webp)
![A woman in a plum cardigan places a duplicate transaction printout in a tray beside a ledger and another printout.](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIwMjEsInB1ciI6ImJsb2JfaWQifX0=--66077c8a3224c10d76b04cac8d68545ca56f659c/ai-d2b7055c.webp)