Membangun pemerintahan terdesentralisasi: struktur DAO, governance tokens, on-chain voting dengan timelock dan quorum, pengelolaan treasury, plus praktik menyiapkan sistem governance

Setelah di episode 21 kalian men-deploy di L2, pada episode ini kita membangun struktur yang membuat sebuah protokol dikendalikan komunitasnya: DAO (Decentralized Autonomous Organization). DAO adalah organisasi yang berjalan di atas smart contract — aturan, keputusan, dan treasury-nya dikodekan, bukan dipegang segelintir orang.
Pada 2026, DAO bukan sekadar kripto-native: proto-token governance, multi-sig treasury, dan on-chain voting sudah menjadi standar protokol serius. Episode ini membedah komponen, mekanisme voting, dan praktik menyiapkannya.
DAO terdiri dari empat komponen inti:
| Komponen | Fungsi |
|---|---|
| Governance token | Hak suara; sering = kepemilikan protokol |
| Voting contract | Menerima vote, menghitung quorum & hasil |
| Timelock | Penundaan eksekusi untuk keamanan |
| Treasury | Dana bersama yang dikendalikan proposal |
DAO yang sehat menempatkan timelock di antara keputusan dan eksekusi — memberi komunitas waktu untuk membatalkan proposal berbahaya.
Governance token memberikan hak suara proporsional: 1 token = 1 vote. Contoh dari episode 4 kita kembangkan dengan mint terkendali:
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/governance/Governor.sol";
contract GovernanceToken is ERC20, Ownable {
constructor() ERC20("DAO Token", "GOV") Ownable(msg.sender) {
_mint(msg.sender, 1_000_000 * 10 ** decimals());
}
function mint(address _to, uint256 _amount) external onlyOwner {
_mint(_to, _amount);
}
}Warning
Jangan pernah memberikan mint tak terbatas ke tim. Distribusi token adalah keputusan paling penting sebuah proyek — token yang terlalu terpusat di tim memicu vote hijacking, sementara distribusi ceroboh memicu whale dominance. Desain distribusi harus dipikirkan seperti desain kode.
Ada dua pendekatan voting yang perlu kalian bedakan:
| Pendekatan | Cara kerja | Kelebihan | Kekurangan |
|---|---|---|---|
| Snapshot (off-chain) | Vote ditandatangani, dihitung off-chain | Gratis, cepat, UX mulus | Tidak mengikat secara on-chain |
| On-chain governor | Vote direkam di kontrak | Mengikat, transparan, bisa eksekusi otomatis | Mahal (gas per vote) |
Kebanyakan proyek memakai keduanya: Snapshot untuk keputusan sehari-hari dan pengukuran sentimen, on-chain governor untuk keputusan yang mengubah kontrak atau menggerakkan treasury.
OpenZeppelin menyediakan kerangka Governor lengkap. Menggabungkannya dengan voting token dan timelock:
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;
import "@openzeppelin/contracts/governance/Governor.sol";
import "@openzeppelin/contracts/governance/extensions/GovernorCountingSimple.sol";
import "@openzeppelin/contracts/governance/extensions/GovernorVotes.sol";
import "@openzeppelin/contracts/governance/extensions/GovernorTimelockControl.sol";
contract MyGovernor is
Governor,
GovernorCountingSimple,
GovernorVotes,
GovernorTimelockControl
{
uint256 public constant QUORUM = 4; // 4% token untuk quorum
constructor(IVotes _token, TimelockController _timelock)
Governor("MyGovernor")
GovernorVotes(_token)
GovernorTimelockControl(_timelock)
{}
function votingDelay() public pure override returns (uint256) {
return 1 days;
}
function votingPeriod() public pure override returns (uint256) {
return 5 days;
}
function quorum(uint256) public pure override returns (uint256) {
return (10 ** 18) * QUORUM * 100;
}
function _execute(
uint256 proposalId,
address[] memory targets,
uint256[] memory values,
bytes[] memory calldatas,
bytes32 descriptionHash
) internal override(Governor, GovernorTimelockControl) {
super._execute(proposalId, targets, values, calldatas, descriptionHash);
}
}Alur proposal lengkap:
Propose → votingDelay (1 hari) → votingPeriod (5 hari)
→ hasil dihitung → timelock (pending) → executeSetiap fase memberi lapisan perlindungan: delay memberi waktu review, periode memberi waktu voting, dan timelock memberi waktu veto sebelum eksekusi.
Tip
Parameter governance (voting delay, period, quorum) menentukan keamanan dan UX. Quorum terlalu rendah → mudah di-manipulasi; terlalu tinggi → proposal mati. Timelock terlalu pendek → komunitas tak sempat bereaksi; terlalu panjang → pengembangan terhambat. Desain parameter adalah keputusan produk, bukan kode.
Treasury adalah dana DAO. Pola praktik terbaik 2026:
Contoh aturan multi-sig:
Penjaga: 5 alamat (2 tim inti, 2 komunitas, 1 tim keamanan)
Threshold: 3 dari 5 untuk setiap eksekusi
Batas kecil < $10k → eksekusi langsung setelah 3 tanda tangan
Batas besar > $10k → butuh proposal governance + timelockMerakit komponen dalam urutan deploy yang benar:
1. Deploy GovernanceToken
2. Deploy TimelockController (admin = governor)
3. Deploy MyGovernor (token + timelock)
4. Transfer timelock admin ke governor
5. Transfer token (opsional) ke treasury multi-sigUrutan ini krusial: timelock dikendalikan governor, bukan sebaliknya. Kalau timelock punya admin terpisah, kontrak bisa diambil alih pihak lain. Selalu mulai dari siapa yang mengendalikan siapa — lalu deploy dari dalam ke luar.
Inti yang harus dibawa pulang:
Di episode 23 selanjutnya kita masuk sektor paling dinamis — Web3 Gaming: play-and-earn, aset in-game, dan integrasi blockchain yang tidak terlihat. Mari lanjut ke episode 23!