> For the complete documentation index, see [llms.txt](https://docs.ammplify.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ammplify.xyz/technical-specs/liquidity-lending.md).

# Liquidity Lending

Lending liquidity is how we redirect liquidity from one protocol to another. There are two ways this can be triggered, **Active Multiplexing and Passive Multiplexing borrows,** two types of borrows that can be initiated, **Secure and Insecure Borrowing,** and two types of borrow sizing, **by Tranche and by Range.**

**Remember that any user can opt out of allowing Range borrows, Tranche borrows, or both. If you just want a few utilities on top of your basic LP and no fancy yield stacking, more power to you!**

## Range vs. Tranche

* A **ranged borrow** borrows liquidity from a given price range. To satisfy this the liquidity tree finds the proper breakdown for that range and inserts negative balances into its bookkeeping. Then Hyperplex actually sources the liquidity from those nodes which means either removing it from the base protocol or from a tranche borrow. When sourcing, if the exact nodes for the desired breakdown has insufficient liquidity, then it borrows from parent nodes. If parent nodes are insufficient, the borrowing protocol should split the range into distinct calls to utilize child nodes.
* A **Tranche borrow** is specific to AMM liquidity. The AMM's ticks are split into tranches according to their distance from the current token price as indicated by a Chainlink oracle. Only the tranche containing the active tick is deployed to the AMM to collect fees. The other tranches are deployed to passive sources of income such as money markets. When the oracle changes, a call is made by our off-chain infrastructure to rebalance if necessary. 
  * There is hysteresis in the rebalancing requirements to minimize rebalances.
  * This rebalancing is not like AMM liquidity rebalancing. Your out of range liquidity remains out of range and your IL risk is not increased. This rebalancing does not pose a risk to users, it only affects capital efficiency.
  * Tranche sizing is based on the token pair's volatility.
  * There is the rare possibility that a large swap moves the price directly into another tranche, therefore we'll miss a portion of the swap fees for that specific move. While that may be true, this is actually profitable for tranche borrowed liquidity. See [The Tranche Rebalancing Premium](/technical-specs/liquidity-lending/the-tranche-rebalancing-premium.md) for details.

## Secure vs. Insecure Borrowing

* **Secure borrows** interact with Hyperplex, can manipulate the liquidity on Hyperplex, but never actually removes assets off of Hyperplex's smart contract. Additionally, they have to collateral for these borrows. The collateral to ensures they can pay fees and return the assets to their original constraints. These borrows are extremely safe.
* **Insecure borrows** actually move assets off the Hyperplex smart contract and promise to return it at a later time. For these the team and the borrower's auditors  throughly inspect any potential sources of risk. The fees charged to these protocol are higher and extra security guarantees like circuit breakers are implemented. These are riskier, but often result in higher returns.

## Multiplexing

An **active multiplexing** borrow is initiated by a protocol who needs to immediately reroute to satisfy a user's demand. For example, if someone opens a perpetual option the liquidity is rerouted in the same transaction as that open and is return in the closing transaction. 

A **passive multiplex** is a borrow that is less time sensitive and is often initiated by us. The requirements are validated on chain so in theory anyone can initiate a rebalance of a passive multiplex. These are not tied to any users but are managed by a strategy manager who might be a smart contract automating some requirements or an actual team of people. An example is the [Ambient AAVE](/technical-specs/liquidity-perks/strategy-yields/ambient-aave.md) layer, where we deposit inactive ticks into AAVE to collect a money market yield.