토큰의 이름·symbol·logo는 누구나 복제할 수 있으므로 공식성을 확인할 때는 chain별 contract address를 기준으로 삼아야 합니다. 발행자 공식 도메인의 문서나 announcement에서 주소를 얻고, 해당 체인의 탐색기에서 bytecode·verified source·배포자·proxy 표시를 확인한 뒤 신뢰할 wallet 또는 token list와 교차 대조합니다. 탐색기의 verified source는 코드 대응을 뜻할 뿐 발행자 신원이나 투자 안전성을 보증하지 않습니다.
토큰 이름은 고유 식별자가 아닙니다
EVM에서는 누구나 기존 stablecoin과 같은 name·symbol·decimals를 가진 contract를 배포할 수 있습니다. 지갑에 USDT라고 표시되고 로고와 가격이 붙어도 공식 발행자 자산이라는 뜻은 아닙니다. 거래·입금·approval 전에는 chain ID와 contract address를 하나의 식별자로 기록합니다.
주소는 검색 결과의 광고나 SNS 답글에서 복사하지 않습니다. 발행자 공식 도메인을 즐겨찾기나 이미 검증한 채널로 열고 networks 페이지를 찾습니다. 여러 chain을 지원하면 Ethereum, Arbitrum, Base 등의 주소가 각각 다를 수 있으므로 현재 지갑 network와 같은 행을 선택합니다.
토큰의 이름은 상품명이고, 체인과 계약 주소의 조합이 실제 식별표입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 토큰 이름은 고유 식별자가 아닙니다
EVM에서는 누구나 기존 stablecoin과 같은 name·symbol·decimals를 가진 contract를 배포할 수 있습니다.
- 세 출처가 같은 주소를 가리키는지 봅니다
첫째 발행자 공식 문서, 둘째 해당 chain의 explorer, 셋째 신뢰할 wallet·거래소·token list를 대조합니다.
- 프록시와 구현 주소를 섞지 않습니다
upgradeable token은 사용자가 상호작용하는 proxy address 와 logic code가 있는 implementation address가 다를 수 있습니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
세 출처가 같은 주소를 가리키는지 봅니다
첫째 발행자 공식 문서, 둘째 해당 chain의 explorer, 셋째 신뢰할 wallet·거래소·token list를 대조합니다. 한 곳만 다르면 주소를 사용하지 말고 문서의 갱신 날짜, network, proxy 여부를 조사합니다. checksum 대소문자는 오타 탐지에 도움을 주지만 공식성을 증명하지 않습니다.
탐색기에서는 contract 생성 transaction, creator, verified source, token holders, transfers를 봅니다. 거래량과 holder가 많다는 이유만으로 진짜라고 단정하지 않습니다. 사기 토큰도 airdrop으로 holder 수를 늘릴 수 있습니다. 공식 문서가 탐색기 주소로 직접 연결되는 경로가 더 강한 근거입니다.
| 출처 | 확인 항목 | 한계 |
|---|---|---|
| 발행자 공식 문서 | chain별 전체 주소 | 도메인 피싱 주의 |
| 블록 탐색기 | bytecode·source·creator | verified가 안전 보증 아님 |
| 공식 거래소 입금 | 지원 network·contract | 상장 정책은 변동 |
| 신뢰할 token list | 주소·decimals·logo | 업데이트 지연 가능 |
| 커뮤니티 게시물 | 변경 공지 단서 | 단독 근거로 부족 |
프록시와 구현 주소를 섞지 않습니다
upgradeable token은 사용자가 상호작용하는 proxy address와 logic code가 있는 implementation address가 다를 수 있습니다. 잔액과 allowance는 보통 proxy의 storage 맥락에서 관리됩니다. implementation 주소를 token contract로 지갑에 추가하거나 그쪽으로 전송하면 의도한 동작이 아닐 수 있습니다.
OpenZeppelin은 proxy가 호출을 implementation에 delegate하고 상태는 proxy에 남는 구조를 설명합니다. explorer의 ‘Read as Proxy’·implementation 표시와 ERC-1967 slot을 확인하고, 공식 발행자가 제공한 사용자-facing 주소가 proxy인지 대조합니다. 관리자와 upgrade 가능성도 위험 평가에 포함합니다.
- 공식 발행자 도메인을 직접 엽니다.
- 현재 chain과 전체 contract를 복사합니다.
- 탐색기 source·creator·proxy 표시를 확인합니다.
- 다른 신뢰할 목록과 주소를 대조합니다.
- 지갑 서명 화면의 contract와 다시 비교합니다.
decimals와 자산 표시도 검증합니다
ERC-20의 raw balance는 decimals를 적용해 화면 금액으로 바뀝니다. 가짜 token은 유명 자산과 다른 decimals나 transfer 제한, 예상치 못한 fee를 구현할 수 있습니다. symbol과 decimals만 같아도 contract code와 주소가 다르면 별도 자산입니다.
지갑에 custom token을 추가할 때 주소를 넣으면 symbol·decimals가 자동 채워지기도 하지만 그 자동값을 공식성 판정으로 사용하지 않습니다. 입력 후 보이는 잔액이 비정상적으로 크거나 시장 가치가 표시돼도 swap이나 claim을 누르기 전에 유동성과 공식 지원을 확인합니다.
주소 변경 공지는 이전 경로와 함께 검증합니다
token migration이나 bridge 변경으로 새 contract가 생길 수 있습니다. ‘긴급 swap’을 재촉하는 DM보다 기존 공식 사이트·기존 contract announcement·검증된 SNS 계정을 서로 연결해 확인합니다. migration contract가 요구하는 approval 한도와 교환 비율, deadline을 읽습니다.
검증 결과는 chain, proxy address, implementation 확인 시각, 공식 URL로 남깁니다. 이후 upgrade나 migration이 가능하므로 영구 목록처럼 쓰지 않습니다. 큰 거래 전에는 다시 확인하고 작은 test transaction과 예상 수신 token contract를 점검합니다.
자주 묻는 질문
탐색기에 Verified라고 뜨면 공식 토큰인가요?
아닙니다. source와 bytecode 대응을 뜻하며 발행자 신원·경제적 안전성을 보증하지 않습니다.
같은 티커의 토큰 중 holder가 많은 것을 고르면 되나요?
아닙니다. 에어드롭으로 holder 수를 만들 수 있으므로 공식 발행자 문서의 주소를 기준으로 확인하세요.
프록시와 implementation 중 어느 주소를 지갑에 추가하나요?
보통 공식 발행자가 안내한 사용자-facing proxy 주소입니다. 프로젝트 문서와 탐색기 표시를 함께 확인하세요.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
