Mục lục
Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch.
Trả lời ngắn: Governance token là token hoặc nguồn quyền biểu quyết cho phép người đủ điều kiện tham gia hệ thống quản trị theo rule. Nó có thể tạo voting power, quyền đề xuất hay ủy quyền, nhưng không tự là cổ phần, quyền sở hữu treasury hoặc quyền nhận lợi nhuận. Muốn hiểu đúng phải lần tới bước execution.
Đọc xong, bạn sẽ hiểu:
- Token balance, delegated voting power và snapshot power khác nhau thế nào.
- Proposal threshold, quorum, majority, timelock và executor làm việc ở bước nào.
- Cách kiểm tra quyền quản trị thật thay vì chỉ nhìn nút Vote trên giao diện.
1. Governance token là gì?
a. Token chỉ là một phần của hệ thống
Governance token thường cung cấp hoặc liên kết tới voting power: trọng số dùng để tham gia một quyết định tại timepoint xác định. Phần còn lại nằm ở governor contract, voting rules, timelock, executor và các quyền admin.
Ví như thẻ thành viên của một câu lạc bộ. Thẻ có thể giúp bạn bỏ phiếu theo nội quy, nhưng không mặc định biến bạn thành cổ đông hay cho phép lấy tiền trong quỹ. Muốn biết quyền thật, phải đọc nội quy và xem ai được ký quyết định sau cuộc họp.
Bài Value Capture trong Crypto là gì? #8 đã tách governance right khỏi cash-flow claim. Một token cho phép vote có thể hữu ích, nhưng quyền vote không tự tạo quyền nhận fee, treasury hay tài sản protocol.
b. Ba lớp Voice, Decision và Execution
Voice trả lời ai có voting power và power được tính lúc nào. Decision chứa proposal threshold, voting window, quorum và counting rule. Execution xác định proposal thành công được queue, chờ timelock và chạy bởi contract/address nào.
Một giao diện hiện “Passed” mới cho biết vote đạt rule ở lớp Decision. Nếu action chưa queue hoặc execute, trạng thái on-chain chưa đổi. Vì vậy đường kiểm tra phải đi hết:
Token/Votes → Delegate → Snapshot → Propose → Vote → Quorum + Counting → Queue → Timelock → Execute
Hình 1 — Governance chỉ hoàn tất khi action đi qua đúng rule và được executor thực thi, không phải khi giao diện báo vote pass.
c. Không phải hệ thống nào cũng 1 token bằng 1 vote
Voting power có thể lấy từ balance, delegated balance, token đã lock, nhiều token, NFT hoặc công thức riêng. OpenZeppelin Governor được thiết kế theo module: voting power, counting, quorum và timelock có thể được triển khai khác nhau (OpenZeppelin Governance API).
Do đó, “có 100 token” chưa đủ để nói “có 100 votes”. Cần đúng contract, clock/timepoint và delegation state của deployment.
2. Một proposal đi từ ý tưởng tới execution
a. Delegation, snapshot và proposal threshold
Delegation là ủy quyền voting power cho một địa chỉ khác mà không chuyển token. A giữ 100 token nhưng delegate 100 votes cho B: A vẫn giữ asset; B có thêm power theo rule. Compound v2 docs mô tả delegation làm vote count của delegate thay đổi theo balance được ủy quyền (Compound Governance).
Snapshot là timepoint lịch sử dùng để tính power cho proposal. Nó giống chụp danh sách cử tri trước kỳ bỏ phiếu; balance đổi sau snapshot không nhất thiết đổi weight của proposal đó.
Proposal threshold là power tối thiểu để tạo proposal, không phải số phiếu để proposal pass. Ví dụ giả định: tổng voting units là 1.000 và threshold là 20. Một delegate có 25 units được đề xuất; người có 15 thì chưa đủ.
b. Quorum và counting rule
Giả sử rule của bài tập là:
- Quorum: participation ít nhất
200/1.000. - For, Against và Abstain đều tính vào participation.
- Proposal succeeds khi
For > Against.
Case A có For 150, Against 40, Abstain 30:
Participation = 150 + 40 + 30 = 220
Quorum đạt vì 220 ≥ 200; majority rule đạt vì 150 > 40. Proposal chuyển sang trạng thái succeeded theo rule giả định. Abstain giúp đạt quorum nhưng không cộng vào For.
OpenZeppelin docs tách quorum khỏi counting và cho phép triển khai nhiều module khác nhau; proposalThreshold, snapshot, deadline, quorum và vote success là các kiểm tra riêng (OpenZeppelin Governance API). Không mang rule của case A áp cho protocol khác.
Hình 2 — Đủ quyền đề xuất, đủ quorum và thắng counting rule là ba điều kiện khác nhau.
c. Queue, timelock và execute
Proposal succeeded chưa chắc thực thi ngay. Queue lên lịch action; timelock bắt buộc chờ một khoảng thời gian; executor là contract hoặc address có quyền kích hoạt action.
Giả sử Case A phải chờ timelock 48 giờ. Con số này chỉ là dữ liệu demo. Sau khi delay hết và proposal vẫn hợp lệ, executor mới chạy calldata. OpenZeppelin mô tả TimelockController tạo delay giữa proposal và execution; proposal dùng timelock cần queue trước khi execute (OpenZeppelin On-chain Governance Guide).
Compound III cũng tách holder/delegate governance khỏi các admin functions mà proposal có thể gọi (Compound III Governance). Muốn biết vote điều khiển gì, phải lần ownership/permissions của target contracts.
3. Sai lầm, giới hạn và rủi ro kiểm soát
a. Balance không phải voting power
Token nằm ở ví A nhưng votes có thể delegated cho B. Power có thể bị khóa tại snapshot, tính theo token locked, hoặc bằng 0 nếu holder chưa delegate theo deployment. Chỉ đếm holder addresses sẽ bỏ qua concentration ở delegate layer.
Hình 3 — Cùng một token balance có thể tạo voting power khác nhau sau delegation và snapshot.
b. Quorum không phải majority, pass không phải execute
Quorum đo participation tối thiểu. Majority/counting rule quyết định lựa chọn nào thắng. Case C có participation 230 nên đạt quorum, nhưng For 80 thấp hơn Against 110 nên vẫn defeated.
Một proposal succeeded còn có thể chờ queue, timelock hoặc người gọi execute. Nó cũng có thể bị cancel nếu rule cho phép. Không viết “DAO đã thay đổi tham số” khi evidence mới dừng ở vote result.
c. Concentration và quyền đặc biệt
Một delegate kiểm soát 450/1.000 units có ảnh hưởng lớn dù token nằm ở nhiều ví. Voter apathy làm tỷ trọng power tham gia khác tổng supply. Bribery, borrowed voting power hoặc coordination ngoài chain là các rủi ro cần xem theo design, không phải kết luận chắc chắn.
Guardian, security council, multisig, admin hoặc emergency role có thể pause, cancel hay upgrade ngoài đường vote thường. Timelock sai role cũng có thể khiến execution bị chặn hoặc có đường tắt. Hệ thống “on-chain governance” vẫn cần audit quyền đặc biệt và ownership của target contracts.
4. Checklist đọc governance
a. Khóa mười trường
- Votes token/adapter và governor contract nào?
- Voting power lấy từ balance, lock hay delegation?
- Snapshot dùng block number hay timestamp nào?
- Proposal threshold là bao nhiêu và denominator gì?
- Voting delay/period kéo dài thế nào?
- Quorum tính những option nào?
- Counting rule xử lý For/Against/Abstain ra sao?
- Proposal có queue/timelock không?
- Executor và cancel authority là ai?
- Guardian, emergency, admin và upgrade rights thuộc ai?
b. Tách observation khỏi kết luận
Observation: “Ở snapshot giả định, delegate B có 25 units, cao hơn threshold 20.”
Interpretation giới hạn: “B đủ power tạo proposal.” Không nói B đủ power làm proposal pass, vì quorum và votes của người khác chưa biết.
Alternative: power đến từ delegation có thể được rút ở proposal sau. Invalidation: snapshot khác, counting module đổi, proposal canceled hoặc target contract không còn do timelock kiểm soát.
c. Điểm dừng
Dừng khi tài liệu chỉ nói “community governed” nhưng không đưa contracts/rules. Dừng khi dashboard hiện token balance thay voting power. Dừng khi kết quả vote không kèm proposal state và execution transaction.
Dừng cả khi không tìm được owner/admin của target contract, timelock roles hoặc emergency path. Một proposal có thể đúng quy trình nhưng không có quyền gọi action dự kiến.
Hình 4 — Control Card buộc kiểm tra cả quyền biểu quyết lẫn quyền thực thi và đường khẩn cấp.
5. Bài tập 15 phút: mô phỏng proposal
a. Công cụ và rule
Dùng Google Sheets hoặc Calculator; không connect wallet và không dùng tiền thật. Nhập ba cột For, Against, Abstain. Rule giả định: total 1.000, threshold 20, quorum 200; cả ba option tính participation; success cần For > Against.
Participation = For + Against + Abstain
b. Mẫu đối chiếu ba proposal đã điền
| Case | For | Against | Abstain | Participation | Quorum 200 | Result |
|---|---|---|---|---|---|---|
| A | 150 | 40 | 30 | 220 | Đạt | Succeeded: For > Against |
| B | 120 | 20 | 20 | 160 | Thiếu | Defeated do thiếu quorum |
| C | 80 | 110 | 40 | 230 | Đạt | Defeated: For ≤ Against |
Case B cho thấy For áp đảo vẫn chưa đủ nếu participation thấp. Case C cho thấy quorum đạt vẫn chưa đủ nếu counting rule thất bại.
c. Nối tới execution
Thêm cột Queued, Timelock ETA và Executed. Với Case A, đặt delay giả định 48 giờ; trước ETA ghi Waiting, sau ETA nhưng chưa gọi execute ghi Ready, chỉ khi transaction thành công mới ghi Executed.
Ghi invalidation: rule đổi, snapshot sai, proposal canceled, executor mất quyền hoặc target ownership đổi. Mục tiêu là phân loại state, không chọn token.
6. Tổng kết và bài tiếp theo
a. Năm ý chính
- Governance token là nguồn voting power, không phải toàn bộ governance system.
- Token balance có thể khác delegated và snapshot voting power.
- Proposal threshold, quorum và counting rule giải quyết ba câu hỏi khác nhau.
- Vote succeeded chưa phải executed; queue, timelock và executor vẫn cần kiểm.
- Admin, guardian và upgrade rights có thể tạo đường kiểm soát ngoài vote thường.
b. Câu hỏi tự kiểm tra
- Vì sao giữ 100 token chưa chắc có 100 voting units?
- Proposal threshold khác quorum thế nào?
- Case C đạt quorum nhưng vì sao vẫn defeated?
- Khi nào mới được gọi proposal đã thực thi?
c. Gợi ý đáp án
Xem gợi ý câu 1
Power còn phụ thuộc delegation, snapshot và voting module. Xem lại mục 1–2.
Xem gợi ý câu 2
Threshold cho quyền tạo proposal; quorum là participation tối thiểu của vote. Xem lại mục 2.
Xem gợi ý câu 3
Participation là 230 nhưng For 80 không lớn hơn Against 110. Xem lại mục 2 và 5.
Xem gợi ý câu 4
Khi action đã qua rule, timelock và có execution transaction thành công. Xem lại mục 2.
d. Thuật ngữ cần nhớ
| Thuật ngữ | Giải thích ngắn |
|---|---|
| Governance token | Token hoặc adapter cung cấp voting power theo rule. |
| Voting power | Trọng số dùng để biểu quyết tại timepoint. |
| Delegation | Ủy quyền votes mà không chuyển token. |
| Snapshot | Timepoint khóa power cho một proposal. |
| Proposal threshold | Power tối thiểu để tạo proposal. |
| Quorum | Participation tối thiểu để vote hợp lệ. |
| Counting rule | Cách các option quyết định kết quả. |
| Timelock | Delay bắt buộc trước execution. |
| Executor | Contract hoặc address chạy action đã pass. |
| Guardian | Role đặc biệt có quyền khẩn cấp theo rule. |
e. Nguồn tham khảo
- OpenZeppelin Contracts 5.x — Governance
- OpenZeppelin — On-chain Governance Guide
- Compound III — Governance
- Compound v2 — Governance
Điều hướng: Bài trước là Value Capture trong Crypto là gì? #8. Bài tiếp theo là Advanced Tokenomics #10, nơi ta ghép supply, incentive, value route và governance thành một bản kiểm tra design hoàn chỉnh.
Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch. Mọi thị trường đều có rủi ro mất vốn.
Bài tiếp theo