Diepgaande kwetsbaarheid: een mislukte terugkoopstroom die ervoor kan zorgen dat onderpand vast komt te zitten en tijdelijk buiten het bedoelde inzetpad blijft. Bij meerdere rondes van auditwerk met @aegis_im werd een probleem van gemiddelde ernst uit mei 2025 precies dit benadrukt. Het Aegis-team heeft de juiste stappen ondernomen om het op te lossen, opnieuw te beoordelen en volledig aan te pakken. De opzet De goedkeuringsstroom voor terugkoop van Aegis werkte in twee stappen. Onderpand werd overgedragen naar AegisMinting als een voorafgaande storting. De fondsbeheerder riep vervolgens approveRedeemRequest() aan om de terugkoop te finaliseren. Klinkt redelijk. Maar het creëerde een gevaarlijke randgeval. Als approveRedeemRequest() terugkeerde vanwege slippage-controles, vervaldatum of een andere goedkeuringsbeperking, mislukte de terugkoop, maar het onderpand dat al was verplaatst, werd niet teruggegeven. Het bleef vastzitten in AegisMinting. Waarom het belangrijk was Dat onderpand zou door de inzet- en risicobeheerstroom van Aegis blijven bewegen. Bij normale werking zou dat kunnen inhouden dat onderpand werd omgezet en in een delta-neutrale strategie werd ingezet om prijsblootstelling te verminderen. Wanneer fondsen vast kwamen te zitten vóór goedkeuring, gebeurde dat allemaal niet. De backing stopte met het verdienen van rendement zoals bedoeld. De backing bleef ongehedged en blootgesteld aan prijsbewegingen van het onderpand, inclusief het risico op depeg van stablecoins. Als die backing waarde verloor terwijl de YUSD-aanvoer onveranderd bleef, nam de druk op depeg toe. Een mislukte goedkeuring van de terugkoop kon het systeem een risico laten dragen dat het niet zou moeten dragen. Oorzaak Niet-atomair ontwerp. Het systeem verplaatste eerst de bewaring, en controleerde vervolgens of de goedkeuring daadwerkelijk kon worden voltooid. Zodra het onderpand binnen AegisMinting was, liet een latere terugkeer in approveRedeemRequest() het protocol in een tussenstaat achter: de terugkoop was niet goedgekeurd, het onderpand was al verplaatst, en er was geen afgedwongen terugrolmechanisme om de storting terug te draaien. Storting en goedkeuring waren van elkaar gescheiden, en een mislukking in de tweede stap ving waarde van de eerste. Voorbeeld van een mislukte weg Een terugkoopverzoek wordt geïnitieerd. Onderpand wordt overgedragen naar AegisMinting. Voor goedkeuring vervalt de bestelling of slippage beweegt buiten de grenzen. De fondsbeheerder roept approveRedeemRequest() aan. Het keert terug. Het onderpand blijft vastzitten, ongebruikt en ongehedged. Geen exotisch aanvallersgedrag was nodig. Dit kon worden getriggerd via de normale goedkeuringsworkflow. Oplossing De schoonste mitigatie was om de stroom atomair te maken. Valideer de terugkoop, verplaats het onderpand en finaliseer de goedkeuring in één pad, zodat fondsen alleen bewegen als de goedkeuring slaagt. Als een tweestapsstructuur moet blijven bestaan, heeft het protocol een duidelijke herstelweg nodig, zoals cancelRedeemRequest(), refundRedeemDeposit() of escrow-stijl boekhouding, zodat niet-gefinaliseerde stortingen altijd door de rechtmatige partij kunnen worden teruggevorderd. Waarom dit het bestuderen waard is Dit is het soort probleem dat belangrijk is bij audits. Meervoudige financiële systemen breken niet allemaal tegelijk. Ze breken in gedeeltelijke staten. Fondsen bewegen, één afhankelijkheid faalt, en het protocol blijft risico's dragen die het nooit had moeten dragen. Veel sterke bevindingen komen precies uit dat soort halfvoltooide stromen. Onderpand komt vast te zitten. Boekhoudkundige aannames houden op met bestaan. Backing eindigt inactief, blootgesteld of buiten het pad dat het had moeten volgen. Een schone gelukkige weg beschermt een systeem niet tegen schade veroorzaakt door een onvolledige weg. Een shoutout naar het @aegis_im-team voor het toestaan dat we dit probleem kunnen benadrukken en voor het nemen van de juiste stappen om het grondig op te lossen en te beoordelen.

Vriendelijke herinnering: als jouw protocol geen gebruik maakt van AI-auditing, breng je jouw team in een grote achterstand ten opzichte van de teams die dat al wel doen. Dit is geen toekomstige verschuiving. Het gebeurt nu al.

We zijn enthousiast om @Liquidity_land te verwelkomen als een Sherlock Security Partner. Door deze samenwerking krijgen web3-teams in het netwerk partnervoordelen en kortingen op Sherlock AI, audits, bugbounties en het complete beveiligingsaanbod van Sherlock gedurende de hele levenscyclus. Liquidity Land helpt protocollen om TVL aan te trekken via gestructureerde liquiditeitsprogramma's die zijn ontworpen voor langdurige groei door verbinding te maken met institutioneel kapitaal, walvissen en gecoördineerde LP's. We kijken ernaar uit om meer teams te helpen sterker te bouwen vanaf dag één.