Ammalgam Explained: What If DeFi Never Needed Oracles?
Table of Contents
The Oracle Problem No One Talks About
Rethinking the Stack and Why Fragmentation Exists
One Deposit, Three Revenue Streams
How You Price Collateral Without an Oracle
One Deposit, Three Revenue Streams
Leverage Without the Middleman
The Safety Architecture
Competitive Landscape and How Ammalgam Fits In
Real Risks and Open Questions
Why Oracle-Free Matters Beyond Ammalgam
References
The Oracle Problem No One Talks About
Lending protocols need to know what your collateral is worth. Without a price, there’s no way to determine when a position becomes undercollateralized, when liquidation should trigger, or how much someone can borrow in the first place.
So protocols ask oracles. Chainlink, Pyth, or custom feeds pull prices from exchanges and deliver them onchain. This creates a dependency where the protocol’s entire liquidation logic hinges on data it doesn’t control.
Most of the time, this works. But oracles can lag during volatile markets, get manipulated through thin liquidity on source exchanges, or fail outright at critical moments. The Mango Markets exploit wasn’t a smart contract bug. It was oracle manipulation that drained $110 million. During the LUNA collapse, price feeds struggled to keep pace with a death spiral, throwing off liquidation timing across multiple protocols.
The standard response is to add redundancy through multiple oracle sources, staleness checks, and circuit breakers. These measures reduce risk but don’t eliminate it, and the external dependency remains baked into the architecture.
Ammalgam starts from a different premise. If you’re already running an AMM, you already have a price. The question becomes whether you can build lending and liquidation logic that uses this internal price instead of asking the outside world.
Rethinking the Stack and Why Fragmentation Exists
DeFi’s separation of trading and lending wasn’t arbitrary. AMMs like Uniswap never needed oracles because the constant product formula prices swap internally through reserve ratios. Lending protocols face a different problem. They need to continuously value collateral to determine solvency and trigger liquidations, which is why Aave and Compound reach for Chainlink. Merging the two functions seemed to require bolting oracles onto AMMs, reintroducing the very dependency that AMMs had elegantly avoided.
This architectural split forces liquidity providers into an either/or position. Deposit into an AMM and earn swap fees, or deposit into a lending protocol and earn interest. Doing both means splitting capital across platforms. Market makers who want leverage have it worse, borrowing on one protocol to deploy liquidity on another while paying fees to both and managing risk across separate platforms.
Ammalgam’s DLEX attempts to collapse this fragmentation by combining trading, lending, and leverage into a single pool. One deposit serves as swap liquidity, lendable capital, and collateral simultaneously. The mechanism for pulling this off without oracles is where things get interesting.
How You Price Collateral Without an Oracle
If the pool is going to replace the oracle, it needs to resist manipulation. A single block’s price is too easy to distort with a large swap, so Ammalgam doesn’t rely on it alone. Instead, the protocol tracks three price metrics simultaneously.
The spot price at the end of the most recent block
The geometric mean over the last 64 blocks
A longer-term geometric mean with a configurable lookback period
When evaluating collateral for a new loan, the protocol uses whichever price is least favorable to the borrower. An attacker trying to inflate collateral value would need to sustain the manipulation across all three windows, which becomes prohibitively expensive.
But price accuracy alone isn’t enough. A loan that looks healthy in isolation might still threaten the pool if liquidating it would cause massive slippage. So Ammalgam calculates a Slippage-Adjusted LTV that simulates what would happen if the collateral had to be sold into the pool’s current liquidity. If the liquidation would destabilize reserves or if too many existing positions occupy the same price range, the loan gets blocked. The protocol tracks these exposures across tranches to prevent concentration that could trigger cascading liquidations.
Liquidations themselves follow a Dutch auction mechanism that needs no external trigger. Positions become eligible for liquidation once LTV reaches 60%, but the economics don’t favor liquidators immediately. At that threshold, they receive no premium and have no incentive to act. As LTV rises toward 75%, the premium grows until liquidation becomes profitable. This creates a continuous incentive gradient tied entirely to the onchain state, with no oracle required to signal when a position has gone underwater.
One Deposit, Three Revenue Streams
Ammalgam’s Dual Purpose Pools unify what other protocols separate. A single deposit enters a pool where it simultaneously serves as AMM liquidity for swaps, as supply that borrowers can draw from, and as collateral for the depositor’s own leveraged positions if desired. Yield accrues from multiple sources at once. Swap fees from trades executing against the pool, interest from borrowers, and funding payments from traders holding leveraged long or short positions.
Ammalgam estimates this stacked yield model can generate 20-60% higher returns than equivalent positions split across a DEX and lending protocol, though actual performance depends on utilization rates, trading volume, and market conditions.
The pool balances these competing demands through utilization curves that adjust interest rates in real time. As borrowing increases, rates rise to attract more deposits and encourage repayment. As utilization drops, rates fall. LPs don’t need to actively manage allocation between lending and trading. The protocol handles it, and capital stays productive across all three functions without manual rebalancing.
Leverage Without the Middleman
Perpetual DEXs like GMX and dYdX let traders take leveraged long and short positions, but they rely on oracles to determine entry prices, liquidation triggers, and funding rates. Ammalgam offers similar exposure through a different mechanism. Traders borrow directly from Dual Purpose Pools to construct leveraged positions, with the pool’s internal pricing governing the entire lifecycle of the trade.
Each position is isolated to a single trading pair. A leveraged bet on ETH/USDC exists independently from positions in other pools, so a liquidation in one market can’t cascade into forced selling elsewhere in a trader’s portfolio. This containment limits systemic risk at both the individual and protocol level.
Funding rates emerge organically from pool dynamics rather than external open interest data. When borrowing demand for an asset increases, utilization rises and interest rates follow. Traders holding leveraged positions pay these rates to liquidity providers, creating the same economic function as perpetual funding but derived entirely from the onchain state.
The Safety Architecture
Unifying this much functionality in a single pool creates compounding risks during market stress. If an asset appreciates rapidly while being heavily borrowed, the pool can face a gamma squeeze where forced liquidations accelerate price movement, which triggers more liquidations. Ammalgam addresses this with a layered defense system that intensifies as conditions deteriorate.
The first layer is a three-tier interest rate curve. At low utilization, rates climb gently. As utilization approaches 90%, rates steepen aggressively, reaching around 40% annualized. Beyond that threshold, a third tier kicks in with rates that can spike to 100%, 200%, or higher. The goal is to make holding borrowed positions increasingly painful until the market responds with either new deposits or loan repayments. A hard cap at 90% utilization ensures that 10% of reserves always remain available for swaps regardless of borrowing demand.
If rate pressure fails to restore balance, Depleted Asset Protection activates. This mechanism adjusts the AMM’s invariant curve under stress so that swaps can continue executing even when one side of the pool is nearly drained. Dynamic swap pricing complements this by taxing withdrawals of the scarce asset and rewarding deposits of it, creating incentives for the pool to heal itself without requiring external intervention.
These layered defenses position Ammalgam differently from protocols that outsource risk management to oracles.
Competitive Landscape and How Ammalgam Fits In
Ammalgam occupies a space that existing protocols only partially address. Each category solves one problem while inheriting limitations that Ammalgam attempts to avoid.
Traditional DEXs optimize for trading but leave LP capital underutilized between swaps. Lending protocols unlock yield on idle assets but inherit oracle risk that has historically led to cascading liquidations when price feeds lag or fail. Perpetual platforms offer leverage but depend entirely on external data for core functions.
Ammalgam’s design attempts to capture the benefits of each category while shedding their primary dependencies. Whether this tradeoff holds under real market stress remains to be proven, but architecturally it represents a distinct approach rather than an incremental improvement on any single category.
Real Risks and Open Questions
Ammalgam’s architecture eliminates oracle dependency, but it introduces different tradeoffs that deserve scrutiny.
The most significant is price divergence. The protocol has no visibility into external markets, so when prices move quickly on centralized exchanges or other DEXs, there’s a window before arbitrageurs bring the pool back into alignment. During that gap, borrowers might get liquidated at stale prices, or traders could extract value before the correction. Dynamic fees help compensate LPs when arbitrageurs close the spread, capturing some of that value rather than losing it entirely. The mitigation helps, but it’s not a complete solution during extreme volatility.
Liquidity depth also matters more here than in a standard AMM. Deep pools keep slippage low and allow larger loans. Thin pools tighten everything, restricting how much users can borrow and making the experience worse overall. The protocol can tap external liquidity for liquidations, which helps at the margins. But new pools will likely face the classic cold-start problem until volume picks up.
Complexity is an inherent tradeoff of unification. Combining AMM mechanics, lending logic, and leverage in one system creates more surface area for edge cases, interactions that simply wouldn’t exist in single-purpose protocols. And unlike Aave or Uniswap, there’s no multi-year track record here. The design is sound on paper, but real confidence comes from surviving real stress.
Why Oracle-Free Matters Beyond Ammalgam
Every oracle is a trust assumption. You’re trusting that the data source is accurate, that the delivery mechanism won’t fail, and that no one can manipulate the feed faster than the protocol can respond. These aren’t hypothetical risks. They’ve been exploited repeatedly, and they’ll be exploited again.
What Ammalgam demonstrates is that the dependency isn’t strictly necessary. Lending, liquidations, leverage, and dynamic fees can all function using prices derived from onchain pool state. The tradeoffs are different rather than absent, but it opens a design path most protocols never considered.
DeFi was supposed to be about removing intermediaries. Oracles are intermediaries, just infrastructure ones rather than financial ones. We’ve grown comfortable treating them as inevitable. Ammalgam is betting there’s a better way. The market will decide if they’re right.
References
Ammalgam documentation
Batch Auctions vs. Dutch Auctions in Crypto
The oracle problem is political
Liquidity Should Work Harder: The Case for Dual-Purpose Pools in DeFi
Ammalgam Links
Website | Docs | Discord | Twitter | Github
Thanks for reading Dewhales Research! Subscribe for free to receive new posts and support our work.
We’d love to hear your thoughts on the article! Your feedback helps us improve and bring you the best content possible—it won’t take more than 2 minutes.
Also, this post is public, so feel free to share it!
Thank you so much! ❤️
Our links:
🔗Website
🐦Twitter
✉️Substack
🔸DeBank
Disclaimer: The content presented in this article, along with others, is based on opinions developed by the analysts at Dewhales and does not constitute sponsored content. At Dewhales, we firmly adhere to a transparency-first philosophy, making our wallets openly available to the public through our website or DeBank, and our articles serve as vehicles for self-expression, education, and contribution to the ecosystem.
Dewhales Capital does not provide investment advisory services to the public. Any information should not be taken as investment, accounting, tax or legal advice or as a recommendation to purchase, sell or hold or to pursue any investment style or strategy. The accuracy and appropriateness of the information is not guaranteed by Dewhales Capital.