Squid, een cross‑chain cryptoplatform, neemt afstand van een hack waarbij, op het moment van schrijven, 3,2 miljoen dollar is buitgemaakt. Het geld verdween uit een extern smart contract dat sterk leek op de officiële contracten van Squid. Het bedrijf zegt dat dit contract niet van hen is en waarschuwt gebruikers voor verwarring. De kwestie speelt online in de DeFi-markt en leidt tot vragen over veiligheid en toezicht.
Squid ontkent betrokkenheid
Squid benadrukt dat het gehackte contract door een derde partij is gemaakt. Het contract lijkt qua naam of opzet op hun eigen code, maar valt niet onder hun beheer. Het bedrijf verwijst gebruikers naar geverifieerde adressen op hun website en officiële kanalen. Zo wil het merkverwarring en extra schade voorkomen.
De verklaring is bedoeld om duidelijk te maken waar de verantwoordelijkheid ligt. In de cryptowereld circuleren vaak kopieën en klonen van bekende projecten. Dit kan snel tot misverstanden leiden bij beleggers die handelen op basis van een bekende naam. Squid roept daarom op om altijd adresgegevens dubbel te controleren.
De reactie van Squid laat zien hoe kwetsbaar reputaties zijn in DeFi. Een incident met een gelijkend contract kan direct afstralen op het originele project. Duidelijke communicatie en snelle verificatie zijn dan cruciaal. Dat beschermt zowel gebruikers als het ecosysteem.
Gelijkend contract misleidt beleggers
Een look‑alike smart contract is een stukje code dat lijkt op het originele contract van een bekend project. Aanvallers kopiëren vaak naam, interface of functies. Soms voegen ze kleine, verborgen wijzigingen toe. Zo wekken ze vertrouwen en lokken ze geld of machtigingen uit.
Een look‑alike contract gebruikt dezelfde stijl, naam of functies als het origineel, maar wordt bestuurd door anderen en kan kwaadaardige code bevatten.
Gebruikers raken de weg kwijt als contractadressen nauwelijks afwijken. Een extra teken, een ander netwerk of een kopie van de interface kan genoeg zijn. Ook goed nagemaakte websites spelen daarbij een rol. Dit vergroot de kans op foutieve transacties of te ruime machtigingen.
Verificatie van adressen blijft daarom de eerste verdedigingslijn. Officiële documentatie, GitHub‑links en geverifieerde profielen op block explorers helpen. Veel projecten publiceren een “contract registry” met alle actuele adressen. Zonder die controle is het risico op misbruik groot.
Technische oorzaak nog onduidelijk
De exacte oorzaak van de hack is nog niet publiek vastgesteld. Mogelijke routes zijn misbruik van te ruime token‑machtigingen, een fout in de contractlogica of een gecompromitteerde sleutel. Ook social engineering via nagemaakte front‑ends komt vaak voor. Alleen een volledige on‑chain analyse kan dit bevestigen.
Audits en bug‑bounties verkleinen risico’s, maar bieden geen garantie. Aanvallers zoeken zelden naar één grote fout. Ze combineren kleine hiaten in code, processen en menselijk gedrag. Zo ontstaat alsnog een lek met financiële schade.
Transparantie over post‑mortems helpt de markt te leren. Heldere rapporten beschrijven wat er misging en welke maatregelen volgen. Dat vergroot het vertrouwen in serieuze projecten. Het dwingt ook tot betere basispraktijken, zoals beperkte machtigingen en time‑locks.
Europese regels en toezicht
In Europa valt crypto‑toezicht vooral onder MiCA, de nieuwe verordening voor cryptodiensten. Die richt zich op uitgevers en dienstverleners, zoals beurzen en bewaarders. Volledig gedecentraliseerde DeFi‑contracten vallen nog grotendeels buiten het directe bereik. Toch vraagt de ESMA om extra data en richtsnoeren voor risicobeheer.
Voor aanbieders in de EU gelden ook cybersecurity‑eisen via NIS2 en operationele weerbaarheid via DORA. Dit raakt partijen die wallets, infrastructuur of interfaces leveren. Incidentrespons, logging en kwetsbaarheidsbeheer worden strenger. Dat kan misbruik sneller zichtbaar maken en beperken.
In Nederland waarschuwen AFM en DNB al langer voor cryptorisico’s. Transparante risico‑info en duidelijke contractadressen passen bij die lijn. Consumentenbescherming staat centraal, zeker bij platforms met Europese klanten. Binnen MiCA moeten aanbieders, op het moment van schrijven, ook heldere informatie over risico’s publiceren.
Aanbevelingen voor gebruikers
Controleer altijd het contractadres via officiële kanalen van het project. Klik niet op links uit chats of advertenties. Beperk token‑machtigingen tot het minimum en trek oude machtigingen in. Gebruik daarvoor betrouwbare “approval revoker” tools.
Test nieuwe contracten met kleine bedragen. Gebruik waar mogelijk een hardware wallet. Let op geverifieerde badgets op block explorers, maar vertrouw niet alleen daarop. Combineer meerdere verificatiestappen voordat u handelt.
Volg updates van het project over incidenten en post‑mortems. Let op waarschuwingen van Europese toezichthouders en nationale autoriteiten. Dien bij verlies een melding in bij de politie en uw bank, ook al is verhaal vaak lastig. Snel handelen vergroot de kans op bevriezing bij centrale platforms.
