> 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/the-pool-and-its-book.md). # The pool and its book How an Efficient pool's book changes on each entry, sell, buy and exit, and how the pool values depositors' shares from it. **Every Efficient pool runs the same steps on each entry, sell, buy and exit.** The pool operator's choice of hooks and settings doesn't change them. Entries and exits are proportional. A sell borrows only what the pool can't pay from its own balances. A buy repays any debt first. A pool can connect to lending markets, but it doesn't have to. Steps at a lending market apply only to a pool that has one. Borrowing and collateral apply only to a pool that borrows. A sell trades the pool asset to the pool for the [first loan asset](/how-pools-work/just-in-time-financing.md#loan-assets-and-the-drawn-set). That's the other token in the pool's pair, the one the pool can borrow. It's the only loan asset that trades directly against the pool asset. A buy is the reverse. The examples use the book of a hypothetical Efficient pool that borrows. It trades the first Everlong vault's pair, cbBTC against USDC on Base, and it's financed through Morpho Blue. Its pool asset is cbBTC, and its first loan asset is USDC. ## The book **The pool's book is everything it holds and owes.** That's its pool asset, any debt, and any loan asset on hand or supplied. Its **gross holding** is the pool asset it holds directly plus any it has posted as collateral. A pool has collateral posted only where it borrows, or while it still owes debt from before its borrowing went off. The pool values each loan-asset balance in the pool asset at the feed price. The feed price is the ratio of the two assets' USD prices on its [price feed](/how-pools-work/price-feeds-and-oracles.md). | Example book | Amount | | ------------------------ | ------------------ | | Gross holding | 100 cbBTC | | Debt | $2,000,000 | | USDC on hand or supplied | None | | Feed price | $100,000 per cbBTC | | Debt at the feed price | 20 cbBTC | | Net asset value (NAV) | 80 cbBTC |
## Net asset value **Depositors' shares claim the pool's net asset value (NAV).** NAV is the gross holding plus each loan asset's net position at its feed price. $$ \text{NAV} = G + \sum\_{i} \frac{L\_i + S\_i - D\_i}{P\_i} $$ Here $$G$$ is the gross holding. The terms $$L\_i$$, $$S\_i$$ and $$D\_i$$ are loan asset $$i$$ on hand, supplied and borrowed. Its feed price $$P\_i$$ is in units of that loan asset per unit of the pool asset. The pool rounds what it holds down and what it owes up. NAV never goes below zero. On the example book, NAV is 100 minus 2,000,000 over 100,000, which is 80 cbBTC. {% hint style="info" %} NAV nets these balances for valuation only. Netting doesn't repay any debt. {% endhint %} A book that owed $2.5m and had supplied $500,000 would also show 80 cbBTC. It would still pay interest and face liquidation checks on the full $2.5m. The pool normally doesn't carry debt and supply together. That's because a sell withdraws supply before it borrows, and a buy repays before it lends. The pool's `totalAssets` returns NAV. [Understanding returns](/use-efficient/provide-liquidity/understanding-returns.md) covers value per share and what moves it. ## Entry **The pool's own deposit calls add to every part of the book in proportion.** So each share carries the same slice. With `depositProRata`, the new shares are the same fraction of the share supply as the deposit is of the gross holding. When the book owes the loan asset on net, the deposit borrows the new shares' slice of each debt. It pays the depositor their slice of the net debt. When the book holds a surplus instead, the depositor pays in the new shares' slice of the surplus. In a pool with lending markets, each position grows in proportion. Where the pool borrows, it posts [collateral](/how-pools-work/credit-and-collateral.md#the-ltv-pin-and-collateral) before it borrows. Interest or a price fall can push a market past the LTV pin. In that case, the deposit posts extra collateral there to restore the pin. The deposit draws on the pool's idle pool asset where its own falls short. The second deposit call, `mintProRata`, is sized in shares. It serves only a book that owes nothing, so it never borrows. Its cap on the share supply is zero at creation. That keeps it closed until the pool operator raises the cap. Depositors with only the pool asset use the asset router or the entry market. The asset router builds on `depositProRata` in pools with one loan asset. [Provide liquidity](/use-efficient/provide-liquidity.md) covers both routes and what can stop a deposit. ### Entry example On the example book, a proportional deposit of 1 cbBTC is 1% of the gross holding. It runs in this order: 1. The depositor pays in the 1 cbBTC. 2. The pool increases its posted collateral by 1%. 3. The pool borrows 1% of its debt, which is $20,000, and pays it to the depositor. 4. The depositor receives new shares equal to 1% of the existing supply. The depositor now holds shares worth 0.8 cbBTC net, plus the $20,000 of USDC. ## A sell **A sell pays the trader in the first loan asset.** The pool borrows only what its balances can't cover, if it borrows at all. It funds the payout in this order: 1. It uses the loan asset it holds on hand. 2. If that isn't enough, it withdraws what it has supplied to lending markets. It follows the withdraw order, set by the keeper, the pool operator or the controller hook. 3. Before each borrow, it posts enough pool asset as collateral to keep that market's debt within the pool's [LTV pin](/how-pools-work/credit-and-collateral.md). That debt includes the new borrow. It can post any pool asset it holds, including what the trader is selling. 4. It borrows the remainder, in the borrow order. 5. It pays the trader. All five steps run inside the trader's swap transaction. A sell paid wholly from the loan asset on hand withdraws no supply, posts no collateral and borrows nothing. With borrowing in the loan asset switched off, a sell only withdraws supply and posts no collateral. It fills only up to the loan asset the pool holds on hand and has supplied. A pool with no lending market pays every sell from the loan asset on hand. The [execution buffer](/how-pools-work/just-in-time-financing.md) settings decide how much loan asset a pool with lending markets keeps on hand. The pool's [invariant hook](/how-pools-work/hooks.md) prices each fill. The pool settles and checks every fill the same way, whichever hooks it runs. Where the pool can borrow, a sell fills only up to the credit room under the LTV pin. No sell fills past the per-swap cap. A funding shortfall reverts the sell whole. [Credit and collateral](/how-pools-work/credit-and-collateral.md) covers those limits. The pause stops sells, and [Roles and governance](/run-a-pool/roles-and-governance.md) covers it. ## Interest before each swap **Every read of a lending-market position includes interest owed up to the current block.** So the book, credit room and NAV use current balances. While borrowing in the first loan asset is on, each swap first accrues that interest. That only makes later reads cheaper in gas. A pool with no lending market has nothing to accrue. ## A buy **A buy runs the other way and repays any debt first.** The trader pays the first loan asset and receives the pool asset. The steps run in this order: 1. The pool repays debt with the trader's payment and any loan asset on hand, up to the whole debt. It repays in the repay order and skips only a lending market that refuses a repay. 2. The pool keeps its reserve target of any leftover loan asset on hand. It lends the excess once that reaches the minimum supply batch. Lending stays within supply caps and the conditions the [execution buffer](/how-pools-work/just-in-time-financing.md#the-execution-buffer) sets. 3. The pool pays the trader in the pool asset. It pays first from what it holds directly, its execution buffer in that asset. Next it draws on collateral above what the LTV pin requires, then on collateral the repayment freed. If that falls short, the buy reverts with `InsufficientCollateral`. 4. It releases posted collateral above what the LTV pin requires. It does so only when that excess is at least 10% of its posted collateral. A pool with no lending market keeps the whole payment on hand. It pays the trader only from the pool asset it holds. Collateral enters steps 3 and 4 only in a pool that owes debt. A buy takes the [credit check](/how-pools-work/credit-and-collateral.md#deposits-buys-and-exits) too. No pause stops it. ## Exit **The pool's own exit call, `redeemProRata`, reverses a proportional deposit and pays in kind.** It reads no price. It withdraws each lending market's supply, repays any debt and releases any collateral in proportion to the shares redeemed. The owner of the shares or an approved address calls it. The caller provides the shares' slice of any net debt in each loan asset. The receiver gets the pool asset and the shares' slice of any net surplus. At creation, 1,000 base units of shares are locked at a dead address, and they always remain. So any holder can redeem every share. An exit can revert on its [ratio test](/how-pools-work/credit-and-collateral.md#deposits-buys-and-exits) or wait on a lending market's own limits. [Provide liquidity](/use-efficient/provide-liquidity.md#what-can-stop-a-deposit-or-an-exit) covers what can stop one. ### Exit example On the example book, 1% of the shares carries $20,000 of debt and a claim on 1 cbBTC. Redeeming them runs in this order: 1. The depositor brings $20,000 of USDC. 2. The pool repays that $20,000 of debt and releases the shares' slice of the collateral. 3. The pool pays the depositor in kind, which on this book means cbBTC alone. The depositor receives the 1 cbBTC the shares claim. That's 0.8 cbBTC net of the $20,000 the depositor provided, valued at the feed price. ## When a position can't be read **The pool never values its book with a lending-market position left out.** It admits a Morpho Blue market only if its rate model qualifies. The model must run the reviewed AdaptiveCurveIrm code, checked by code hash. That model answers every state the market can hold. So the `IrmUnreadable` revert in the Morpho Blue lending-market account never runs for an admitted market. A venue type that can stop answering must report its last good position. It must also refuse every action while it can't be read. Morpho Blue is the only venue type in the code, and it can't reach that state. The pool reads such a position as frozen. NAV and both share conversions revert with `VenueFrozen`, and no deposit or exit moves at those figures. Swaps read no NAV, so they go on. NAV also reverts with `PriceUnchecked` while a loan asset with a position has no checked feed price. A pool with no price band reads no feed price. So its NAV reverts this way whenever it holds any loan asset.