Sonic DEX Hack: Technical Report, Asset Tracing, compensation plan and future plans

Developers Showcase
1

On 15 July 2026, Sonic DEX experienced a sophisticated exploit that resulted in the unauthorized extraction of assets from multiple liquidity pools.

Since the incident, our engineering and security teams have conducted an extensive investigation to determine exactly how the attack occurred, trace the movement of the stolen funds, and coordinate with centralized exchanges and law enforcement.

This post provides a detailed overview of our findings and the actions we are taking

Summary

  • Incident Date: 15 July 2026

  • Estimated Loss: Estimated $276,000

  • Liquidity Pools Affected: 26

  • Root Cause: Transaction atomicity vulnerability triggered through asynchronous canister execution

  • Current Status:

    • Vulnerability identified

    • Attack fully analyzed

    • Funds traced on-chain

    • Exchanges notified

    • Law enforcement process underway

Our forensic investigation traced the stolen assets through multiple intermediary wallets, swaps, and cross-chain transfers before they were ultimately converted to Bitcoin and deposited at HitBTC exchange.

Technical Analysis (Basic Analysis)

After a comprehensive review of the attack, we identified a transaction atomicity vulnerability within the Sonic DEX swap endpoints. The issue stemmed from the asynchronous execution model used by Internet Computer canisters. Under carefully orchestrated conditions, an attacker was able to submit a large number of precisely timed asynchronous requests that manipulated execution ordering during intermediate state transitions. Instead of following the expected execution sequence, the requests created race conditions within the task queue. This broke the expected transactional atomicity of the swap process.

As a result, the attacker was able to extract funds before the protocol completed reconciliation of the final transaction state. The exploit did not rely on compromised private keys or administrative privileges. Instead, it exploited an edge case in the protocol’s execution flow.

Root Cause

Our investigation determined that the exploit was caused by:

  • asynchronous execution ordering,

  • race conditions during intermediate state transitions,

  • loss of transactional atomicity under concurrent execution,

  • unauthorized state transitions before final reconciliation.

The attacker repeatedly executed carefully coordinated requests at high frequency, allowing them to exploit these timing conditions to withdraw assets that should not have been available. Following identification of the vulnerability, we immediately disabled the affected functionality and began implementing architectural changes to eliminate this class of issue.

On-Chain Investigation

In parallel with identifying the technical root cause, our team conducted a comprehensive forensic investigation to trace every movement of the stolen assets on-chain.

The investigation reconstructed the complete transaction flow from the affected Sonic DEX liquidity pools to the attacker’s final cash-out destination.

Our findings show that the attacker:

  • Drained assets from 26 concentrated liquidity pools, resulting in an estimated loss of approximately $276,000.

  • Consolidated approximately $195,000 into the primary attacker wallet:

    • abgpi-7mp67-kkjkv-l4hft-4bkxv-nd2gi-uyidc-xd6vh-tay7a-krima-vae

  • Distributed smaller amounts across three secondary wallets:

    • 4e18c7452ec8a54c87c3751b6e93ab2b26d5ada04ecdacc63452b4b945c5e580

    • 3a6a4f43d0da28574844cc7237bb8339ca33e378f5f03edb47ad5e02502a91de

    • 6d123e9bc79ea9f2ced187b8c58338341ef49cacb02792bbdb37ef455d27da74

The attacker then followed a structured laundering process:

1. Relay Wallet

The attacker transferred 96,780 ICP through the relay wallet: d154feac98eb916d77078abbeec34166daac0c3b80a15ee2ea055d21f3dbdfd9 This wallet was used solely as a temporary laundering step before the funds were moved again.

2. ICPSwap Conversion

The stolen ICP was swapped into ckBTC through the ICPSwap ckBTC/ICP Pool: (Canister:
xmiu5-jqaaa-aaaag-qbz7q-cai)
At the same time, approximately 30 million BOOM tokens were liquidated through the ICPSwap BOOM Pool: (Canister: fdno6-ayaaa-aaaag-qckuq-cai)

3. Consolidation

After the swaps, both the ckBTC and BOOM proceeds were consolidated into: tq34e-t2u7t-uernl-4p7re-mlcwv-6srpn-gu32m-g5iv5-i4rsi-2nacq-rae

This wallet served as the central aggregation point before the cross-chain transfer.

4. Bitcoin Exit

The attacker converted approximately 3.145 BTC from ckBTC into native Bitcoin through 62 separate burn transactions, sending the funds to the Bitcoin staging wallet: bc1qyf5f4nm66yuaga8zjs809lslmt3fapt68uhly4

5. Peel Chain

To make tracing more difficult, the attacker split the Bitcoin into multiple single-use peel-chain wallets before reconverging the funds into a centralized exchange (HitBTC) deposit transaction.

The final exchange deposit transaction identified by our investigation is:

Transaction ID :1aeea09d80ebf99f21df94792db3d65f86f1935e42f7e70b8bba379885da0aad

Timestamp: 2026-07-16 03:40 UTC

6. Centralised Exchange (HitBTC)

Our forensic investigation ultimately traced the funds to the following Bitcoin deposit address hosted by a centralized exchange (HitBTC): bc1qdfl3dfnwwvlqa5jpckh0ccwpjczh5y566c4g76

Based on our forensic findings, we contacted centralized exchanges that were connected to the movement of funds. We provided detailed transaction records, wallet traces, and forensic evidence. The exchanges acknowledged receipt of our reports and confirmed their willingness to cooperate with official law enforcement investigations where legally permitted.

As part of our ongoing investigation, we identified another important lead. Approximately one month prior to the exploit, the attacker-controlled wallet received funds from another wallet, providing an additional avenue.

Law Enforcement

We are actively working with the appropriate authorities to pursue this investigation. Our forensic report identifies the complete on-chain trail up to the centralized exchange deposit. Identification of the individual behind the exchange account requires information held by the exchange and the appropriate legal process.

We will continue cooperating with investigators and provide any additional evidence required.

Security Improvements & The Next Chapter for Sonic

While addressing the security incident has been our immediate priority, we have also taken this opportunity to redefine the future of Sonic.

Over the past several months, our engineering team has been redesigning the platform from the ground up with a stronger focus on security, performance, and long-term sustainability.

As part of this transformation, we have made the strategic decision to sunset the Liquidity Pool (LP) protocol and evolve Sonic into a next-generation platform centered around AI-powered discovery, market analytics, token aggregation, and investing tools.

Our objective is not simply to recover from this incident, but to relaunch Sonic as a stronger, more secure, and more innovative platform than ever before. The upcoming version of Sonic represents a new chapter for the project—one that combines robust security with powerful new products designed to make on-chain investing more accessible, intelligent, and user-friendly.

We look forward to sharing more details, previews, and launch timelines with our community in the coming weeks.

User Compensation Portal

While our investigation and recovery efforts continue, we are also committed to supporting affected members of the Sonic community. To begin this process, we will launch a dedicated compensation portal next week where eligible users can submit:

  • Their wallet address

  • Information about their affected Sonic DEX assets

  • Supporting details required for verification

Our team will review every submission and verify the reported balances against our on-chain records. Following verification, we intend to compensate eligible users either fully or partially, depending on the final recovery process and available funds. Compensation will be distributed directly to the wallet provided during the submission process over the coming month.

At this stage, our commitment is focused on reimbursing regular community users who were directly affected by the exploit. Additional details regarding eligibility, the verification process, compensation methodology, timelines, and any other categories of affected participants will be announced separately before the portal goes live.

We understand the uncertainty this incident has caused, and we are committed to handling the compensation process in a transparent, fair, and accountable manner. More details about the compensation portal, eligibility criteria, and reimbursement process will be published soon

Commitment to the Community

We understand the impact this incident has had on our users and liquidity providers. Transparency is important to us, which is why we are publishing both the technical findings and the forensic analysis of the attack.

We remain fully committed to:

  • pursuing recovery of stolen assets,

  • cooperating with exchanges and law enforcement,

  • strengthening Sonic DEX’s security and product,

  • keeping our community informed as the investigation progresses.

We sincerely appreciate the patience, support, and trust of our community throughout this process.

We will continue to share meaningful updates as they become available.

Thank you ,
Sonic Team.

2

Would you mind sharing the vulnerable code section in question, as well as how long that particular code /bug has been operative? was this bug present since launch or introduced more recently?

3

Bumping this, would be helpful for other SNS’s and DEX’s.

I call shenanigans.

https://www.youtube.com/watch?v=9F9GDG3uTvU
“… that’s how wars get started ..” :wink:

4

Appreciate the transparency. I see the app is still unavailable. Will the app be available again soon?

5

Thanks for publishing this at the level of detail you did; the root-cause
section is more useful to the rest of the ecosystem than most post-mortems,
and the asset trace is genuinely rare. Sorry it happened.

The failure class deserves to be named plainly, because it is the one that
catches almost everyone building on IC and it is not obvious coming from a
synchronous or EVM mental model:

On the Internet Computer, every await is a commit point.

A canister is single-threaded per message, not per call. At an await the
message yields, everything written so far is committed, and other messages
run before the callback resumes. So any value read before an await is a
snapshot of a moment that no longer exists by the time you act on it. Read
reserves → await a transfer → update reserves is not a transaction; it is
three independent messages with a public window between them, and the
attacker’s only job is to arrive inside that window enough times.

What we have found actually helps, roughly in order of leverage:

  1. Do the whole decision synchronously, or don’t call it atomic.
    The strongest fix is usually not a better lock; it is moving dedup,
    limit checks, pricing and persistence into ONE message with zero await
    between them, so a trap rolls the entire thing back together. Anything
    that must cross an await should be a reservation you compensate on
    failure, never a check you re-apply later.

  2. RAII locks, never manual release.
    If state must survive an await, take the lock in a Drop guard. IC
    rolls back a trapping callback but NOT what was written before the
    await; a lock released by an explicit line after the await sticks
    forever on trap and silently bricks the flow for everyone. Pick the
    narrowest key that still excludes the real hazard, and make sure every
    flow that touches the same resource shares one keyspace. Two flows
    guarding the same object under two different keys serialize nothing.

  3. Assume the response can be lost, and design for it.
    SYS_UNKNOWN means you genuinely do not know whether the call took
    effect. Pin created_at_time on every value-moving transfer so the
    ledger’s dedup window absorbs a retry, and write a forensic record
    between the .await returning Ok and the response decode; a decode
    panic after a committed transfer otherwise erases your only evidence
    that funds moved. Then classify failures as definitely-not-landed vs
    maybe-landed and never recompute an amount on the ambiguous branch.

  4. Rate limits keyed on principal are friction, not a cap.
    Fresh identities are free on IC, so any per-caller budget multiplies by
    however many identities the attacker scripts. Timing attacks like this
    one need a global cross-caller cap on the expensive path, plus a cycle
    floor that refuses the work outright below a threshold.

  5. Write the concrete attack script before believing the code is safe.
    Literally: t=0 attacker reads X, t=1 attacker yields, t=2 victim reads
    X, t=3 attacker acts… If you cannot produce a timeline where the
    invariant breaks, the concern is not real; if you can, the fix is
    whichever step you cannot reorder into a single message.

One structural note that is easy to miss: when the only thing preventing a
double payout is the ledger rejecting an overdraft, the code is not safe;
it is bounded. It becomes exploitable the moment anyone adds local
accounting on top of that path, and the person who adds it usually has no
idea the safety was coming from somewhere else. Worth marking those spots
explicitly in the code so a future change does not quietly remove the only
thing holding.

Good luck with the recovery and with the exchange/law-enforcement track.

7

You gotta hack a contract or two, boys. You gotta hack a contract or two.

8

Why should we break our backs
Flying straight, paying gas?
Better get some untaxed income
You better…

10

Sorry guys, it seems all exchanges are now being hacked

12

I hoped you wre gone for good, guess not. Characters.

13

Please say more as you’re on your 70th alt account

14

Which law enforcement are you working with, and in what jurisdiction? Because you’re the attacker and must be arrested, FIRST!

15

yes, we are working on it. first we will launch a claim portal

16

(post deleted by author)

17

Then go ahead and work with the legal authorities to help bring the attacker to justice. We’ve already done our part by tracing the stolen funds to HitBTC, identifying a connection to Coinbase, and providing detailed forensic evidence to the relevant exchanges.
We are happy to assist you .Making accusations without evidence doesn’t help the investigation or the affected users

19

On this chain, one thing counts

ICP, large amounts

Liquidity doesn’t grow on trees

You’ve gotta…

20

You blame everything on wenzel. It’s old and gay. Fagma