Ditulis oleh Eric, Foresight News
Pada sekitar pukul 10:21 waktu Beijing hari ini, Resolv Labs, yang mengeluarkan mata wang stabil USR menggunakan strategi delta neutral, diserang oleh perompak. Alamat bermula dengan 0x04A2 mencetak 50 juta USR daripada protokol Resolv Labs menggunakan 100,000 USDC.

Sehingga berita itu diumumkan, USR jatuh ke sekitar $0.25, tetapi pulih semula kepada sekitar $0.8 pada masa penulisan. Harga token RESOLV juga mengalami penurunan sementara tertinggi mendekati 10%.

Selepas itu, perompak mengulangi taktik yang sama dengan mencetak 30 juta USR menggunakan 100,000 USDC. Seiring dengan pelonggaran besar-besaran USR, para pedagang arbitrase bertindak cepat; banyak pasaran pinjaman di Morpho yang menyokong jaminan seperti USR dan wstUSR hampir habis dikosongkan, dan Lista DAO di BNB Chain juga menghentikan permintaan pinjaman baharu.

Bukan hanya protokol pinjaman ini yang terjejas. Dalam reka bentuk protokol Resolv Labs, pengguna juga boleh mencetak token RLP yang mempunyai volatiliti harga yang lebih tinggi dan pulangan yang lebih besar, tetapi perlu bertanggungjawab menanggung kerugian apabila protokol mengalami kerugian. Kini, jumlah beredar token RLP mendekati 30 juta, dengan pemegang terbesar, Stream Finance, memiliki lebih daripada 13 juta RLP, dengan eksposur risiko bersih sekitar $17 juta.
Betul, Stream Finance yang sebelumnya mengalami kegagalan xUSD mungkin akan mengalami serangan lagi.
Pada masa penulisan ini, perompak telah menukar USR menjadi USDC dan USDT, serta terus membeli Ethereum, dengan jumlah pembelian melebihi 10,000 unit. Dengan menggunakan 200,000 USDC, perompak telah menarik aset bernilai lebih daripada $20 juta, dan menemukan "koin seratus kali ganda" miliknya semasa pasaran bear.
Lagi-lagi dimanfaatkan kerana "tidak teliti"
Pada 11 Oktober tahun lalu, penurunan tajam menyebabkan banyak stablecoin yang mengunakan strategi delta netral mengalami kerugian jaminan akibat ADL (auto-deleveraging). Sebahagian projek yang menggunakan altcoin sebagai aset pelaksanaan strategi mengalami kerugian yang lebih teruk dan ada yang terus melarikan diri.
Resolv Labs yang diserang kali ini juga menggunakan mekanisme serupa untuk mengeluarkan USR. Projek ini sebelumnya mengumumkan pada April 2025 bahawa ia telah menyelesaikan pembiayaan benih sebanyak $10 juta yang dipimpin oleh Cyber.Fund dan Maven11, dengan penyertaan Coinbase Ventures, dan melancarkan token RESOLV pada akhir Mei dan awal Jun.
Namun, sebab Resolv Labs diserang bukan kerana pergerakan pasaran yang ekstrem, tetapi kerana reka bentuk mekanisme pencetakan USR yang "tidak cukup teliti".
Sampai kini, tiada syarikat keselamatan atau pihak rasmi yang telah menganalisis sebab kejadian perompakan ini. Komuniti DeFi YAM telah menghasilkan kesimpulan awal melalui analisis: serangan kemungkinan besar disebabkan oleh SERVICE_ROLE yang digunakan oleh latar belakang protokol untuk memberikan parameter kepada kontrak pencetakan telah dikendalikan oleh perompak.

Berdasarkan analisis Grok, apabila pengguna mencetak USR, mereka akan menghantar permintaan di rantai dan memanggil fungsi requestMint kontrak, dengan parameter termasuk:
_depositTokenAddress:Alamat token yang disetor;
_amount: Jumlah deposit;
_minMintAmount: Jumlah minimum USR yang diharapkan diterima (untuk mengelakkan slippage).
Selepas itu, pengguna akan menyimpan USDC atau USDT ke kontrak, dan bahagian belakang projek dengan SERVICE_ROLE akan memantau permintaan, memeriksa nilai aset yang disimpan menggunakan oracle Pyth, kemudian memanggil fungsi completeMint atau completeSwap untuk menentukan jumlah USR yang sebenarnya dicetak.
Masalahnya ialah, kontrak penciptaan sepenuhnya mempercayai _mintAmount yang disediakan oleh SERVICE_ROLE, menganggap nombor tersebut telah disahkan secara luar rantai oleh Pyth, oleh itu tidak menetapkan had atas, juga tidak melakukan pengesahan oracle secara rantai, terus melaksanakan mint(_mintAmount).
Berdasarkan ini, YAM menduga perompak mengawal SERVICE_ROLE yang seharusnya dikendalikan oleh pihak projek (mungkin akibat kegagalan orak dalaman, penipuan dalaman, atau kunci dicuri), dan secara langsung menetapkan _mintAmount sebagai 50 juta semasa penciptaan, melaksanakan serangan yang menghasilkan 50 juta USR dengan hanya 100,000 USDC.
Pada akhirnya, Grok menyimpulkan bahawa Resolv tidak mempertimbangkan kemungkinan alamat (atau kontrak) yang digunakan untuk menerima permintaan pencetakan pengguna akan dikendalikan oleh perompak; ketika permintaan pencetakan USR dihantar ke kontrak terakhir yang mencetak USR, tiada had pencetakan maksimum ditetapkan, dan tiada pengesahan kedua oleh orakel rantai digunakan, sebaliknya semua parameter yang disediakan oleh SERVICE_ROLE dipercayai secara langsung.
Pencegahan juga tidak mencukupi
Selain menjangka sebab peretasan, YAM juga menunjukkan bahawa pihak projek tidak bersedia dengan baik untuk menghadapi krisis.
YAM di X menyatakan bahawa Resolv Labs baru menghentikan protokol selepas 3 jam setelah serangan pertama berlaku, dengan kira-kira 1 jam tertunda kerana pengumpulan 4 tanda tangan yang diperlukan untuk transaksi multi-sig. YAM berpendapat bahawa penghentian kecemasan sepatutnya hanya memerlukan satu tanda tangan, dan kuasa seharusnya diberikan seboleh mungkin kepada ahli pasukan atau operator luar yang dipercayai, supaya meningkatkan perhatian terhadap kejadian tidak biasa di rantai, meningkatkan kemungkinan penghentian pantas, serta memberi liputan yang lebih baik kepada zon masa yang berbeza.
Walaupun cadangan untuk menghentikan protokol hanya dengan satu tanda tangan agak radikal, keperluan untuk mendapatkan beberapa tanda tangan dari pelbagai zon masa untuk menghentikan protokol memang boleh menyebabkan kelewatan semasa keadaan kecemasan. Memperkenalkan pihak ketiga yang dipercayai dan memantau tingkah laku di atas rantai secara berterusan, atau menggunakan alat pemantauan yang mempunyai kuasa untuk menghentikan protokol secara kecemasan, adalah pelajaran yang diperoleh daripada insiden ini.
Serangan terhadap protokol DeFi sudah lama tidak lagi terhadap lubang kontrak sahaja; insiden Resolv Labs memberi amaran kepada pihak projek: anda harus mengandaikan bahawa tiada satu pun elemen dalam keselamatan protokol boleh dipercayai, dan semua proses yang melibatkan parameter mesti diperiksa sekurang-kurangnya dua kali, termasuk backend yang dioperasikan sendiri oleh pihak projek.



