토큰 배분 정정 공지, 숫자 오류와 권리 변경을 구분하기

토큰 배분 정정은 원본 표의 숫자 오류를 바로잡는 경우와 실제 수령자·수량·베스팅·해제 조건을 바꾸는 경우를 먼저 갈라야 합니다. 합계가 100%로 고쳐졌다고 해서 온체인 발행량이나 누군가의 권리가 자동으로 바뀐 것은 아닙니다. 반대로 표가 아닌 계약·지갑·베스팅 일정이 바뀌었다면 원문 공지, 변경 권한, 거래 또는 계약 기록을 함께 확인해야 합니다. ERC-20의 totalSupply와 balanceOf는 계약이 보고하는 값이지만, 배분표의 각 범주나 법적·계약상 권리까지 혼자 설명하지는 않습니다.

먼저 정정 대상이 문서인지 권리인지 나눕니다

배분표의 오탈자, 백분율 반올림, 행 합계 오류는 문서의 숫자를 고치는 일일 수 있습니다. 이 경우 정정 전후 표에서 어느 셀을 왜 바꿨는지, 총공급량과 수량 합계가 어떻게 맞는지를 보여 주면 독자가 수정 범위를 재계산할 수 있습니다. 표가 수정됐다는 사실만으로 이미 발행된 토큰의 이동이나 새 권리의 발생을 뜻하지는 않습니다.

반면 수령자 지갑, 배정 수량, 잠금 기간, cliff, 해제 속도, 청구 조건을 바꾸는 공지는 권리와 실행에 영향을 줄 수 있습니다. 이 경우 최초 배분표와 정정표의 차이뿐 아니라 어떤 계약이나 관리자 권한이 변경을 허용하는지, 변경이 실제로 실행됐는지를 분리해 확인해야 합니다. 계획·승인·실행은 한 단계가 아닙니다.

‘정정’이라는 제목은 범위를 보증하지 않습니다. 원문이 숫자 표만 고쳤는지, 기존 문장을 철회했는지, 앞으로 적용할 규칙을 바꿨는지 동사를 그대로 읽습니다. 변경 이유가 공개되지 않았거나 실행 증거가 없을 때에는 단순 표기 정정인지 권리 변경인지 확정하지 말고 미확인으로 남겨야 합니다.

배분표의 오류를 바로잡는 일과 배분 권리를 다시 쓰는 일은 같은 편집이 아닙니다.

JOBCOIN 해설

VISUAL GUIDE뉴스·공시를 확인하는 세 가지 기준

1. 01
   먼저 정정 대상이 문서인지 권리인지 나눕니다

   배분표의 오탈자, 백분율 반올림, 행 합계 오류는 문서의 숫자를 고치는 일일 수 있습니다.

2. 02
   표를 다시 계산해도 온체인 상태가 자동으로 나오지는 않습니다

   배분표는 보통 전체 공급량을 기준으로 범주별 비율과 수량을 설명합니다.

3. 03
   decimals와 수량 표기는 같은 단위를 요구합니다

   ERC-20에는 decimals 조회가 있어 화면에 표시할 단위를 정할 수 있습니다.

AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.

표를 다시 계산해도 온체인 상태가 자동으로 나오지는 않습니다

배분표는 보통 전체 공급량을 기준으로 범주별 비율과 수량을 설명합니다. 각 행의 수량을 더하고 그 합계를 총공급량으로 나누어 백분율을 다시 계산하면 표 내부의 일관성은 점검할 수 있습니다. 다만 표가 사용하는 총공급량의 정의가 현재 발행량, 최대 발행량, 향후 민팅 가능량 중 무엇인지 명시되지 않았다면 산식이 맞아도 해석은 달라질 수 있습니다.

ethereum.org의 ERC-20 표준 설명에 따르면 totalSupply는 네트워크에서 사용 가능한 토큰 총공급을 조회하는 함수이고 balanceOf는 특정 계정의 잔액을 조회합니다. 이 함수들은 계약이 추적하는 수량을 읽는 기술적 인터페이스입니다. 팀·투자자·커뮤니티 같은 배분 범주, 잠긴 물량, 거래소 수탁 잔액의 실질 소유자까지 자동으로 분류해 주지는 않습니다.

같은 계약의 totalSupply와 공개 표의 합계가 다르면 바로 오류라고 쓰기보다 단위와 기준일을 먼저 맞춥니다. decimals가 18이면 원시 정수값은 사람이 읽는 토큰 수량으로 바꿔야 하며, 민팅·소각·브리지 래핑·별도 체인 배포가 있는지에 따라 비교 범위도 달라질 수 있습니다. 원문이 설명하지 않는 차이는 추정하지 않습니다.

decimals와 수량 표기는 같은 단위를 요구합니다

ERC-20에는 decimals 조회가 있어 화면에 표시할 단위를 정할 수 있습니다. 튜토리얼은 토큰 수량이 내부적으로 정수로 저장되고 decimals가 사람이 읽는 표시 단위와 관련된다는 점을 설명합니다. 예를 들어 원시값 1000000이 곧 100만 토큰인지, 1토큰인지 판단하려면 decimals를 알아야 합니다.

배분 정정의 합계를 검산할 때 수량 열의 단위, 백분율의 분모, 반올림 자릿수, 기준일을 같은 표에 씁니다. 33.33%씩 세 행을 반올림하면 99.99%가 될 수 있는데, 이것은 곧바로 0.01%의 누락 배분을 뜻하지 않습니다. 반올림 규칙과 실제 원시 수량을 확인해야 합니다.

계약 주소가 여러 개이거나 네트워크가 바뀐 경우에는 같은 심볼을 한 공급량으로 합치지 않습니다. 새 계약의 totalSupply와 이전 계약의 totalSupply는 별도 상태일 수 있습니다. 브리지나 래핑 토큰의 발행·소각 규칙도 원본 체인의 배분표와 다른 질문을 다룰 수 있으므로 주소와 체인을 함께 기록합니다.

• 원본·정정본의 게시 URL과 시간, 바뀐 셀을 보관합니다.
• 총공급량의 정의와 표의 수량 단위를 먼저 확인합니다.
• totalSupply·balanceOf·decimals 조회는 계약 주소와 네트워크를 붙여 기록합니다.
• 베스팅·수령자 변경은 권한·조건·실행 증거를 별도 확인합니다.

베스팅 변경은 일정표와 권한을 함께 읽습니다

베스팅은 특정 수량을 일정과 조건에 따라 사용할 수 있게 하는 구조입니다. 표가 ‘팀 물량 20%’라고 적어도 그 20%가 한 지갑에 있는지, 별도 베스팅 계약에 잠겨 있는지, 이미 일부 해제됐는지는 표만으로 알 수 없습니다. 그래서 배분표의 범주와 실제 주소·계약 상태를 동일한 것으로 가정하면 안 됩니다.

일정을 수정한다는 공지는 cliff 날짜, 선형 해제 기간, 취소·회수 가능 조건, 수령자 변경, 관리자의 권한 가운데 무엇이 바뀌었는지 밝혀야 합니다. 관리자 권한이 존재한다는 사실도 그 권한이 실제로 사용됐다는 증거는 아닙니다. 실행을 주장하려면 관련 거래·이벤트 또는 공식 후속 보고를 찾습니다.

개별 수령자의 지갑 잔액이 변했다고 해서 반드시 배분 권리가 변경됐다고 볼 수도 없습니다. 전송, 수탁, 매매, 브리지 이동은 서로 다른 사건입니다. 주소 라벨과 지갑 잔액은 보조 관측 자료로 쓰되, 변경 공지와 계약 조건을 대체하는 증거로 쓰지 않는 편이 안전합니다.

정정 공지는 이전 버전과 함께 보관합니다

정정이 나온 뒤 원본 표를 삭제하면 무엇이 바뀌었는지 검토하기 어려워집니다. 원본 URL·게시 시각·정정 URL·정정 시각을 보관하고, 삭제된 행·새 행·변경된 수량·변경 사유를 따로 표시하세요. URL이 같은 문서가 수정되는 경우에는 확인 시각과 문서 버전·스크린샷 같은 식별 정보를 남깁니다.

독자 메모에는 ‘표의 백분율 반올림을 정정함’, ‘수령자 주소 변경을 발표함’, ‘베스팅 계약 변경 거래를 확인함’처럼 증거 수준에 맞춘 문장을 씁니다. 발표만 있는 단계에서 ‘배분이 변경됐다’고 단정하지 않고, 계약 기록만 보고 ‘공식 정정’이라고 단정하지 않는 구분이 필요합니다.

이 글은 특정 토큰의 공급이나 권리를 판정하거나 거래 행동을 권하지 않습니다. 실제 정정의 법적 효과와 서비스 지원 조건은 프로젝트 원문·계약 문서·이용 중인 사업자의 최신 안내에서 확인해야 합니다. 불명확한 전환이나 승인 요청은 출처·주소·네트워크가 맞을 때까지 보류하는 편이 좋습니다.

자주 묻는 질문