DAO 제안은 찬성표가 많아도 정족수·임계값을 충족하고, 실행 가능한 calldata가 큐에 올라 타임락을 지난 뒤 실제 execute 거래가 성공해야 상태가 바뀐다. 사회적 제안은 통과해도 온체인에서 자동 실행되지 않을 수 있다.
제안은 어디에서 시작됐는가
DAO 포럼의 온도 조사와 초안은 의견 수렴일 수 있다. Snapshot 서명 투표는 가스 없이 신호를 모으지만 계약 상태를 직접 바꾸지 않을 수 있다. Governor 계약의 proposal ID와 투표 시작·종료, 실행 payload가 있어야 온체인 제안 범위를 재현할 수 있다.
투표권 위임은 토큰을 보내는 행위가 아니지만 위임 집중도를 바꾼다. 큰 위임자가 투표 직전 대표를 바꾸거나 여러 주소를 합치면 보이는 참여자 수와 실질 통제력이 다르다. snapshot timepoint와 위임 이벤트를 확인해 투표권 계산을 재현한다.
투표 제목은 의도를 설명하고 calldata는 실제로 바뀔 상태를 결정한다.
JOBCOIN 해설
정족수와 찬성률을 동시에 본다
찬성 90%여도 참여 투표권이 정족수에 못 미치면 부결될 수 있다. 투표권은 현재 잔액이 아니라 스냅샷 블록의 위임 잔액으로 계산할 수 있다. abstain이 정족수에는 포함되고 찬반 비율에는 다르게 처리되는지도 Governor 구현을 확인한다.
제안 취소 권한도 중요하다. 제안자가 스스로 취소할 수 있는 시점, guardian이 긴급 취소할 수 있는 범위, 타임락 proposer가 operation을 취소할 권한을 확인한다. 취소가 안전장치가 될 수도 있고 통과된 의사를 막는 중앙화 지점이 될 수도 있다.
통과 뒤 큐와 실행이 남는다
OpenZeppelin TimelockController는 제안과 실행 사이 최소 지연을 강제한다. 성공한 제안을 queue한 뒤 ready 상태가 되고 executor가 실행 거래를 보내야 done이 된다. 실행자가 없거나 선행 작업·기한 조건을 충족하지 못하면 통과 제안도 미실행으로 남을 수 있다.
| 상태 | 의미 | 확인 증거 |
|---|---|---|
| Succeeded | 투표 조건 충족 | proposal state |
| Queued | 타임락 예약 | operation hash·ETA |
| Executed | 호출 성공 | execute TX·상태 변화 |
ENS의 사회적·실행 제안 차이
ENS 문서는 사회적 제안과 실행 제안을 구분하고, 실행 제안은 온체인 Governor 투표와 타임락 뒤 코드 실행으로 이어진다고 설명한다. 사회적 제안은 공동체 의사를 표현해도 외부 운영자·키 보유자의 후속 행동이 필요할 수 있다. 같은 Passed 표시에 기술 효과가 다르다.
배치 제안은 여러 호출 중 하나가 실패하면 전체가 되돌려질 수 있다. 서로 독립적인 지급과 업그레이드를 한 proposal에 묶으면 사소한 실패가 핵심 조치를 막을 수 있다. execute 시뮬레이션에서 각 target의 현재 상태와 allowance·role 조건을 점검한다.
설명과 실행 내용 불일치 확인
target 주소, ETH value, 함수 selector, 인수와 배치 순서를 디코딩한다. 제안 설명이 수수료를 1%로 낮춘다고 써도 calldata가 다른 계약을 호출하거나 관리자 권한을 함께 넘길 수 있다. 시뮬레이션 결과와 현재 프록시 구현도 확인한다.
거버넌스 공격 분석에서는 빌린 투표권을 막는 snapshot과 제안 지연, quorum을 함께 본다. 투표 기간 동안만 토큰을 보유하면 되는지, flash loan으로 같은 블록에서 제안·투표가 가능한지 구현에 따라 다르다. 토큰 가격만으로 공격 비용을 계산하지 않는다.
투표 집중도와 비상권한 읽기
최대 위임자 몇 명이 정족수와 과반을 단독 달성할 수 있는지, 제안자 임계값과 투표 지연을 본다. Security Council·멀티시그의 취소·긴급 실행 권한은 일반 거버넌스와 별도다. 비상권한이 사용됐다면 사후 비준과 권한 회수 조건을 확인한다.
실행 뒤에도 상태 변화가 설명과 일치하는지 검증한다. 업그레이드라면 새 구현 주소와 storage layout, 재무 지급이라면 수취 주소·금액, 매개변수 변경이면 이벤트와 getter 값을 확인한다. execute 성공 상태만 보고 의도한 효과가 모두 났다고 쓰지 않는다.
가스비와 복잡성이 실행을 막는 운영 위험도 있다. 누구나 execute할 수 있어도 거래 비용이 매우 크거나 RPC·프런트엔드가 calldata를 제공하지 않으면 지연될 수 있다. DAO가 실행 자동화와 모니터링 책임을 누구에게 맡겼는지 본다.
- proposal ID·스냅샷 블록·투표 기간을 기록한다
- 정족수와 찬반 계산 방식을 계약에서 확인한다
- target·calldata를 디코딩해 설명과 대조한다
- queue·ETA·execute TX까지 추적한다
자주 묻는 질문
찬성률 99%면 바로 실행되나요?
정족수, 투표 종료, 타임락 큐와 실행 거래가 남을 수 있다. 상태를 단계별로 확인해야 한다.
Snapshot 투표는 온체인 실행인가요?
대개 오프체인 서명 신호다. 별도 멀티시그나 Governor 제안이 필요한지 DAO 규칙을 본다.
누구나 실행할 수 있으면 위험한가요?
타임락에 예약된 작업만 실행하도록 제한될 수 있다. proposer와 executor 권한을 함께 확인한다.
