토큰 계약 주소 변경은 이름이나 심볼이 아니라 발행 주체가 직접 게시한 원문에서 새 주소와 대상 네트워크를 함께 확인하는 일부터 시작합니다. 다음으로 그 원문이 새 계약의 배포·전환·교환 지원 중 무엇을 말하는지 구분하고, 탐색기에서 주소별 코드와 거래 기록을 읽습니다. 소스 코드 검증 표시는 해당 주소의 공개 소스와 배포 바이트코드의 일치를 돕는 정보이지, 그 계약이 특정 프로젝트의 공식 자산이라는 보증은 아닙니다. 이전 계약을 보았다고 해서 자동으로 새 계약으로 교환되거나, 새 주소를 받았다고 해서 즉시 전송해야 하는 것도 아닙니다.
‘주소가 바뀐다’는 문장을 먼저 세 갈래로 나눕니다
주소 변경 공지는 한 문장처럼 보이지만 실제로는 서로 다른 사건을 가리킬 수 있습니다. 새 체인에 별도 토큰을 배포했다는 안내, 보유분을 새 계약으로 전환한다는 절차, 지갑이나 거래소가 표시할 기본 주소를 교체한다는 고지가 대표적입니다. 이 셋은 이용자가 해야 할 일이 다르므로 ‘새 주소’만 복사해 지갑에 등록하기 전에 공지가 어느 경우인지 읽어야 합니다.
발표 시각도 현재 동작을 뜻하지 않습니다. ‘계획’, ‘지원 예정’, ‘전환 시작’, ‘종료’처럼 원문이 사용하는 동사를 따로 적어 두면 과거 공지를 현재의 입금 안내로 오해하는 일을 줄일 수 있습니다. 특히 이전 계약의 잔액을 새 계약에서 그대로 쓸 수 있는지, 별도 청구나 교환 창구가 필요한지는 프로젝트별 규칙과 지원 사업자 조건에 달려 있습니다. 원문이 그 조건을 밝히지 않으면 추정으로 자산을 보내지 않는 편이 안전합니다.
발행 주체가 관리하는 공식 사이트의 원문과 주소를 직접 연결해 확인하는 과정이 출발점입니다. ethereum.org의 사기 토큰 안내도 정식 토큰의 주소는 해당 조직의 사이트에서 확인하라고 설명합니다.
주소 변경 공지의 핵심은 새 문자열을 찾는 일이 아니라, 그 문자열을 누가 어떤 조건으로 공표했는지 확인하는 일입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- ‘주소가 바뀐다’는 문장을 먼저 세 갈래로 나눕니다
주소 변경 공지는 한 문장처럼 보이지만 실제로는 서로 다른 사건을 가리킬 수 있습니다.
- 이름·심볼·보유자 목록은 계약의 신분증이 아닙니다
ERC-20에서는 이름과 심볼이 사람이 읽기 쉬운 표기 역할을 하지만, 다른 계약이 같은 값을 쓰는 것을 막지는 않습니다.
- 공식 원문과 탐색기는 서로 다른 질문에 답합니다
발행 주체의 원문은 주소의 출처를, 탐색기는 해당 주소에서 일어난 코드·거래의 기록을 확인하는 데 씁니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
이름·심볼·보유자 목록은 계약의 신분증이 아닙니다
ERC-20에서는 이름과 심볼이 사람이 읽기 쉬운 표기 역할을 하지만, 다른 계약이 같은 값을 쓰는 것을 막지는 않습니다. ethereum.org는 사기 계약이 정식 토큰과 같은 이름·심볼을 사용할 수 있다고 설명합니다. 따라서 지갑 검색 결과에 같은 티커가 여러 개 보이거나, 받은 토큰의 이름이 익숙하다는 사실은 공식 계약이라는 근거가 되지 않습니다.
보유자 목록과 전송 횟수도 독립적인 판정 근거가 아닙니다. 계약 작성자는 특정 주소에 잔액이 있는 것처럼 보이게 하거나, 전송 이벤트를 만들 수 있습니다. 탐색기 라벨과 커뮤니티 신고는 보조 신호로 유용할 수 있지만, 라벨이 없다는 이유만으로 안전하다고 결론낼 수는 없습니다. 같은 네트워크에서 이미 존재하는 정식 계약과 같은 주소를 복제해 쓸 수는 없습니다. 그래서 전체 주소와 네트워크를 함께 비교해야 합니다.
주소를 비교할 때는 네트워크도 함께 기록합니다. EVM 계열에서는 비슷한 0x 형식이 여러 체인에서 쓰이므로, 주소 문자열이 같더라도 Ethereum·Base·OP Mainnet 등 어느 네트워크의 계약인지 확인해야 합니다. 공지에 체인 이름이 빠져 있거나 지갑 화면의 선택 네트워크와 맞지 않으면, 그 시점에서는 전송이나 승인보다 공식 지원 채널의 확인이 우선입니다.
공식 원문과 탐색기는 서로 다른 질문에 답합니다
발행 주체의 원문은 주소의 출처를, 탐색기는 해당 주소에서 일어난 코드·거래의 기록을 확인하는 데 씁니다. 공지에서는 새 주소, 이전 주소의 취급, 전환 일정, 지원되는 체인과 문의 경로를 찾습니다. 반면 탐색기에서는 그 주소가 실제로 어느 네트워크에 존재하는지, 코드가 있는지, 어떤 거래가 기록됐는지를 확인합니다. 두 자료는 경쟁 관계가 아니라 역할이 다릅니다. 공지만 보고 코드 상태를 단정하거나, 탐색기 화면만 보고 발행 주체를 단정하면 각각 빈칸이 남습니다.
소스 코드 검증의 뜻도 좁게 읽어야 합니다. ethereum.org는 검증을 공개 소스와 해당 주소에서 실행되는 바이트코드를 비교하는 과정으로 설명합니다. 이것은 코드 읽기와 독립 검토에 도움을 주지만, 사업자가 어떤 주소를 공식 자산으로 채택했는지까지 증명하지는 않습니다. 검증된 계약이라도 다른 이름을 내세울 수 있고, 반대로 프로젝트의 공지가 없는 주소를 ‘공식 교체본’으로 부를 근거가 생기는 것은 아닙니다.
프록시 구조라면 탐색기에서 보이는 주소와 실제 실행 로직의 주소가 다를 수 있습니다. 이때는 프록시 주소가 공지의 대상인지, 구현 주소 변경을 알린 기술 공지인지부터 구별합니다. 프록시 업그레이드의 주소 역할을 분리해 읽는 방법도 함께 참고할 수 있습니다.
| 자료 | 확인할 내용 | 그 자료만으로 확정할 수 없는 것 |
|---|---|---|
| 발행 주체의 공식 원문 | 새·이전 주소, 네트워크, 전환 조건과 일정 | 그 주소의 코드가 공지 내용과 동일하게 동작하는지 |
| 체인 탐색기 | 주소 존재, 코드, 거래·이벤트 기록 | 해당 프로젝트가 그 주소를 공식 자산으로 채택했는지 |
| 소스 코드 검증 정보 | 공개 소스와 배포 바이트코드의 일치 범위 | 코드의 안전성, 발행 주체의 신원, 투자 적합성 |
| 지갑·거래소 안내 | 해당 서비스의 입출금·전환 지원 조건 | 다른 서비스나 체인에서의 지원 여부 |
이전 계약은 ‘가짜’와 같은 뜻이 아닙니다
프로젝트가 새 계약을 공지했더라도 이전 계약은 체인에 남아 있을 수 있습니다. 이것은 과거 기록이나 보유분이 존재한다는 뜻일 수 있지만, 지금도 입금·거래·교환이 지원된다는 뜻은 아닙니다. 반대로 종료 공지가 없는 이전 계약을 두고 새 계약이 아닌 모든 토큰을 가짜라고 단정하는 것도 정확하지 않습니다. 이용자에게 필요한 결론은 ‘어느 주소가 현재 어떤 목적에 지원되는가’입니다.
전환이 필요한 사례라면 원문에서 대상 보유자, 스냅샷 기준, 신청 방법, 기한, 수수료, 예외를 확인합니다. 교환 비율이나 자동 반영 여부가 명시되지 않았다면 지갑의 토큰 가져오기 기능, 검색 광고, 개인 메시지로 조건을 보완하지 않습니다. 지갑 확장 프로그램에서 서명·승인을 요구하는 화면이 나타나면 공지의 도메인과 연결 경로부터 다시 확인하고 권한 요청을 별도로 읽습니다.
거래소의 지원 공지도 발행 주체 공지와 분리해 보아야 합니다. 거래소가 특정 시점에 이전 계약 입금을 중단하거나 새 계약만 지원한다고 안내했다면, 이는 그 거래소의 운영 조건입니다. 같은 주소를 개인 지갑에서 보유하는 문제와는 별개이며 다른 거래소나 지갑의 처리 결과를 예고하지 않습니다.
주소를 대조할 때는 전체 문자열과 연결 경로를 남깁니다
주소 앞뒤 몇 글자만 보는 습관은 유사한 접두사·접미사를 이용한 혼동에 취약합니다. 공식 페이지에서 주소를 열어 탐색기로 이어지는 링크가 있는지 확인하고, 그 페이지의 도메인을 북마크나 이미 알고 있던 공식 경로에서 다시 여는 방식이 좋습니다. 검색 광고, 답글, DM으로 받은 링크는 공지 원문의 출처가 되지 않습니다.
복사한 주소는 붙여넣기 전후에 전체 문자열을 대조하고, 지갑이 선택한 네트워크와 공지의 네트워크를 같은 줄에 적습니다. 이전 주소와 새 주소를 한 표에 놓으면 잘못된 주소를 ‘업데이트된 것’으로 기억하는 실수를 줄일 수 있습니다. 소액 전송조차 잘못된 대상이면 되돌릴 수 없을 수 있으므로, 출처·네트워크·지원 상태 중 하나라도 비어 있으면 실행 단계로 넘어가지 않는 것이 합리적입니다.
- 발행 주체가 관리하는 공식 사이트에서 공지의 게시일과 원문 URL을 확인합니다.
- 새 주소와 이전 주소를 각각 전체 문자열로 기록하고, 해당 체인 이름을 나란히 적습니다.
- 공지의 표현을 계획·전환 진행·지원 종료 중 어느 상태인지 분류합니다.
- 탐색기에서 주소의 코드와 검증 상태를 보되, 검증 표시를 발행 주체 인증으로 확대 해석하지 않습니다.
- 지갑·거래소의 입출금 지원 조건을 따로 확인하고 불명확하면 전송·승인·서명을 보류합니다.
확인 결과는 ‘확정’과 ‘미확인’을 나누어 기록합니다
확인 메모에는 ‘공식 원문에서 새 계약 주소와 Ethereum 네트워크를 확인함’처럼 출처와 사실을 함께 적습니다. ‘새 계약이 안전하다’, ‘전환이 모든 보유자에게 자동 적용된다’처럼 원문과 코드 검토만으로 말할 수 없는 결론은 적지 않습니다. 이 구분은 이후 공지가 수정되거나 지원 조건이 바뀌었을 때 무엇을 다시 확인해야 하는지도 보여 줍니다.
현재의 주소·지원 상태는 시간이 지나면 달라질 수 있습니다. 이 글에서 다루는 것은 2026년 9월 27일에 확인한 일반적인 판독 원칙이며, 특정 프로젝트의 주소나 전환 상태를 제시하지 않습니다. 실제 안내를 따라야 할 때는 당시의 공식 원문과 이용 중인 서비스의 최신 안내를 다시 열어 확인하세요. 이는 매수·매도 권유가 아니라, 서로 다른 증거가 말하는 범위를 구분하는 정보입니다.
자주 묻는 질문
탐색기에 소스 코드가 검증돼 있으면 공식 토큰인가요?
아닙니다. 소스 코드 검증은 공개 소스와 해당 주소의 배포 바이트코드가 맞는지 확인하는 정보입니다. 프로젝트가 그 주소를 공식 자산으로 공지했는지는 발행 주체의 원문에서 별도로 확인해야 합니다.
기존 계약 주소에 잔액이 있으면 새 계약으로 자동 이동하나요?
자동 이동 여부는 프로젝트별 전환 규칙과 지원 서비스 조건에 따라 다릅니다. 스냅샷, 청구 절차, 기한, 대상 체인이 공식 원문에 명시됐는지 확인하기 전에는 자동 전환으로 가정하지 마세요.
같은 주소가 다른 체인에도 보이면 같은 토큰인가요?
주소 문자열만으로는 판단할 수 없습니다. EVM 계열 체인에서는 같은 형식의 주소가 쓰이므로, 공지가 지정한 네트워크와 각 체인의 계약 코드·발행 주체 안내를 함께 대조해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
