Oracles have long been the connective tissue of decentralized finance. They feed blockchains with off-chain data so smart contracts can function. Asset prices, rates, events - everything trickles into blockchains via oracles. But this crucial role comes with risk. In recent years, we've seen oracles become the source of some of DeFi's most devastating failures, the target of hacks, manipulations and the cause of mass liquidations.

The truth is - DeFi’s dependency on oracles is a design flaw.

This is why we took a different approach when building Ammalgam. One where the protocol's architecture doesn't rely on external oracles at all. Instead, it uses internal pricing logic and time-based mechanisms to secure lending and trading. No price feeds. No exploit windows and no middlemen pretending to be trustless.

The oracle problem: centralized risk in a decentralized system

Oracles are supposed to deliver real-world data to blockchains. But that data can be delayed, misrepresented, or outright fabricated in some cases.

Latency: Oracles don’t deliver data in real time. Most use off-chain aggregators and multi-step reporting, resulting in a lag between real-world events and on-chain updates. Attackers can exploit even small delays, spotting and acting on pricing mismatches before protocols catch up. This opens the door to oracle-based arbitrage and increases the risk of inaccurate liquidations or bad debt during volatile conditions.

Vulnerable to manipulation: Oracles pull from external sources like centralized and decentralized exchanges, market data providers, time-weighted average price (TWAP) feeds, liquidity-weighted price aggregators across multiple platforms, and low-liquidity trading pairs. If those sources can be manipulated through spoofing, wash trading, or poorly designed VWAP windows on-chain, then the oracle can be tricked into reporting false prices. Smart contracts built on this false data behave as intended, but with destructive consequences.

Centralization: Many oracle systems rely on a small set of validator nodes or data reporters, even when claiming to be decentralized. If enough of those nodes are compromised or act with malicious intent, they can submit false data. Creating a single point of failure in systems meant to be trustless and undermining the security model of the entire protocol

A look at hacks and failures tied to oracles

We've already seen the risks posed by oracles materialize in some of DeFi’s most damaging incidents. Vulnerabilities in oracle design have been exploited to manipulate prices, drain protocols, and trigger unjustified liquidations. Some of the most well-known examples speak for themselves:

Mango Markets (Oct 2022): An attacker manipulated the oracle-reported price of MNGO using large trades, inflating its value and using it as collateral to borrow over $100M in assets. The protocol was drained in a single transaction.

bZx Protocol (2020): Attackers used flash loans to manipulate low-liquidity price feeds from Kyber, inflating asset prices and tricking the protocol into issuing undercollateralized loans. The flawed reliance on a single oracle led to over $8M in losses across two incidents.

Chainlink (2025): Chainlink’s oracle mispriced deUSD, a synthetic stablecoin, triggering over $500,000 in liquidations across the Euler lending platform on Avalanche. The error happened due to a VWAP anomaly in an under‑liquid deUSD/USDT Curve pool. A large MEV‑driven trade caused the oracle feed to spike above $1.02 and spark a forced unwind in a matter of minutes, highlighting how traditional oracle models (especially VWAP based on low-liquidity pools) can inject outsized risk into leveraged systems.

Each of these incidents had a common thread: smart contracts trusted external data more than internal market behavior. That trust was misplaced.

Why oracles fail lending protocols

Lending protocols depend on accurate and timely price data to determine how much users can borrow, when to liquidate positions, and how to manage risk. But:

• If data is slow: Liquidations don’t trigger in time and bad debt accumulates.

• If data is wrong: Users get unfairly liquidated or exploit the system for profit.

• If data is manipulated: Entire pools can be drained before anyone reacts.

Protocols try to compensate by adding buffers, multiple feeds, or circuit breakers. But those are band-aids. The real fix needs to happen at the architecture layer.

Ammalgam: oracle-free by design

Ammalgam doesn’t use price feeds. It doesn’t ask third parties what an asset is worth. Instead, it builds its own pricing based on internal market activity. That means:

• Trades and not external reports determine price.

• Risk is priced by behavior, not a feed.

• Security comes from protocol logic rather than trust in third-parties.

Instead of time delays, Ammalgam applies a dynamic fee mechanism that scales quadratically during volatility. When reserves get stressed or asset ratios skew too far, the cost of extracting liquidity rises sharply. This makes it much more expensive to manipulate the system and gives LPs better rewards for sticking around.

What oracle-free means for LPs

Liquidity providers often bear the cost of oracle failures: bad trades, sudden losses, or unfair liquidations that devalue their positions.

In Ammalgam:

• The system is more resilient to external shocks because it doesn’t depend on off-chain oracles.

• Liquidity, pricing and risk are all managed internally.

• The protocol responds dynamically without relying on external inputs or interventions.

• Fee revenue comes from real trading and lending, not cex-dex arbitrage.

• Risk is localized within the system, so LPs know what they’re opting into.

What oracle-free means for market makers

Market makers rely on accurate pricing to manage spreads and inventory. Oracles create uncertainty that they can’t control.

In Ammalgam:

• All prices are derived from internal trades, so behavior is predictable.

• There is no sudden re-pricing from off-chain data as the price is only allowed to move so far each block.

• Volatility is priced and compensated within the pool, not distorted by external manipulation.

What oracle-free means for traders

Traders in DeFi often get wiped by oracle delays or errors, especially in highly volatile markets.

In Ammalgam:

• Prices reflect actual market supply and demand.

• No front-running or slippage caused by delayed feeds.

• Borrowing and trading costs are transparent and encoded, not arbitrarily triggered by oracles.

The future of DeFi: less trust, code is law

DeFi shouldn’t depend on trusting external sources to validate data. It should rely on cohesive systems that work even when everything outside is broken.

We didn't remove oracles for the sake of decentralization. We did it to remove a whole category of failure and make finance more native to crypto. And, most importantly, to build systems that price risk from the inside out.

Explore the docs to learn how Ammalgam’s oracle-free model works in practice.