Apakah DAO Web3 adalah proposisi palsu? Mengupas secara mendalam mengapa Bonk diserang oleh tata kelola.

Penulis: Biteye; Sumber: X, @BiteyeCN

Apa? Penyerang hanya perlu 4 juta dolar AS untuk menguras 20 juta dolar AS dari treasury DAO?

Kemarin dini hari, BONK DAO mengalami serangan tata kelola. Penyerang memanfaatkan celah desain seperti ambang tata kelola BONK yang rendah, mekanisme suara mayoritas sederhana, dan tidak adanya penundaan eksekusi Timelock, melalui proposal jahat untuk mencoba mentransfer aset treasury.

Lantas, bagaimana seharusnya proses tata kelola DAO yang matang dirancang? Mengapa protokol seperti Aave, ENS, Lido mengurangi risiko melalui tata kelola multi-lapis, sementara BONK lebih rentan terhadap serangan tata kelola?

Artikel ini akan menguraikan proses tata kelola DAO dalam lima tahap: Proposal → Diskusi Komunitas → Snapshot Temperature Check → Voting On-chain → Eksekusi Timelock

1. Tahap Proposal (Proposal)

Dalam ekosistem DAO, tahap proposal adalah titik awal dari semua tindakan tata kelola.

Isi inti dari proposal formal biasanya mencakup penyesuaian parameter protokol, onboarding aset baru, alokasi dana Treasury, upgrade kontrak, modifikasi rencana insentif, dan restrukturisasi aturan tata kelola.

Untuk menyeimbangkan efisiensi tata kelola dan mencegah proposal sampah, berbagai protokol menetapkan ambang kepemilikan token atau delegasi yang berbeda untuk pengusul:

• Aave: Ambang tinggi, membutuhkan sekitar 0,5% hak suara AAVE.
• ENS: Proposal eksekutif membutuhkan delegasi 100.000 ENS, proposal sosial sekitar 10.000 ENS.
• Lido: Harus berdiskusi di forum terlebih dahulu, dan memenuhi ambang minimal 1.000 LDO.
• BONK: Ambang rendah, hanya perlu 100M Bonk (425,99 dolar AS), inilah alasan Bonk diserang tata kelola.

2. Tahap Diskusi Komunitas (Governance Forum)

Diskusi komunitas adalah tahap pra-seleksi sebelum pemungutan suara resmi. Sebagian besar DAO matang mewajibkan proposal masuk ke forum tata kelola resmi terlebih dahulu, melalui diskusi terbuka untuk menyelesaikan:

• Pengungkapan rencana dan pengumpulan pendapat: Memungkinkan komunitas mengetahui isi proposal lebih awal dan mengajukan pertanyaan.
• Optimalisasi rencana proposal: Menyesuaikan parameter dan detail eksekusi berdasarkan umpan balik, meningkatkan kualitas proposal.
• Menyaring proposal berkualitas rendah: Menghindari proposal jahat atau tidak matang langsung masuk ke voting on-chain.

Namun tidak semua DAO memiliki tahap ini. Contoh BONK DAO, BONK tidak memiliki proses Governance Forum formal, terutama mengirimkan proposal BIP langsung melalui Solana Realms dan memberikan suara.

DAO matang biasanya membentuk firewall tata kelola melalui mekanisme multi-lapis seperti Governance Forum, Snapshot, Timelock, sementara DAO Meme seperti BONK lebih cenderung voting langsung, meningkatkan efisiensi pengambilan keputusan, tetapi juga menurunkan ambang serangan.

3. Snapshot Temperature Check (Voting Off-chain)

Sebelum voting on-chain resmi, banyak DAO terlebih dahulu melakukan voting off-chain melalui Snapshot, sebagai uji kehendak komunitas.

Tahap ini sering disebut: Temperature Check

Fungsi utamanya:

• Mengurangi biaya voting: Voting off-chain tidak perlu membayar Gas, anggota komunitas dapat berpartisipasi dengan biaya rendah.
• Validasi konsensus lebih awal: Mengamati apakah proposal mendapat dukungan cukup, menghindari rencana tidak matang langsung masuk ke eksekusi on-chain.
• Mengoptimalkan arah proposal: Menyesuaikan detail rencana berdasarkan hasil voting dan umpan balik komunitas.

Jika Snapshot Temperature Check tidak lolos, biasanya berarti komunitas belum membentuk konsensus yang cukup, proposal akan langsung dihentikan atau dikembalikan untuk dimodifikasi, tidak akan masuk ke tahap voting on-chain resmi.

Dan BONK DAO justru karena tidak merancang lapisan keamanan penting Snapshot ini, sehingga "pencuri" dengan mudah menerobos masuk.

4. Voting On-chain Resmi (On-chain Governance)

Setelah diskusi komunitas dan Snapshot Temperature Check (jika proyek mengadopsinya), proposal akan masuk ke tahap tata kelola on-chain resmi.

Tahap ini dilaksanakan oleh kerangka tata kelola on-chain, misalnya:

• Kontrak Governor (umum di ekosistem Ethereum)
• Aragon (kerangka manajemen DAO)
• Realms (kerangka tata kelola Solana)

Untuk memastikan keseriusan dan keamanan voting on-chain, kontrak pintar akan memeriksa secara ketat dua indikator inti berikut saat penyelesaian.

Ambang Partisipasi Minimum: Sebagai garis merah keamanan tata kelola DAO, Quorum menetapkan jumlah total partisipasi suara minimum yang harus dicapai agar suatu proposal sah secara hukum.

Jika total token yang berpartisipasi tidak mencapai target, meskipun suara setuju 100%, proposal akan langsung ditolak.

Misalnya dalam model token dengan total pasokan 100 juta, jika Quorum ditetapkan 5%, maka setidaknya diperlukan 5 juta token untuk berpartisipasi. Pengaturan Quorum berbagai DAO utama berbeda:

• Lido menetapkan ambang tinggi 5% dari total pasokan (sekitar 50 juta LDO)
• Aave (sekitar 2% total pasokan) dan ENS, BONK (1% total pasokan) relatif standar
• Optimism lebih fleksibel, menyesuaikan secara dinamis antara 3% hingga 30% tergantung jenis proposal.

Syarat Kelulusan Voting: Setelah mencapai Quorum (ambang partisipasi minimum), proposal juga perlu memenuhi rasio persetujuan yang sesuai untuk lolos secara resmi.

Sebagian besar DAO menggunakan sistem mayoritas sederhana (Simple Majority) untuk tata kelola sehari-hari, yaitu: Suara setuju (YES) > Suara menolak (NO)

Namun untuk perubahan besar yang melibatkan aturan inti protokol, seperti mengubah konstitusi ENS, menyesuaikan parameter tata kelola kunci, atau meningkatkan protokol dasar, DAO biasanya menggunakan sistem super mayoritas (Super Majority).

Membutuhkan proporsi dukungan yang lebih tinggi, misalnya: 2/3 (sekitar 66,7%) setuju; atau dukungan lebih tinggi.

Mekanisme ini mencegah pemegang token besar minoritas mendorong modifikasi besar yang mempengaruhi seluruh protokol melalui mayoritas sederhana.

Alasan lain BONK diserang tata kelola adalah parameter tata kelola DAO-nya yang relatif longgar.

Ambang partisipasi minimum hanya perlu mencapai 1% dari total pasokan hak suara BONK untuk memasuki voting yang valid. Dan syarat kelulusan voting menggunakan sistem mayoritas sederhana: YES > NO

Ini berarti penyerang tidak perlu memiliki mayoritas besar BONK, hanya perlu mengendalikan sekitar 1% pasokan, dan membuat proposalnya mendapat dukungan mayoritas, untuk mendorong eksekusi tata kelola.

5. Penundaan Eksekusi Timelock dan Eksekusi On-chain (Execution)

DAO matang biasanya tidak langsung mengeksekusi proposal setelah voting lolos, tetapi menambahkan mekanisme Timelock (kunci waktu): Voting lolos → Tunggu Timelock → Eksekusi on-chain.

Fungsi Timelock adalah memberikan waktu penyangga bagi komunitas, memungkinkan anggota untuk:

• Memeriksa kode proposal;
• Menemukan potensi risiko serangan;
• Mengorganisir penolakan atau mengambil tindakan darurat.

Setelah periode tunggu berakhir, proposal baru akan dieksekusi secara otomatis oleh kerangka tata kelola.

Alasan penting lain BONK diserang tata kelola adalah karena proses tata kelolanya tidak memiliki standar penundaan eksekusi Timelock: Voting lolos → Eksekusi langsung.

Dalam insiden serangan tata kelola BIP #76, penyerang memanfaatkan karakteristik proses tata kelola BONK yang tidak memiliki mekanisme penundaan eksekusi, dengan cepat mengeksekusi operasi jahat setelah proposal lolos.

Penutup

Insiden serangan tata kelola BONK membuka masalah lama di DeFi: Jika tidak ada yang berpartisipasi dalam tata kelola, apakah DAO masih perlu ada?

Ketika tata kelola komunitas berubah menjadi pertunjukan, apakah DAO benar-benar diperlukan? Faktanya, sepinya partisipasi tata kelola membuat arsitektur DAO lebih seperti beban yang tidak efisien, bukan jaminan protokol.

Ketika kekuasaan tata keloa yang sesungguhnya hanya dipegang oleh segelintir orang, sementara sebagian besar pengguna hanya penonton diam, mengejar desentralisasi nominal secara sengaja tidak hanya meningkatkan biaya pengambilan keputusan, tetapi juga mengekspos celah keamanan besar bagi protokol.

Mungkin, kita harus mengakui bahwa tidak semua proyek membutuhkan DAO. Seperti dunia bisnis yang matang, membiarkan pembuat keputusan inti mengendalikan arah besar seringkali menghasilkan eksekusi yang lebih efisien dan kemampuan menahan risiko yang lebih kuat. Setelah hiruk-pikuk desentralisasi, kita perlu kembali ke esensi: Ketahanan protokol seringkali bergantung pada akuntabilitas yang jelas dan tim eksekusi yang fokus, bukan pemungutan suara semu oleh seluruh warga.