> For the complete documentation index, see [llms.txt](https://docs.efficientdex.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.efficientdex.com/how-pools-work/just-in-time-financing.md).

# Just-in-time financing

How an Efficient pool that borrows funds the other side of its pair only when a trade needs it, through one shared financing router.

**An Efficient pool that borrows doesn't prefund the other side of its pair.** Instead, it borrows that side inside the sell that needs it. A pool can also keep borrowing off, or run with no lending market at all.

The other side of the pair is the pool's first loan asset: USDC, in an Efficient pool that trades BTC against USDC. Any other token the pool can borrow is also a loan asset.

One financing router, shared by every pool, works with the lending markets each pool operator chooses. It supplies idle loan asset there. For a pool that borrows, it also borrows, repays and posts collateral.

[The pool and its book](/how-pools-work/the-pool-and-its-book.md) follows a sell and a buy step by step. [Credit and collateral](/how-pools-work/credit-and-collateral.md) covers how much a pool can borrow.

## The financing router

**Pools reach their lending markets through one shared contract, the financing router.** The router never holds a token. Each transfer settles between the pool and the pool's account at the lending market. Only the four emergency calls act on that account directly, as [Credit and collateral](/how-pools-work/credit-and-collateral.md#emergency-calls) explains.

The contracts call each lending market a pool uses a venue, such as one Morpho Blue market. Each venue type plugs in through its own account contract. The router deploys that contract for each pool and loan asset.

Morpho Blue is the only venue type today. The protocol Safe makes a new venue type available to every pool after the factory's upgrade delay.

| Limit       | Value                                                                                |
| ----------- | ------------------------------------------------------------------------------------ |
| Loan assets | Up to 16 per pool, against one pool asset                                            |
| Venues      | Up to 32 per pool, within the router's limit of 64. A retired venue's slot is reused |

Each venue is a separate position at its lending market, so a liquidation at one venue never reaches collateral posted at another.

The protocol Safe can pause new borrowing and supply on the router, for every pool at once. Repaying, withdrawing supply and releasing collateral continue during a pause, so buys and exits still settle.

### Loan assets and the drawn set

**Only the first loan asset trades directly against the pool asset.** So it's the only loan asset a sell pays out or borrows. A `swap` naming another loan asset reverts with `InvalidPair`.

The other loan assets trade only through a loan-to-loan swap. A loan-to-loan swap needs the pool's optional loan-to-loan swap hook and feature bit 6, `FEATURE_LOAN_SWAP`. See [Hooks](/how-pools-work/hooks.md). The swap logic is in audit. No loan-to-loan swap hook has shipped yet, so no pool runs one today.

The **drawn set** is the set of loan assets carrying debt at one time. By default it holds at most one. The router refuses a borrow in any other loan asset once the set is full. The set never limits repaying or supplying a surplus.

The pool operator sizes the drawn set with `setRiskLimits`, up to the number of loan assets. The guardian can only lower it.

### Adding venues and loan assets

A pool operator adds a venue or a loan asset in two calls. The first call schedules it. The identical call, made after the pool's governance delay, executes it. Venues named at creation skip the delay. The guardian can cancel a scheduled addition.

A venue must be an existing market that lends the pool's loan asset against its pool asset. Its rate model must run the reviewed code. While the oracle band is on, the venue's oracle must sit inside the band, and admission needs a checked feed price for the loan asset.

A venue admitted with borrowing on also needs a liquidation LTV that clears the LTV pin plus the safety gap. A venue admitted with borrowing off may sit under that bound. Its borrowing can't be switched on until it clears it.

A pool with no price band reads no price. So it skips both price checks and admits only venues with borrowing off.

[Roles and governance](/run-a-pool/roles-and-governance.md) lists every call for adding, cancelling and retiring, and the conditions for retiring. [Configure a pool](/run-a-pool/configure-a-pool.md) covers pools that only supply or use no lending market.

## Funding orders

**A pool works through its venues in four orders.** There's one each for borrowing, supplying, withdrawing supply and repaying. The keeper, the pool operator or a bound controller hook sets them with `setPriorities(borrow_, supply_, withdraw_, repay_)`. Each order lists every live venue once.

At creation, all four follow the order the venues were listed in. Each new venue joins the end. Retiring a venue removes it from all four, and the venue listed last takes its place.

A sell pays first from the loan asset on hand. Past that, it withdraws supply in the withdraw order, up to each venue's free cash. Then it borrows in the borrow order, if borrowing is on. With the loan asset's borrow switch off, a sell pays out no more than the loan asset on hand plus what the pool has supplied.

A buy repays debt in the repay order, then supplies any surplus in the supply order.

For example, take a hypothetical Efficient pool with borrowing on and USDC as its first loan asset. Its book has 10,000 USDC on hand, 15,000 USDC supplied and no debt. A sell that pays out 50,000 USDC uses the 10,000, withdraws the 15,000 and borrows the other 25,000.

The router's `fund` plans the whole shortfall past the loan asset on hand before it moves anything. If the plan falls short, it reverts with `InsufficientLiquidity`, so it never funds part of a payout.

### Moving debt and supply between venues

The keeper, the pool operator or the controller hook moves debt or supply between two venues of one loan asset. The call is `maintain(kind, a, b, amount)`. The kind `Refinance` moves debt with its share of collateral. The kind `MigrateSupply` moves supply.

Each kind needs feature bit 4, `FEATURE_MAINTENANCE`, switched on. Each checks that the total is conserved, and each stops while the router is paused.

A refinance checks the receiving venue's bounds from [Limits on new borrowing](/how-pools-work/credit-and-collateral.md#limits-on-new-borrowing). These include a liquidation LTV that clears the pin plus the safety gap. A refinance doesn't check the loan asset's borrow switch or debt cap. On a partial move, the source venue must also pass the oracle band and stay within the pin.

## The execution buffer

**A pool's execution buffer is what it keeps on hand of each asset.** It lets a trade pay out without a lending-market call. The pool operator sets the loan asset's buffer. The pool asset's buffer is all the pool asset the pool holds outside its lending markets.

### The loan asset's buffer

**Each loan asset has a reserve target and a minimum supply batch.** The reserve target, `reserveTarget`, is the amount the pool keeps on hand. The minimum supply batch, `minSupplyBatch`, is the smallest surplus it supplies. Both are absolute amounts in units of the loan asset, not a share of the pool's value.

A buy repays debt with everything on hand before it keeps any back. So the buffer builds only once the debt is repaid. The pool then supplies the whole surplus over the target once that surplus reaches the batch.

Supplying also needs the pool and the router unpaused, a live venue, and feature bit 3, `FEATURE_SUPPLY_LENDING`, switched on. Supply caps limit it.

**The buffer and the batch save gas.** A sell paid from the buffer withdraws, borrows and posts nothing at a lending market. The batch means fewer swaps carry a supply call.

The loan asset held back earns no supply interest, so a pool operator weighs that interest against the gas.

A batch of zero, the default, supplies every surplus. A batch at the maximum supplies nothing. With the loan asset's borrow switch off, a payout that withdraws supply also refills the buffer to the target, if the venue has the cash. That refill needs a batch above zero and below the maximum.

The pool operator sets the reserve target with `setLoanConfig`, or with `setRiskLimits` for the first loan asset. It sets the batch with `setMinSupplyBatch`. The guardian can only raise the reserve target and the minimum supply batch, never lower them.

### The pool asset's buffer

**In a pool that borrows, the pool asset's buffer is the pool asset not posted as collateral.** Borrowing posts only what the LTV pin requires. A buy pays from that buffer before it reclaims any collateral.

A pool that never borrows has no collateral, so all of its pool asset stays on hand. [Credit and collateral](/how-pools-work/credit-and-collateral.md) covers when a pool that borrows posts more, and when a buy releases collateral.

The pool operator can set a reserve for this buffer with `setPoolAssetReserve`. A buy then refills the buffer only up to the reserve and leaves the rest posted. The reserve rule needs a venue that pays a return on collateral. Morpho Blue doesn't, so no pool can switch it on today. The guardian can only switch the rule off.