We often think of DeFi as autonomous, trustless and self-executing. But that is only partially true. Smart contracts are deterministic and automated, but they also need external input. They cannot observe markets, prices or events. They can only act on information that already exists on the blockchain.

This limitation matters because finance is not self-contained. Lending, borrowing and risk management all depend on external facts. A protocol needs to know what an asset is worth, whether collateral is sufficient, and when a position has become unsafe. Without access to that information, most DeFi primitives cannot exist.

Oracles were introduced to solve this problem. They enable smart contracts to interact with the world outside the chain. This is the basis of modern DeFi. But in doing so, they also introduced a dependency that has become a weakness.

At its core, an oracle is like a translator. It takes information from outside the blockchain and writes it into a format that a smart contract can read. In most cases, that information is a price.

When a lending protocol decides how much you can borrow, it is not evaluating the market itself. It is reading a number that was delivered by an oracle. Once that number is on-chain, the contract treats it as truth. It does not know how the price was formed, how liquid the market was, or how fast conditions are changing. It only knows that the value exists.

This abstraction is powerful. It allows protocols to behave as if they understand the market without directly interacting with it. It also means that every critical decision depends on the quality, timing and assumptions of that external input.

As long as markets are calm, this dependency is easy to ignore.

Without oracles, DeFi would be limited to systems that only reason about assets already inside their own contracts. Early on, that was not enough. Protocols wanted lending markets, leverage, derivatives and structured products. All of these require comparison between assets whose values are determined elsewhere.

Oracles made that possible. They allowed DeFi to mirror traditional financial logic on-chain. Collateral ratios, liquidation thresholds and risk models could now be expressed in code. Growth followed quickly.

But this came with an implicit assumption: that external data could be imported safely, consistently and fast enough to support increasingly leveraged systems.

That assumption is where problems arose.

Oracle systems do not fail because of poor design. They fail because they operate under constraints that financial markets do not respect.

Prices move continuously. Oracles update at fixed intervals. When markets move quickly, protocols can act on information that is already outdated. This gap has been exploited multiple times in DeFi’s history.

In March 2020, during the COVID market crash, MakerDAO experienced severe issues when the price of ETH collapsed rapidly. Oracle updates lagged behind the market move, and network congestion delayed liquidations. Some auctions cleared at zero bids, allowing opportunistic actors to acquire collateral for almost nothing. The system remained solvent, but the event exposed how latency and infrastructure stress can interact with oracle-dependent designs.

Even when updates are frequent, oracle prices can still be distorted. In February 2020, attackers targeted bZx by manipulating low-liquidity trading pairs used in its price oracle. By briefly moving prices on decentralized exchanges, they were able to borrow assets at inflated valuations and extract value from the protocol. The oracle reported accurate prices from the markets it observed, but those markets were momentarily manipulated.

Similar techniques were used later in 2020 against Compound-integrated protocols, where thin liquidity pairs fed into oracle calculations. In each case, the weakness was not a faulty oracle, but reliance on prices that could be moved cheaply for short periods of time.

As DeFi matured, oracle dependencies became more layered. Protocols began relying on decentralised exchanges like Uniswap for price discovery, which in turn fed into oracle systems such as Chainlink. When liquidity conditions on underlying markets shifted abruptly, oracle feeds reflected those shifts with delay or distortion, affecting lending and liquidation logic across multiple protocols at once.

Governance has also played a role. In November 2020, MakerDAO governance debated emergency oracle parameter changes during periods of high volatility. These moments highlighted that oracle systems ultimately depend on human coordination for edge cases, reintroducing discretion into otherwise automated systems.

At scale, managing oracle risk became one of the central challenges of DeFi. Not because oracles are optional, but because most lending and leverage-based systems cannot function without them.

The core limitation of oracle-based design is not accuracy. It is reactivity.

A protocol that depends on external signals does not know its own state independently. Instead of observing conditions directly, it waits for the world to report them through delayed, sampled, and sometimes manipulable inputs, then reacts. That gap between reality and observation is what makes the system inherently probabilistic: outcomes hinge on when a signal is captured, when it arrives on-chain, and who can act in between. As leverage increases, small errors in those inputs are amplified into large, discontinuous outcomes. Timing becomes exploitable, and each added layer of complexity compounds fragility rather than reducing it.

At some point, improving oracle design stops addressing the root issue. You are still importing uncertainty into a deterministic system and hoping the interface holds.

Ammalgam starts from the opposite assumption.

Most DeFi protocols rely on external price feeds to decide how much users can borrow and when positions should be unwound. Ammalgam takes a different approach by defining value entirely from within the protocol, using information that already exists on-chain.

Instead of treating price as a single, precise number, Ammalgam works with a price range. This range is derived from the protocol’s own liquidity over time rather than from external markets. By observing how assets are traded inside its pools across recent blocks and longer periods, Ammalgam forms a view of value that reflects actual, sustained market behaviour rather than momentary spikes.

When a new position is opened, collateral is evaluated using the most conservative value within this range. This ensures borrowing limits are based on realistic conditions, not optimistic assumptions. During liquidations, the system can use values within the same range that reduce unnecessary pressure during short-term volatility.

To keep this internal pricing stable, Ammalgam limits how much prices can move within a single block and filters out extreme outliers. This makes sudden distortions expensive and discourages attempts to push prices beyond what the pool’s liquidity can support.

Borrowing is also constrained by real liquidity, not just price. Before a position is allowed, the protocol checks whether the available assets in the pool could actually absorb the trade required to unwind it. If closing a position would cause excessive slippage, the position is not permitted. This ties leverage directly to what the system can realistically handle.

Finally, Ammalgam tracks exposure across the entire price range rather than position by position. This prevents large risks from being hidden across many smaller positions and helps maintain balance as market conditions change.

By combining price ranges, liquidity-aware limits and internal tracking, Ammalgam removes the need for oracles entirely. All decisions are based on what the protocol can observe and verify itself. The result is a lending system that values assets based on on-chain reality, not external assumptions, and stays aligned with the actual capacity of the market at all times.

Early DeFi focused on copying traditional finance on-chain. Oracles made that possible by bringing in prices and market data from the outside world. That approach worked, but it also added complexity and dependency.

As DeFi grows, those dependencies matter more. The more a protocol relies on external signals, the harder it becomes to reason about, maintain and scale safely. Managing risk starts to mean managing everything the protocol depends on, not just its own logic.

Ammalgam points to a simpler direction. By defining value using only what exists on-chain, it reduces reliance on external systems and keeps decision-making internal. This does not replace every DeFi model, but it shows that some financial primitives work better when they are self-contained.

As DeFi moves forward, protocols that reduce external dependencies while maintaining internal coherence can show more resilience than designs that rely on many external assumptions to appear flexible.

We often think of DeFi as autonomous, trustless and self-executing. But that is only partially true. Smart contracts are deterministic and automated, but they also need external input. They cannot observe markets, prices or events. They can only act on information that already exists on the blockchain.

This limitation matters because finance is not self-contained. Lending, borrowing and risk management all depend on external facts. A protocol needs to know what an asset is worth, whether collateral is sufficient, and when a position has become unsafe. Without access to that information, most DeFi primitives cannot exist.

Oracles were introduced to solve this problem. They enable smart contracts to interact with the world outside the chain. This is the basis of modern DeFi. But in doing so, they also introduced a dependency that has become a weakness.

At its core, an oracle is like a translator. It takes information from outside the blockchain and writes it into a format that a smart contract can read. In most cases, that information is a price.

When a lending protocol decides how much you can borrow, it is not evaluating the market itself. It is reading a number that was delivered by an oracle. Once that number is on-chain, the contract treats it as truth. It does not know how the price was formed, how liquid the market was, or how fast conditions are changing. It only knows that the value exists.

This abstraction is powerful. It allows protocols to behave as if they understand the market without directly interacting with it. It also means that every critical decision depends on the quality, timing and assumptions of that external input.

As long as markets are calm, this dependency is easy to ignore.

Without oracles, DeFi would be limited to systems that only reason about assets already inside their own contracts. Early on, that was not enough. Protocols wanted lending markets, leverage, derivatives and structured products. All of these require comparison between assets whose values are determined elsewhere.

Oracles made that possible. They allowed DeFi to mirror traditional financial logic on-chain. Collateral ratios, liquidation thresholds and risk models could now be expressed in code. Growth followed quickly.

But this came with an implicit assumption: that external data could be imported safely, consistently and fast enough to support increasingly leveraged systems.

That assumption is where problems arose.

Oracle systems do not fail because of poor design. They fail because they operate under constraints that financial markets do not respect.

Prices move continuously. Oracles update at fixed intervals. When markets move quickly, protocols can act on information that is already outdated. This gap has been exploited multiple times in DeFi’s history.

In March 2020, during the COVID market crash, MakerDAO experienced severe issues when the price of ETH collapsed rapidly. Oracle updates lagged behind the market move, and network congestion delayed liquidations. Some auctions cleared at zero bids, allowing opportunistic actors to acquire collateral for almost nothing. The system remained solvent, but the event exposed how latency and infrastructure stress can interact with oracle-dependent designs.

Even when updates are frequent, oracle prices can still be distorted. In February 2020, attackers targeted bZx by manipulating low-liquidity trading pairs used in its price oracle. By briefly moving prices on decentralized exchanges, they were able to borrow assets at inflated valuations and extract value from the protocol. The oracle reported accurate prices from the markets it observed, but those markets were momentarily manipulated.

Similar techniques were used later in 2020 against Compound-integrated protocols, where thin liquidity pairs fed into oracle calculations. In each case, the weakness was not a faulty oracle, but reliance on prices that could be moved cheaply for short periods of time.

As DeFi matured, oracle dependencies became more layered. Protocols began relying on decentralised exchanges like Uniswap for price discovery, which in turn fed into oracle systems such as Chainlink. When liquidity conditions on underlying markets shifted abruptly, oracle feeds reflected those shifts with delay or distortion, affecting lending and liquidation logic across multiple protocols at once.

Governance has also played a role. In November 2020, MakerDAO governance debated emergency oracle parameter changes during periods of high volatility. These moments highlighted that oracle systems ultimately depend on human coordination for edge cases, reintroducing discretion into otherwise automated systems.

At scale, managing oracle risk became one of the central challenges of DeFi. Not because oracles are optional, but because most lending and leverage-based systems cannot function without them.

The core limitation of oracle-based design is not accuracy. It is reactivity.

A protocol that depends on external signals does not know its own state independently. Instead of observing conditions directly, it waits for the world to report them through delayed, sampled, and sometimes manipulable inputs, then reacts. That gap between reality and observation is what makes the system inherently probabilistic: outcomes hinge on when a signal is captured, when it arrives on-chain, and who can act in between. As leverage increases, small errors in those inputs are amplified into large, discontinuous outcomes. Timing becomes exploitable, and each added layer of complexity compounds fragility rather than reducing it.

At some point, improving oracle design stops addressing the root issue. You are still importing uncertainty into a deterministic system and hoping the interface holds.

Ammalgam starts from the opposite assumption.

Most DeFi protocols rely on external price feeds to decide how much users can borrow and when positions should be unwound. Ammalgam takes a different approach by defining value entirely from within the protocol, using information that already exists on-chain.

Instead of treating price as a single, precise number, Ammalgam works with a price range. This range is derived from the protocol’s own liquidity over time rather than from external markets. By observing how assets are traded inside its pools across recent blocks and longer periods, Ammalgam forms a view of value that reflects actual, sustained market behaviour rather than momentary spikes.

When a new position is opened, collateral is evaluated using the most conservative value within this range. This ensures borrowing limits are based on realistic conditions, not optimistic assumptions. During liquidations, the system can use values within the same range that reduce unnecessary pressure during short-term volatility.

To keep this internal pricing stable, Ammalgam limits how much prices can move within a single block and filters out extreme outliers. This makes sudden distortions expensive and discourages attempts to push prices beyond what the pool’s liquidity can support.

Borrowing is also constrained by real liquidity, not just price. Before a position is allowed, the protocol checks whether the available assets in the pool could actually absorb the trade required to unwind it. If closing a position would cause excessive slippage, the position is not permitted. This ties leverage directly to what the system can realistically handle.

Finally, Ammalgam tracks exposure across the entire price range rather than position by position. This prevents large risks from being hidden across many smaller positions and helps maintain balance as market conditions change.

By combining price ranges, liquidity-aware limits and internal tracking, Ammalgam removes the need for oracles entirely. All decisions are based on what the protocol can observe and verify itself. The result is a lending system that values assets based on on-chain reality, not external assumptions, and stays aligned with the actual capacity of the market at all times.

Early DeFi focused on copying traditional finance on-chain. Oracles made that possible by bringing in prices and market data from the outside world. That approach worked, but it also added complexity and dependency.

As DeFi grows, those dependencies matter more. The more a protocol relies on external signals, the harder it becomes to reason about, maintain and scale safely. Managing risk starts to mean managing everything the protocol depends on, not just its own logic.

Ammalgam points to a simpler direction. By defining value using only what exists on-chain, it reduces reliance on external systems and keeps decision-making internal. This does not replace every DeFi model, but it shows that some financial primitives work better when they are self-contained.

As DeFi moves forward, protocols that reduce external dependencies while maintaining internal coherence can show more resilience than designs that rely on many external assumptions to appear flexible.