Lending utilisation is the share of a pool’s supplied assets that has been borrowed, and it is the number that decides both what borrowers pay and whether suppliers can withdraw. A pool at 60 percent utilisation behaves nothing like the same pool at 99 percent, even though the interface may show the same headline yield.
Understanding lending utilisation turns a confusing experience into a predictable one. If your withdrawal was queued, the pool was not broken: it had lent out nearly everything it held, and the queue is the mechanism that keeps accounting solvable while borrowers still owe the money.
- Utilisation is a ratio, not a balance. It equals borrows divided by supplied assets, so it rises when people borrow and when suppliers withdraw.
- Rates are a function of it. Most markets use a curve with a kink, so borrowing gets sharply more expensive above a target level.
- Idle liquidity is the withdrawal budget. Only the unborrowed portion can leave immediately, which is why queues appear at high utilisation.
- A queue is a design feature. It prevents a first-come-first-served run from leaving later suppliers with an unfillable claim.
What lending utilisation measures
Lending utilisation measures how much of the supplied pool is working, and it is calculated as total borrows divided by total supplied assets. If a pool holds 10 million in supplied assets and 9 million is borrowed, utilisation is 90 percent and only 1 million is idle.
The formula and its moving parts
The ratio has two inputs that move independently. Borrows change when users take or repay loans, and supply changes when users deposit or withdraw. That means a supplier withdrawing can push utilisation up even if no one borrows another unit, because the denominator shrinks while the numerator holds.
Many pools also carry a reserve component that accrues to the protocol. Where reserves are subtracted before the ratio is computed, the figure you see differs slightly from a simple borrows-over-supply division.
Why 100 percent is a special case
At full utilisation there is no idle liquidity at all. Interest keeps accruing because borrowers still owe the balance, but nothing can be withdrawn until someone repays. That state is not a software failure; it is the arithmetic consequence of lending out every unit that was deposited.
How lending utilisation sets the borrow rate
Lending utilisation drives the borrow rate through a curve that most markets publish openly. The curve is flat-ish at low utilisation and steep above a target, commonly called the optimal or kink point, which usually sits somewhere between 70 and 90 percent depending on the market.
Below the kink
Below the target, borrowing is cheap and the rate rises slowly with demand. The design intent is to keep capital employed without punishing ordinary borrowing, while suppliers earn a modest yield.
Above the kink
Above the target, the curve steepens sharply. Borrowing becomes expensive quickly, which is deliberate: the rate is doing the job that a queue would otherwise do, by persuading borrowers to repay and suppliers to deposit. In stressed conditions the borrow rate can rise by orders of magnitude within a short window, and the headline supply yield rises with it.
That high yield is not free money. It compensates for liquidity risk, and it is paid in a claim you cannot withdraw until utilisation falls.
Why the withdrawal queue exists
The withdrawal queue exists because a pool’s assets are loaned out, and a claim on a loan cannot be settled instantly without someone taking the other side. When idle liquidity runs out, requests are held in order rather than satisfied out of thin air.
Design feature, not outage
A queue is how a pooled lending market stays solvent under a run. Honouring withdrawals purely in arrival order with no limit lets the first suppliers out take the idle cash, leaving the last with a claim on a pool that has none. Queuing, batching or pro-rata treatment spread that constraint across all claimants instead of concentrating it on whoever arrived last.
A queue is the market telling you the truth about maturity mismatch: your deposit was callable, the loan it funded was not, and something has to give.
How a queue clears
Queues clear in three ways. Borrowers repay and restore idle liquidity. New suppliers deposit, adding liquidity but diluting the elevated yield. Or the market allows a secondary exit, such as transferring the receipt token at a discount. Each route has a cost, and that cost is a direct read on how tight the pool is.
| Utilisation band | Borrow rate behaviour | Withdrawal availability |
|---|---|---|
| Below 50% | Low and stable | Normally immediate |
| 50 to 80% | Rises gently with demand | Usually immediate for normal sizes |
| 80 to 95% | Sharply higher above the kink | Can queue if requests exceed idle cash |
| 95 to 99% | Very high, volatile | Queues likely, clearing depends on repayments |
| At or near 100% | At or near the curve maximum | Fully blocked until repayment or new deposits |
A worked example of a queued withdrawal
Take a pool with 10,000,000 supplied and 9,000,000 borrowed. Utilisation is 90 percent and idle liquidity is 1,000,000. A supplier requests 1,500,000 back.
Only 1,000,000 can leave immediately. The remaining 500,000 enters the queue, and the pool sits at 100 percent utilisation the moment the first tranche is paid, because supply falls to 9,000,000 while borrows stay at 9,000,000. Paying the full 1,500,000 out of hand is arithmetically impossible: supply would fall to 8,500,000 against 9,000,000 of borrows, which is more than the pool owns.
Now suppose a borrower repays 600,000. Idle liquidity becomes 1,600,000, the queued 500,000 clears, and utilisation settles at 8,400,000 divided by 10,000,000, or 84 percent. The withdrawal completes because the underlying loan was repaid, not because the protocol relented.
Two things follow. Your place in the queue matters, so submitting early beats submitting large. And the wait is a function of borrower behaviour, so a pool can stay blocked for as long as borrowers choose to stay in.
What to check before you supply
Check utilisation history, not the current reading alone. A pool that has sat above 90 percent for weeks has a different exit profile from one that touched it briefly.
- Read the current utilisation and the kink parameter, so you know how much room sits below the steep part of the curve.
- Compute idle liquidity as supplied assets minus borrows, and compare it with the size you might want to withdraw.
- Look at the utilisation chart over the past month for how often it has exceeded 90 percent.
- Identify who is borrowing, if the market publishes it, and how concentrated those positions are.
- Check whether the market supports batching, a withdrawal window, or a transferable receipt token as alternative exits.
- Size the deposit so that your realistic withdrawal is a small share of typical idle liquidity, not of total pool size.
The last step prevents most unpleasant surprises. Liquidity risk here is a personal number: it depends on the ratio between your position and the pool’s idle cash, not on the pool’s advertised size.
0 comments
No comments yet — ask a question and we will answer it here.