On October 29, $6.3 billion was drained from Binance's hot wallets. According to Binance, an attacker compromised a DevOps engineer’s laptop, gaining access to internal services and initiating withdrawals via those services; there is no evidence of private key exposure.

In other words, the attacker likely didn’t need private keys at all—instead, they tricked Binance’s own signing system into authorizing withdrawals. Binance later discovered additional attack vectors, but a full post-mortem has not yet been released. $3 billion has been frozen, and Binance has committed to covering losses.

On Ethereum, TRM reported that the attacker exploited Binance’s signing system to approve an EIP-7702 delegation, transferring control of a hot wallet to an attacker-controlled contract. Researchers believe the signing system only blocks known malicious actions rather than operating as a whitelist of approved actions, allowing this newer authorization method to slip through. Binance has not confirmed this detail, nor does it explain losses on Bitcoin, Solana, or Tron.

A month prior, Bitget suffered over $350 million in losses via a similar mechanism: attackers infiltrated the backend system responsible for feeding transaction data to the signer, enabling withdrawals with valid signatures to exit.

If an exchange’s system can move your funds, gaining access to the system is sufficient. Perpetual DEXs have long claimed their mechanisms inherently avoid such risks. I examined four platforms, analyzing the same three questions: Where are your funds? Who can move them? And if the team disappears or gets compromised, can you still exit?

Answers come from on-chain data, verified smart contract code, team documentation and posts, and @l2beat; event history draws from public reports. This is neither an audit nor a vulnerability hunt. I only assessed one scenario: If the team’s systems and keys were breached like Binance’s, what could an attacker do with them, and can you still recover your funds?

I’m not claiming these protocols have vulnerabilities or will be hacked. Off-chain safeguards like MPC wallets, signature policies, and monitoring are invisible from outside and may significantly raise the barrier to exploitation. Thus, what follows describes what the contracts permit—not predictions.

Lighter: Server breach won’t touch your balance

Lighter holds approximately $1 billion in Ethereum-based contracts: $556 million in USDC, $430 million in LIT (151 million tokens), plus ETH and minor assets.

Under normal operation, funds can only exit via batches validated by ZK proofs. Standard withdrawals go only to the account owner’s wallet, which is fixed at first deposit. Faster withdrawals or transfers to other accounts require your wallet’s signature. Therefore, regardless of who controls Lighter’s sequencer, prover, or validator keys, no single entity can withdraw your balance alone.

You don’t have to wait. You can initiate a forced withdrawal directly on Ethereum; if Lighter fails to process it within 14 days, anyone can trigger “desert mode.” The upgrade stops, and everyone exits using ZK balance proofs based on existing Ethereum data.

But it’s not fully trustless.

Prices are provided by Lighter’s operators—their index price and mark price—and the proof does not validate oracle signatures. Price inaccuracies may lead to unfair liquidations; L2BEAT has also flagged this risk.

Additionally, two guardian keys exist to pause batch processing and withdrawals. One allows up to 24 hours of suspension, the other up to 72 hours, with cooling periods required between uses. However, neither can block “desert mode”: if no one processes a forced withdrawal within 14 days, the contract still enters a full exit state.

Upgrades follow a separate process. Normally, a 3/5 multisig must publicly announce upgrades on Ethereum at least 21 days in advance, giving users time to review changes. But if a second 4/7 security committee signs, this 21-day notice can be entirely skipped, and the upgrade takes effect immediately. To date, every Lighter upgrade has used this fast lane. In October alone, the proof verifier was replaced five times. As the proof verifier is the contract component validating ZK withdrawal proofs, frequent replacements mean “how quickly code can be changed” is not just theoretical risk.

Historically, during the crash on October 10, 2025, the system experienced ~4.5 hours of downtime. After LIT launched at the end of December 2025, withdrawal delays occurred. On October 17, 2026, a 2-hour guardian pause happened—L2BEAT treated it as a test. On October 20 and October 29, each saw ~4.5 hours of status update interruptions, both resolved after fast-track verifier upgrades. No public reports indicate loss of custodied funds.

My assessment: Among the four, only Lighter withstands a Binance-style server breach—attackers inside the server cannot extract balances without external cooperation. The cost is that prices are set by the operator, and multisig can rapidly change code. What you truly must trust are these two things.

Hyperliquid: Most USDC locked in Coinbase single-key and proprietary chain

Hyperliquid has $6.5 billion in USDC backing, distributed across three locations.

The Coinbase wallet is a standard address with a single private key. Thus, 86% of the USDC’s safety depends entirely on how Coinbase secures that key—a fact invisible on-chain. Hyperliquid’s chain can bypass Coinbase’s private key entirely, using a non-signature system to transfer USDC between the Coinbase wallet and Circle’s contract, maintaining a roughly 9:1 balance ratio—meaning the Coinbase wallet holds about nine times more USDC than the Circle contract.

Coinbase has staked 506,000 HYPE (~$46 million) for this role. This stake is only forfeited if the wallet fails to pay its protocol revenue share, and represents less than 1% of the total balance—far from a meaningful endorsement of the wallet.

The Circle contract is upgradable, with a single admin address. Hyperliquid’s chain can also directly move USDC out. On the Arbitrum bridge, any three of four validators can authorize disbursement, with a 200-second window before release to intercept.

Circle provides the safety net. It can freeze native USDC—Binance’s stolen $823 million USDC was frozen before transfer. Freezing stops theft but locks funds until someone intervenes.

There are 27 active validators on-chain. Hyper Foundation runs 5 of them, accounting for 47% of staking. The top three collectively exceed one-third; if they go offline, the chain stalls. All run Hyperliquid’s closed-source node software, the only implementation, distributed as a binary signed by Hyper Foundation’s keys.

BTC, ETH, and SOL enter via independent protocol Unit, so your spot holdings on Hyperliquid are Unit tokens (UBTC, UETH, USOL). Unit holds $940 million across 14 assets, with $690 million in BTC, ETH, and SOL. According to documentation, three guardians (Unit, Hyperliquid, Infinite Field) control these vaults, requiring two of three signatures per withdrawal—without them, redemption is impossible. After the Binance incident, Unit added delays to all deposits and withdrawals.

After the JELLY squeeze in March 2025 and exposure of Hyperliquid’s own liquidity vault, validators voted to delist the market and settled at self-selected prices. The Arbitrum bridge has been emergency-paused multiple times, most recently in November 2025; each lasted hours, then reopened—no bridge funds were lost.

My assessment: The safety of most USDC hinges solely on Coinbase’s custody and Hyperliquid’s chain; Circle freezing serves as the fallback. The chain itself relies heavily on a validator set favoring Hyper Foundation, running closed-source software.

Aster: Custody with on-chain speed limits

Aster holds approximately $500 million across BNB Chain, Ethereum, Arbitrum, and Solana vaults, including $100 million in USDF. This doesn’t include another $1 billion in ASTER and APX held in BNB Chain vaults.

Vault funds are pooled, with ownership records maintained on Aster Chain—currently operated exclusively by Aster’s own validators.

Each withdrawal from EVM vaults must be initiated by Aster’s operational address and signed by two Aster keys. You also sign withdrawal requests, but the verified code only compares your signature to the address provided by the Aster keys—thus, it confirms you initiated a request, but offers no protection to the pool.

This presents the same custody risk as Binance: if Aster’s keys or backend are compromised, funds can be withdrawn. Each EVM vault has an hourly withdrawal cap: $30 million on BNB Chain and Ethereum, $20 million on Arbitrum; once hit, the vault pauses.

Users cannot bypass Aster’s own withdrawal process. The verified EVM vault contract contains no function allowing users to initiate withdrawals independently.

EVM vault upgrades use a 4/7 multisig with a 6-hour timelock, but the same multisig can instantly change roles and caps. Solana programs are upgraded instantly via a 3/6 multisig.

Caps have been triggered multiple times—in December 2024, September 2025, and July 2026—leading to vault pauses due to over-withdrawal. After each, the multisig raised the cap. In September 2025, incorrect XPL market pricing caused traders to be liquidated; Aster compensated within hours. In October 2025, DeFiLlama delisted Aster’s perpetual trading volume due to high similarity to Binance, and Aster couldn’t provide order-level data. Its predecessor, ApolloX, lost $2 million in native tokens in 2022 due to a vulnerability.

My assessment: Fundamentally, this remains a custody model. Funds sit in Aster’s vaults, withdrawals initiated by Aster’s operations team and signed by two Aster keys; your signature only proves you requested a withdrawal, not pool protection. Hourly caps on-chain do slow down fund extraction—but they’re speed limits, not permission controls. And the same 4/7 multisig can both set caps and instantly increase them—so the brakes can always be released. Ultimately, fund safety depends on how well Aster guards its two keys and its backend system.

Variational: Contract design most permissive

Variational holds $290 million in USDC on Arbitrum: $223 million distributed across 208,000 user settlement pools (trader and market maker margins combined), $54 million in market maker OLP addresses, and $12 million in treasury.

You can deposit into pools, but cannot withdraw. Each withdrawal is initiated by one of 17 operational keys—16 of which are standard wallets. Any one can transfer USDC from any pool, and the contract imposes no amount limit.

A function directly sends USDC to the caller’s wallet in a single transaction, capable of batching multiple pools; theoretically, a single key could empty all pools in minutes. The administrator is also a standard wallet, with actions taking effect instantly: adding keys, switching pools to another oracle contract, or pausing all withdrawals. Documentation claims the OLP vault is a smart contract, but the listed address has no code.

Variational uses Fireblocks for contract deployment and oracle signing, but details on which keys are covered or approval rules are not public. If behind these keys lies a multisig threshold or cap, it’s invisible on-chain.

Users also lack an off-team exit path. Once the backend halts, withdrawal requests go unprocessed; the admin can also directly pause the oracle, freezing the withdrawal flow. In both cases, the contract contains no backup withdrawal route or forced exit function—users cannot retrieve funds independently of the team.

No reports of hacks, theft, or withdrawal pauses have surfaced historically. After the Binance incident, Variational stated user funds are safe on-chain and can be withdrawn anytime—both statements are true, as long as the backend continues signing. External safety nets include Circle freezing USDC or Arbitrum’s Security Council intervention—both were activated after the Binance event.

My assessment: Looking only at verified contracts, Variational has the largest risk exposure. Any of the 17 operational keys can transfer USDC from any user pool, with no amount cap. Compromise of a single key is enough to empty the pools. The only potential check is the admin pausing the oracle or removing keys—but the admin is a single wallet with instant, un-timed, and un-multisigged actions. This is more post-incident damage control than pre-emptive defense. Like Aster, ultimate fund safety depends on the integrity of those keys and backend systems.

Four platforms compared side-by-side

Among the four, only Lighter enables you to exit without relying on the team.

Who is safest?

Answering the three questions above—based solely on on-chain verifiable information:

Lighter is the most secure by design. Breaching its server is insufficient to extract your balance; even if the team vanishes, you can still use forced withdrawals and desert mode. However, the operator sets prices, and bad prices can still liquidate you. A total of 7 votes—3 from the 3/5 multisig and 4 from the 4/7 security committee—can change code without notice; every upgrade so far has used this path.

Hyperliquid sits in the middle. 86% of USDC resides in a single-key Coinbase wallet—Coinbase’s key and Hyperliquid’s chain can both move it; Circle freezing acts as the fallback.

Aster matches Hyperliquid. EVM withdrawals are initiated by Aster’s operations team and signed by two Aster keys. Hourly caps slow down fund extraction, but the 4/7 multisig can instantly raise the cap.

Variational’s contract design is the most permissive. Any of 17 operational keys can move USDC from any user pool, with no cap. Circle freezing again serves as the fallback.

How to use this checklist

Whether DEX or CEX, keep only the funds you’re actively trading in your exchange.

Before scaling up, perform two checks. First, where are your funds actually held: locked in on-chain contracts, or sitting in a team-controlled wallet, exchange custody account, or cross-chain bridge? If in a contract, who has permission to move them—single key, multisig, or like Lighter, only via ZK proof validation? Second, can you exit without the team? Does the contract include forced withdrawals, escape routes, or timelocks, or do you rely entirely on the operator’s signature for every withdrawal?

Don’t treat the “DEX” label as a safety guarantee. Perpetual DEXs may offer frontend decentralization and on-chain trading, but funds may still be controlled by team keys, operational addresses, or multisigs—Aster and Variational are examples. Labels don’t reveal who controls withdrawal rights; only contract permissions and exit paths do.

Written by: 0xJaehaerys, Compiled by: AididiaoJP, Foresight News