Risiko Fork Protokol yang Tidak Diaudit Ulang

CREAM Finance, sebuah fork dari Compound dengan tambahan fitur dan jenis aset yang lebih luas, mengalami setidaknya tiga eksploit besar antara 2021 dan 2022 — insiden terbesarnya pada Oktober 2021 dilaporkan menyebabkan kerugian lebih dari $130 juta lewat flash loan attack. Kode dasar Compound yang dipinjam CREAM sudah lama teruji dan diaudit, tapi fitur tambahan yang membedakan CREAM dari protokol aslinya-lah yang berulang kali jadi titik masuk eksploit. Fork mewarisi reputasi protokol aslinya, tapi tidak otomatis mewarisi tingkat keamanan yang sama.

Bagaimana Risiko Fork Bekerja

Fork adalah praktik umum di DeFi — sebuah tim mengambil kode open-source dari protokol yang sudah ada (Uniswap, Compound, Aave, dan sejenisnya), lalu memodifikasinya untuk chain baru, fitur tambahan, atau target pasar berbeda. Ini bukan hal yang salah, tapi menciptakan tiga sumber risiko yang sering luput dari perhatian pengguna:

1. Modifikasi menciptakan attack surface baru. Kode asli mungkin sudah diaudit berkali-kali dan bertahan bertahun-tahun tanpa insiden. Tapi begitu tim fork menambah fungsi baru — jenis kolateral tambahan, mekanisme reward berbeda, integrasi oracle baru — bagian itu adalah kode baru yang belum melalui pengujian jangka panjang yang sama, terlepas seberapa teruji kode induknya.

2. Reputasi induk dipinjam untuk menaikkan kepercayaan. Fork sering dipasarkan dengan menonjolkan “dibangun di atas kode Compound/Aave yang sudah teruji” — klaim yang secara teknis benar untuk bagian yang tidak diubah, tapi menyesatkan kalau pembaca menyimpulkan seluruh protokol fork sama amannya.

3. Fork sering dideploy di chain baru dengan pengawasan komunitas lebih tipis. Protokol asli biasanya sudah punya komunitas besar yang memantau aktivitas mencurigakan. Fork di chain baru sering belum punya lapisan pengawasan komunitas itu, sehingga potensi masalah bisa berlangsung lebih lama sebelum terdeteksi.

4. Fork bisa mewarisi bug yang belum ditemukan di kode aslinya. Kalau protokol asli sendiri punya celah yang belum terungkap saat fork dibuat, fork itu ikut mewarisi celah yang sama. Ketika bug ditemukan dan diperbaiki di protokol asli, tim fork tidak selalu segera menerapkan patch yang sama — terutama kalau mereka sudah memodifikasi bagian kode itu sendiri dan patch resmi tidak lagi cocok begitu saja.

Pola umum di balik banyak eksploit DeFi besar — termasuk yang melibatkan fork — dibahas lebih luas di pola umum di balik hack DeFi terbesar.

Red Flag yang Bisa Anda Cek

• Marketing menekankan “kode teruji dari protokol X” tanpa menyebut secara spesifik bagian mana yang dimodifikasi.
• Tidak ada laporan audit terpisah untuk fork tersebut — hanya mengandalkan reputasi audit protokol asli.
• Fitur tambahan yang signifikan dibanding protokol asli (jenis kolateral baru, mekanisme leverage baru, integrasi oracle berbeda) tanpa dokumentasi teknis yang jelas soal bagaimana fitur itu diuji.
• Tim anonim yang melakukan fork protokol besar tanpa track record sebelumnya di ekosistem DeFi.
• TVL melonjak cepat di awal peluncuran karena insentif token tinggi, padahal fork itu baru berjalan beberapa minggu atau bulan.
• Tim fork tidak mengikuti update keamanan dari protokol asli — cek apakah ada patch keamanan terbaru di protokol induk yang belum diterapkan di fork-nya.

Langkah Mitigasi

1. Cari tahu secara spesifik apa yang dimodifikasi dari protokol asli — dokumentasi resmi fork biasanya menyebutkan perbedaan ini, kalau tidak ada, ini sendiri red flag.
2. Cek apakah ada audit terpisah yang mencakup bagian yang dimodifikasi, bukan hanya mengklaim mewarisi audit protokol asli.
3. Jangan samakan tingkat kepercayaan fork dengan protokol aslinya — evaluasi fork sebagai protokol baru yang independen, dengan checklist yang sama seperti protokol baru pada umumnya, seperti dibahas di audit bukan jaminan protokol aman.
4. Perhatikan berapa lama fork sudah berjalan di chain barunya — umur pendek plus fitur tambahan yang belum teruji adalah kombinasi paling berisiko.
5. Batasi jumlah dana yang dialokasikan ke fork protokol, terutama untuk fitur tambahan yang tidak ada di protokol aslinya.
6. Bandingkan insentif yang ditawarkan fork dengan protokol asli — insentif jauh lebih tinggi biasanya untuk menarik likuiditas awal, bukan cerminan model bisnis yang sustainable.
7. Cek apakah tim fork aktif menerapkan patch keamanan yang dirilis protokol asli — fork yang tertinggal beberapa versi dari patch terbaru punya risiko lebih tinggi mewarisi bug yang sudah diperbaiki di tempat lain.

Kalau Anda sedang mempertimbangkan mencoba protokol baru — baik fork maupun bukan — checklist lengkap sebelum deposit dana ada di mau coba protokol baru, aman tidak.

Kalau Sudah Terlanjur

Kalau fork protokol yang Anda pakai baru saja kena eksploit di bagian fitur tambahannya, langkah pertama adalah mengecek apakah pool atau posisi spesifik Anda terdampak langsung — beberapa eksploit hanya menyerang satu jenis aset atau fitur tertentu, bukan seluruh protokol. Bandingkan juga dengan protokol asli yang menjadi sumber fork tersebut: kalau protokol asli tidak terdampak insiden yang sama, ini mengonfirmasi bahwa masalahnya memang berasal dari modifikasi yang ditambahkan tim fork, bukan warisan dari kode induknya. Kalau memang dana Anda terdampak, dokumentasikan transaksi terkait dan ikuti kanal resmi tim untuk update, sambil bersikap realistis bahwa pemulihan penuh tidak selalu terjadi. Kalau Anda mengalami situasi ini, kena rug pull, apa yang bisa dilakukan membahas langkah selanjutnya.

⚠️ Disclaimer: Artikel ini bersifat edukatif, bukan saran keuangan atau investasi personal.