On Oct. 29, Binance lost $6.3 billion from a hot wallet. Binance said a DevOps engineer’s laptop was compromised, which gave the attacker access to internal services. Withdrawals were then sent from those internal systems, and Binance said there was no sign that private keys had been exposed.
Put plainly, the attacker likely did not need the private keys at all. The exchange’s own systems may have been used to sign the withdrawals. Binance later said it had found additional points of compromise, though a full post-mortem has not been released. It also said $3 billion had been frozen and that it would cover the losses.
On Ethereum, TRM said the attacker got Binance’s signing system to approve an EIP-7702 delegation that handed control of one hot wallet to an attacker-controlled contract. Researchers cited in the piece said the signing system may have been screening against a list of known bad actions instead of allowing only known good actions, which would have let a newer authorization pattern slip through. Binance has not confirmed that detail, and the explanation does not account for losses on Bitcoin, Solana, and Tron.
A month earlier, Bitget lost more than $350 million in a similar way. In that case, the attacker got into a backend system that fed transaction data to the signer, and withdrawals left with valid signatures.
That setup frames the comparison in this article. The author looks at four perpetual DEXs and asks three questions: where the money actually sits, who can move it, and whether users can still get out if the team disappears or its systems are hacked. The analysis draws on on-chain reads, verified contract code, team documents and posts, plus material from @l2beat. Historical incidents are taken from public reports. The author says this is not an audit and not a vulnerability hunt. It examines one scenario only: if a team’s systems and keys were compromised in a Binance-style breach, what could an attacker do, and could users still recover funds?
The piece also makes a narrow claim. It does not say these protocols have vulnerabilities or will be hacked. Off-chain protections such as MPC wallets, signing policies, and monitoring are not visible from the outside and may make these scenarios much harder in practice. What follows is about what the contracts allow, not a prediction.
Lighter: a server compromise still does not let an attacker drain balances
Lighter holds about $1 billion in Ethereum contracts, including $556 million in USDC, $430 million in LIT, equal to 151 million tokens, plus some ETH and smaller residual assets.
Under normal operation, funds can leave only through batches validated by ZK proofs under the contract rules. Standard withdrawals can go only to the account owner’s wallet, and that destination is fixed at the first deposit. Faster withdrawals and transfers to another account also require the user’s wallet signature. Under that design, even someone who controls Lighter’s sequencer, prover, or validator keys cannot unilaterally withdraw user balances.
Users are not forced to wait on the team either. They can initiate a forced withdrawal directly on Ethereum. If Lighter does not process it within 14 days, anyone can switch the contracts into what the article calls "desert mode." At that point, upgrades stop and all users can exit with ZK balance proofs built from data already available on Ethereum.
Still, the model is not trustless in every respect. Prices come from operator-supplied index and mark prices, and the proof system does not verify oracle signatures. A bad price could lead to unfair liquidations. L2BEAT has flagged the same issue.
Lighter also has two guardian keys that can pause batch processing and withdrawals. One can pause for up to 24 hours at a time, the other for up to 72 hours, and each use is followed by a cooldown before it can be used again. Even so, neither key can block desert mode. If a forced withdrawal goes unprocessed for 14 days, the contract can still move into a full exit state.
Upgrades follow a separate path. In the ordinary flow, a 3-of-5 multisig must post a 21-day notice on Ethereum so users can review the changes. But if a separate 4-of-7 security council also signs, that notice can be skipped and the upgrade takes effect at once. The author says every Lighter upgrade so far has used that fast lane. In October alone, the proof verifier was replaced five times. Since the verifier is the contract component that checks ZK withdrawal proofs, those repeated swaps show how quickly the code can change in practice.
The historical record cited in the article includes a roughly 4.5-hour outage during the Oct. 10, 2025 crash, withdrawal delays after LIT launched in late December 2025, a two-hour guardian pause on Oct. 17, 2026 that L2BEAT treated as a test, and two separate state update interruptions of about 4.5 hours on Oct. 20 and Oct. 29, both ending after fast-track verifier upgrades. No public report says custodial funds were lost.
The author’s conclusion is blunt: among the four, only Lighter can withstand a Binance-style server compromise in design terms. An attacker who gets into the servers still cannot drain balances with server access alone. The tradeoff is that the operator controls pricing, and the multisig structure can change code quickly.
Hyperliquid: most USDC depends on a Coinbase single-key wallet and the chain itself
Hyperliquid has $6.5 billion in USDC backing spread across three locations:
- about $5.6 billion, or 86%, in a Coinbase-owned USDC reserve wallet on HyperEVM;
- about $622 million, or 10%, in Circle’s CoreDepositWallet contract;
- about $290 million, or 4.4%, still on the legacy Arbitrum bridge.
That Coinbase wallet is a standard address controlled by a single private key. In other words, the safety of 86% of the USDC depends on how Coinbase protects that key, and that is not something on-chain data can show. At the same time, the Hyperliquid chain can move USDC between the Coinbase wallet and the Circle contract through system transactions that do not require a signature, keeping the balances near a 9:1 ratio, with the Coinbase wallet holding roughly nine times as much USDC as the Circle contract.
Coinbase has staked 506,000 HYPE, worth about $46 million, for that role. The article notes that the stake can be slashed only if the wallet fails to pay the protocol’s revenue share, and it amounts to less than 1% of the relevant balance. The author does not treat that as meaningful backing for wallet safety.
The Circle contract is upgradeable and has a single-address administrator. The Hyperliquid chain can also move USDC out directly. On the Arbitrum bridge, 3 of 4 validators can release funds, with a 200-second interception window before release.
The final backstop is Circle. It can freeze native USDC, and the article points to $823 million in stolen Binance USDC that was frozen before it could be moved. A freeze can stop a thief, but the funds remain stuck until someone resolves the situation.
At the chain level, Hyperliquid has 27 active validators. Five run by the Hyper Foundation account for 47% of stake. The top three together control more than one-third, enough to stall the chain if they go offline. All of them run Hyperliquid’s closed-source node software, the only implementation, distributed as binaries signed with Hyper Foundation keys.
BTC, ETH, and SOL enter through a separate protocol called Unit, so spot holdings on Hyperliquid are actually Unit tokens: UBTC, UETH, and USOL. Unit holds $940 million across 14 assets, including $690 million in BTC, ETH, and SOL. According to its documentation, three guardians — Unit, Hyperliquid, and Infinite Field — control those vaults, and each withdrawal needs signatures from any two of the three. Without them, redemption is not possible. After the Binance incident, Unit added delays to all deposits and withdrawals.
The article also cites a March 2025 JELLY squeeze, after which validators voted to delist the market and settle it at a chosen price once Hyperliquid’s own liquidity vault was exposed. The Arbitrum bridge has been paused in emergencies several times, most recently in November 2025. Each time it reopened within hours, and no bridge funds were reported lost.
The author places Hyperliquid in the middle of the pack. Most of its USDC security rests on Coinbase custody and the Hyperliquid chain, while Circle’s freeze authority serves as the backstop. The validator set, in the author’s view, is also tilted toward the Hyper Foundation and runs closed-source software.
Aster: custody with on-chain speed limits
Aster holds about $500 million in vaults on BNB Chain, Ethereum, Arbitrum, and Solana, including $100 million in USDF. That figure does not include $1 billion in ASTER and APX sitting in a BNB Chain vault.
Funds are pooled in those vaults, while user balances are recorded on Aster Chain. For now, that chain is run only by Aster’s own validators.
On the EVM side, every withdrawal must be sent by an Aster operating address and approved by two Aster keys. Users also sign withdrawal requests, but the verified code only compares the user signature against the address supplied by Aster’s keys. That proves the user requested a withdrawal. It does not protect the pool itself.
The author treats that as the same class of custodial risk seen in the Binance case. If Aster’s keys or backend are compromised, funds can leave the vaults. Each EVM vault has an hourly withdrawal cap. The latest figures listed are:
- BNB Chain: $10 million
- Ethereum: $6 million
- Arbitrum: $3 million
- Solana: $1 million
Users cannot bypass Aster and withdraw on their own. The verified EVM vault contracts do not include a function that lets users initiate withdrawals directly.
For upgrades, the EVM vaults use a 4-of-7 multisig with a 24-hour timelock, but that same multisig can instantly change roles and limits. The Solana program can be upgraded immediately by a 3-of-6 multisig.
The article says the withdrawal caps were hit multiple times in December 2024, September 2025, and July 2026, causing vault pauses before the multisig raised the limits. In September 2025, a pricing error in the XPL market liquidated traders and Aster compensated them within hours. In October 2025, DefiLlama removed Aster perpetuals volume because it closely resembled Binance and Aster could not provide order-level data. ApolloX, its predecessor, lost $2 million in its own token in a 2022 exploit.
The author’s view is that Aster remains a custodial model at its core. Funds sit in Aster-controlled vaults, withdrawals are initiated by the operator, and two Aster keys approve them. The user signature only proves "I asked to withdraw." It does not defend the pool. The hourly caps can slow a drain, but they are speed limits, not permission limits. And because the same 4-of-7 multisig can raise those limits or change roles immediately, the brake can be released at any time. In the end, the safety of funds depends on how Aster protects those keys and its backend systems.
Variational: the least defended contract design of the four
Variational holds $290 million in USDC on Arbitrum. Of that, $223 million is spread across 208,000 user settlement pools where trader and market-maker margin is commingled, $54 million sits at a market-maker OLP address, and $12 million is in treasury.
Users can deposit into the pools on their own, but they cannot withdraw on their own. Every withdrawal is sent by one of 17 operating keys, 16 of which are standard wallets. Any one of those keys can move USDC out of any pool, and the contracts impose no amount cap.
One function can send USDC directly to the wallet behind the calling key and can process multiple pools in a single transaction. In theory, the author says, a single key could empty all pools within minutes. The administrator is also a standard wallet, with actions taking effect immediately. That wallet can add keys, switch pools to another oracle contract, and pause all withdrawals. The documentation says the OLP vault is a smart contract, but the address listed there has no code.
Variational uses Fireblocks for contract deployment and oracle signing, but it does not disclose which keys are covered or what approval rules apply. If there are multisig thresholds or limits behind those keys, they are not visible on-chain.
Users also have no exit path that works without the team. If the backend stops, withdrawal requests stop being processed. The administrator can also pause the oracle directly, which blocks the withdrawal flow. In either case, the contracts do not provide a backup withdrawal route or a forced exit function, so users cannot bypass the team and retrieve funds themselves.
No public report cited in the article shows a hack, theft, or withdrawal pause in Variational’s history. After the Binance incident, Variational said user funds were safe in on-chain contracts and could be withdrawn at any time. The author says both statements are true only as long as the backend keeps signing. The external backstops are Circle freezing USDC or the Arbitrum security council stepping in, and both acted after the Binance incident.
The author ranks Variational as the widest on-chain exposure among the four. Looking only at verified contracts, any one of the 17 operating keys can move USDC out of any user pool with no amount limit. One compromised key would be enough to drain the pools. The only contract-level response is for the administrator to pause the oracle or remove keys, but that administrator is itself a single wallet with immediate powers, no timelock, and no multisig threshold. The article describes that as damage control after the fact, not a preventive defense. As with Aster, fund safety ultimately depends on the keys and the backend.
Cross-comparison: only Lighter lets users exit without the team
The article’s broad conclusion is simple. Of the four, only Lighter gives users a way out that does not rely on the team.
Using the three questions above and looking only at what can be verified on-chain, the author’s ranking is:
- Lighter: the strongest design in this group. A server compromise is not enough to drain balances, and users still have forced withdrawals and desert mode if the team disappears. But the operator controls pricing, and code can be changed without notice if 3 of 5 multisig signers and 4 of 7 security council members approve it. The article says every upgrade so far has used that route.
- Hyperliquid: in the middle. Eighty-six percent of USDC sits in a single-key Coinbase wallet, and both Coinbase’s key and the Hyperliquid chain can move it. Circle freeze powers are the backstop.
- Aster: in the same tier as Hyperliquid. EVM withdrawals are initiated by the operator and approved by two Aster keys. Hourly caps can slow a drain, but the 4-of-7 multisig can raise those caps at any time.
- Variational: the least defended contract design. Any one of 17 operating keys can move USDC out of any user pool, and there is no amount cap. Circle freezes are again only a backstop.
How the author says users should read this list
The practical takeaway is narrow and direct: whether the venue is a DEX or a CEX, keep only trading capital on an exchange.
Before sizing up, the article suggests two checks. First, where does the money actually sit? Is it locked in an on-chain contract, or is it sitting in a team-controlled wallet, a custodial exchange account, or a bridge? If it is in a contract, who can move it — a single key, a multisig, or a proof-gated system like Lighter’s? Second, can users leave without the team? Does the contract include forced withdrawals, an escape hatch, or a timelock, or does every withdrawal depend on an operator signature?
The final warning is that the word "DEX" is not a safety guarantee. A perpetual DEX can have a decentralized front end and on-chain trading while user funds are still controlled by team keys, operating addresses, or multisigs. The article points to Aster and Variational as examples. The label does not tell users who holds withdrawal power. Contract permissions and exit paths do.
