ERC-20 interface는 transfer의 value 인수와 수신자의 실제 balance 증가가 항상 같다고 보장하지 않습니다. Fee-on-transfer token은 일부를 burn·treasury·holder에게 보내 수령액을 줄일 수 있고, rebase token은 transfer 없이도 계정 balance와 totalSupply를 비례 조정할 수 있습니다. Protocol이 amount 인수를 그대로 입금액으로 장부화하거나 저장한 token balance가 계속 같다고 가정하면 과대 mint, 출금 실패와 insolvency가 생깁니다. 입금 전후 balance 차이를 측정하고 내부 share로 지분을 기록하되 outgoing fee·negative rebase와 token별 지원 정책도 명시해야 합니다.
Value 인수와 balance 변화가 다를 수 있습니다
사용자가 vault에 transferFrom 100을 호출해도 token이 2를 fee로 떼면 vault balance 증가는 98입니다. Vault가 100 shares를 mint하면 기존 depositor의 자산을 새 사용자가 가져갑니다. Safe transfer wrapper는 call 성공·false 반환을 처리할 뿐 경제적으로 100이 도착했는지 확인하지 않습니다.
입금 직전 b0와 직후 b1을 읽어 received=b1-b0로 계산하면 incoming fee를 반영할 수 있습니다. 그러나 token callback 중 reentrancy, 동시 donation과 unusual balance semantics가 있으면 단순 delta도 위협 모델이 필요합니다. 지원 token을 임의 contract로 열지 여부를 정합니다.
ERC-20 호환은 함수 호출 언어가 같다는 뜻이며, 한 번의 전송 뒤 회계 숫자가 같은 방식으로 움직인다는 보장은 아닙니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- Value 인수와 balance 변화가 다를 수 있습니다
사용자가 vault에 transferFrom 100을 호출해도 token이 2를 fee로 떼면 vault balance 증가는 98입니다.
- Rebase는 transfer 없이 balance를 바꿉니다
Rebase token은 underlying 지분 단위와 표시 balance의 환율을 바꿔 모든 holder balance를 늘리거나 줄일 수 있습니다.
- DEX와 vault 사례를 실제 숫자로 봅니다
Pool reserve가 1,000으로 기록됐고 trader가 100 fee token을 보냈지만 95만 도착했다면 1,100을 기준으로 output을 계산하는 router는 invariant를 왜곡합니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
Rebase는 transfer 없이 balance를 바꿉니다
Rebase token은 underlying 지분 단위와 표시 balance의 환율을 바꿔 모든 holder balance를 늘리거나 줄일 수 있습니다. Protocol이 deposit 당시 100 token이라는 절대 숫자만 debt로 저장하면 positive rebase 이익 배분이나 negative rebase 손실을 반영하지 못합니다.
Share 기반 vault는 total managed assets 대비 shares 비율로 각 지분을 계산할 수 있습니다. 하지만 balanceOf가 호출 시 계산되는지, rounding과 excluded accounts가 있는지 token 구현마다 다릅니다. ‘리베이스 지원’은 실제 token version별 테스트 결과로 제한합니다.
| 동작 | 깨지는 가정 | 대응 |
|---|---|---|
| Incoming fee | 입력액=수령액 | 전후 balance delta |
| Outgoing fee | 차감액=사용자 수령액 | 최소 수령액·정책 |
| Positive rebase | 잔액은 transfer 때만 증가 | share 환율 |
| Negative rebase | 원금 수량 유지 | loss 처리 |
| False·no return | 성공 시 true | 안전 wrapper |
DEX와 vault 사례를 실제 숫자로 봅니다
Pool reserve가 1,000으로 기록됐고 trader가 100 fee token을 보냈지만 95만 도착했다면 1,100을 기준으로 output을 계산하는 router는 invariant를 왜곡합니다. Supporting fee-on-transfer 경로는 pool의 실제 balance 증가를 사용하지만 모든 router·quote 함수가 이를 지원하는 것은 아닙니다.
Vault가 1,000 assets와 1,000 shares를 가진 상태에서 10% negative rebase가 나면 assets는 900이고 share당 자산은 0.9입니다. 먼저 출금한 사용자에게 원래 1:1을 지급하면 뒤 사용자에게 손실이 집중됩니다. Exchange rate와 rounding 순서를 명시합니다.
- Token code·proxy implementation과 관리자 권한을 확인합니다.
- 입금·출금 전후 balance delta를 측정합니다.
- Positive·negative rebase를 fork test로 주입합니다.
- Share 환율과 rounding invariant를 검사합니다.
- 지원하지 않는 token은 명확히 거부합니다.
Event만으로 회계를 복원하지 않습니다
ERC-20은 transfer가 Transfer event를 내도록 규정하지만 fee token이 여러 events를 내거나 rebase가 별도 event·내부 index로 표현될 수 있습니다. Indexer가 Transfer value만 합산해 balance를 만들면 on-chain balanceOf와 달라질 수 있습니다.
입금 credit은 transaction receipt 성공, contract의 실제 balance와 내부 shares를 함께 확인합니다. Token upgrade 뒤 semantics가 바뀔 수 있으므로 code hash와 관찰 시점을 기록하고 symbol이 같다는 이유로 정책을 재사용하지 않습니다.
승인과 전송 성공도 별도로 다룹니다
Allowance 100이 있어도 transferFrom이 fee 때문에 receiver 100을 보장하지 않습니다. 일부 오래된 token은 bool을 반환하지 않고 일부는 false를 반환하므로 low-level returndata를 안전 wrapper 규칙으로 처리합니다. 성공 wrapper와 수령액 검증은 두 단계입니다.
Frontend quote는 예상 token fee와 최소 수령량을 보여 주되 token 관리자가 fee를 바꿀 수 있는지 확인합니다. 정확한 수익률·원금 보장을 하지 않고 unsupported behavior 감지 시 deposit을 pause하는 절차를 둡니다.
자주 묻는 질문
SafeERC20을 쓰면 fee-on-transfer도 자동 처리되나요?
호출 성공 형식을 처리하지만 실제 수령액 회계를 자동 수정하지는 않습니다. Balance delta가 필요합니다.
Rebase 뒤 사용자의 share 수도 바뀌나요?
일반 share 회계에서는 share 수는 유지하고 share당 assets가 변하지만 구현 정책에 따라 확인해야 합니다.
Transfer event 합계로 잔액을 확정할 수 있나요?
비표준 rebase·fee 구현에서는 부족할 수 있어 balanceOf와 계약 회계를 대조해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
