On-Chain Governance: Tech Stack Dijelaskan

Governance sering dibicarakan seperti proses politik, tapi mekanisme di baliknya adalah pure software engineering: smart contract, token accounting, dan consensus rule yang menentukan siapa yang bisa mengubah sistem dan bagaimana. Jika Anda mengevaluasi DAO atau jalur upgrade protokol, memahami tech stack lebih penting daripada membaca mission statement.

Komponen inti

Sebagian besar sistem on-chain governance dibangun dari serangkaian kecil bagian:

• Voting contract — melacak proposal, menghitung suara, dan menegakkan quorum threshold
• Token atau reputation weighting — menentukan berapa banyak suara dari address tertentu dihitung (token-weighted, quadratic, atau delegated)
• Timelock contract — menunda eksekusi proposal yang lolos, biasanya 24-72 jam, sehingga user dapat bereaksi sebelum perubahan diterapkan
• Execution module — code path yang benar-benar memanggil contract yang terpengaruh setelah vote lolos

Compound's Governor Bravo dan OpenZeppelin's Governor contract adalah reference implementation yang paling banyak dipelajari project yang lebih baru fork atau extend. Jika Anda membaca satu codebase untuk memahami pattern-nya, baca Governor.sol dari OpenZeppelin — code-nya well-commented dan menunjukkan full proposal lifecycle: propose, vote, queue, execute.

Bagaimana proposal benar-benar bergerak melalui sistem

Proposal bukan sekadar forum post yang divoting secara informal. On-chain, itu adalah calldata: target contract address, function selector, dan encoded parameter. Ketika seseorang submit governance proposal, mereka submit exact transaction yang akan execute jika vote lolos.

Alur biasanya seperti ini:

1. Proposer submit calldata plus deskripsi, sering kali memerlukan minimum token balance untuk mencegah spam
2. Voting delay (commonly 1 block hingga beberapa hari) memberi waktu holder untuk review sebelum voting dibuka
3. Voting period berjalan (Compound menggunakan kira-kira 3 hari by default, meskipun banyak fork mengonfigurasi jendela yang lebih panjang)
4. Jika quorum dan approval threshold terpenuhi, proposal masuk queue ke timelock
5. Setelah timelock delay berakhir, siapa pun dapat memanggil execute untuk menjalankan transaction

Gap antara voting close dan execution adalah security backstop. Itu adalah jendela di mana community dapat menyadari proposal yang malicious atau buggy dan, dalam kasus ekstrem, mengkoordinasikan emergency response — asalkan protokol memiliki emergency guardian role atau multisig override, yang banyak lakukan di tahap awal governance.

Di mana weighting logic menjadi rumit

Simple token-weighted voting memiliki masalah yang dikenal: siapa pun yang memegang paling banyak token mengontrol hasil, dan voter turnout biasanya rendah. Segelintir governance forum melaporkan turnout dalam single-digit percentage dari circulating supply untuk routine proposal.

Project telah mencoba beberapa fix:

• Delegation — token holder menugaskan voting power mereka ke delegate tanpa mentransfer token, yang merupakan cara Compound dan Uniswap menangani representative voting
• Quadratic voting — cost dari additional vote meningkat secara quadratic, dimaksudkan untuk mengurangi whale dominance, meskipun Sybil resistance (satu orang membuat banyak address) tetap menjadi open problem
• Conviction voting — digunakan oleh beberapa Gitcoin-adjacent tooling, di mana voting power terakumulasi semakin lama token tetap committed ke suatu posisi, mengutamakan sustained preference daripada snapshot vote

Tidak satu pun dari ini sepenuhnya menyelesaikan low-turnout, dinamika yang cenderung plutocracy dari token voting. Ini adalah mitigasi, bukan fix, dan entry glosarium apa pun yang mengklaim sebaliknya adalah overselling tech.

Off-chain signaling versus on-chain execution

Banyak dari apa yang disebut