Snapshot의 일반 투표는 서명된 메시지와 설정된 전략으로 계산한 오프체인 결과다. 통과 표시만으로 금고 자산이나 프로토콜 파라미터가 바뀌지는 않는다. 제안에 실행 payload가 있는지, 누가 실행 권한을 갖는지, Safe·Governor·timelock에서 같은 호출이 queue되고 execute됐는지 거래 해시로 확인해야 집행 완료라고 말할 수 있다.
Snapshot의 통과 표시는 무엇을 확정하는가
Snapshot 공식 문서는 Snapshot을 gasless off-chain multi-governance client로 설명한다. 표준 투표는 지갑으로 서명한 메시지이며, 공간이 선택한 voting strategy가 특정 snapshot 블록의 토큰·NFT·위임 상태를 읽어 voting power를 계산한다. 결과는 누가 어떤 선택에 얼마의 투표력을 행사했는지 검증할 수 있게 하지만, 그 자체가 대상 계약에 상태 변경 함수를 호출하는 거래는 아니다.
따라서 ‘찬성 60%로 통과’라는 문장에는 분모가 필요하다. 찬성 600, 반대 400이라도 쿼럼이 2,000이면 공간 규칙상 실패할 수 있다. 반대로 쿼럼을 넘겼어도 제안이 단순 온도 점검인지, 운영팀에 행동을 요청하는 신호 투표인지, 실행 payload가 연결된 제안인지에 따라 다음 단계가 다르다.
투표 결과는 의사결정의 증거이고, 실행 거래는 상태 변경의 증거다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- Snapshot의 통과 표시는 무엇을 확정하는가
Snapshot 공식 문서는 Snapshot을 gasless off-chain multi-governance client 로 설명한다.
- 숫자보다 먼저 스냅샷과 전략을 고정한다
투표력은 현재 지갑 잔액이 아니라 제안이 지정한 snapshot 시점 의 상태로 계산될 수 있다.
- 통과 뒤 실행 경로를 표로 분리한다
같은 ‘passed’라도 집행 구조는 다르다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
숫자보다 먼저 스냅샷과 전략을 고정한다
투표력은 현재 지갑 잔액이 아니라 제안이 지정한 snapshot 시점의 상태로 계산될 수 있다. 제안 후 토큰을 샀거나 옮겼다고 이미 정해진 투표력이 바뀌지 않는 이유다. 여러 전략을 합산하거나 위임, LP 지분, NFT 보유를 계산하면 표면 잔액과 결과가 달라질 수 있다. 공간 설정의 network, snapshot block, strategy 이름과 파라미터를 보관해야 재현할 수 있다.
교육용 예시로 snapshot 블록에서 A가 400표, B가 350표, C가 250표를 가지고 모두 참여했다고 하자. 찬성 600, 반대 300, 기권 100이면 찬성 비율을 찬반만으로 계산할 때 600÷900=66.7%다. 총 참여 대비로는 60%다. 공간 규칙이 어느 분모와 쿼럼을 쓰는지 확인하지 않으면 두 숫자 중 하나를 임의로 ‘가결률’이라 부르게 된다.
통과 뒤 실행 경로를 표로 분리한다
같은 ‘passed’라도 집행 구조는 다르다. 다음 표에서 제안이 어느 유형인지 찾아야 실제 완료 조건을 정할 수 있다.
| 제안 유형 | 통과 뒤 필요한 행위 | 완료 증거 |
|---|---|---|
| 신호 투표 | 팀·재단의 후속 결정 | 공식 결정문과 실행 공지 |
| Safe 다중서명 요청 | 서명 임계치 충족 후 거래 실행 | Safe transaction hash와 체인 tx |
| Governor 직접 실행 | 성공한 제안 payload execute | ProposalExecuted 이벤트 |
| Governor+Timelock | queue 후 최소 지연, execute | ETA·queue·execute 이벤트 |
| Snapshot X 실행 전략 | 설정된 execution strategy 호출 | 해당 공간의 온체인 실행 거래 |
Governor와 timelock에서는 상태가 더 늘어난다
OpenZeppelin Governor는 투표 기간이 끝나고 쿼럼과 다수 조건을 충족한 제안을 successful로 본다. timelock을 붙인 구성에서는 제안을 queue한 뒤 정해진 지연이 지나야 execute할 수 있다. 이때 실제 자산과 권한을 보유하는 주체가 timelock일 수 있으며 proposer, executor, canceller 역할도 설정에 따라 다르다. 성공 상태만 보고 자산 이동 완료라고 쓰면 안 된다.
예를 들어 9월 1일 투표 종료, 9월 2일 queue, 최소 지연 48시간, 9월 4일 execute라면 정책 효력 시점은 제안 문구와 실행 대상에 따라 9월 4일이 될 수 있다. queue transaction이 성공했어도 아직 대상 계약 값은 바뀌지 않을 수 있다. execute 거래의 target, value, calldata와 제안 본문이 일치하는지 확인한다.
- Snapshot proposal ID와 원문 본문을 저장한다
- network·snapshot block·strategies·quorum을 기록한다
- 찬성·반대·기권의 분모 정의를 확인한다
- 실행 payload와 target 계약을 대조한다
- queue 시각·ETA·timelock 지연을 기록한다
- execute 거래와 상태 변경 이벤트를 확인한다
수정된 실행안은 같은 제안으로 취급하지 않는다
투표 후 실행 과정에서 수신 주소, 금액, 함수 인자가 달라지면 원래 의결과 같은 집행인지 다시 판단해야 한다. 설명 문구가 같아도 calldata hash가 다르면 별도 행위다. 운영팀이 실행 편의를 위해 거래를 나눴다면 각 거래가 제안 범위를 어떻게 구현하는지 공식 설명이 필요하다.
취소와 만료도 통과와 공존할 수 있다. timelock의 canceller가 queue된 작업을 취소하거나 실행 가능 기간을 넘겼다면 과거 투표 결과는 남아도 정책은 적용되지 않는다. 기사 제목에는 ‘투표 통과’, ‘실행 대기’, ‘온체인 집행 완료’ 중 확인된 단계만 쓴다.
검증 가능한 완료 문장을 만든다
완료 문장은 ‘Snapshot 제안은 쿼럼을 넘겨 통과했고, 동일한 target과 calldata가 timelock에서 48시간 대기한 뒤 거래 0x…로 실행됐다’처럼 제안과 거래를 연결한다. 실행 해시가 없다면 ‘통과했으나 온체인 집행은 확인되지 않았다’가 정확하다.
이 글의 표 수치는 계산 설명용 가정이며 특정 DAO의 현황이 아니다. 거버넌스 결과만으로 토큰 가격이나 수익을 예상하지 않는다. 공식 제안, 공간 설정, 실행 계약과 체인 receipt를 확인한 범위만 기록한다.
자주 묻는 질문
Snapshot에 Passed라고 나오면 정책이 바로 바뀌나요?
일반 Snapshot 투표는 오프체인 서명 결과다. 신호 투표라면 별도 운영 결정이, 실행형 제안이라면 Safe·Governor·timelock 등의 온체인 거래가 더 필요할 수 있다.
찬성률은 어떻게 다시 계산하나요?
공간 규칙이 기권을 분모에 넣는지, 쿼럼은 총 투표력과 참여 투표력 중 무엇을 기준으로 하는지 먼저 확인한 뒤 같은 규칙으로 계산한다.
Queue 거래가 성공하면 집행 완료인가요?
timelock 구성에서는 대기열 등록일 뿐이다. 지연 후 execute 거래와 대상 계약의 상태 변경까지 확인해야 한다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
