Binance Hot Wallet Exploit: Aave's Response

Risk
1

Last updated 01:00 UTC, 30 October 2026.

What happened

At 20:24 UTC on 29 October 2026, a Binance hot wallet on Ethereum sent about 63 tokens and 167,464 ETH to a single address in one transaction. The same exploiter address received a further 28,006 ETH from a second Binance hot wallet on Ethereum, and funds on Arbitrum, Optimism and Avalanche within the following minutes. A second inflow of 444,537 AVAX on Avalanche at 23:04 UTC suggests the compromise was still active more than two hours later.

The exploiter has since spread the funds across more than 20 new wallets and is selling tokens such as UNI, LINK and AAVE for ETH on decentralised exchanges.

Between 20:58 and 21:01 UTC, one wallet in the exploiter’s cluster supplied 60M USDT on Aave V3 Ethereum Core and borrowed 19,762 WETH, worth about $44.6M at the time. This happened about 40 minutes before the first freeze at 21:42, and no exploiter wallet has interacted with Aave since 21:01. It is the exploiter’s only position on Aave across all networks and versions. The position holds $59.9M of USDT collateral against $43.8M of debt, so it is over-collateralised and remains subject to normal liquidation. It does not put Aave suppliers at risk.

What we did

Within 10 minutes of the first reports we joined Aave Labs, TokenLogic, and Certora in a joint war room. The group decided to freeze Aave markets across all networks. The exploiter could swap the stolen funds into any listed asset, so freezing only the stolen token reserves would have left other ways in. We chose a freeze because the guardian can reverse it, while cutting caps instead would have needed a governance vote and about five days to restore.

A freeze stops anyone, including the exploiter, from opening new supply or borrow positions. Users can still repay and withdraw, and liquidations keep running. Because frozen reserves take no new supply, users cannot add collateral, so while the freeze is on, repaying is the only way to raise a health factor.

Together with Aave Labs’ engineering team, we prepared and simulated the freeze transactions for every network and proposed them to the guardian multisigs, which signed and executed them between 21:42 and 23:04 UTC. In total, 175 reserves were frozen on Aave V3 across 16 networks and 117 on Aave V4 across four networks. The freeze now covers:

  • Aave V3 on the Ethereum Core and Prime markets and on Arbitrum, Avalanche, Base, BNB Chain, Celo, Gnosis, Ink, Linea, Mantle, MegaETH, Monad, Optimism, Plasma, Polygon and X Layer.
  • Aave V4 on the main Ethereum spokes, the Avalanche spokes, the Base tokenized equities spoke and the Arc spokes.

The Horizon RWA market was left open because all of its collateral is permissioned and cannot be used by the exploiter. No market has been paused.

We also track the exploiter in real time. We follow every wallet in its cluster on Ethereum, Arbitrum, Optimism and Avalanche, watch for any interaction with Aave, and monitor the Chainlink price feeds that Aave relies on.

Market impact

Oracle feeds have worked normally throughout. As of 00:55 UTC, ETH and BTC are down about 4% since the drain. Governance tokens the exploiter holds have fallen further, with AAVE and LINK down about 9%, UNI about 8% and ARB about 6%. The freeze prevents the exploiter from depositing any of these tokens on Aave. Existing positions backed by them remain healthy, and we are watching them for liquidations as the selling continues.

Stablecoins have held their pegs. GHO slipped from about $0.998 before the drain to $0.997 as holders redeemed about 4.6M GHO for USDT through the GHO Stability Module between 21:49 and 22:07, and it has stayed near that level since.

Next steps

The situation is still developing. We will keep monitoring the exploiter’s wallets and the affected price feeds and will share updates as they come. Markets will stay frozen until the exploiter’s funds stop moving and we get more clarity on the containment from Binance’s side. We will then work with Aave Labs and the other service providers on a staged unfreeze. A long freeze also affects utilisation. Frozen reserves take no new supply, so withdrawals by large suppliers raise utilisation and borrow rates, and only repayments pull them back down. We are watching utilisation on the frozen reserves, and will evaluate the order of the unfreeze.

5 Likes
2

Unfortunately, after the Kelp incident, the team failed to take any measures to prevent such large-scale on-chain hacks. AAVE still lacks a flow limit mechanism like Fluid. This suggests that one day, AAVE’s ultimate fate will be that a hacker, after stealing assets elsewhere, will use AAVE as an ATM, causing its complete demise, even if AAVE itself did nothing wrong.

2 Likes
3

Yes, I proposed this [TEMP CHECK] Automated Supply Cap Updater – Restricting Short-Term Supply Increases in Aave V3 for example and it was ignored.

Now they have to freeze the markets…

4

Imagine if Binance’s entire $6 billion in assets had been deposited into AAVE—what would the consequences be? Would a war room still be needed? No, because aave would be dead.

Your suggestion is excellent, but unfortunately they’re ignoring it. They haven’t realized that in the current DeFi space, simply ensuring your own security is useless. When others experience security vulnerabilities, AAVE becomes the perfect ATM, because it has a massive pool of funds and unlimited, uncontrolled liquidity.

2 Likes
5

This is probably an overreaction. 60 million isn’t anywhere close enough to effect Aave’s stability. Aave obviously completely trusts Circle, Tether, etc so this is their problem, following the rules of crypto/defi if they were too slow to issue an erc20.burn() on the exploiter’s addresses, that’s on them and the exploiter followed all defi rules/protocol and their borrow was valid. Hyperliquid continues as normal and they have similar TVL as Aave and just as much, if not more, USDC exposure. High probability that these hacks will continue happening, if your solution is shutdown, freeze, scare everyone into withdrawing, etc every few months then aave, especially aavev3, centralized model is inferior to morpho.

6

Proposal for Aave: Large Deposit Cooldowns and Sybil-Resistant Borrowing Limits

Aave should introduce stricter risk controls for large collateral deposits, particularly those exceeding $10 million USD.

1. Define large deposits clearly

Any address depositing more than $10 million in collateral, cumulatively within a rolling 7-day window, should trigger enhanced borrowing restrictions.

2. Gradually unlock borrowing capacity

For large deposits, newly generated borrowing power should be released according to the following schedule:

  • First 24 hours: 0% available

  • After 24 hours: 25% available

  • After 48 hours: 50% available

  • After 72 hours: 75% available

  • After 96 hours: 100% available

Each deposit should have its own unlocking schedule.

3. Prevent Sybil attacks through multiple wallets

A per-wallet threshold alone is insufficient. Attackers could easily split $100 million across 20 wallets, each depositing $5 million, to bypass the restrictions.

To prevent this, Aave should implement:

  • Protocol-level rate limits: Cap aggregate new borrowing volume across all addresses within rolling time windows, regardless of wallet count.

  • Asset-level monitoring: Track cumulative deposits and borrowing activity across the entire market, rather than relying solely on individual wallets.

  • Collateral activation limits: Apply baseline restrictions to newly deposited collateral regardless of deposit size, with stricter requirements above $10 million.

  • Dynamic risk controls: Automatically tighten borrowing limits when large inflows, abnormal borrowing activity, or liquidity stress are detected.

The key principle is simple: Splitting one large deposit into hundreds of smaller wallets must not bypass borrowing restrictions.

Rate limiting must be enforced at the protocol and asset levels, not just the wallet level.

Aave needs proactive risk management, not another preventable crisis.

1 Like
8

Imagine a hacker depositing $6 billion in stolen USDT into Aave and immediately borrowing as much ETH and other assets as possible.

Tether could then blacklist the contract holding Aave’s pooled USDT, potentially freezing innocent depositors’ funds alongside the stolen assets.

Meanwhile, Binance and other claimants could pursue legal action over ownership of those funds, just like the April rsETH incident, where a $71 million recovery became entangled in a New York court dispute.

Now Aave faces frozen liquidity, competing ownership claims, prolonged litigation, and potentially years of uncertainty. Even if every loan was valid under DeFi rules, Aave cannot force Tether to unfreeze the USDT or courts to resolve the dispute.

That’s the terrifying part: Aave loses control of its own fate. A protocol handling billions cannot afford to rely entirely on the decisions of centralized issuers and courts.

2 Likes
9

What I proposed can be implemented without changes to the core protocol. It’s an overreaction because it was just 60 million, but if it were 600 or 6000?

10

I’m not aware of a single instance in defi history where Circle or Tether has done blanket freezes by issuing erc20.burn() on contract/protocol addresses vs individual EOAs. That isn’t going to happen.

We can “imagine” all we want, what actually happened was a mere 60 million deposit. Thor faced nearly this exact same situation a month ago for ~350 million from bitget hack IIRC, they continued operations as normal despite pleas to shutdown, and guess what happened? Nothing. That was bitget’s problem, not theirs.

“Now Aave faces frozen liquidity, competing ownership claims, prolonged litigation, and potentially years of uncertainty. Even if every loan was valid under DeFi rules, Aave cannot force Tether to unfreeze the USDT or courts to resolve the dispute.”

Along those lines, Perhaps Aave should implement KYC also, you know, just to be safe? We could get a nice opensource facescan implemented in aave’s ABI, people would love that → right before you call approve()/supply() you call verifyAaveV3FacescanBytes();

It’s simple, we trust in the code, and nothing else. Yes, by that “law” aave has every right to arbitrarily halt everything, but if that’s the best solution they can come up with to mitigate this, liquidity providers are going to migrate to platforms where their hands are not forced like this.

11

We are very fortunate that $6B didn’t hit AAVE this time, but the headline people remember is “Binance hacker borrows $44M on Aave.” Every time Aave shows up next to an exploit, it hurts how institutions and partners see us. We don’t want to become the place hackers go to cash out.

There must be a solution and velocity limits on borrowing could be the simple fix.

It will act like the ATM daily limit. Cap how much of an asset can be borrowed market wide in a rolling window (for example: $10M WETH per 10 min). Once it’s hit, new borrows wait.

This time the exploiter pulled $44M WETH in about 3 minutes, and the freeze came 40 minutes later. With a cap, they’d have gotten a fraction of that and the Guardian would’ve had time to act.

Velocity limit is simple and predictable. No AI, no false positives, no new trusted keys. I am not suggesting this is the answer to the problem but we need a stronger safe guard.

1 Like
12

Should AAVE reconsider bringing back Chaos Labs?

Before their departure, Chaos Labs, AAVE’s primary risk management provider, cited deep disagreements over how risk should be handled and the growing complexity of the protocol’s next phase.

Food for thought.

13

So Aave will now play staring contest with Binance exploiter? Like waiting until exploiter’s wallet have nothing left to supply to Aave and then unfreeze markets?

14

You’re saying that the assets deposited into AAVE were legitimate, but were stolen. What if the deposited assets were illegitimate, worthless assets created out of thin air like rseth? I’m assuming a hacker could mint an unlimited amount of WBTC and the amount involved were $1 billion, do you think AAVE would still be alive? AAVE have died if it weren’t DeFi United. Adding a flow limit function can only have benefits, not drawbacks.

I just want to ask you one question: If a hacker created 1 billion WBTC out of thin air, deposited it into AAVE, and borrowed all the assets, what do you think the consequences would be?

1 Like
15

It’s very simple, Tether, Circle, etc are highly modified sources with the specific intent to control user funds, if a call to erc20.transfer() on USDC, USDT, etc emits a log/event indicating the transfer occurred, it is legit, period, end of story.

The implied reason behind maintaining source code functionality to do network wide pauses is to protect the integrity of the protocol. The AAVE protocol was never at risk yesterday, it functioned perfectly. This network wide pause occurred with the explicit intention of freezing a single user’s activity. Even still, the freeze did not occur in a timely fashion, AAVE was too slow to react, as usual.

Hacks will continue to happen, if your solution to mitigate that is to hide under your bed for a week or two several times per year, morpho’s model and even heaven forbid closed source hyperliquid, is superior, AAVE is making them look very good right now.

16

Rate limits are not intended to restrict legitimate users. Quite the opposite: limiting borrowing velocity can protect depositors’ assets from being rapidly drained.

I propose tying the borrowing limits generated by newly deposited collateral to Aave’s annualized protocol revenue. For example, the total borrowing attributable to new deposits within any rolling one-hour window should not exceed Aave’s annualized revenue.

This restriction should primarily apply to collateral deposited within the past 24 hours. Deposits that have remained in the protocol for longer can reasonably be considered lower-risk and should not be subject to these limits.

Withdrawals and repayments should remain completely unrestricted, and borrowing against long-established collateral should continue as normal.

In practice, this would affect only a small fraction of users, while significantly limiting an attacker’s ability to deposit massive amounts of stolen assets and immediately drain Aave’s liquidity.

The goal is not to limit DeFi activity, but to prevent newly introduced collateral from being used to drain billions in liquidity within minutes.

17

I have a proposal. It’s a highly technical cyber concept.

The 1st thing aave needs is people who can tell computers what to do, and even do this thing called “computer automation”. We’ll call these people “computer programmers”.

Are you keeping up with me? Yeah! Let’s go! Let’s keep that thought train toot tooting all the way to the next station!

AAVE needs to get probably 10 or 15 of these “computer programmers” and even more, AAVE needs to figure out a way to get them all, in the same place, at the same time, every weekday morning. That place, we’ll call that “an office”.

I know, it’s a crazy idea, but with 10 or 15 of these “computer programmers” going to this strange place called “an office” every morning, their job is to solve problems, they can do things like write scripts to monitor Binance’s pubically known hot wallets for unusual activity, which AAVE is obviously NOT currently doing, and properly react to these very predictable events.

https://cryptorank.io/price/aave/team → These look like a lot of useless eaters… go look at your colleagues at hyperliquid, arbitrum, etc how their teams look and you’ll notice a big difference…

18

Update, 13:49 UTC, 30 October 2026.

Risk Steward actions

While the markets were frozen, we executed two Risk Steward batches across Aave V3 and Aave V4.

The first batch lowered Slope2 on the largest stablecoin reserves, and on WETH on the Aave V4 Ethereum Core Hub, so that the borrow rate at full utilization does not exceed 10.00% APR. Supplier withdrawals during the freeze pushed these reserves to between 92% and 100% utilization. With new supply blocked, a high rate could not attract deposits and only added to borrower debt, therefore, these actions were executed to lower the interest rate pressure on the borrowers. These changes are temporary, and we will review the previous Slope2 settings once markets are back to normal.

The second batch reduced borrow caps and draw caps on the largest borrow paths to about 2% above the amount borrowed just before the exploit. This removes about $3.7B of unused borrow capacity on Aave V3 and $130M on Aave V4, which would otherwise have become available all at once when markets reopen. Every reserve can still return to its pre-exploit borrow size. The GHO borrow cap reductions on Aave V3 Core and Prime were queued with the GHO Stewards.

How the unfreeze proceeds

Together with Aave Labs and the other Aave service providers, we defined the market freeze rollback plan. The guardians will execute this plan in four waves.

  1. All Aave V3 reserves frozen during the incident are unfrozen, with LTV kept at 0 for now.
  2. On Aave V4, each keep-list reserve below receives a new collateral configuration with a collateral factor of 0, which applies to every new borrow against it. This wave has already been executed.
  3. LTV is restored on Aave V3 for the majority of the reserves.
  4. Aave V4 reserves are unfrozen. The keep-list reserves keep the collateral factor 0 configuration from the second wave, so after the unfreeze they still cannot back new borrows on Aave V4.

USDT, USDC, USDT0, POL, WAVAX, sAVAX, XAUt, PAXG and OP, including their bridged and wrapped versions, stay at LTV 0 on Aave V3 and at a collateral factor of 0 on Aave V4, on every market where they are listed. On Aave V3 this also applies to E-Mode. These are the assets held across the exploiter’s address cluster.

LTV 0 on Aave V3 and a collateral factor of 0 on Aave V4 only stop these assets from adding new borrowing power when used as collateral. Supplying, withdrawing, borrowing and repaying them works as normal. On Aave V3, existing positions that use them as collateral keep their liquidation thresholds, so health factors do not change. On Aave V4, existing positions stay on their current collateral configuration until a new borrow, a collateral withdrawal or a collateral toggle moves them to the configuration with a collateral factor of 0.

Next steps

We will evaluate the conditions under which LTV can be restored for the keep-list assets and share them in this thread. We continue to monitor the exploiter’s wallets, the reserves affected by the freeze and the Chainlink price feeds that Aave relies on.

1 Like