> 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/use-cases.md). # Use cases What Efficient pools are for: leveraged market making, yield on idle inventory, tranches, exits, gains for token issuers and lending markets, and cheaper debt, now in audit. **Efficient pools serve market makers, token issuers and lending markets.** Each use depends on how the pool operator sets up the pool. [How Efficient works](/how-efficient-works.md) explains the mechanism behind each one. Each pool values its shares in one token, the pool asset, and trades it against the other side of its pair. For example, take an Efficient pool that trades BTC against USDC, where depositors have put in only BTC. BTC is the pool asset. USDC is the other side, and the pool can borrow it from a lending market. ## Leveraged market making **An Efficient pool that borrows can quote more depth than its deposits.** A trader who sells pool asset gets paid in the other token. If the pool doesn't have enough of that token, it borrows the rest. The [credit check](/how-pools-work/credit-and-collateral.md#the-credit-check) caps that debt at the pool's LTV pin. The leverage a pool reaches follows from its pin, so it differs from pool to pool. The pin must sit below the lending market's liquidation LTV. As a guide, leverage runs from about 1.2x to 10x on volatile pairs and from 10x to 40x on stable pairs. The pin is the pool's own setting. The pool's safety gap and minimum distance set how close the pin can sit to that liquidation LTV. For example, take an Efficient pool whose depositors have put in only pool asset. It has a credit setting of 1 and a pin of $$\ell$$. Sells can grow the pool asset it holds and has posted as collateral to about $$1/(1-\ell)$$ times that deposit. Depth is also capped by: * each lending market's free liquidity * the debt caps set for each venue * the pool's per-swap cap **A market maker can price its pool with its own invariant hook.** That puts the pricing model it already uses onchain. As a backstop, every pool that borrows bounds the hook's fills with a price band. The band is up to 10% around the pool's feed price. [Build a hook](/run-a-pool/build-a-hook.md) covers what a hook must return. ## Yield on idle inventory **A pool lends out spare tokens on the borrowed side.** Spare means above its execution buffer, the amount it keeps on hand to pay trades. The pool supplies them to its lending markets, where they earn the supply rate between trades. That interest offsets what the pool pays while it borrows. When a trader buys pool asset, the tokens they pay first repay any debt the pool owes in that token. The pool then supplies what's left above the execution buffer. The pool operator or the keeper sets the order of supply across the lending markets. A controller hook can order it instead, by conditions the pool operator sets. ## Cheaper debt through loan-to-loan swaps **Loan-to-loan swaps let traders move a pool's debt into a token that's cheaper to borrow.** Each swap trades one borrowable token for another. The pool's loan-to-loan swap hook prices each swap, fee included. That gives the pool's debt its own price and fee. The pool needs at least two tokens it can borrow. For example, take an Efficient pool that can borrow both USDT and USDC. It starts out owing USDT, while USDC is cheaper to borrow. A trader pays in USDT and takes out USDC. So the pool repays USDT debt and borrows cheaper USDC instead. **No pool runs a loan-to-loan swap yet.** The pool code supports them through `swapLoan` and is in audit. Each pool adds its own loan-to-loan swap hook when it deploys, or later through a new hook set. The pool operator must also switch on feature bit 6, `FEATURE_LOAN_SWAP`. Both Everlong vaults, on Base and Katana, leave it off. ## Tranches for market makers **A tranche controller splits a pool's shares into two claims.** The senior claim accrues a target rate. The junior claim takes the first loss. A market maker can offer the senior claim to outside depositors and hold the junior claim itself. The senior claim loses value only once the junior claim is used up. The market maker keeps what the pool earns above the target rate. [Tranches](/use-efficient/provide-liquidity/tranches.md) covers how this works. ## Exits without rebalancing **The entry market takes deposit and exit requests for a pool's shares as intents.** Each request has a minimum output. An exit can settle against a deposit request at value per share, or against a maker's own inventory. Either way, existing shares change hands and the pool's book is left alone. So the exit unwinds nothing. In a pool with only one token besides its pool asset, an exit can also settle through the pool. That unwinds the book pro rata. [Provide liquidity](/use-efficient/provide-liquidity.md) covers each way a request settles. ## Token issuers **A token issuer can bring only its own token and have the pool borrow the other side.** The issuer chooses the lending market. The issuer's token is the pool asset, so the issuer funds no second asset to make a market in it. This needs a price feed for both tokens, and a lending market that lends against the issuer's token. A pool can also run with no lending market and trade only what it holds. Without a price band, such a pool needs a feed only for the other token, but its invariant hook must price without a feed. The pool is then limited to that one other token. It never borrows and charges no performance fee. ## Lending markets **Pools that connect to a lending market bring the teams that manage it new borrowing, new supply or both.** Pools borrow there to fill sells. They supply idle tokens on the borrowed side back to the market. That borrowing raises the market's utilisation. Higher utilisation lifts the supply rate the market's depositors earn. ## Distribution [Integrate](/integrate.md#choose-a-route) lists the routes into a pool. [Swaps for aggregators and solvers](/integrate/swaps-for-aggregators-and-solvers.md) covers the adapters and the KyberSwap source. ## The PropAMM venue, in development **In a PropAMM venue, market-making desks quote their own signed prices.** Efficient's PropAMM venue is in development, and none of it is deployed. In the plan, each desk holds one signing key and one WebSocket. It would hold no builder keys, wallets or gas of its own. On Ethereum, a relay would send each pair's newest signed quotes to the builders Titan, BuilderNet, Quasar and Bombora. Together they build just over 80% of blocks. A builder would land the quotes at most once a block, and only right before a fill that reads them. Each fill would be checked against a Pyth Pro price. The pool would never sell below that price less a set fence, or buy above it plus the fence. The plan sets gas targets for fills paid from the pool's own inventory, proxy included. They're 130,000 to 145,000 gas on Ethereum and 135,000 to 155,000 on Base. Rollout is planned for Ethereum first, then Base. ## Already running **The first Everlong vault runs on Efficient through the Everlong hook, the first custom hook.** The vault trades cbBTC against USDC on Base. Depositors put in cbBTC, and the vault can borrow USDC. The hook manages the vault's leverage through the prices it quotes, the way a market maker manages inventory. [Everlong](https://docs.foreverlong.io/everlong) documents the strategy. [Deployments](/reference/deployments.md) lists every chain where Efficient runs. ## What's next **Four things are planned next:** * the PropAMM venue on Ethereum * more custom hooks * lending-market accounts for Aave and Euler * the first pools run by outside pool operators