A liquidity locker can be hacked when the locker contract itself has an owner or admin key that can override the lock. The unlock date you see on a certificate is then only as reliable as whoever holds that key. A locker with no such key has no equivalent attack path, though it can still contain ordinary bugs.
The clearest recent example is DxSale, in May 2026.
What happened at DxSale
DxSale’s older locker contracts on BNB Chain, deployed in 2021 and 2022, held LP tokens for projects for years. On May 27 and 28, 2026, an attacker drained roughly $7.3 million from more than 1,400 LP positions in them. Rekt’s write-up reports that the attacker took ownership of the legacy lockers, then used the owner role to bypass the time restrictions, set fees to zero and withdraw LP tokens directly. A batch transaction hit many pools in one pass.
Crypto Times reports that PeckShield and the on-chain analyst Tahax flagged the drain. It also reports that DxSale had issued no public statement when the article went out. Rekt says the team’s first official response came more than a day after the first alerts.
How the attacker got the owner role is not established in the sources I read. Rekt lists both an insider and an outside compromise as unconfirmed, so this article does not take a side. The mechanism is the useful part, and it does not depend on the answer.
Why the lock did not hold
Each project that used those lockers had set an unlock date. The projects did what a founder is supposed to do. The date still did not matter, because the locker contract had a function that let its owner change that date and change the fee.
A lock has two layers. The first is the rule written for you: tokens go in, they come out on a date. The second is the set of functions that can change that rule. A certificate shows you the first layer and says nothing about the second. In an owner-controlled locker, anyone who gets hold of the owner key can rewrite the first layer.
This is also why age matters. Those contracts were deployed in 2021 and 2022. The owner key had to stay secure for four or five years across team changes, laptops, backups and access lists. Admin keys do not have to be malicious to fail. They only have to outlive the discipline of the people who held them. The admin-keys post covers the general pattern.
What an owner can do inside a locker
If you can read Solidity, the pattern is easy to spot. Look for functions guarded by a check against a privileged address, usually written as onlyOwner or a role check. In a locker, the dangerous ones are:
- a function that changes an unlock time, or marks a lock as released
- a function that withdraws tokens on behalf of a lock
- a setter for the fee, the fee receiver or a token allowlist
pause()andunpause(), which can trap everyone’s tokens- an upgrade path (a proxy, or
delegatecallto an address the owner controls) that can replace the whole contract
Any one of these means a person or a key, not code, has the last word. The zero admin access article goes through each of them in more detail.
How to check a locker in five minutes
You do not have to trust a claim on a website. The checks are public.
- Open the locker contract on the chain’s block explorer and confirm the source is verified. If it is not, treat the lock as unverified.
- Read the contract’s functions. Search the source for
onlyOwner,Ownable,AccessControl,pause,upgradeToanddelegatecall. - On the explorer’s Read Contract tab, look for an
owner()function. If it exists, see who the owner is: a plain wallet, a multisig or the zero address. - Check whether the contract sits behind a proxy. Explorers usually label this, and the Read as Proxy tab appears.
- Look at the fee. If a setter exists, the fee you pay today is not guaranteed tomorrow.
A locker that fails some of these is not necessarily malicious. Many have an owner for legitimate reasons, such as raising a fee or pausing during an incident. The point is that the owner’s power is part of what you are trusting, and it should be on your list of risks next to the unlock date.
What is different without an owner
If a contract has no owner, no admin role, no pause and no proxy, there is no address to take over. Nobody can move the unlock date, because the only functions that exist are the ones every user can call under the same rules.
0xKeep is built that way. The contract (V12) inherits only OpenZeppelin’s reentrancy guard. Each lock has an owner, which is the wallet that created it, and only that wallet can withdraw, and only once the unlock time has passed. The owner can extend a lock but cannot shorten it. Fees and the fee receiver are set in the constructor as immutable values. The source is verified on Sourcify, and the security page lists the addresses and the 91 public tests.
It has costs. 0xKeep has not been audited by a third party. An internal review found no critical, high, medium or low issues, but an internal review is not an independent audit. It cannot be patched either: if a bug turned up, the fix would be a new deployment, and existing locks would stay on the old contract. It also locks only ERC-20 tokens, which covers Uniswap v2 and Aerodrome classic LP tokens but not NFT positions such as Uniswap v3.
An owner-free design also does not protect you from everything. A lock does not stop a team from selling its own tokens, from minting new supply, or from holding most of the supply in a few wallets. It answers one question: can the liquidity be pulled before the date. For the others, see what a liquidity lock does and does not cover.
What founders and buyers can take from DxSale
If you are a founder with an old lock, find out who controls the locker’s owner role today. If the answer is a single wallet, check whether the locker offers a way to move your LP somewhere else once the date passes, and plan for it. If you are about to buy a token, the lock certificate is only the first of two checks. The second is the locker’s own contract.
The immutable contracts post explains why 0xKeep treats this as a design rule instead of a feature.