Penulis: Eric, Foresight News
Pada sekitar pukul 10:21 WIB hari ini, Resolv Labs, yang meluncurkan stablecoin USR dengan strategi delta netral, mengalami serangan peretas. Alamat yang dimulai dengan 0x04A2 mencetak 50 juta USR dari protokol Resolv Labs menggunakan 100.000 USDC.
Setelah peristiwa tersebut terungkap, USR jatuh ke sekitar $0,25, dan hingga penulisan artikel ini memulihkan kembali ke sekitar $0,80. Harga token RESOLV juga mengalami penurunan sementara hingga mendekati 10%.
Setelah itu, peretas mengulangi metode yang sama dengan mencetak 30 juta USR menggunakan 100.000 USDC. Seiring dengan melemahnya pegangan USR, para arbitrase segera bertindak; banyak pasar pinjaman di Morpho yang mendukung USR, wstUSR, dan lainnya sebagai jaminan hampir habis, dan Lista DAO di BNB Chain juga menghentikan permintaan pinjaman baru.
Yang terdampak tidak hanya protokol pinjaman ini. Dalam desain protokol Resolv Labs, pengguna juga dapat mencetak token RLP yang memiliki volatilitas harga lebih tinggi dan imbal hasil lebih besar, tetapi wajib menanggung tanggung jawab kompensasi jika protokol mengalami kerugian. Saat ini, sirkulasi token RLP mencapai sekitar 30 juta unit, dengan pemegang terbesar, Stream Finance, memegang lebih dari 13 juta RLP, dengan eksposur risiko bersih sekitar $17 juta.
Benar, Stream Finance yang sebelumnya pernah mengalami kegagalan xUSD mungkin akan kembali terpukul.
Pada saat penulisan, peretas telah mengonversi USR menjadi USDC dan USDT, serta terus membeli Ethereum, dengan jumlah pembelian telah melebihi 10.000 unit. Dengan menggunakan 200.000 USDC, peretas berhasil menarik aset senilai lebih dari $20 juta, menemukan "coin 100x" miliknya selama pasar bearish.
Lagi-lagi dimanfaatkan karena "tidak ketat"
Pada 11 Oktober tahun lalu, penurunan tajam menyebabkan banyak stablecoin yang menggunakan strategi delta netral mengalami kerugian jaminan akibat ADL (auto deleveraging). Beberapa proyek yang menggunakan altcoin sebagai aset strategi pelaksanaan mengalami kerugian lebih parah dan bahkan langsung kabur.
Resolv Labs yang menjadi sasaran serangan ini juga menggunakan mekanisme serupa untuk menerbitkan USR. Proyek ini sebelumnya mengumumkan pada April 2025 telah menyelesaikan pendanaan seed senilai $10 juta yang dipimpin oleh Cyber.Fund dan Maven11, dengan partisipasi Coinbase Ventures, dan meluncurkan token RESOLV pada akhir Mei hingga awal Juni.
Namun, alasan Resolv Labs diserang bukan karena pergerakan pasar yang ekstrem, tetapi karena desain mekanisme pencetakan USR yang "tidak cukup ketat".
Sampai saat ini, belum ada perusahaan keamanan atau pihak resmi yang menganalisis penyebab insiden peretasan ini. Komunitas DeFi YAM, melalui analisis awal, menyimpulkan bahwa serangan kemungkinan besar disebabkan oleh kontrol hacker terhadap SERVICE_ROLE yang digunakan oleh backend protokol untuk memberikan parameter ke kontrak pencetakan.
Menurut analisis Grok, saat pengguna mencetak USR, mereka akan mengirim permintaan di blockchain dan memanggil fungsi requestMint kontrak, dengan parameter berikut:
_depositTokenAddress: Alamat token yang disetorkan;
_amount: Jumlah setoran;
_minMintAmount: Jumlah minimum USR yang diharapkan diterima (slippage).
Setelah itu, pengguna menyetor USDC atau USDT ke kontrak, backend proyek dengan SERVICE_ROLE memantau permintaan, memeriksa nilai aset yang disetor menggunakan oracle Pyth, lalu memanggil fungsi completeMint atau completeSwap untuk menentukan jumlah USR yang benar-benar dicetak.
Masalahnya terletak pada fakta bahwa kontrak pencetakan sepenuhnya mempercayai _mintAmount yang disediakan oleh SERVICE_ROLE, menganggap angka tersebut telah diverifikasi secara off-chain oleh Pyth, sehingga tidak menetapkan batas atas dan tidak melakukan verifikasi orakel on-chain, langsung mengeksekusi mint(_mintAmount).
Berdasarkan hal ini, YAM menduga peretas mengendalikan SERVICE_ROLE yang seharusnya dikendalikan oleh tim proyek (kemungkinan karena kegagalan oracle internal, penyalahgunaan wewenang, atau kunci dicuri), dan langsung mengatur _mintAmount menjadi 50 juta selama proses pencetakan, sehingga berhasil menyerang dengan mencetak 50 juta USR menggunakan 100.000 USDC.
Pada akhirnya, Grok menyimpulkan bahwa Resolv tidak mempertimbangkan kemungkinan alamat (atau kontrak) yang digunakan untuk menerima permintaan pencetakan pengguna akan dikendalikan oleh peretas, tidak menetapkan batas maksimum pencetakan saat permintaan pencetakan USR dikirim ke kontrak terakhir yang mencetak USR, dan juga tidak menggunakan orakel on-chain untuk verifikasi sekunder, melainkan langsung mempercayai semua parameter yang disediakan oleh SERVICE_ROLE.
Pencegahan juga tidak memadai
Selain menebak penyebab peretasan, YAM juga menunjukkan bahwa tim proyek kurang siap dalam menangani krisis.
YAM di X menyatakan bahwa Resolv Labs baru menangguhkan protokol tiga jam setelah serangan pertama oleh peretas, dengan sekitar satu jam keterlambatan disebabkan oleh kebutuhan untuk mengumpulkan empat tanda tangan untuk transaksi multi-sig. YAM berpendapat bahwa penangguhan darurat seharusnya hanya memerlukan satu tanda tangan, dan otoritas sebaiknya didistribusikan sebanyak mungkin kepada anggota tim atau operator eksternal tepercaya, sehingga meningkatkan perhatian terhadap anomali on-chain, meningkatkan kemungkinan penangguhan cepat, serta lebih baik mencakup zona waktu yang berbeda.
Meskipun usulan untuk menjeda protokol hanya memerlukan satu tanda tangan terdengar agresif, kebutuhan akan beberapa tanda tangan dari berbagai zona waktu untuk menjeda protokol memang dapat menyebabkan keterlambatan saat terjadi keadaan darurat. Memperkenalkan pihak ketiga yang dapat dipercaya dan terus memantau perilaku di blockchain, atau menggunakan alat pemantau yang memiliki wewenang menjeda protokol dalam keadaan darurat, adalah pelajaran penting dari insiden ini.
Serangan terhadap protokol DeFi sudah lama tidak lagi terbatas pada kerentanan kontrak. Insiden Resolv Labs memberi peringatan kepada tim proyek: asumsi dalam keamanan protokol harus menganggap tidak ada satupun elemen yang dapat dipercaya; semua tahap yang melibatkan parameter harus setidaknya diverifikasi dua kali, bahkan backend yang dioperasikan oleh tim proyek sendiri sekalipun.