Ditulis oleh: Eric, Foresight News
Sekitar pukul 10:21 waktu Beijing hari ini, Resolv Labs, yang menerbitkan stablecoin USR menggunakan strategi delta netral, diserang oleh hacker. Alamat yang dimulai dengan 0x04A2 menggunakan 100.000 USDC untuk mencetak 50 juta USR dari protokol Resolv Labs.
Seiring terungkapnya peristiwa ini, harga USR langsung anjlok ke sekitar $0,25, dan pada saat penulisan ini, telah pulih ke sekitar $0,8. Harga token RESOLV juga mengalami penurunan tertinggi hampir 10% dalam waktu singkat.
Kemudian, hacker melakukan hal yang sama lagi dengan menggunakan 100.000 USDC untuk mencetak 30 juta USR. Seiring dengan terlepasnya pasak (depegging) USR secara signifikan, pedagang arbitrase juga cepat bertindak. Banyak pasar pinjaman di Morpho yang mendukung USR, wstUSR, dll. sebagai jaminan hampir habis dilahap. Lista DAO di BNB Chain juga telah menghentikan permintaan pinjaman baru.
Yang terkena dampak tidak hanya protokol pinjaman ini. Dalam desain protokol Resolv Labs, pengguna juga dapat mencetak token RLP, yang memiliki fluktuasi harga lebih besar dan imbal hasil lebih tinggi, tetapi bertanggung jawab untuk memberikan kompensasi ketika protokol mengalami kerugian. Saat ini, jumlah token RLP yang beredar hampir 30 juta, dengan pemegang terbesar Stream Finance memegang lebih dari 13 juta RLP, dengan eksposur risiko bersih sekitar $17 juta.
Benar, Stream Finance, yang sebelumnya sudah terkena imbas sekali karena xUSD, mungkin akan terkena pukulan lagi.
Pada saat penulisan, hacker telah mengonversi USR menjadi USDC dan USDT, dan terus membeli Ethereum, dan telah membeli lebih dari 10.000 ETH. Dengan 200.000 USDC, hacker menguangkan aset senilai lebih dari $20 juta, menemukan 'token 100x' miliknya selama pasar bearish.
Sekali Lagi, Dimanfaatkan karena 'Tidak Ketat'
Penurunan tajam pada 11 Oktober tahun lalu menyebabkan banyak stablecoin yang diterbitkan menggunakan strategi delta netral mengalami kerugian collateral karena ADL (Automatic Deleveraging). Beberapa proyek yang menggunakan altcoin sebagai aset untuk menjalankan strategi mengalami kerugian yang lebih parah bahkan langsung kabur.
Resolv Labs, yang diserang kali ini, juga menggunakan mekanisme serupa untuk menerbitkan USR. Proyek ini pernah mengumumkan pada April 2025 bahwa mereka telah menyelesaikan putaran seed senilai $10 juta yang dipimpin oleh Cyber.Fund dan Maven11, dengan partisipasi dari Coinbase Ventures, dan meluncurkan token RESOLV pada akhir Mei/awal Juni.
Namun, alasan Resolv Labs diserang bukanlah kondisi pasar yang ekstrem, melainkan desain mekanisme pencetakan USR yang 'tidak cukup ketat'.
Saat ini belum ada perusahaan keamanan atau pihak resmi yang menganalisis penyebab peristiwa peretasan ini. Komunitas DeFi YAM melalui analisis awal menyimpulkan: Serangan kemungkinan besar disebabkan karena SERVICE_ROLE, yang digunakan oleh backend protokol untuk memberikan parameter ke kontrak pencetakan, dikendalikan oleh peretas.
Menurut analisis Grok, ketika pengguna mencetak USR, mereka akan mengirimkan permintaan on-chain dan memanggil fungsi requestMint dari kontrak, parameternya termasuk:
_depositTokenAddress: alamat token yang disetor;
_amount: jumlah yang disetor;
_minMintAmount: jumlah minimum USR yang diharapkan diterima (perlindungan slippage).
Kemudian, pengguna menyetor USDC atau USDT ke dalam kontrak, backend proyek SERVICE_ROLE memantau permintaan, menggunakan oracle Pyth untuk memeriksa nilai aset yang disetor, lalu memanggil fungsi completeMint atau completeSwap, untuk menentukan jumlah USR yang sebenarnya dicetak.
Masalahnya terletak pada, kontrak pencetakan sepenuhnya mempercayai _mintAmount yang diberikan oleh SERVICE_ROLE, menganggap angka ini telah diverifikasi off-chain oleh Pyth, sehingga tidak menetapkan batasan上限 (batas atas), juga tidak ada verifikasi oracle on-chain, langsung menjalankan mint(_mintAmount).
Berdasarkan ini, YAM menduga hacker mengendalikan SERVICE_ROLE yang seharusnya dikendalikan oleh pihak proyek (mungkin karena oracle internal失控 (kendali hilang), penipuan内部 (internal), atau pencurian kunci), saat mencetak langsung mengatur _mintAmount menjadi 50 juta, mewujudkan peristiwa serangan dengan menggunakan 100.000 USDC untuk mencetak 50 juta USR.
Pada akhirnya, kesimpulan yang diberikan Grok adalah, Resolv saat mendesain protokol tidak mempertimbangkan kemungkinan bahwa alamat (atau kontrak) yang digunakan untuk menerima permintaan pencetakan pengguna dapat dikendalikan oleh peretas. Saat permintaan pencetakan USR diserahkan ke kontrak yang akhirnya mencetak USR, tidak ada pengaturan jumlah pencetakan maksimum, juga tidak meminta kontrak pencetakan untuk melakukan verifikasi ulang dengan oracle on-chain, langsung mempercayai semua parameter yang diberikan oleh SERVICE_ROLE.
Pencegahan Juga Tidak Memadai
Selain menduga alasan peretasan, YAM juga menunjuk pada kesiapan yang tidak memadai dari pihak proyek dalam menangani krisis.
YAM di X menyatakan, Resolv Labs baru menjeda protokol 3 jam setelah serangan pertama hacker selesai,其中 (diantaranya) sekitar 1 jam penundaan berasal dari pengumpulan 4 tanda tangan yang diperlukan untuk transaksi multi-signature. YAM berpendapat, penjeda darurat seharusnya hanya memerlukan satu tanda tangan, dan wewenang harus didistribusikan ke anggota tim sebanyak mungkin, atau personel operasional eksternal yang tepercaya, untuk meningkatkan perhatian pada perilaku anomali on-chain, meningkatkan kemungkinan penjeda cepat, dan lebih baik mencakup zona waktu yang berbeda.
Meskipun saran untuk hanya memerlukan satu tanda tangan untuk menjeda protokol agak radikal, tetapi memerlukan多个 (banyak) tanda tangan dari berbagai zona waktu yang berbeda untuk menjeda protokol memang dapat menunda hal besar dalam situasi darurat. Memperkenalkan pihak ketiga tepercaya yang terus memantau perilaku on-chain, atau menggunakan alat pemantauan yang memiliki izin untuk menjeda protokol darurat, adalah 'pelajaran' yang dibawa oleh peristiwa ini.
Serangan hacker terhadap protokol DeFi早就 (sudah lama) tidak terbatas pada kerentanan kontrak. Peristiwa Resolv Labs memberikan peringatan kepada proyek: Asumsi dalam hal keamanan protokol应该是 (seharusnya) tidak mempercayai salah satu环节 (link) pun, semua环节 yang melibatkan parameter harus setidaknya diverifikasi ulang, bahkan backend yang dioperasikan oleh proyek sendiri也不例外 (tidak terkecuali).
