> 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-efficient-works.md). # How Efficient works How an Efficient pool is built from hooks, can reach lending markets through one router and caps any debt, and the checks every pool enforces. **An Efficient pool is built from hooks that price its trades.** It can reach lending markets through one shared router. Lending markets are optional, and a pool with none trades only the inventory it holds. The pool holds the book and issues ERC-20 shares valued in one token, the pool asset. It checks every fill against limits no hook can change. A pool that uses lending markets can borrow the other side of its pair from them. For example, take an Efficient pool that trades BTC against USDC, where depositors have put in only BTC. That pool can borrow USDC. [How pools work](/how-pools-work.md) covers each part below in detail. ## The hooks **Every pool runs three required hooks and can add two optional ones.** The hooks quote each swap's fill and fee from the pool's book. The pool pays the fill unaltered. * **Invariant hook.** The liquidity curve. It can be concentrated, amplified, laddered or a market maker's own pricing. Its fills stay inside a price band around the [feed price](/how-pools-work/price-feeds-and-oracles.md), where the pool has one. * **Fee hook.** Prices each fill's fee inside the pool's floor and cap. It can adjust the fee to volatility, inventory skew and trade direction. * **Recentring hook.** Folds checked prices into the curve and moves its anchor, within bounds the caller of `recenter` sets. * **Controller hook, optional.** Orders lending-market operations when a pool has more than one market. It can also refinance debt, move supply and collateral, and recentre, under conditions the pool operator sets. * **Loan-to-loan swap hook, optional.** Prices swaps between tokens the pool can borrow. This lets the pool pay traders to move its debt into a token that's cheaper to borrow. The swap logic is in the pool and in audit. A pool can take this hook when it's deployed, or later through a new hook set. The pool operator then switches on `FEATURE_LOAN_SWAP`. Every pool starts with one token it can borrow: the other side of its pair. So loan-to-loan swaps also need a second one, added after the governance delay. Neither Everlong vault, on Base or Katana, runs this hook yet. The deposit allowlist, not a hook, controls who can deposit. A pool bound to no allowlist at creation admits every depositor. [Hooks](/how-pools-work/hooks.md) covers each hook. [Build a hook](/run-a-pool/build-a-hook.md) explains how to write one, and [The Everlong strategy](https://docs.foreverlong.io/everlong/everlong-strategy) describes the Everlong hook. ## The financing router **One financing router handles borrowing, supply, repayment and collateral for every pool.** It never holds a token. Each transfer settles between the pool and its own account at the lending market. The router is built for any lending market with supply and borrow. It reaches each market through an account that implements one interface. Morpho Blue is the first and, today, the only one. Aave and Euler integrations are planned. **The router plans a sell's whole shortfall before it touches any lending market.** That's what the pool's borrowed-side tokens on hand can't cover. The router withdraws the pool's supply first. Then it sizes each borrow to that market's free liquidity, debt cap and borrow-rate ceiling. A sell the plan can't fund reverts. So depth on the borrowed side scales with free liquidity across the pool's lending markets, within its LTV pin. Each market is a separate position, so a liquidation in one Morpho Blue market never reaches collateral posted in another. ## Just-in-time financing and idle supply **A pool that borrows doesn't need to prefund its borrowed side.** A sell borrows only what the pool's tokens on that side can't pay. Each step runs inside the trader's swap. The pool pays from tokens on hand first, then from its supply, then with new borrowing. A buy repays debt first. Then it can lend out anything on the borrowed side above the execution buffer. A pool with borrowing off pays a sell only from what it holds and supplies. **The execution buffer is what a pool keeps on hand to settle trades without calling a lending market.** It covers both sides of the pair. On the borrowed side, it's each token's reserve target, `reserveTarget`. A buy keeps that reserve back only once it has repaid that token's debt. On the pool-asset side, it's the pool asset left unposted, since a buy releases collateral the pin no longer needs. **The pool supplies idle tokens on the borrowed side to its lending markets.** The pool operator or keeper sets the order. A controller hook can apply conditions instead. [Just-in-time financing](/how-pools-work/just-in-time-financing.md) covers each step in full. ## The credit check and the LTV pin **A credit check caps a pool's debt at its LTV pin after every sell.** The cap holds whatever the hooks quote. The pin sits at least a safety gap below the liquidation LTV of each market the pool borrows from. Each borrow posts collateral to the pin, so prices have room to move before a loan nears liquidation. The first Everlong vault trades cbBTC against USDC, and its depositors put in only cbBTC. It runs a pin of 0.55 against its Morpho Blue market's liquidation LTV of 0.86. [Credit and collateral](/how-pools-work/credit-and-collateral.md) covers every limit. [The pool and its book](/how-pools-work/the-pool-and-its-book.md) works through an example book. ## What every pool enforces These checks hold in every pool, whatever its hooks and settings. * **Price band.** Where a pool has a price band, every fill must price inside it, fee included (`PriceBand`). The band sits around the feed price and is at most 10% in code, under a committed ceiling. A pool can run with no band only with borrowing off, no second token to borrow and a hook that prices without a reference. * **Fee bounds.** A swap against the pool asset must carry a fee rate inside the pool's floor and cap. The pool refuses any fill outside them (`FeeOutOfBounds`). The cap sits under its own ceiling. A loan-to-loan swap carries no fee rate, so only the price band bounds its price. * **Credit check.** A sell must leave net debt at or under the LTV pin times the pool asset the pool holds and has posted (`LedgerBoundBreached`). * **Size limits.** A per-swap cap, where a pool has one, binds every fill whatever the hooks quote. A buy over the cap fills at the cap. A cap set to zero leaves the pool's swaps uncapped. The pool sets no deposit cap, so only a deposit's legs at each lending market bound it. Those legs must fit the pool operator's debt cap, supply cap and borrow-rate ceiling, and the market's cash. Entries through `mintProRata` have their own cap. An entry over it reverts with `DepositCapExceeded`. * **Open exits.** A pause never stops a proportional exit, a buy or the permissionless collateral top-up. No feature switch gates a proportional exit or the top-up. Buys have their own switch, `FEATURE_SWAP_BUY`, which the pool operator or the guardian can clear. * **Notice.** New hooks, new tokens to borrow and new lending markets wait out the pool's governance delay. So do rises in the performance fee or a ceiling. A band-ceiling raise waits at least 10 days. New pool code, new venue types and protocol-fee rises wait out the factory's upgrade delay. Both delays are at least a day in code. The first Everlong vault's pending redeployment sets each to 10 days. A new hook set executes only while the pool is paused. [Risks and safeguards](/use-efficient/risks-and-safeguards.md) covers what these checks mean for depositors. [Roles and governance](/run-a-pool/roles-and-governance.md) explains who can change each setting.