리베이스 토큰은 transfer가 없어도 계정의 표시 balance와 total supply가 바뀔 수 있으므로 가격 수익률만으로 보유 성과를 계산하면 안 됩니다. 시작·종료 balance와 같은 시각의 가격을 곱해 가치 수익률을 구하고, 내부 share가 있다면 share 수와 share당 자산가치 변화를 분리합니다. Positive rebase가 수익을 보장하지 않으며 가격이 같은 비율로 하락하면 가치가 그대로일 수 있습니다. Transfer event 합계만으로 balance history를 복원하는 것도 실패할 수 있습니다.
가격과 수량을 같은 시각에 묶습니다
가정 시작 balance 100 token, 가격 10달러면 가치는 1,000달러입니다. +5% positive rebase 뒤 balance 105, 가격 9.60달러라면 종료 가치는 1,008달러이고 보유 가치 수익률은 0.8%입니다. 가격만 보면 -4%, 수량만 보면 +5%라 어느 하나도 실제 결과가 아닙니다.
Snapshot 시각이 price candle close와 어긋나면 급변 구간 오차가 커집니다. Chain block timestamp와 시장 가격의 UTC 기준을 맞춥니다. **가격 수익률과 보유 가치 수익률을 별도 열로 둡니다**.
리베이스 자산의 성과 단위는 한 token의 가격이 아니라 같은 지분이 가리키는 전체 자산가치입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 가격과 수량을 같은 시각에 묶습니다
가정 시작 balance 100 token, 가격 10달러면 가치는 1,000달러입니다.
- Share와 표시 balance를 분리합니다
Lido 문서는 stETH balance를 account shares×total pooled ether÷total shares로 설명합니다.
- Transfer event만으로 잔액을 복원하지 않습니다
리베이스가 모든 holder balance를 계산식으로 바꾸면 각 주소마다 Transfer event를 발생시키는 것은 비현실적입니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
Share와 표시 balance를 분리합니다
Lido 문서는 stETH balance를 account shares×total pooled ether÷total shares로 설명합니다. Oracle report로 pooled ether가 늘면 shares가 그대로여도 표시 balance가 늘 수 있습니다. Integration은 변하지 않는 shares를 기본 단위로 다루도록 권고합니다.
가정 user share 1, total shares 5, pooled asset 10이면 balance는 2입니다. Pooled asset이 15로 늘고 shares가 같다면 balance는 3입니다. **표시 balance 증가를 새 share 발행으로 기록하지 않습니다**.
| 항목 | 시작 | 종료 | 변화 |
|---|---|---|---|
| Internal shares | 1.00 | 1.00 | 0% |
| Token balance | 100 | 105 | +5% |
| Unit price | $10.00 | $9.60 | -4% |
| Holding value | $1,000 | $1,008 | +0.8% |
| Protocol ownership | 고정 가정 | 고정 가정 | share 기준 |
Transfer event만으로 잔액을 복원하지 않습니다
리베이스가 모든 holder balance를 계산식으로 바꾸면 각 주소마다 Transfer event를 발생시키는 것은 비현실적입니다. Lido도 rebase balance 증가에 holder별 Transfer event가 없다고 설명합니다. Event indexer가 입출금만 합산하면 실제 balance와 달라집니다.
기준 block마다 balanceOf 또는 share 값을 읽고 rebase report를 적용합니다. Archive state가 없으면 당시 값을 현재 공식으로 역산할 때 fee mint, share burn과 rounding을 포함해야 합니다. **Event 합계와 state snapshot을 정기적으로 대사합니다**.
Positive와 negative rebase의 원인을 봅니다
Positive rebase는 reward, fee accounting 또는 공급 조절 정책에서 나올 수 있고 negative rebase는 penalty·손실이나 목표 가격 정책에서 생길 수 있습니다. 같은 +5%라도 보유자의 protocol 지분이 유지됐는지, fee share가 새로 발행됐는지 확인합니다.
Rebase 직전·직후 DEX reserve와 oracle price 반영 시각도 다를 수 있습니다. Arbitrage 뒤 가격 변화까지 포함한 기간 수익률을 보고 순간 snapshot을 무위험 이익으로 해석하지 않습니다.
Wrapper와 세금·회계 경계를 명시합니다
Non-rebasing wrapper는 token 수량 대신 wrapper당 underlying 교환율이 변할 수 있습니다. Wrapped version과 rebasing version을 합산하려면 같은 share 또는 underlying 단위로 변환하고 둘을 별도 자산처럼 중복 더하지 않습니다.
리베이스의 법률·세무 인식은 관할과 서비스에 따라 다르므로 기술적 balance 증가만으로 과세 시점이나 소득을 단정하지 않습니다. 원장에는 rebase event, share rate, 가격 source와 실제 처분을 분리해 보관합니다.
- 시작·종료 block의 balance와 share를 읽습니다.
- 동일 UTC 시각의 검증 가능한 가격을 붙입니다.
- 입출금 cash flow를 기간 수익에서 분리합니다.
- Rebase·fee mint·share burn을 원인별 기록합니다.
- Wrapper는 underlying 또는 share 단위로 환산합니다.
자주 묻는 질문
Positive rebase 10%면 수익률도 10%인가요?
가격과 현금 흐름이 함께 변하므로 종료 보유 가치로 계산해야 하며 10% 수익을 보장하지 않습니다.
Transfer event를 모두 더하면 잔액을 알 수 있나요?
Holder별 event 없이 rebase가 적용될 수 있어 balanceOf·share snapshot이 필요합니다.
Wrapped rebase token도 수량이 늘어나나요?
Wrapper는 수량 대신 underlying 교환율이 변하는 구조가 많으므로 해당 contract 공식을 확인해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
