ERC-20 인터페이스는 transfer의 value 인수와 받는 쪽 잔액의 실제 증가분이 늘 같다고 보장하지 않습니다. 전송 수수료형 토큰(fee-on-transfer token)은 일부를 소각하거나 재무 금고·보유자에게 보내 받는 양을 줄일 수 있고, 리베이스 토큰(rebase token)은 전송 없이도 계정 잔액과 totalSupply를 비율대로 조정할 수 있습니다. 프로토콜이 amount 인수를 그대로 입금액으로 장부에 올리거나, 저장해 둔 토큰 잔액이 계속 같다고 가정하면 지분 과다 발행, 출금 실패, 지급 불능이 생깁니다. 입금 전후 잔액 차이를 재고 내부 지분(share)으로 몫을 기록하되, 출금 수수료·음의 리베이스와 토큰별 지원 정책도 명시해야 합니다.
value 인수와 잔액 변화가 다를 수 있습니다
사용자가 금고 계약에 transferFrom 100을 호출해도 토큰이 2를 수수료로 떼면 금고 잔액은 98만 늘어납니다. 이때 금고가 지분 100을 발행하면 새 사용자가 기존 예치자의 자산을 가져가는 셈입니다. 안전 전송 래퍼는 호출 성공과 false 반환을 처리할 뿐, 경제적으로 100이 실제 도착했는지는 확인하지 않습니다.
입금 직전 b0와 직후 b1을 읽어 received=b1-b0로 계산하면 들어올 때 붙는 수수료를 반영할 수 있습니다. 그러나 토큰 콜백 중 재진입, 동시에 들어온 기부성 입금, 특이한 잔액 규칙이 있으면 단순한 차이 계산에도 위협 모델이 필요합니다. 아무 계약이나 지원 토큰으로 받아들일지부터 정합니다.
ERC-20 호환은 함수 호출 언어가 같다는 뜻이며, 한 번의 전송 뒤 회계 숫자가 같은 방식으로 움직인다는 보장은 아닙니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- value 인수와 잔액 변화가 다를 수 있습니다
사용자가 금고 계약에 transferFrom 100을 호출해도 토큰이 2를 수수료로 떼면 금고 잔액은 98만 늘어납니다.
- 리베이스는 전송 없이 잔액을 바꿉니다
리베이스 토큰은 기초 지분 단위와 표시 잔액 사이의 환율을 바꿔 모든 보유자의 잔액을 늘리거나 줄일 수 있습니다.
- 탈중앙 거래소와 금고 사례를 실제 숫자로 봅니다
풀 준비금이 1,000으로 기록돼 있고 거래자가 수수료형 토큰 100개를 보냈는데 95만 도착했다면, 1,100을 기준으로 출력량을 계산하는 라우터는 불변식을 비틀어 버립니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
리베이스는 전송 없이 잔액을 바꿉니다
리베이스 토큰은 기초 지분 단위와 표시 잔액 사이의 환율을 바꿔 모든 보유자의 잔액을 늘리거나 줄일 수 있습니다. 프로토콜이 입금 당시 토큰 100개라는 절대 숫자만 부채로 저장하면 양의 리베이스 이익을 나누거나 음의 리베이스 손실을 반영하지 못합니다.
지분 기반 금고는 운용 자산 총액 대비 지분 비율로 각자의 몫을 계산할 수 있습니다. 다만 balanceOf가 호출 시점에 계산되는지, 반올림 방식과 리베이스 제외 계정이 있는지는 토큰 구현마다 다릅니다. ‘리베이스 지원’이라는 말은 실제 토큰 버전별 테스트 결과 범위로 좁혀 씁니다.
| 동작 | 깨지는 가정 | 대응 |
|---|---|---|
| 입금 수수료 | 입력액=수령액 | 전후 잔액 차이 |
| 출금 수수료 | 차감액=사용자 수령액 | 최소 수령액·정책 |
| 양의 리베이스 | 잔액은 전송 때만 증가 | 지분 환율 |
| 음의 리베이스 | 원금 수량 유지 | 손실 처리 |
| false 반환·반환값 없음 | 성공 시 true | 안전 래퍼 |
탈중앙 거래소와 금고 사례를 실제 숫자로 봅니다
풀 준비금이 1,000으로 기록돼 있고 거래자가 수수료형 토큰 100개를 보냈는데 95만 도착했다면, 1,100을 기준으로 출력량을 계산하는 라우터는 불변식을 비틀어 버립니다. 수수료형 토큰 지원 경로는 풀의 실제 잔액 증가분을 쓰지만, 모든 라우터·견적 함수가 이를 지원하지는 않습니다.
금고에 자산 1,000과 지분 1,000이 있는 상태에서 10% 음의 리베이스가 일어나면 자산은 900, 지분당 자산은 0.9가 됩니다. 먼저 출금한 사용자에게 원래대로 1:1을 지급하면 나중 사용자에게 손실이 몰립니다. 환율 계산과 반올림 순서를 명시합니다.
- 토큰 코드·프록시 구현과 관리자 권한을 확인합니다.
- 입금·출금 전후의 잔액 차이를 잽니다.
- 양·음의 리베이스를 포크 테스트로 주입합니다.
- 지분 환율과 반올림 불변식을 검사합니다.
- 지원하지 않는 토큰은 분명하게 거부합니다.
이벤트만으로 회계를 복원하지 않습니다
ERC-20은 전송 때 Transfer 이벤트를 내도록 정하지만, 수수료형 토큰은 이벤트를 여러 개 내기도 하고 리베이스는 별도 이벤트나 내부 지수로 표현되기도 합니다. 인덱서가 Transfer의 value만 더해 잔액을 만들면 체인 위 balanceOf 값과 어긋날 수 있습니다.
입금을 인정할 때는 거래 영수증의 성공 여부, 계약의 실제 잔액, 내부 지분을 함께 확인합니다. 토큰이 업그레이드되면 동작 규칙이 바뀔 수 있으므로 코드 해시와 관찰 시점을 기록하고, 심볼이 같다는 이유로 정책을 그대로 다시 쓰지 않습니다.
승인과 전송 성공도 따로 다룹니다
사용 한도 100이 있어도 transferFrom은 수수료 때문에 받는 쪽에 100이 도착한다고 보장하지 않습니다. 일부 오래된 토큰은 bool을 돌려주지 않고 일부는 false를 돌려주므로, 저수준 반환 데이터를 안전 래퍼 규칙에 따라 처리합니다. 호출 성공 확인과 수령액 검증은 서로 다른 두 단계입니다.
화면의 견적은 예상 토큰 수수료와 최소 수령량을 보여 주되, 토큰 관리자가 수수료를 바꿀 수 있는지도 확인합니다. 정확한 수익률이나 원금을 약속하지 말고, 지원하지 않는 동작이 감지되면 입금을 멈추는 절차를 마련해 둡니다.
자주 묻는 질문
SafeERC20을 쓰면 수수료형 토큰도 자동으로 처리되나요?
호출 성공 형식은 처리하지만 실제 수령액 회계까지 고쳐 주지는 않습니다. 잔액 차이 계산이 따로 필요합니다.
리베이스 뒤에는 사용자의 지분 수도 바뀌나요?
일반적인 지분 회계에서는 지분 수는 그대로 두고 지분당 자산이 변합니다. 다만 구현 정책에 따라 다를 수 있으니 확인해야 합니다.
Transfer 이벤트 합계로 잔액을 확정할 수 있나요?
비표준 리베이스·수수료 구현에서는 부족할 수 있으므로 balanceOf와 계약 회계를 대조해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
