USDC 입금 확인 2026 체인과 바운티 검증 방법
USDC 입금은 체인과 공식 계약, 수취 주소, 수량이 일치하는 전송 기록으로 확인합니다. 거래 성공과 최종성까지 점검한 뒤 바운티 지급 약속, 환불, 자체 이체와 구별하세요.
지급받기로 한 체인과 공식 USDC 계약 주소를 확인하세요.
선택한 체인의 수취 주소를 본인 지갑이나 수취 서비스에서 확인하세요.
해당 체인의 탐색기에서 거래 성공과 Transfer 이벤트를 대조하세요.
거래가 포함된 블록의 최종성을 확인하세요.
작업 대금과 연결한 뒤 환불·자체 이체·중복 기록을 따로 분류하세요.
USDC 입금은 약속한 체인의 공식 토큰 전송으로 확인합니다. 수취 주소와 수량이 맞아야 합니다. 거래 성공과 블록 최종성도 별도로 확인하세요. 공고의 보상액이나 해시만으로 바운티 지급을 인정할 수는 없습니다.
주소와 체인 ID는 Circle·Ethereum·Base 공식 문서에서 재확인하세요. (확인값 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, 10진수 | 체인 ID, 16진수 | 공식 USDC 계약 주소 | 탐색기
Ethereum Mainnet | 1 | 0x1 | 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 | Etherscan
Base Mainnet | 8453 | 0x2105 | 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 | BaseScan
계약 주소의 근거는 Circle의 USDC contract addresses입니다. Ethereum 체인 ID는 EIP-155에 명시되어 있습니다. Base 체인 ID는 Base의 eth_chainId 문서에서 확인할 수 있습니다.
같은 수취 주소 문자열도 체인이 다르면 별도 기록입니다. Ethereum의 입금이 Base 잔액에 자동으로 합쳐지지는 않습니다. Sepolia 같은 테스트넷의 USDC는 실제 대금으로 집계하지 마세요.
수취 주소와 거래를 확인하는 순서
지급 조건을 먼저 고정하면 다른 거래를 대금으로 오인하기 어렵습니다. 이 절차는 공개된 거래 기록을 읽는 작업입니다. 탐색기 조회를 위해 지갑 연결이나 서명을 할 필요는 없습니다.
· 지급 합의에서 네트워크와 토큰을 확인하세요. 공고의 달러 표시와 실제 지급할 USDC 수량을 구별하세요.
· 받을 지갑에서 해당 네트워크의 수취 주소를 복사하세요. 거래소를 이용한다면 해당 서비스의 입금 화면을 기준으로 삼으세요. 서비스의 지원 네트워크도 확인하세요.
· Circle의 Mainnet 표에서 해당 체인의 계약 주소를 찾으세요. 토큰 이름이나 로고만으로 판단하지 마세요.
· 해당 체인의 탐색기에서 txHash를 검색하세요. txHash는 거래를 찾는 식별값입니다. 검색 결과가 없으면 네트워크와 해시를 다시 대조하세요.
· 거래 상세의 상태와 토큰 전송 기록을 확인하세요. 이어서 Logs 탭에서 실제 Transfer 이벤트를 대조하세요.
조회되지 않는 해시는 아직 입금 증거가 아닙니다. 다만 조회 실패만으로 상대방의 사기를 단정할 수는 없습니다. 잘못된 체인이나 해시 복사 오류부터 확인하세요.
Transfer 이벤트에서 확인할 항목
수취 여부는 USDC 계약이 남긴 Transfer 이벤트로 판별합니다. 거래 상단의 To는 호출받은 계약일 수 있습니다. 토큰을 받은 주소는 이벤트 안의 to에서 확인하세요.
ERC-20 표준은 전송 이벤트를 다음과 같이 규정합니다.
MUST trigger when tokens are transferred, including zero value transfers. 출처: ERC-20: Token Standard, Transfer 항목
이 규정에는 수량이 0인 전송도 포함됩니다. 따라서 이벤트 존재만으로 유상 지급을 인정하면 안 됩니다. 원문은 ERC-20: Token Standard에서 확인할 수 있습니다.
확인 항목 | 읽을 위치 | 통과 기준
거래 실행 결과 | 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에서 확인할 수 있습니다.
거래 성공과 최종성의 차이
Success는 거래 실행 성공을 뜻합니다. 블록이 최종 확정되었다는 뜻은 아닙니다. 최종성은 합의 규칙상 블록이 확정된 상태를 말합니다. 이 글의 최종 확인된 입금은 최종성까지 점검한 기록입니다.
네트워크 | 먼저 관찰할 수 있는 상태 | 최종 확인 기준
Ethereum | 거래가 블록에 포함되어 성공 | 거래 블록이 finalized 범위에 포함
Base | 사전 확인 또는 L2 블록 포함 | 해당 L2 블록이 L1 배치 최종성에 도달
Base 내부 전송과 Ethereum으로의 출금은 절차가 다릅니다. 출금의 대기 기간을 Base 내부 입금에 그대로 적용하지 마세요. Base는 블록 포함과 L1 배치 최종성을 구분합니다. 근거는 Base의 Transaction Finality입니다.
탐색기에 최종성이 명확하지 않을 때
최종성 표시가 없으면 확인 상태를 보류할 수 있습니다. 개발자는 해당 체인의 신뢰할 수 있는 RPC로 재검증할 수 있습니다. RPC는 블록체인 노드에 데이터를 요청하는 인터페이스입니다.
· eth_chainId로 접속한 체인을 확인하세요.
· eth_getTransactionReceipt로 영수증을 읽으세요. status, 로그, 블록 번호와 블록 해시를 확인하세요.
· 같은 블록 번호를 eth_getBlockByNumber로 조회하세요. 반환된 해시가 영수증의 blockHash와 같은지 대조하세요.
· eth_getBlockByNumber에 finalized와 false를 전달하세요. 반환된 블록 높이가 거래 블록 높이 이상인지 확인하세요. Base 거래는 Base RPC의 finalized 블록을 기준으로 비교하세요.
영수증이 null이면 해당 응답으로 포함 여부를 확인할 수 없습니다. finalized 조회를 지원하지 않는 응답도 성공 판정에 쓰지 마세요. latest나 단순 확인 수를 finalized로 바꿔 해석하면 안 됩니다. 메서드는 Ethereum JSON-RPC와 Base 블록 조회 문서에 설명되어 있습니다.
계산 예시: 합성 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인데 지갑 잔액이 보이지 않으면 어떻게 합니까?
먼저 이벤트의 수취 주소와 공식 계약을 대조하세요. 일치한다면 선택한 네트워크와 토큰 표시를 확인하세요. 수취 서비스의 내부 반영 상태도 별도 확인 대상입니다.
Base 입금을 Ethereum에서 찾아도 됩니까?
Base 거래는 Base 탐색기에서 조회하세요. 같은 주소를 쓰더라도 체인별 기록은 분리됩니다. Ethereum 검색 결과만으로 Base 미입금을 판단하지 마세요.
거래 상단에 0 ETH가 표시되면 무입금입니까?
0 ETH 표시는 USDC 미전송의 증거가 아닙니다. 거래의 ETH 수량과 ERC-20 토큰 수량은 별개입니다. Transfer 이벤트의 USDC 수량을 확인하세요.
최종 확인된 외부 입금이면 새 매출입니까?
외부 입금만으로 새 작업 매출을 확정할 수는 없습니다. 환불이나 다른 목적의 송금일 수도 있습니다. 청구서와 지급 명세로 입금 목적을 연결하세요.
입금 확인 결과로 세금을 계산해도 됩니까?
이 절차는 온체인 수취 증거를 확인하는 용도입니다. 개인의 납세 결과를 판단하지는 않습니다. 한국 세무 안내는 국세청의 종합소득세 개요에서 확인하세요.
Injoys
