Summary
On 28 and 29 May 2026, public reporting indicated that DxSale’s legacy liquidity locker contracts on BNB Chain were drained for approximately $7.3 million across more than 1,400 old liquidity provider positions. The reported attack path is not a fresh smart contract bug, but a long-dormant retention of privileged control over old, unverified locker contracts that allowed an attacker to behave as the legitimate owner years after deployment.
Early analysis caveat
At drafting time, no official DxSale postmortem or detailed official statement has been verified. Root cause and attribution therefore remain pending direct confirmation from DxSale. The summary below is reconstructed from third-party reporting and on-chain analyst commentary, and should be read as early analysis rather than a settled account.
What public reporting says
Crypto Times reported that the drain was flagged by PeckShield and on-chain analyst Tahax, with losses estimated at roughly $7.3 million from old DxSale liquidity locker contracts on BNB Chain. The SlowMist Hacked feed categorises the incident as an Ownership Override Attack. CryptoNews describes the issue as involving retained administrative privileges on an unverified legacy contract. AMBCrypto additionally reports claims circulating about possible insider involvement, which have not been substantiated.
Reported attack path
According to the reporting cited above, the sequence reads as follows. Ownership of the affected legacy locker contracts was silently transferred away from the expected DxSale-controlled address roughly 269 days before the drain. That transfer was then routed through approximately 80 intermediate wallets, consistent with attempts to obscure attribution rather than any immediate extraction.
On the day of the drain, the attacker reportedly deployed a custom drainer contract, used the retained owner privilege to reduce or remove the lock fees, and backdated the unlock timestamps on locked positions to 1970, which is the Unix epoch and effectively zero. With the locks no longer enforcing any meaningful time constraint, the drainer withdrew the LP tokens from more than 1,400 old liquidity pool positions, then swapped the underlying assets primarily into BNB.
If that sequence is confirmed, the binding failure is not a logic bug in the locker maths. It is that an owner-level path existed at all on contracts that were assumed by users to be inert, that the ownership transfer was not monitored, and that the locker’s time-based protection could be unwound through that same owner path.
Confirmed so far vs pending
| Field | Status | Detail |
|---|---|---|
| Incident dates | Reported | 28 and 29 May 2026 |
| Affected platform | Reported | DxSale legacy liquidity locker contracts on BNB Chain |
| Total reported loss | Reported | Approximately $7.3 million across more than 1,400 LP positions |
| Categorisation | Reported | Ownership Override Attack, per SlowMist Hacked feed |
| Initial action | Reported | Silent ownership transfer roughly 269 days prior, routed via ~80 intermediate wallets |
| Drainer mechanics | Reported | Custom drainer deployed, lock fees reduced or removed, unlock timestamps backdated to 1970 |
| Primary attacker address | Reported | Reportedly moved 2,958 BNB worth approximately $1.87M to two main wallets, then to multiple Binance deposit addresses |
| Root cause | Pending official confirmation | No verified DxSale postmortem at drafting time; insider involvement claims unsubstantiated |
Technical evidence and explorer links
The following address appears in public reporting as the primary attacker address. It is reproduced here as reported and has not been independently verified by Security4Web3.
- Reported primary attacker address:
https://bscscan.com/address/0xC4574DDEF299e7E563971e200433e592EeaaFA69 - Reported flow: approximately 2,958 BNB, valued at roughly $1.87M, to two main wallets and then onward to multiple Binance deposit addresses.
Why this matters
A liquidity lock is meant to convert trust into an enforceable constraint. Holders accept a token because the deployer’s liquidity is locked for a stated period. If a legacy admin or owner path can override that lock years after the fact, the lock was never a durable control. It was a UI promise wrapped around a privileged contract.
Retained privilege on old contracts is a balance-sheet item. Locker platforms accumulate value over time as more pools are locked. The aggregate exposure of legacy contracts therefore grows even when no new code is shipped. Treating old deployments as inert is exactly how a 269-day-old ownership change can sit unnoticed until it is used to drain $7.3 million.
Time-based protections need to be one-way. An unlock timestamp that can be moved backwards by any privileged caller is a soft constraint, not a hard one. Locker designs that allow the owner to shorten or reset locks, change fees, or rotate the drain destination retain the very flexibility that the lock was supposed to remove.
What to watch next
- An official DxSale statement and postmortem confirming whether the entry point was a long-ago key compromise, a deliberate owner handover, an insider action, or a different vector entirely.
- Verification of the affected locker contract addresses, and confirmation of whether any active DxSale lockers share the same owner path or are isolated from it.
- Binance and other centralised venues’ responses to the reported deposits, including any frozen funds or attributed accounts.
- Whether holders of the more than 1,400 affected LP positions receive any form of remediation, and what that implies for the platform’s ongoing liability for legacy deployments.
What defenders can take from this
Treat ownership changes as security events, not housekeeping. Any transfer of ownership on a contract that holds or controls user value should generate an alert that is reviewed by a human, regardless of how old the contract is. A 269-day blind spot on a privileged role change is a monitoring failure as much as a contract design failure.
Isolate legacy value from active code. When a platform sunsets a contract version, the old deployments should be ring-fenced: ownership renounced where feasible, privileged functions disabled, and remaining value migrated under fresh controls. Leaving legacy contracts in place with intact admin paths means the aggregate blast radius of a future compromise is the sum of every old deployment, not just the current one.
Audit the privileged surface, not just the happy path. Locker contracts are usually audited against the user-facing flow: lock, wait, unlock. The vector here was not the user path. It was the owner-only ability to change fees, shorten locks, and effectively pre-unlock everything. Reviews need to enumerate every owner-callable function and ask what an attacker who reaches that role can do, not just what the intended operator would do.
Sources
- Crypto Times, “Hackers drain $7.3M from DxSale’s old BNB Chain liquidity lockers”
- SlowMist Hacked feed
- CryptoNews, coverage of the DxSale legacy locker incident
- AMBCrypto, “DxSale hit by $7.3 mln exploit as claims of insider involvement rise”
If you operate a launchpad, locker, vesting vault, or any other contract whose value proposition is a time-based or role-based constraint, the question is not whether the contract is audited. It is whether every privileged path on every version you have ever deployed still behaves the way your users assume it does today. Security4Web3 can help you map retained privileges across your historic deployments, monitor ownership and role changes in real time, and design migration and renunciation strategies that turn legacy contracts from a quiet liability into a closed chapter.