발행 스케줄은 총 배정량, 시작 시각, cliff, 종료 시각, 방출 주기와 반올림 규칙을 먼저 구조화한 뒤 공통 관측 간격에서 누적 해제량을 계산해야 합니다. 각 시점의 신규 방출량은 현재 누적 해제량에서 직전 시점 누적량을 뺀 값입니다. Cliff는 그 전까지 0이었다가 경계에서 일부가 한꺼번에 풀릴 수 있고, linear는 시간에 비례하며, epoch 방식은 경계마다 계단식으로 증가합니다. 계약의 vested 값은 수령 가능 상한일 수 있어 실제 claim·유통량 증가와 동일하다고 단정하지 않습니다.
문장을 여섯 개 입력값으로 바꿉니다
“1년 cliff 뒤 3년 linear”라는 문장만으로는 계산이 끝나지 않습니다. 총 배정량 A, 시작 시각 S, cliff 시각 C, 종료 E, 방출 주기 P, 정수 반올림 규칙을 기록합니다. UTC 초·일·epoch 중 계약이 실제 쓰는 단위를 보존하고 달력 월을 30일로 임의 치환하지 않습니다.
OpenZeppelin VestingWallet은 기본 누적 vested amount를 선형 곡선으로 계산하며 schedule을 override할 수 있습니다. 이미 시작된 wallet에 뒤늦게 자산을 보내면 과거부터 있었던 것처럼 일부가 즉시 releasable할 수 있습니다. **계약 주소의 현재 잔액만으로 총 배정량을 정하지 않습니다**.
방출 모델의 공통 언어는 이번 달 물량이 아니라 시각 t까지 풀린 누적량 V(t)입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 문장을 여섯 개 입력값으로 바꿉니다
“1년 cliff 뒤 3년 linear”라는 문장만으로는 계산이 끝나지 않습니다.
- 누적 함수에서 신규 방출량을 만듭니다
가정 배정량 1,200만 개, 시작 2026-01-01, 90일 cliff, 전체 360일이라고 하겠습니다.
- 계단 경계의 포함 조건을 시험합니다
Epoch 방출은 floor((t-S)/P)처럼 완료된 구간 수를 쓰는 경우가 많습니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
누적 함수에서 신규 방출량을 만듭니다
가정 배정량 1,200만 개, 시작 2026-01-01, 90일 cliff, 전체 360일이라고 하겠습니다. Linear-with-cliff가 cliff 뒤에도 원래 종료일을 유지하면 90일 경계 누적량은 300만 개가 될 수 있습니다. 반면 cliff 뒤부터 270일간 새로 선형 방출하는 계약이면 경계 직후 0에서 시작합니다. 문구가 같아 보여도 곡선은 다릅니다.
월별 표에서는 매월 말 V(t)를 먼저 계산하고 신규량 ΔV=V(t)-V(t-1)를 구합니다. 일별 계산을 월별로 합산한 값과 월말 차분이 일치하는지 대조합니다. **중간 반올림은 하지 않고 계약 정수 나눗셈을 재현합니다**.
| 시점 | Cliff 일시 방출 | 연속 linear | 90일 epoch |
|---|---|---|---|
| 0일 | 0 | 0 | 0 |
| 90일 | 3,000,000 | 3,000,000 | 3,000,000 |
| 180일 | 6,000,000 | 6,000,000 | 6,000,000 |
| 270일 | 9,000,000 | 9,000,000 | 9,000,000 |
| 360일 | 12,000,000 | 12,000,000 | 12,000,000 |
계단 경계의 포함 조건을 시험합니다
Epoch 방출은 floor((t-S)/P)처럼 완료된 구간 수를 쓰는 경우가 많습니다. 정확히 경계인 timestamp가 새 tranche에 포함되는지, 마지막 잔여량을 종료 시점에 몰아 주는지 확인합니다. 블록 timestamp와 현지 날짜 표기가 어긋나면 하루 앞선 unlock으로 보일 수 있습니다.
경계 직전 C-1, 경계 C, 직후 C+1을 계산하는 테스트가 중요합니다. 시작 전, 종료 후, schedule 중 추가 입금, 이미 release된 금액도 넣습니다. **문서 도표보다 배포된 계약 함수를 우선해 대조합니다**.
해제량과 시장 유입량을 분리합니다
Vested는 beneficiary가 받을 권리가 생긴 누적 상한이고 released는 이미 인출한 누적량입니다. releasable은 대체로 vested-released입니다. 인출된 물량도 treasury나 수탁 주소에 남으면 데이터 제공자의 circulating 기준에 따라 제외될 수 있습니다.
따라서 공급 충격 표에는 scheduled vested, on-chain release, 거래소·브리지 유입을 별도 열로 둡니다. 300만 개 cliff가 있어도 당일 전량 매도된다는 결론은 근거가 없습니다. 가격 영향 분석에는 실제 주소 이동, 호가 깊이와 기간을 추가해야 합니다.
재현 가능한 계산표를 남깁니다
입력에는 계약 주소, chainId, code version, allocation source, start·cliff·end timestamp, timezone, decimals를 저장합니다. 계산 결과마다 원 단위 정수와 표시 단위를 함께 남기고 schedule 변경 권한이나 취소 가능성도 기록합니다.
검산 순서는 총 신규량 합계가 배정량과 일치하는지, 누적량이 감소하지 않는지, 종료 뒤 배정량을 넘지 않는지입니다. 여러 wallet은 수혜자별 계산 후 합산하고 같은 물량의 wrapper·bridge representation을 중복 더하지 않습니다. 계산 workbook에는 입력값과 공식 버전을 잠그고 변경된 schedule은 새 scenario로 보존합니다. 그래야 과거 보고서가 현재 계약 조건으로 조용히 다시 계산되는 일을 막을 수 있습니다.
- 총 배정량과 각 수혜자 배정 합계를 맞춥니다.
- Cliff 직전·경계·직후 누적량을 계산합니다.
- 누적량 차분과 실제 release event를 대조합니다.
- UTC timestamp와 표시 달력의 변환을 기록합니다.
- 종료 시 잔여 정수 단위가 어디에 배정되는지 확인합니다.
자주 묻는 질문
Cliff 날에는 항상 전량이 한꺼번에 풀리나요?
아닙니다. Cliff가 지급을 막기만 하고 원래 선형 곡선을 따라 catch-up하는지, cliff 뒤 새 곡선이 시작되는지 계약을 확인해야 합니다.
Unlock 수량을 circulating supply 증가로 봐도 되나요?
권리 발생·claim·공개시장 유통은 다르므로 주소 분류와 실제 이동을 추가로 확인해야 합니다.
월별 모델은 날짜 수를 모두 30일로 두면 되나요?
계약이 초 단위 시간을 쓰면 실제 UTC timestamp 차이로 계산하고 표시에만 월 단위를 사용해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
