A continuation of “DeFi Exploited for Over $630 Million So Far in 2026”
In July, I wrote about the risks DeFi protocols inherit when core functionality relies on external systems. That article focuses primarily on oracle manipulation, keepers and offchain verifiers. Hooks were included, but they weren’t the center of it, mainly because the data didn’t exist, or I at least hadn’t come across it yet. Then 0x published an article titled “Uniswap v4 hooks were a mistake,” based on its analysis of 84,163 hooks across six chains.
Only 19.4% of hooks were classified as safe.
Data source: 0x, “Uniswap v4 hooks were a mistake”. Data as of September 11, 2026. | https://0x.org/post/uniswap-v4-hooks-were-a-mistake
TL;DR
DeFi hooks are external smart contracts that can add custom functionality to liquidity pools, including the ability to alter fees, pricing and execution behavior.
0x classified 54.2% of 84,163 analyzed hooks as malicious and another 26.4% as likely malicious. Some trades delivered as much as 50% less than the amount quoted.
Carbon DeFi provides native trading and liquidity strategies without hooks, oracles or keepers. Its orders can be discovered and filled using liquidity from major DEXs chainwide through a built-in solver.
What Are DeFi Hooks?
Hooks are external smart contracts attached to individual liquidity pools. They can run at defined points in a pool’s lifecycle, including before or after a swap and before or after liquidity is added or removed.
They give developers considerably more control over how a pool behaves.
Hooks have been promoted as a way to support functionality such as:
onchain limit orders
time-weighted execution
dynamic fees
custom pricing curves
customized onchain oracles
auto-compounding LP fees
lending integrations
alternative ways of distributing MEV revenue
The documentation for the hook framework explains that some permissions allow a hook to adjust balances. Custom accounting can consume the swap amount, bypass the pool’s standard concentrated-liquidity math and execute separate trading logic.
Once a pool uses a hook, its behavior is no longer defined by the core AMM alone.
The official hook security framework acknowledges the consequences. A hook logic can compromise pool accounting, misprice trades, alter fees, introduce reentrancy or expose liquidity providers to losses.
A hook may also call or depend on oracles, lending markets, bridges, other AMMs or offchain data sources. When it does, the pool inherits the failure modes of those systems as well.
How Can Malicious Hooks Manipulate a Trade?
Only 19.4% of the hooks analyzed by 0x were classified as safe as of September 11, 2026. According to the research, 54.2% were malicious and another 26.4% were likely malicious.
Some were designed to show aggregators one price during a quote request and produce another result when the trade settled.
0x observed users receiving as much as 50% less than the amount quoted.
A pool returns an attractive quote, giving an aggregator a reason to select it. When the transaction reaches settlement, the hook changes the economics through a fee or other execution logic. The route wins because the quote doesn’t describe what the user ultimately receives.
One hook analyzed by 0x was associated with an ETH/NVDAc pool on Base. It recorded 6,516 fills and charged 3,946 of them. The median fee on charged fills was 18%, producing more than $143,000 in fees.
Another hook associated with USDT/WBNB on BNB Chain recorded 4,879 fills. It charged 1,619 of them, with a median charged fee of 12.8%.
Selective charging makes the behavior harder to detect. A hook that applies the same fee to every trade leaves a consistent pattern. One that extracts value from every trade is quickly exposed. By charging only some fills, a malicious pool can build a history of apparently normal execution while still extracting substantial value from routed trades.
How Can a Hook Detect an Aggregator Simulation?
A separate onchain analysis shared by @Schlagonia documented a hook using the transaction’s remaining gas to distinguish simulations from ordinary wallet transactions.
The pool advertised a 0% LP fee. If more than four million gas remained when beforeSwap was called, the hook exempted the trade from its fee. Aggregators and solver bots commonly simulated or submitted transactions with limits between six million and 15 million gas, so they saw fee-free execution.
Transactions from ordinary wallets arrived with gas limits closer to expected usage. When the remaining gas fell below the threshold, the hook deducted a randomized 2.9%, 4.9% or 6.9% fee from the output after the swap.
The contract also maintained address-specific fee settings. Bots that identified the gas test could be assigned a fee directly, preventing them from simply increasing their gas allowance to receive the fee-free execution shown during simulation.
This exposes a difficult limitation of simulation. A router may be evaluating the behavior the hook shows during simulation, not necessarily how the hook will behave during execution.
A quote should describe the trade available to execute. Here, it functions as bait. The pool wins the route by showing one result, then applies different logic at settlement.
Why Do Hooks Require Continuous Screening?
0x shows what the architecture now requires. It uses static analysis, dynamic analysis and observations of settled trades to prevent malicious pools from entering its routes. It also argues that routers must verify quoted amounts against execution, while applications need controls for removing suspicious routes quickly.
The official security framework recommends specialized audits, invariant testing, bug bounties, continuous monitoring, anomaly detection and, for some hooks, formal verification. Higher-risk implementations may require monitoring for sudden fee increases, abnormal slippage and differences between expected and actual execution.
The result is a growing trust stack around an architecture described as permissionless. The user relies on the hook developer to write the code correctly, auditors to identify vulnerabilities, routers to detect deceptive behavior, aggregators to exclude malicious pools, applications to remove suspicious routes and monitoring systems to catch anything the earlier layers missed.
All of this just to determine whether the displayed quote describes the trade that will execute.
Calling a system trustless doesn’t make those assumptions disappear. Trust has shifted into a sequence of contracts and infrastructure providers, each expected to be competent, honest and functioning as intended.
As 0x put it:
“permissionless liquidity does not automatically mean trusted liquidity.”
Does Advanced Onchain Trading Require Hooks?
Many of the capabilities associated with hooks concern trading and liquidity management: onchain limit orders, automated execution, custom pricing, adjustable fees and auto-compounding liquidity positions.
These capabilities aren’t unique to hook-based architecture.
Bancor designed Carbon DeFi around programmable trading and liquidity from the beginning. Makers can create:
Limit Orders at an exact price
Range Orders that buy or sell progressively through a custom range
Recurring Orders with separate buy and sell curves and proceeds that rotate between them
Concentrated Liquidity with custom ranges and spreads
Full Range Liquidity from zero to infinity
Prices, ranges, budgets and strategy types remain adjustable onchain without requiring the maker to withdraw and rebuild the position.
Concentrated Liquidity natively auto-compounds, and makers keep 100% of the fees earned by their strategies.
Carbon provides these capabilities without arbitrary third-party logic. The maker defines the executable prices and curves, and those conditions are stored onchain and enforced by the protocol.
Anyone can take the other side of the order, but they can’t change its terms.
If the order fills, it follows the maker’s predefined settings.
Can Native Orders Access Chainwide Liquidity?
Part of the appeal of hooks is distribution. A builder can introduce custom trading behavior around liquidity on an established DEX rather than launch a separate venue and build liquidity from the ground up.
Carbon DeFi separates the trading functionality from the source of liquidity.
Carbon’s strategy types have zero third-party dependencies. No oracle, keeper or hook is required to create, maintain or enforce them. External liquidity can provide another path to execution, but it doesn’t define how the strategy behaves.
While anyone can fill an order or trade against a position, Carbon DeFi also has a dedicated solver system that acts as a de facto taker, searching major DEXs chainwide for opportunities to fill Carbon orders using liquidity available across the wider market.
Consider a maker selling a token through a Carbon Range Order. The maker defines the token pair, budget and price range in advance. Another trader can accept those terms directly. If the solver finds a profitable opportunity elsewhere, it can also trade against the order using liquidity from another DEX. What the solver finds elsewhere can determine whether an opportunity exists and whether the order is filled.
In both cases, the maker’s execution terms remain the same.
Carbon orders and liquidity strategies can therefore be discovered and filled using liquidity from major DEXs chainwide, without allowing those external venues to change the maker’s execution terms.
Can Dependency Risk Be Designed Out?
Some of it can.
Carbon DeFi doesn’t rely on hooks, oracles or keepers to define how trading behaves. Makers set their prices, ranges, budgets and direction, and the protocol enforces those terms natively.
This doesn’t eliminate smart contract risk, but it does remove additional contracts, permissions and externally deployed logic from the execution path.
Detection asks whether each new dependency is safe. Design asks whether that dependency needs to be there at all.
When the required behavior can be enforced natively, removing the external dependency is a more durable solution than continuously evaluating every new implementation that appears.
Sources and methodology: Hook classifications, fill data, fee figures and quoted-versus-settled execution findings are drawn from 0x’s analysis of 84,163 hooks across six chains. The classifications reflect 0x’s methodology and the dataset available as of September 11, 2026. The gas-based simulation example is drawn from the separate onchain analysis published by @Schlagonia.
Bancor
Bancor is a pioneer in decentralized finance (DeFi), established in 2016. It invented the core technologies underpinning the majority of today’s automated market makers (AMMs) and continues to develop the foundational infrastructure critical to DeFi’s success — focusing on enhanced liquidity mechanics and robust onchain market operation. All products of Bancor, including Carbon DeFi and the Arb Fast Lane, are governed by the Bancor DAO.
Carbon DeFi — Powered by Bancor’s latest patented technologies: Asymmetric Liquidity and Adjustable Bonding Curves.
Live on Ethereum, Sei, Celo, COTI, and TAC.
The Arb Fast Lane — Carbon DeFi’s built-in solver system and DeFi’s most advanced arbitrage infrastructure, powered by Marginal Price Optimization, a new method of optimal routing.
Website | MCP Server | Blog | X/Twitter | YouTube
