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 drained a DxSale liquidity locker on BNB Smart Chain a little over an hour after being funded, then distributed the 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 our 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. We 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.

Executive summary

One caveat governs the entire laundering half of this report and we put it up front: the attacker address is a serial operator, and the funds it moved are commingled proceeds of its broader activity. Our 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. We claim no DxSale-specific dollar figure for the laundered funds.

1. Ownership capture High · evidence

On 2026-05-26, within a ~6-minute window spanning blocks 100449023–100449822 (01:08:21Z to 01:14:21Z), deployer address 0x47BAcf935066b802EAA0067eC14AB035B24eB78b sent three 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

In all three, the newOwner argument was 0xC4574DDEF299e7E563971e200433e592EeaaFA69 — the address block explorers label DxSale Exploiter 1. Control of all three lockers moved to that single address in one batch.

What we 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). Both sealed sources show the sender tagged Bybit 17 and the receiver tagged DxSale Exploiter 1.

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

Honest limits:

• Calling Bybit 17 a Bybit “hot wallet” is our inference from an exchange-operations label — not text the label itself states. Independent second-source corroboration of the exchange attribution (e.g. Arkham) is pending, not yet sealed. The transfer facts (amount, addresses, block, success) are high-confidence with two sealed sources; the exchange-identity layer is not.
• 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.
• The sender and receiver are distinct addresses and must not be conflated.

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.

We 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 we 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

This is a hypothesis, not on-chain verified by us. 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 of F-03 support this reading but do not prove it.

The exact bypass path remains open because:

• Selector 0x11b432b4 is custom and unverified — we have not decompiled or ABI-resolved the called code, so we 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 (floor): 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 at least 2,965.28 BNB to at least 30 distinct receiving wallets.
• Closure: DIST-01 returned 15.001 BNB to the attacker across 3 tx.

These are floor quantities. The public EVM RPC cannot enumerate transactions by address, so the counts (22 / 8 / 30) come from a single browser-side explorer enumeration and are floors — not exhaustive totals. We do not claim these are the distributors’ only outflows, nor an exact wallet count, nor (here) the exchange attribution of the 30 wallets.

6. Consolidation to a single exchange wallet High · evidence

We 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 we do not claim: we assert consolidation for the 5 sampled wallets only. The statement “all 30 wallets consolidate to Binance” is deliberately not made — the remaining 25 wallets’ outflows were not sealed. 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 (this corrects a “triple convergence” note in the pre-Lab trail). On the BSC side, RELAY-02’s inputs totaled 8,809.826078 BUSD + 9,885.496711 USDT + 90.840809 WBNB (sealed receipts).

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 our own pricing. Per our confidence standard, cross-chain linkage carries an ex-ante ceiling because no hash is shared across the 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.
• Terminal movements: 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. 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…).

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 we did not enumerate. The mixer is a hard visibility boundary — deposits are observable, withdrawals are unlinkable on-chain. We 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 us; 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 → at least 30 wallets (≥2,965.28 BNB floor), 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 deep we enumerated each side. We frame it for the reader; we do not resolve it.

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. Wallet and transaction counts on the EVM side are floors.
• 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 our 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.