거버넌스 토큰을 가지고 있어도 그 수량이 곧 투표권은 아닐 수 있습니다. 널리 쓰이는 OpenZeppelin의 ERC20Votes 구현은 기본 상태에서 토큰 잔액을 투표권으로 세지 않고, 보유자가 자기 자신이나 다른 주소에 위임해야 투표권 기록(체크포인트)이 시작됩니다. 또 제안의 투표권은 보통 지금 잔액이 아니라 정해진 과거 시점의 투표권으로 계산됩니다. 이 글은 OpenZeppelin 문서에 적힌 ERC20Votes의 구조만 설명하며, 특정 토큰이 이 구현을 쓴다고 단정하지 않습니다.
확인 기준일 2026-10-27 · 다음 확인 예정 2027-01-27
잔액과 투표권은 따로 기록됩니다
OpenZeppelin 문서는 ERC20Votes를 Compound 방식의 투표와 위임을 지원하는 ERC-20 확장이라고 소개합니다. 이 확장은 계정마다 투표권의 이력을 체크포인트로 저장합니다. 문서는 기본적으로 토큰 잔액이 투표권에 반영되지 않으며, 이렇게 하면 전송 비용이 줄지만 사용자가 투표권을 추적받으려면 자기 자신에게 위임해야 한다고 적습니다.
| 상황 | 토큰 잔액 | 투표권(getVotes) |
|---|---|---|
| 토큰만 받고 위임하지 않음 | 보유량만큼 있음 | 0으로 셀 수 있음 |
| 자기 자신에게 위임함 | 보유량만큼 있음 | 보유량만큼 기록됨 |
| 다른 주소에 위임함 | 보유량만큼 있음 | 위임받은 주소의 투표권에 더해짐 |
과거 시점의 투표권을 묻는 이유
투표권은 getVotes(현재)와 getPastVotes(과거 시점)로 조회합니다. 거버넌스 제안은 흔히 제안이 만들어진 무렵의 특정 시점을 기준으로 투표권을 계산하므로, 투표 기간 중에 토큰을 새로 사거나 옮겨도 그 제안의 투표권은 바뀌지 않을 수 있습니다. 같은 시점의 전체 공급은 getPastTotalSupply로 따로 조회합니다. 시점의 단위(블록 번호 또는 시각)는 계약의 clock()과 CLOCK_MODE()로 확인합니다.
제안의 기준 시점과 실행 단계는 스냅샷 투표 통과와 온체인 집행은 왜 다를까 글에서 따로 정리했습니다.
구현이 정한 한계
문서에 따르면 이 구현은 Compound보다 일반화되어 토큰 공급을 2의 208제곱 빼기 1까지 지원하고(COMP는 2의 96제곱 빼기 1), Compound의 COMP 토큰과 인터페이스가 호환되지 않습니다. 최대 공급 한도는 투표 체크포인트를 저장하는 구조 때문이며, 이 값을 키우면 투표 단위 이동 계산이 넘쳐 전송이 실패할 수 있다고 경고합니다. 토큰마다 다른 거버넌스 구현을 쓸 수 있으므로, 실제 토큰은 검증된 계약 코드에서 어떤 확장을 쓰는지 확인해야 합니다.
자주 묻는 질문
거버넌스 토큰을 사면 바로 투표할 수 있나요?
구현에 따라 다릅니다. OpenZeppelin ERC20Votes는 기본적으로 잔액을 투표권으로 세지 않아, 자기 자신이나 다른 주소에 위임해야 투표권이 기록됩니다.
투표 기간에 토큰을 더 사면 투표권이 늘어나나요?
제안이 과거 특정 시점의 투표권(getPastVotes)을 기준으로 한다면 그 제안의 투표권은 바뀌지 않을 수 있습니다. 기준 시점은 거버넌스 계약의 설정을 확인해야 합니다.
모든 거버넌스 토큰이 ERC20Votes를 쓰나요?
아닙니다. ERC20Votes는 OpenZeppelin이 제공하는 한 가지 확장일 뿐이며, 토큰마다 다른 구현을 쓸 수 있습니다. 검증된 계약 코드로 확인해야 합니다.
