From manipulated price feeds to compromised crosschain verification, attackers are increasingly targeting third-party infrastructure — an attack surface DeFi has largely overlooked.
On July 22, an algorithmic stablecoin minted against Bitcoin-backed collateral collapsed by more than 99% following an oracle manipulation exploit, sending its price from near its $1 peg to approximately $0.0014.
The attacker fed the protocol a manipulated Bitcoin price, causing the system to believe that BTC’s value had fallen dramatically. This triggered liquidations of otherwise healthy collateral positions, enabling the attacker to seize assets and extract approximately $912,000.
The incident highlights one of DeFi’s biggest challenges: a protocol is only as secure as the external systems it depends on.
Third-party systems that supply data, initiate transactions, verify crosschain messages, or trigger critical actions can each become an attack surface. As core smart contracts become more robust, attackers are increasingly targeting the surrounding infrastructure, including oracles, keepers, hooks, and offchain verification systems.
The Hidden Risks of External Dependencies
Every external dependency introduces another potential point of failure:
Oracles can be manipulated, delayed, or provide inaccurate price data.
Keepers are external bots or automated services responsible for monitoring blockchain activity and triggering transactions on behalf of the protocol or user, which can be another attack vector.
Offchain services can go offline or behave unexpectedly.
Hooks add additional smart contract logic and execution paths that should be separately audited in addition to the underlying protocol.
Even when the core protocol is secure, an external dependency can become the weakest link.
The more components a protocol depends on, the more opportunities attackers have to find vulnerabilities.
This is obviously a security consideration, but it is also a question of predictability and protocol design. Reducing unnecessary dependencies can remove entire categories of failure.
Oracle Manipulation: When Price Feeds Become Attack Vectors
An oracle is a service that provides blockchain applications with external information, such as the price of BTC or ETH.
Because smart contracts cannot independently verify external data, they must trust the oracle’s output.
If an attacker can manipulate that data, they can cause a protocol to make incorrect decisions as demonstrated by the Balance Coin exploit.
Example
Imagine a lending protocol where a user deposits 1 BTC as collateral to borrow stablecoins.
If the protocol’s oracle is manipulated and reports BTC is worth $5,000 instead of $120,000:
Healthy positions may appear undercollateralized.
Users may be liquidated unnecessarily.
Attackers can purchase collateral at artificially discounted prices.
The attacker captures the difference.
This is the fundamental risk behind oracle manipulation attacks.
Oracle manipulation can happen through:
Low-liquidity markets influencing reported prices.
Weak oracle update mechanisms.
Flashloans temporarily distorting asset prices.
Compromised oracle infrastructure or configuration.
Major Oracle-Related Exploits in DeFi
For this analysis, ‘oracle-related’ includes direct price-feed manipulation as well as exploits involving oracle verification flaws, compromised oracle signer keys, and manipulated collateral pricing.
Ostium Authorized Oracle-Report Exploit — Approximately $24 Million (July 2026)
An attacker used authorized oracle credentials to submit fabricated, future-dated price reports that made repeated leveraged trades appear profitable. Because the reports carried valid authorization, Ostium’s contracts accepted them and paid out approximately $23.75 million in artificial profits, according to later estimates.
Some reports attribute the breach to a compromised oracle signer key, although Ostium has not publicly confirmed how the attacker obtained the authority to submit the reports.
Summer.fi was not itself a conventional oracle or keeper exploit. Its inclusion in that broader pattern reflects another dependency-related failure: a stale external Silo valuation remained incorporated into the protocol’s NAV calculation.
Balance Coin Bitcoin Oracle Manipulation — $912,000 (July 2026)
The attacker submitted an artificially low Bitcoin price to the oracle used by Balance Protocol’s collateral vaults. The false price made healthy positions appear eligible for liquidation, allowing the attacker to seize collateral and drain approximately $912,000.
Bonzo Finance Oracle Verification Exploit — $9 Million (July 2026)
A verification flaw in a third-party Supra oracle contract allowed the attacker to submit a false SAUCE price update with an invalid, zeroed signature. Bonzo accepted the inflated valuation, allowing a few dollars of SAUCE to be used as collateral to borrow approximately $9 million in USDC and wrapped HBAR.
Drift Protocol Oracle and Privileged-Access Exploit — $285 Million (April 2026)
After gaining privileged control of Drift, the attackers approved a worthless token as collateral and assigned it an artificial price through an oracle they controlled. They deposited 500 million of these tokens and withdrew $285 million in real assets against collateral whose reported value had been manufactured.
YieldBlox VWAP Oracle Manipulation — $10.2 Million (Feb 2026)
After liquidity disappeared from the USTRY/USDC market, the attacker used a single trade to push USTRY’s oracle-reported price from approximately $1.05 to $106. The inflated collateral valuation allowed the attacker to borrow the lending pool’s entire reserves, leaving approximately $10.2 million in bad debt.
Makina Finance Price-Feed Manipulation — $4.1 Million (Jan 2026)
The attacker used a $280 million flash loan to manipulate Makina’s MachineShareOracle within a single transaction. Once the dependent Curve pool accepted the distorted share price, the attacker traded against roughly $5 million of available liquidity and drained approximately $4.1 million.
OEV: When Oracles Create a Race for Value
Oracle Extractable Value (OEV) is another consequence of relying on external price updates.
Unlike oracle manipulation, OEV does not involve corrupting the oracle.
Instead, searchers compete to capture value created when a legitimate oracle update makes positions eligible for liquidation.
For example:
ETH price drops.
Oracle updates the new price.
Lending positions become eligible for liquidation.
Searchers compete to execute liquidations first.
The fastest participant captures the liquidation reward.
This creates a competitive race where external actors extract value from protocol users.
When Third-Party Infrastructure Becomes the Attack Surface
KelpDAO Offchain Verification Infrastructure Exploit — $292 Million
Attackers compromised RPC nodes supplying blockchain-state data to LayerZero’s verifier and caused it to attest to a crosschain token burn that never occurred. Because KelpDAO used a 1-of-1 verifier configuration, no independent verifier challenged the fabricated message, and its bridge released 116,500 rsETH without corresponding assets being burned on the source chain.
Where Carbon DeFi Differs
Many of DeFi’s largest failures share a common theme: critical functionality depends on external systems.
Carbon DeFi, Bancor’s orderbook-style DEX, takes a different architectural approach by removing reliance on external execution layers.
Carbon DeFi does not rely on external price oracles to determine when trades should execute. Instead, users define their own trading parameters directly within their strategies.
Trades execute only when another participant, including its built-in solver system, interacts with those predefined prices.
Because execution is based on user-defined conditions rather than oracle-provided prices, Carbon DeFi avoids an entire category of oracle manipulation risks.
Keepers: DeFi’s Blind Spot
Keepers are external bots or services that monitor onchain activity and initiate transactions when predefined conditions are met. Because they can occupy privileged positions within a protocol’s execution flow, the risks extend beyond downtime, congestion, or compromised private keys. The execution path itself can become an attack surface.
GMX V1 Keeper Execution-Flow Exploit — $42 Million
The attacker used GMX V1’s keeper execution flow to access a temporary window in which leverage was enabled, then re-entered the vault to create unusually large short positions. Those positions manipulated the global short average price used in GMX’s AUM calculation, artificially inflated the price of GLP, and enabled approximately $42 million to be extracted through redemptions.
GMX demonstrates how keeper execution can become part of an exploit path. The keeper wasn’t compromised and didn’t execute an unauthorized transaction. The attacker exploited privileged protocol behavior that became available while the keeper was legitimately executing an order.
More commonly, keepers perform routine actions such as auto-compounding. In many liquidity and yield strategies, they periodically claim accumulated fees or rewards and submit transactions that reinvest them into the position.
Carbon DeFi provides native auto-compounding. Profits are automatically added back to the position as trades execute, without requiring an external bot to monitor the position or submit a separate compounding transaction.
Automation isn’t an additional service layered on top of Carbon DeFi. It is part of the protocol’s underlying execution logic. Removing keeper-based execution eliminates another external dependency and the operational risks that come with it.
Advanced trading features without external hooks
Hooks are a developer design choice that emerged as a way to extend existing concentrated liquidity architectures. They allow developers to add functionality around core protocol actions by introducing external smart contracts that execute before or after events such as swaps, liquidity changes, or position updates.
Hooks provide flexibility, but they also introduce additional complexity. Each hook creates another layer of logic that should be audited, maintained, and secured. Because hooks operate outside the core protocol logic, they can introduce additional execution paths, dependencies, and potential vulnerabilities.
Bunni V2 Hook Logic Exploit — $8.4 Million
Bunni V2 operated as a Uniswap v4 hook and contained a rounding-direction error in its withdrawal logic that allowed repeated withdrawals to distort the pool’s total-liquidity calculation. The attacker combined flashloaned capital, balance manipulation, and 44 withdrawals to compound the accounting error and drain approximately $8.4 million across Ethereum and Unichain.
Rather than building on top of concentrated liquidity and adding functionality through external hooks, Carbon DeFi was designed from the ground up with advanced trading functionality built directly into the protocol.
Carbon DeFi’s native features include adjustable:
Limit Orders — allowing users to set exact buy and sell prices.
Range Orders — distributing liquidity across a chosen price range.
Recurring Orders — automatically rotating capital between buy and sell strategies.
Advanced Concentrated Liquidity — enabling advanced liquidity strategies with auto-compounding, and without traditional concentrated liquidity constraints.
These capabilities are built into Carbon DeFi’s core execution logic and don’t require external contracts layered on top of the protocol.
The difference is architectural: rather than adapting an existing liquidity model through third-party components, Carbon DeFi was designed around these capabilities from the beginning.
Note: Strategies that may require custom hooks on other DEXs can be created on Carbon DeFi by combining its native order and liquidity features.
A more resilient approach to DeFi execution
From oracle manipulation to supply-chain attacks, many of DeFi’s largest exploits share a common theme: critical functionality depends on external systems.
Bancor introduces a different approach to onchain trading with Carbon DeFi. By eliminating reliance on external execution layers, including oracles, keepers, and hooks, Carbon DeFi removes entire categories of dependency-related risks.
Users define their strategy. Execution happens onchain. No external party determines the price or conditions under which an order can execute.
