Anatomy of the DxSale Locker Exploit: Ownership Capture, a Self-Call Drain, and a Two-Chain Laundering Trail

On May 27, 2026, an attacker address began draining a DxSale liquidity locker on BNB Smart Chain about an hour and forty minutes after being funded — the opening move of a batch drain campaign that ran for multiple days — then distributed proceeds across two chains — one leg blunt and KYC-exposed, the other routed through a bridge, DEX swaps, and a mixer. This is the full on-chain reconstruction, every claim backed by sealed, reproducible evidence.

How to read this report. Each finding carries an explicit confidence level under my forensic standard (OCS-FIS-V1):

• Confidence: High (evidence) — directly observable on-chain and sealed under chain of custody from at least two independent sources.
• Confidence: Medium (hypothesis) — a reasoned interpretation the sealed evidence supports but does not prove. Stated as a hypothesis, never as fact.

Every transaction hash, address, and block is reproducible by any third party against the public chains. I name on-chain entity labels surfaced by block explorers (e.g. “DxSale Exploiter 1”, “Binance 51”) as attributed observations — not as proven real-world identities. No natural person is named or attributed in this report.

Updated 2026-07-15 — correction log. This report was materially corrected and extended after new evidence was sealed under custody. What changed: (1) the ownership capture (F-01) was undercounted — at least six lockers were captured, not three, over a ~9-minute window; (2) the funder’s exchange attribution (F-02) gained a sealed second source (Arkham Intelligence labels the funder Bybit: Hot Wallet); (3) the drain (F-04) is now documented as a sealed batch campaign — at least 19 transactions, 3,576 LP transfers, 17 distinct pools; (4) the distributor outflow set (F-05) was proven complete via consensus-enforced account nonces — floor language upgraded to exact totals; (5) a new finding (F-11) records that of the captured lockers only the Legacy locker has a sealed drain. Full transaction annexes with explorer links were added to F-01, F-04, F-05, F-07, and F-08, and the findings-file hash pin in this page’s front matter was updated accordingly.

Updated 2026-07-19 — editorial revision. The prose of this report was revised from the corporate plural to the first-person singular: OnChainSurfer is one independent forensic investigator and signs accordingly. A one-line summary was added to the front matter for listing cards and meta description. No finding, figure, confidence level, or sealed artifact changed; the findings-file hash pin is unchanged.

Executive summary

One caveat governs the entire laundering half of this report, and I put it up front: the attacker address is a serial operator, and the funds it moved are commingled proceeds of its broader activity. My sealed evidence does not establish that the specific BNB and SOL laundered here came from the DxSale locker drain. What ties the laundering to the DxSale exploit is the shared attacker address, not a sealed value-trace from the drained liquidity. I claim no DxSale-specific dollar figure for the laundered funds.

1. Ownership capture High · evidence

On 2026-05-26, within a ~9-minute window spanning blocks 100449023–100450184 (01:08:21Z to 01:17:04Z), deployer address 0x47BAcf935066b802EAA0067eC14AB035B24eB78b sent at least six successful BSC transactions, each invoking transferOwnership (selector 0xf2fde38b, value 0 BNB) against a different locker contract:

• 0x2D045410f002A95EFcEE67759A92518fA3FcE677 — no explorer label
• 0xEb3a9C56d963b971d320f889bE2fb8B59853e449 — labeled DxSale Network: Legacy Liquidity Locker
• 0x81E0eF68e103Ee65002d3Cf766240eD1c070334d — labeled KIPS: Locked Wallet
• 0x5b5e94485c9628793B01A38762921Dc37B6829b6 — verified contract, no address-book label
• 0x8655E5c4D701186D16765d1CDcef6D5287E4679a — verified contract, no address-book label
• 0xf8AD74e9E5D6b12EFe27dE09Bc57d38a8E52D791 — verified contract, no address-book label

In all six, the newOwner argument was 0xC4574DDEF299e7E563971e200433e592EeaaFA69 — the address block explorers label DxSale Exploiter 1. Each transaction succeeded and emitted an OwnershipTransferred event from the target locker itself. Control of every listed locker moved to that single address in one batch. Six is a floor, not an exhaustive count — the set is sampled from the deployer’s transaction history.

Correction (2026-07-15): an earlier version of this report stated three transfers over a window ending at block 100449822. Both figures were undercounts; three additional captures were sealed and the window extends to block 100450184.

Transaction annex (F-01):

What I do not claim: on-chain data alone cannot distinguish a malicious insider from a compromised deployer key, and a benign internal migration is logically possible — but it is weakened by the subsequent drain of the Legacy locker and the absence of any official DxSale migration announcement.

2. Pre-attack funding High · evidence

In transaction 0xffc7b601d90f6bc5584a9880693eb41f41ad62619e863e97b5d72477f5e4b72a (block 100798786, 2026-05-27T20:57:54Z, success), address 0x318d2aAe4C99c2e74F7B5949fa1C34DF837789B8 sent exactly 104.1473 BNB to the attacker address as a plain transfer (call data 0x, no method). The sealed BscScan transaction page shows the sender tagged Bybit 17 and the receiver tagged DxSale Exploiter 1 (the raw RPC capture, sealed alongside it, carries no entity labels).

This inbound funding precedes the drain by 1h 39m 51s (relative to the drain’s separately sealed timestamp in F-03).

Honest limits:

• The exchange attribution rests on two independent third-party labelers, both sealed: the BscScan Bybit 17 tag and the sender’s Arkham Intelligence entity page, which explicitly labels it Bybit: Hot Wallet (alongside Bybit Proof of Reserves and Centralized Exchange) and shows the same 104.147 BNB outflow to the attacker on 2026-05-27. The “hot wallet” characterization is stated by Arkham’s label — no longer my inference. Neither labeler’s process is audited first-hand by me; the transfer facts (amount, addresses, block, success) are high-confidence independently of the labels.
• A plain transfer from an exchange-labeled wallet is consistent with an ordinary customer withdrawal. It does not, by itself, establish that the exchange directed funds toward the drain, nor prove intent.

3. The drain, as observed on-chain High · evidence

At block 100812090 (2026-05-27T22:37:45Z), transaction 0xb107f19af1a8ff90d19cbb40d935f8be5d79f5fb9b497824e4ed28b9e7555fe9 executed with status success as a self-call — from and to are both the attacker address 0xC4574DDEF299e7E563971e200433e592EeaaFA69. It carried 0 BNB and invoked custom, unverified selector 0x11b432b4.

I re-derived the effect first-hand from the sealed getTransactionReceipt (public RPC), not just from the explorer’s decode. The receipt carries 10 raw event logs:

• 5 are ERC-20/BEP-20 Transfer events of the PancakeSwap LP token (Cake-LP) 0x88DA6Bc38D5BFEF6e332F87E06a310a9e5f768E2, each moving 12.872812929106341247 units (sum 64.364064645531706235) from the Legacy Liquidity Locker 0xEb3a9C56d963b971d320f889bE2fb8B59853e449 to the attacker address.
• The other 5 are non-Transfer events emitted by the locker contract, which I deliberately do not characterize further.

The transaction is displayed with an EIP-7702 Delegated Address 0x74Ad1Ef17Fbb3e494c31c72F7ec730A27FEf0310.

Scope note: the “5” is the Transfer-event count, not the total log count (10). This finding records observable facts only. Whether any control was bypassed, and by what mechanism, is out of scope here — see F-04.

4. Drain mechanism Medium · hypothesis

What is sealed fact — the batch campaign. The drain was not a single transaction. At least 19 sealed transactions — each a self-call (from and to both the attacker) invoking the same custom selector 0x11b432b4 with 0 BNB — moved Cake-LP pool tokens from the Legacy locker to the attacker across blocks 100812090 → 101536778, in at least 3,576 Transfer events covering at least 17 distinct pool-token contracts (all re-derived first-hand from each sealed getTransactionReceipt). These figures are floors over the sealed sample: read-only enumeration surfaced a materially larger campaign across May 27–31, which I assert only as a read-only observation, not a sealed count.

Transaction annex (F-04):

What remains hypothesis — the mechanism. The proposed reading: the drain abused privileged locker functions that became reachable after the ownership capture in F-01 (an OSINT attribution consistent with public write-ups). The sealed facts support this reading but do not prove it.

The exact bypass path remains open because:

• Selector 0x11b432b4 is custom and unverified — I have not decompiled or ABI-resolved the called code, so I cannot confirm it is an owner-only locker withdrawal rather than a generic multicall/router/aggregation path.
• The auxiliary contract at the EIP-7702 delegate 0x74Ad1Ef17Fbb3e494c31c72F7ec730A27FEf0310 has unread bytecode — the delegation may implement the transfer logic itself, making the locker’s own function possibly not the vector.
• Ownership capture as the enabling precondition is inferred and timing-correlated, not causally proven within this transaction.

Resolving the mechanism requires deconstructing the locker and auxiliary contracts — deferred.

5. Distribution across BSC High · evidence

Between BSC blocks 100869981 and 100977493 (every transaction sealed individually as a getTransactionByHash JSON):

• Funding the distributors: the attacker address sent 1,542.285 BNB to distributor DIST-01 0xb71c1C2A0cD7A88f1317f9A996e4d121E7db5E92 (4 tx) and 1,438.285 BNB to distributor DIST-02 0x4c5ee9703653C8e7725C65593bff372655e0453C (4 tx).
• Distribution: 22 sealed DIST-01 outflows to 22 distinct wallets sum to 1,527.28 BNB; 8 sealed DIST-02 outflows to 8 distinct wallets sum to 1,438 BNB — in aggregate 2,965.28 BNB to exactly 30 distinct receiving wallets.
• Early returns: before distributing anything, DIST-01’s first three transactions (nonces 0–2, blocks 100873674–100913254) sent 15.001 BNB back to the attacker — a pattern consistent with path-test transfers, though intent is not asserted.

The outbound set is complete — proven by account nonce. Both distributors are EOAs (their sealed eth_getProof responses report the code hash of empty code). An account’s nonce is the consensus-enforced exact count of transactions it has ever sent, and it reads 25 for DIST-01 and 8 for DIST-02 — attested by two independent providers — exactly matching the sealed transaction sets, which occupy the contiguous nonce ranges 0–24 and 0–7 with no gaps. Every nonce slot these addresses ever consumed maps to a sealed plain transfer (none is an EIP-7702 authorization, which would also consume a slot). The 30 receiving wallets plus the attacker are therefore the only addresses that have ever received value from these distributors, as of block 110205789. Sealed end-balances (0.00397732929 and 0.2849957925 BNB) corroborate near-empty distributors. What this does not cover: inflow completeness is not claimed (dust-level unsealed inflows provably exist and are immaterial), and the exchange attribution of the 30 wallets is addressed separately (F-06) — though Arkham Intelligence independently labels the distributors’ outflow recipients Binance Deposit and reports Exchange Usage of 100% Binance for both distributors ($935.59K DIST-01 / $910K DIST-02, sealed pages), as third-party corroboration.

Transaction annex (F-05):

Funding (attacker → distributors, 8 tx):

DIST-01 early returns to attacker (nonces 0–2, 3 tx):

DIST-01 distribution outflows (nonces 3–24, 22 tx):

DIST-02 distribution outflows (nonces 0–7, 8 tx):

6. Consolidation to a single exchange wallet High · evidence

I sampled 5 of the 30 receiving wallets and sealed their onward hops. All five forwarded the BNB they received to the same address 0x8894E0a0c962CB723c1976a4421c95949bE2D4E3, which the sealed explorer pages label Binance 51:

Every hop is sealed with two independent sources — the public-RPC getTransactionByHash JSON and the explorer transaction-page screenshot. Sweep cadence is fast and uniform: between each wallet’s deposit and its outbound hop, 210 to 1,506 blocks (roughly 95 seconds to ~11 minutes). Worked example, fully from 0xAc69F86C…’s own sealed page: deposit at block 100928690 (13:13:41 UTC), hop at block 100929535 (13:20:02 UTC) — 845 blocks in 381 seconds (~0.45 s/block), consistent with automated sweeping. At least one sampled wallet shows FUNDED BY: Binance: Deposit Funder and repeat deposit-and-sweep cycles before and after the exploit window.

What I do not claim: I assert on-chain consolidation for the 5 sampled wallets only. The statement “all 30 wallets consolidate to Binance” is deliberately not made as an on-chain claim — the remaining 25 wallets’ hops were not sealed. Independently, Arkham labels the distributors’ outflow recipients Binance Deposit and reports both distributors’ Exchange Usage as 100% Binance (sealed pages) — third-party corroboration extending the Binance-destination attribution to the full set, though only the 5-wallet sample carries sealed on-chain hop evidence. Binance 51 is an explorer label, not an on-chain-proven identity.

7. Crossing to Solana via Relay.link High · evidence

24 successful BSC transactions moved value from three relay wallets into the Relay.link bridge. Each crossing is attested end-to-end by three sealed artifacts: (a) the BSC origin transaction, (b) the bridge operator’s own public status record mapping that exact origin hash to a Solana fill signature + destination + USD valuation, and (c) the Solana fill transaction itself, independently sealed.

The three destination accounts are pairwise distinct — the bridged funds did not converge on a single Solana account. On the BSC side, RELAY-02’s inputs totaled 8,809.826078 BUSD + 9,885.496711 USDT + 90.840809 WBNB (sealed receipts).

Transaction annex (F-07) — each crossing with its three sealed artifacts:

Honest limits: the operator’s status records are an independent second source but not chain consensus; this is mitigated by (c), each fill independently retrieved from a public Solana RPC. USD figures are the operator’s valuations at request time — cited as attributed, not my own pricing. Per my confidence standard, cross-chain linkage starts from a confidence ceiling I fixed in advance — before looking at the data — because no transaction hash is shared across a bridge; here the two independent sources meet on exact transaction identifiers, which lifts it to high.

8. Swaps and the mixer boundary High · evidence

Downstream on Solana (all quantities are balance deltas from sealed getTransaction JSONs; the Solana RPC does enumerate an account’s signatures, so per-transaction deltas are high-confidence, but set completeness rests on that enumeration — counts are floors):

• Handoffs: 2dQg9J… forwarded 1,020.653 SOL to AgnEKmN1XHBduneu9bFu1bfp69GRVUuCyNpQjAHSJ6do (2 tx); 8E6SHPRJ… forwarded 4,631.92 SOL to 3vy9hoGMq382E48EEyGuEYTeP8Raya8WRVRgbrvCGxKY (2 tx). (Abbreviated forms of these two accounts are used below after this first full mention.)
• DEX swaps to USDT (2026-06-02): A6uMgTcF… converted 5,300.156953 SOL → 400,000 USDT (its swap output equals its later single 400,000 USDT outflow — the balance closes); 3vy9hoGM… converted 2,324.482379 SOL → 173,500.88 USDT; AgnEKmN1… converted 513.30551 SOL → 38,305 USDT.
• One path ends at a KYC-exposed exchange deposit: AgnEKmN1… sent 38,276 USDT to B3KoJ9TETMmEiAUPMXzeCJsTvHh2rn1mawj3NZMi1zrf (2026-06-08), an account whose sealed Solscan page shows the literal tags #Binance Exchange and #Deposit Address — the single KYC-exposed endpoint observed on the Solana side, and the thread that ties this leg back to a subpoena-serviceable exchange (≈$38K of an operator-valued ≈$1.35M bridged tranche; the majority path ends at the mixer and non-enumerated fan-out). Separately, the pool 4AV2Qzp3N4c9RfzyEbNZs2wqWfW4EwKnnxFAZCndvfGh — Solscan public name Privacy Cash Pool, owner Privacy Cash — was credited 1,107.4496944 SOL across 6 sealed deposits (183.5 SOL from AgnEKmN1…; 923.9496944 SOL from 3vy9hoGM…).

Transaction annex (F-08) — the 35 sealed Solana transactions behind this section:

The honest stop: material outflows (400,000 USDT + 5,424.15 SOL from the RELAY-01 destination, and further outflows from 3vy9hoGM…) went to accounts I did not enumerate. The mixer is a hard visibility boundary — deposits are observable, withdrawals are unlinkable on-chain. I therefore claim no terminal attribution of the Solana leg and no statement about where the majority of its value ultimately landed.

9. An EIP-7702 apparatus High · evidence

The attacker address operated under EIP-7702 (transaction type 0x4) delegation on BSC. Sealed on-chain: transaction 0x6f83d59da4de3ac68c9cb941530daa2d75d33c6e43497ee0dc6a8efbc171e211 (block 101536427) delegates the attacker’s account authority to 0x44BCb3eAeE1C15f5D669A2B5e628d42c1ec19A18 on chainId 0x38. Sealed explorer pages display: over 10,000,000 EIP-7702 authorizations, authority nonce values up to 123,429 by 2026-05-31, and — on the delegate contract page — CONTRACT CREATOR: DxSale Exploiter 1, the attacker’s own label.

Contrast, sealed on-chain: the relay wallets RELAY-01 and RELAY-02 also executed type-0x4 transactions, but they delegate to 0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B — a widely-deployed standard wallet delegate — not to the attacker’s custom delegate.

Scope: the scale figures (>10M authorizations, nonce 123,429) are explorer-computed aggregates on sealed screenshots, not re-derived by me; the delegate’s bytecode was not deconstructed. This is a seed for a dedicated investigation.

10. Two opsec postures — over commingled funds Medium · hypothesis

This is an interpretive frame over the evidence findings above; it asserts no new facts, no identity, and no intent. And it inherits the commingling caveat in full: the attacker address is a serial operator (123,448 transactions; the EIP-7702 apparatus of F-09), and the funds below are its commingled proceeds. The sealed evidence does not establish that they derive from the DxSale locker drain specifically. The link to DxSale is the shared address, not a value-trace.

With that stated, the two chains look very different:

• BSC — minimal obfuscation. Attacker → 2 distributors → exactly 30 wallets (2,965.28 BNB, outbound-complete by nonce), with all 5 sampled wallets sweeping to a single Binance 51 hot wallet: a direct, KYC-exposed exit that concentrates any subpoena leverage on one exchange.
• Solana — substantially more sophistication. The bridged tranche (operator-valued ~$1,350,897.92 across 24 crossings) split across three destinations, swapped into USDT, sent 1,107.45 SOL into a Privacy Cash mixer, and fanned out to non-enumerated accounts — with only 38,276 USDT reaching a Binance-tagged deposit account.

Possible readings, none asserted: (a) different operators or playbooks per chain; (b) one operator applying higher opsec to the cross-chain tranche; (c) the BSC exit relied on mule or compromised accounts where KYC exposure was acceptable. The asymmetry could also be an artifact of how deeply I enumerated each side. I frame it for the reader; I do not resolve it.

11. Captured, but not drained Medium · hypothesis

Of the at least six captured lockers (F-01), only the Legacy Liquidity Locker 0xEb3a9C56d963b971d320f889bE2fb8B59853e449 has a sealed on-chain drain to the attacker (F-03/F-04). For the other five, read-only checks (explorer transfer filters from each locker to the attacker) returned no drain transaction as of those checks.

This is a bounded, single-source negative observation — an absence of observed drain in read-only checks, not proof that those lockers were never drained or cannot be drained; exhaustive confirmation would require archive-node range scans outside this investigation’s read-only tooling. Under this bounded observation, five captured lockers remained under attacker ownership with no observed drain, leaving their locked liquidity exposed to the same ownership-capture vector exercised against the Legacy locker. Independent third-party reporting (rekt.news) characterized a comparable residual exposure as “$15.5M still at risk” — I cite that figure as external reporting only, not as a sealed quantity, and I do not independently value the exposed liquidity.

What this investigation does not claim

• No DxSale-specific dollar figure for the laundered funds. The funds are commingled proceeds of a serial operator; the tie to DxSale is the shared address, not a sealed value-trace.
• No real-world identity. Every “Binance”, “Bybit”, “DxSale Exploiter”, and “Privacy Cash” reference is a block-explorer entity label — an attributed observation, not a proven identity, and never a natural person.
• No exhaustive counts on BSC — with one proven exception. Wallet and transaction counts on the EVM side are floors, except the distributor outflow set (F-05), which is proven complete by consensus-enforced account nonces. The exchange attribution of the 30 receiving wallets rests on the sealed 5-wallet sample plus third-party (Arkham) corroboration — not on sealed hops for all 30.
• No terminal landing on Solana. The mixer and non-enumerated fan-out are hard boundaries.
• No proven drain mechanism. F-04 is a hypothesis pending contract deconstruction.

Methodology and custody

Every cited transaction, address, and block is reproducible by any third party against the public BNB Smart Chain and Solana. All evidence is sealed under a write-once chain of custody: each artifact is content-hashed (SHA-256) at capture and the hashes are pinned; the finding set is validated by a mechanical export gate before publication. Confidence levels follow my forensic standard OCS-FIS-V1: affirmative language is used only for sealed, observable evidence, and interpretations are labeled as hypotheses. The pre-existing public trail for this case was treated as a lead only — every fact here was independently re-collected and re-sealed.

Reference addresses and transaction hashes appear inline above and resolve directly on public explorers.