DeFi was built on modularity. Instead of closed, vertically integrated systems, we got smart contracts that could snap together like money Legos. You could take an AMM, layer lending on top, wrap tokens, automate strategies, and build something new. Composability became more than a feature, it turned into a design philosophy.

But over time, the cracks started to show. Many attempts to combine lending and trading ended up adding more complexity than efficiency. Latency increased. Liquidity became fragmented. And risk, instead of being mitigated by composability, became harder to manage. Not that these are fatal flaws. But they are signs that DeFi architecture needs a rethink about its foundations.

During the DeFi Summer of 2020, experimentation was the norm. SushiSwap launched Kashi, an isolated lending market built on top of its AMM. The idea was to allow long-tail assets to have their own lending markets without introducing contagion risk across pools. In practice, Kashi struggled with low utilization and bad debt. Many of the isolated pairs lacked the liquidity or borrowing demand to function well, and over time, the system was deprecated.

Balancer’s Boosted Pools took a different approach: rather than build trading on top of lending, they deposited idle LP assets into Aave to generate yield. This optimization worked well under certain conditions but added technical complexity. Withdrawals could be delayed, interest rates volatile, and the system became sensitive to liquidity mismatches between Balancer and Aave. That sensitivity increased integration risk during volatile markets, especially for less liquid assets.

These are just a few examples: Rari’s Fuse pools integrated Curve LPs and other exotic collateral, Compound introduced cTokens that other protocols wrapped into new pool designs, and Aave launched an AMM market to let LP tokens serve as collateral. Alpha Homora pioneered leveraged yield farming by borrowing to boost AMM LP positions, while Gearbox extended this model with generalized leveraged strategies across DeFi. Each stacked layer created new functionality, but also introduced tradeoffs: slower execution paths, extra conversions, reliance on external oracle pricing, and fragmented capital pools.

Importantly, these designs were iterative steps forward. They enabled experimentation and real-world composability. But as DeFi infrastructure has matured, it’s become clear that not all primitives are meant to be stacked.

The appeal of composability is that it allows rapid innovation and reuse. But composability alone doesn’t guarantee performance. Systems that weren’t built to speak the same language can suffer from latency, dependency mismatches, or conflicting incentives.

For example, a lending protocol depends on real-time, deep liquidity to support liquidations. If that liquidity is fragmented across AMMs and can only be accessed through swap routing, delays or slippage can cause liquidations to fail or result in bad debt. Similarly, AMMs rely on assumptions about stable pricing and consistent trade flow. But these assumptions may break down if they’re indirectly exposed to leverage dynamics in a lending protocol stacked on top.

There’s also the problem of click friction. A user trying to put on a delta-neutral market making position might first go to Aave to borrow ETH against stables - approve, deposit, borrow - then jump to Uniswap for more approvals, mint liquidity, and manage positions. It’s multiple steps across multiple protocols, each with its own approvals and risks. And even after all that, why can’t that Uniswap LP position serve as collateral on Aave directly?

The result is that when one part of the stack comes under stress or simply slows down, the effects ripple across the system. Protocols become tightly coupled without being truly integrated. They share risk, but not logic. While that’s not inherently bad, it does introduce fragility.

What if we didn’t build lending on top of trading, but alongside it? What if they shared liquidity, pricing, and risk logic from the outset?

That’s the promise of native integration. It’s not about merging two features into a mega-protocol. It’s about designing them to function as one unit from first principles.

With a unified architecture:

• Liquidity is dynamic and shared rather than segmented into "lending" and "trading".

• Liquidations happen using the same liquidity as swaps, eliminating the need for external routing.

• The protocol knows where its risk lives and can price it accordingly, without relying on external oracles or feeds.

• Latency is reduced because all logic executes within the same system.

This doesn't mean composability is obsolete. But it does mean we should be mindful of when and how we rely on it. For deeply interdependent systems like trading and lending, native cohesion offers advantages that stacking can’t replicate.

This is the approach Ammalgam takes. Rather than build a trading layer and plug in lending, or vice versa, Ammalgam treats both as coequal parts of a single system. Lending and trading use the same liquidity. Liquidation logic doesn’t route out but executes in place. Pricing comes from internal execution, not external feeds. And because it's all in one system, risk can be priced in real time. Such a purpose-built architecture is designed to bend with volatility, not break.

The challenge with stacked primitives is technical as well as conceptual. Many DeFi systems are built by combining existing models: an AMM here, a borrow rate curve there, maybe an auction system on top. But these modules weren’t always designed with mutual awareness. They work, until they don’t - especially under stress.

In high-volatility environments, stacked systems tend to break down along their seams. Pricing discrepancies lead to failed liquidations. Latency causes front-running. Risk builds up in one layer but isn’t visible to the others. What appears as a capital-efficient stack can quickly turn into an uncoordinated system with bottlenecks and blind spots.

Cohesion means designing systems where components don’t just interoperate but co-evolve. Where liquidity, risk, and execution are managed holistically. Where incentives are aligned not just across users, but across protocol layers.

As DeFi matures, the architecture needs to evolve with it. Not every protocol needs native integration. But for core functions like borrowing and trading, where latency, liquidity, and leverage intersect, it may be time to stop thinking in layers and start thinking in systems. Ethereum’s breakthrough was to unify those fragmented designs into programmable money: one system flexible enough to serve many use cases.

Today, we stack apps and split lending, trending and yield farming across protocols, pools and platforms. But for core functions like borrowing and trading, where liquidity, leverage, and pricing converge, it may be time to stop thinking in layers and start thinking in systems.

The next wave of DeFi won’t come from stacking more Lego bricks on top of each other. It will come from rethinking the bricks themselves, and asking: isn’t it more efficient for a single system to provide the freedom and composability that once required dozens of separate protocols?

DeFi was built on modularity. Instead of closed, vertically integrated systems, we got smart contracts that could snap together like money Legos. You could take an AMM, layer lending on top, wrap tokens, automate strategies, and build something new. Composability became more than a feature, it turned into a design philosophy.

But over time, the cracks started to show. Many attempts to combine lending and trading ended up adding more complexity than efficiency. Latency increased. Liquidity became fragmented. And risk, instead of being mitigated by composability, became harder to manage. Not that these are fatal flaws. But they are signs that DeFi architecture needs a rethink about its foundations.

During the DeFi Summer of 2020, experimentation was the norm. SushiSwap launched Kashi, an isolated lending market built on top of its AMM. The idea was to allow long-tail assets to have their own lending markets without introducing contagion risk across pools. In practice, Kashi struggled with low utilization and bad debt. Many of the isolated pairs lacked the liquidity or borrowing demand to function well, and over time, the system was deprecated.

Balancer’s Boosted Pools took a different approach: rather than build trading on top of lending, they deposited idle LP assets into Aave to generate yield. This optimization worked well under certain conditions but added technical complexity. Withdrawals could be delayed, interest rates volatile, and the system became sensitive to liquidity mismatches between Balancer and Aave. That sensitivity increased integration risk during volatile markets, especially for less liquid assets.

These are just a few examples: Rari’s Fuse pools integrated Curve LPs and other exotic collateral, Compound introduced cTokens that other protocols wrapped into new pool designs, and Aave launched an AMM market to let LP tokens serve as collateral. Alpha Homora pioneered leveraged yield farming by borrowing to boost AMM LP positions, while Gearbox extended this model with generalized leveraged strategies across DeFi. Each stacked layer created new functionality, but also introduced tradeoffs: slower execution paths, extra conversions, reliance on external oracle pricing, and fragmented capital pools.

Importantly, these designs were iterative steps forward. They enabled experimentation and real-world composability. But as DeFi infrastructure has matured, it’s become clear that not all primitives are meant to be stacked.

The appeal of composability is that it allows rapid innovation and reuse. But composability alone doesn’t guarantee performance. Systems that weren’t built to speak the same language can suffer from latency, dependency mismatches, or conflicting incentives.

For example, a lending protocol depends on real-time, deep liquidity to support liquidations. If that liquidity is fragmented across AMMs and can only be accessed through swap routing, delays or slippage can cause liquidations to fail or result in bad debt. Similarly, AMMs rely on assumptions about stable pricing and consistent trade flow. But these assumptions may break down if they’re indirectly exposed to leverage dynamics in a lending protocol stacked on top.

There’s also the problem of click friction. A user trying to put on a delta-neutral market making position might first go to Aave to borrow ETH against stables - approve, deposit, borrow - then jump to Uniswap for more approvals, mint liquidity, and manage positions. It’s multiple steps across multiple protocols, each with its own approvals and risks. And even after all that, why can’t that Uniswap LP position serve as collateral on Aave directly?

The result is that when one part of the stack comes under stress or simply slows down, the effects ripple across the system. Protocols become tightly coupled without being truly integrated. They share risk, but not logic. While that’s not inherently bad, it does introduce fragility.

What if we didn’t build lending on top of trading, but alongside it? What if they shared liquidity, pricing, and risk logic from the outset?

That’s the promise of native integration. It’s not about merging two features into a mega-protocol. It’s about designing them to function as one unit from first principles.

With a unified architecture:

• Liquidity is dynamic and shared rather than segmented into "lending" and "trading".

• Liquidations happen using the same liquidity as swaps, eliminating the need for external routing.

• The protocol knows where its risk lives and can price it accordingly, without relying on external oracles or feeds.

• Latency is reduced because all logic executes within the same system.

This doesn't mean composability is obsolete. But it does mean we should be mindful of when and how we rely on it. For deeply interdependent systems like trading and lending, native cohesion offers advantages that stacking can’t replicate.

This is the approach Ammalgam takes. Rather than build a trading layer and plug in lending, or vice versa, Ammalgam treats both as coequal parts of a single system. Lending and trading use the same liquidity. Liquidation logic doesn’t route out but executes in place. Pricing comes from internal execution, not external feeds. And because it's all in one system, risk can be priced in real time. Such a purpose-built architecture is designed to bend with volatility, not break.

The challenge with stacked primitives is technical as well as conceptual. Many DeFi systems are built by combining existing models: an AMM here, a borrow rate curve there, maybe an auction system on top. But these modules weren’t always designed with mutual awareness. They work, until they don’t - especially under stress.

In high-volatility environments, stacked systems tend to break down along their seams. Pricing discrepancies lead to failed liquidations. Latency causes front-running. Risk builds up in one layer but isn’t visible to the others. What appears as a capital-efficient stack can quickly turn into an uncoordinated system with bottlenecks and blind spots.

Cohesion means designing systems where components don’t just interoperate but co-evolve. Where liquidity, risk, and execution are managed holistically. Where incentives are aligned not just across users, but across protocol layers.

As DeFi matures, the architecture needs to evolve with it. Not every protocol needs native integration. But for core functions like borrowing and trading, where latency, liquidity, and leverage intersect, it may be time to stop thinking in layers and start thinking in systems. Ethereum’s breakthrough was to unify those fragmented designs into programmable money: one system flexible enough to serve many use cases.

Today, we stack apps and split lending, trending and yield farming across protocols, pools and platforms. But for core functions like borrowing and trading, where liquidity, leverage, and pricing converge, it may be time to stop thinking in layers and start thinking in systems.

The next wave of DeFi won’t come from stacking more Lego bricks on top of each other. It will come from rethinking the bricks themselves, and asking: isn’t it more efficient for a single system to provide the freedom and composability that once required dozens of separate protocols?