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.
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. The Ethereum chain ID is specified in EIP-155. The Base chain ID can be checked in Base's eth_chainId documentation.
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.
· 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.
· 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.
· Find the contract address for that chain in Circle's Mainnet table. Do not rely on the token name or logo alone.
· 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.
· 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.
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.
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.
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.
· Check the connected chain using eth_chainId.
· Read the receipt using eth_getTransactionReceipt. Check status, the logs, the block number, and the block hash.
· Query the same block number using eth_getBlockByNumber. Check whether the returned hash matches the receipt's blockHash.
· 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 and Base's block query documentation.
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.
Injoys
