
Request for Comments (RFC) adalah proses di mana suatu organisasi secara terbuka meminta masukan dari publik atau pemangku kepentingan sebelum memfinalisasi proposal atau rencana. Tujuan utamanya adalah memastikan beragam kepentingan dan potensi risiko telah dipertimbangkan secara menyeluruh, sehingga kualitas dan kelayakan keputusan dapat meningkat.
Dalam tata kelola, “governance” mengacu pada bagaimana komunitas atau organisasi membuat dan melaksanakan keputusan atas hal-hal penting. RFC biasanya digunakan sebelum perubahan aturan, penyesuaian biaya, pembaruan teknis, atau pengeluaran besar. Saluran RFC dapat berupa pengumuman di situs resmi, forum komunitas, formulir online, atau pertemuan. Berbeda dari pemungutan suara langsung, RFC menitikberatkan diskusi terbuka dan pengumpulan bukti; pemungutan suara umumnya dilakukan setelah diskusi selesai.
RFC adalah proses pengumpulan masukan itu sendiri, sedangkan RFC draft adalah dokumen yang digunakan untuk mendukung proses tersebut. RFC draft biasanya berupa dokumen terstruktur yang memuat latar belakang, kondisi saat ini, perubahan yang diusulkan, serta daftar isu untuk mendapatkan masukan publik pada setiap poinnya.
Dalam praktiknya, regulator atau platform kerap menerbitkan RFC draft sebelum memperkenalkan aturan baru dan mengundang pemangku kepentingan menanggapi setiap item. Proyek Web3 juga merilis RFC draft sebelum pembaruan teknis besar atau perubahan aturan, guna meminimalkan miskomunikasi dan mempermudah pelacakan umpan balik maupun amandemen.
RFC sangat penting dalam tata kelola Web3 karena desentralisasi mengandalkan partisipasi luas dan pembentukan konsensus, sementara perubahan aturan teknis atau ekonomi dapat berdampak besar dan berjangka panjang.
Sebagai contoh, DAO (Decentralized Autonomous Organizations) adalah organisasi komunitas yang dikelola bersama oleh pemegang token atau kontributor melalui pemungutan suara on-chain maupun off-chain. Tanpa meminta masukan terlebih dahulu melalui RFC, perubahan pada alokasi dana, struktur biaya, atau parameter protokol dapat menimbulkan konsekuensi yang tidak diinginkan. Diskusi terbuka membantu komunitas mengidentifikasi risiko sejak awal, menyediakan data dan alternatif solusi, serta membangun legitimasi dan transparansi untuk pemungutan suara dan implementasi selanjutnya.
Hingga 2024, banyak DAO besar menerapkan proses dua tahap—mengumpulkan komentar terlebih dahulu, lalu melakukan pemungutan suara—untuk proposal penting. Cara ini efektif mengurangi sengketa prosedural dan fragmentasi tata kelola.
Dalam DAO, RFC umumnya menggabungkan forum komunitas dan alat voting. Prosesnya meliputi pra-diskusi, penyusunan dokumen RFC, pengumpulan umpan balik, revisi, voting, dan eksekusi.
Langkah 1: Mulai pra-diskusi di forum komunitas. Anggota memposting isu dan potensi dampaknya untuk mengumpulkan pandangan awal.
Langkah 2: Susun RFC draft. Daftarkan informasi latar belakang, perubahan yang diusulkan, risiko, dan alternatif sebagai poin terpisah untuk memperoleh umpan balik terarah.
Langkah 3: Kumpulkan umpan balik dan revisi draft. Sajikan bukti pendukung dan sumber data secara jelas, tanggapi keberatan, dan jika perlu lakukan uji coba skala kecil atau simulasi.
Langkah 4: Lakukan temperature check atau voting Snapshot. Snapshot adalah alat voting off-chain yang populer untuk mengukur sentimen komunitas tanpa biaya gas.
Langkah 5: Laksanakan voting resmi on-chain dan eksekusi keputusan. Resolusi dan perubahan akhir diimplementasikan melalui smart contract, yaitu program yang secara otomatis menegakkan aturan.
Pada proses EIP (Ethereum Improvement Proposal) di Ethereum, RFC hadir di setiap tahap mulai dari pengajuan hingga implementasi. EIP merupakan proposal yang menjelaskan perubahan pada protokol Ethereum atau standar di lapisan aplikasi.
Penulis mengajukan draft di GitHub, platform kolaborasi pengembangan untuk pengelolaan versi kode. Komunitas dan tim klien kemudian mendiskusikan kelayakan teknis, risiko, dan strategi implementasi di forum serta repositori. Setelah umpan balik terkumpul, proposal diuji di testnet sebelum tim klien dan pengembang inti memutuskan untuk menggabungkannya. Perubahan yang melibatkan mekanisme biaya atau format transaksi biasanya melalui komentar publik ekstensif dan beberapa kali pengujian.
Di komunitas Gate, RFC umumnya tersedia di Announcement Center, saluran komunitas, serta saat event voting. Topik yang sering dibahas mencakup penjelasan aturan pra-peluncuran fitur baru, penyesuaian struktur biaya, dan ajakan umpan balik atas proposal komunitas.
Saat berpartisipasi, pastikan selalu memeriksa saluran pengumuman resmi Gate untuk verifikasi sumber dan tenggat waktu agar terhindar dari tautan phishing. Untuk perubahan yang memengaruhi aset atau mekanisme perdagangan, disarankan memberikan umpan balik terstruktur—mencakup latar belakang, isu, saran, dan dampak yang diantisipasi—serta mengikuti pembaruan dan pengumuman adopsi berikutnya.
Berpartisipasi dalam RFC tidak mensyaratkan latar belakang teknis, tetapi memerlukan persiapan matang dan komunikasi yang jelas.
Langkah 1: Pastikan keaslian sumber. Verifikasi bahwa pengumuman berasal dari saluran resmi atau komunitas tepercaya dengan memeriksa nama domain, nomor pengumuman, dan periode waktu.
Langkah 2: Baca RFC draft dengan teliti. Sorot perubahan utama yang diusulkan dan identifikasi pengguna atau skenario yang terdampak.
Langkah 3: Siapkan bukti pendukung dan contoh. Gunakan data, tangkapan layar proses, atau pengalaman pengguna nyata untuk memperkuat saran Anda.
Langkah 4: Kirim melalui saluran yang telah ditentukan. Balas di forum, isi formulir umpan balik, atau lampirkan pendapat Anda saat voting di Snapshot.
Langkah 5: Simpan catatan dan pantau perkembangan. Simpan tautan dan penanda waktu untuk melacak pembaruan dan status adopsi; berikan masukan tambahan bila diperlukan.
RFC bukan keputusan akhir, melainkan “diskusi terbuka”; voting dan implementasi biasanya dilakukan pada tahap selanjutnya. Kesalahpahaman yang sering terjadi adalah menganggap hasil diskusi sebagai keputusan final atau mengabaikan pendapat yang berbeda.
Risiko utama meliputi:
RFC yang efektif memiliki cakupan dan periode waktu yang jelas, saluran umpan balik serta mekanisme adopsi yang terdefinisi, dan pembaruan transparan yang menjelaskan keputusan setelah penutupan.
Sumber kredibel, deskripsi masalah yang spesifik, pengungkapan data menyeluruh, dan transparansi risiko mendukung diskusi berkualitas. Jika penyelenggara menjelaskan alasan saran tertentu tidak diadopsi dan menawarkan alternatif atau langkah lanjut, peserta dapat menilai transparansi dan akuntabilitas tata kelola dengan lebih baik.
RFC mempublikasikan diskusi pra-keputusan untuk meminimalkan risiko dan meningkatkan kualitas eksekusi melalui keterlibatan aktif pemangku kepentingan. Dalam tata kelola Web3—dari DAO hingga Ethereum—RFC memainkan peran sentral dalam pengembangan protokol dan penyesuaian aturan di komunitas exchange. Untuk hasil maksimal: pastikan sumber kredibel, susun umpan balik secara jelas, pantau status adopsi, dan selalu waspada terhadap keamanan dana saat menandatangani transaksi atau berinteraksi dengan proposal.
RFC mengacu pada keseluruhan proses pengumpulan masukan; RFC draft adalah dokumen spesifik yang digunakan dalam proses tersebut. Sederhananya: draft berfungsi sebagai versi kerja untuk komentar atau voting komunitas. Yang satu adalah aksi, yang lain adalah mediumnya—keduanya saling berkaitan namun berfokus pada aspek berbeda.
Mulai dengan memahami konteks: baca ringkasan dan tujuan RFC draft. Berikan umpan balik yang spesifik—hindari komentar umum dengan mengidentifikasi area perbaikan atau potensi masalah. Tetap terlibat dalam diskusi lanjutan; pantau respons resmi dan perubahan berikutnya agar masukan Anda benar-benar berdampak.
Tujuan RFC adalah mengumpulkan wawasan kolektif—tidak semua saran dapat diterima. Alasan utama penolakan antara lain tidak sejalan dengan tujuan proyek, tidak layak secara teknis, atau kurang dukungan dari pemangku kepentingan. Proses pengambilan keputusan yang transparan sangat penting—tata kelola yang baik akan menjelaskan alasan saran diterima atau ditolak.
RFC draft yang baik harus dengan jelas menyatakan latar belakang masalah, isi usulan, dan potensi dampak. Pastikan tujuan eksplisit, perubahan yang diusulkan spesifik/terukur, kompatibilitas mundur diperhatikan, dan periode umpan balik wajar. Draft yang kabur atau tergesa-gesa biasanya berkualitas rendah.
Pastikan terlebih dahulu apakah masukan Anda sudah tercatat (dengan meninjau log diskusi resmi). Jika sudah tercatat namun tidak diadopsi, Anda dapat meminta alasan di balik keputusan tersebut. Jika benar-benar terlewat, sampaikan kembali pandangan Anda saat voting tata kelola komunitas atau ajukan lagi pada iterasi berikutnya—partisipasi yang konsisten dan rasional cenderung lebih berpengaruh daripada satu komentar saja.



Apa Itu Request for Comments?