유통량은 계약의 totalSupply를 그대로 옮겨 적은 값이 아닙니다. 데이터 제공자가 잠금, 베스팅, 재단, 팀, 재무 금고, 브리지 주소를 분류해 빼고 남긴 추정치입니다. CoinGecko와 CoinMarketCap도 공개 시장에서 거래될 수 있는지, 내부자·전략적 보유분을 뺐는지를 설명하지만, 제출받은 자료와 검증 시각, 개별 주소 판단까지 같지는 않을 수 있습니다. 비교할 때는 각 수치의 기준 시각과 체인 범위, 총공급, 제외 주소별 잔액을 맞춘 다음, 설명되지 않는 차이를 ‘미분류 잔액’으로 남겨야 합니다.
먼저 각 숫자의 이름과 시각을 고정합니다
제공자 A의 유통량과 제공자 B의 총공급을 비교하면 차이가 나는 것이 당연합니다. API 응답 시각, 블록 번호, 계약 주소, 소수점 자릿수를 저장하고 같은 시점의 총공급부터 맞춥니다. 여러 체인에 배포된 자산이라면 원래 체인에서 발행된 물량과 브리지로 옮겨 간 표현 토큰을 어디까지 넣었는지 밝힙니다.
CoinGecko는 총공급에서 잠금·베스팅·팀·재단처럼 유통되지 않는 지갑을 뺀다고 설명합니다. CoinMarketCap은 일반 시장 참여자 손에 있는 물량의 근사치이며 내부자·전략적 보유분을 뺀다고 밝힙니다. 이름이 같아도 무엇을 빼는지 정한 기준표는 같지 않습니다.
유통량은 온체인의 필드 하나가 아니라 주소와 보유 목적에 붙인 분류 정책의 결과입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 먼저 각 숫자의 이름과 시각을 고정합니다
제공자 A의 유통량과 제공자 B의 총공급을 비교하면 차이가 나는 것이 당연합니다.
- 주소별 차이표로 역산합니다
총공급이 10억 개라고 가정하고, A가 베스팅 2억, 재무 금고 1억, 브리지 예치분 5천만을 빼서 6억5천만으로 계산했다고 해 보겠습니다.
- 잠금 해제와 유통을 구분합니다
시간 잠금이 끝났다는 것은 전송이 가능해졌다는 뜻일 수 있습니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
주소별 차이표로 역산합니다
총공급이 10억 개라고 가정하고, A가 베스팅 2억, 재무 금고 1억, 브리지 예치분 5천만을 빼서 6억5천만으로 계산했다고 해 보겠습니다. B가 잠금이 풀린 재무 금고 물량을 포함하고 브리지 물량은 다른 체인의 공급으로 따로 센다면 7억5천만이 될 수 있습니다. 어느 쪽이 ‘거짓’이라고 단정하기보다 공개된 산정 방법과 주소 목록을 맞춰 봅니다.
시가총액 차이는 가격이 같다면 공급 차이에 비례합니다. 가격을 2달러로 가정하면 6억5천만 개는 13억 달러, 7억5천만 개는 15억 달러입니다. 이 예시는 산식을 설명하기 위한 것일 뿐 실제 자산 평가가 아닙니다. 가격 출처까지 같아야 공급 차이만 따로 비교할 수 있습니다.
| 보유 구분 | 잔액 | 제공자 A | 제공자 B |
|---|---|---|---|
| 일반 지갑 | 650M | 포함 | 포함 |
| 베스팅 계약 | 200M | 제외 | 제외 |
| 재단 금고 | 100M | 제외 | 포함 가능 |
| 브리지 예치 | 50M | 제외 | 체인별 따로 집계 |
| 계산 유통량 | 650M | 750M |
잠금 해제와 유통을 구분합니다
시간 잠금이 끝났다는 것은 전송이 가능해졌다는 뜻일 수 있습니다. 하지만 팀이나 재단이 장기 목적으로 계속 보유하고 있다면 제공자 정책상 여전히 빠질 수 있습니다. 반대로 재무 금고 물량이 지원금이나 시장조성자 대여로 외부에 넘어가면 일부가 유통량에 들어갈 수 있습니다.
잠금 해제 일정표에 나온 누적 해제량을 곧바로 유통량에 더하지 않습니다. 수령인, 보관 방식, 재잠금, 반환, 실제 공개 시장에서 거래할 수 있는지에 관한 자료를 확인합니다. 법적인 해제와 데이터 제공자의 유통 판정은 별개의 단계입니다.
브리지와 소각 주소를 따로 대사합니다
공식 잠금·발행형 브리지에서는 원래 체인에 예치된 5천만과 도착 체인의 래핑 토큰 5천만이 같은 경제적 단위를 가리킵니다. 전체 체인 공급을 계산하면서 둘을 모두 더하면 1억으로 부풀려집니다. 반면 소각·발행 방식으로 옮겼다면 출발 체인의 소각과 도착 체인의 발행을 같은 메시지로 이어 봅니다.
소각 주소로 보내도 계약의 totalSupply가 줄지 않는 구현도 있습니다. 제공자가 검증 가능한 소각분을 총공급에서 빼는지, 단지 접근할 수 없는 주소로만 분류하는지 확인합니다. 토큰 계약 이벤트, totalSupply 조회값, 제공자 조정값을 세 열로 나눠 보존합니다.
차이를 오류 대신 조정 원장으로 관리합니다
날마다 제공자 값, 자체 계산 값, 차이, 산정 방법이 마지막으로 바뀐 날을 저장합니다. 제외 주소마다 보유자 범주, 근거 주소(URL), 시작·종료 블록, 판단 상태를 기록하고, 불분명하면 일반 보유나 잠금으로 억지로 넣지 말고 ‘미결’로 둡니다.
제공자 갱신은 프로젝트의 자료 제출과 검토를 거치느라 늦어질 수 있습니다. 하루치 차이를 공급 충격으로 해석하지 말고 과거 값이 수정됐는지도 확인합니다. 주소 라벨이 바뀌면 과거 시계열까지 고쳤는지 판을 나눠 관리합니다.
- 같은 협정 세계시(UTC) 시각과 블록에서 totalSupply를 읽습니다.
- 제공자별 제외 주소와 정책 문구를 모읍니다.
- 잠금·재단·내부자·브리지·소각 물량을 각각 다른 묶음으로 둡니다.
- 차이를 주소 잔액으로 설명하고, 설명 못 한 부분은 미분류로 남깁니다.
- 가격과 공급 시각을 맞춘 뒤 시가총액을 다시 계산합니다.
자주 묻는 질문
잠금이 풀리면 다음 날 유통량에 자동 반영되나요?
제공자 정책과 검증 주기에 따라 다릅니다. 팀이나 재단이 보유한 물량이라면 잠금이 풀려도 계속 빠질 수 있습니다.
Contract totalSupply가 가장 정확한 유통량 아닌가요?
총발행 잔액으로는 정확할 수 있습니다. 하지만 잠금·재무 금고·브리지 예치 물량이 공개 시장에서 거래될 수 있는지는 구분하지 않습니다.
두 제공자 값 중 어느 것을 써야 하나요?
분석 목적에 맞는 산정 방법을 고르고 출처와 기준 시각을 고정해야 합니다. 서로 다른 공급 정의를 한 시계열에 섞어서는 안 됩니다.
