Aave V3.6 Isolation Debt Ceiling vs Borrow Cap

In Aave V3.6, an isolation debt ceiling limits the normalized debt recorded against one isolated collateral reserve across its borrowers. A borrow cap limits total debt in one borrowed reserve, in that token's units. Both can constrain the same loan. These are legacy mechanics: V3.7 removes isolation-mode debt ceilings, and Aave V4 uses a different Hub-and-Spoke model.

A wallet can have enough collateral to support another loan while a reserve-wide limit blocks it. To explain that rejection, identify which reserve owns each limit before comparing any numbers. The collateral's isolation budget and the borrowed token's cap measure different groups of loans. Neither is a private allowance reserved for one wallet.

Establish the version before reading the fields

This walkthrough pins the EVM Aave V3.6.0 release at commit 5a230ec. It explains the old isolation mechanism for interpreting historical states and integrations. Aave's V3.7 removal document explicitly deletes isolation debt-ceiling tracking and keeps some legacy data-provider outputs as defaults. A zero in an old field therefore needs a version check before interpretation. Aave V3.7 mode-removal specification.

The official changelog also records the V3.7 rollout in April and May 2026. That is a reason to verify a market's implementation at the observation block, rather than assume a page headed “V3” still uses V3.6 logic. Aave protocol changelog.

V4 is a separate architecture: Hubs centralize liquidity and accounting, while Spokes manage user-facing borrowing with their own risk configuration. Its credit and debit lines should not be substituted for the V3.6 counters below. Current Aave V4 overview.

Put each limit beside the reserve it controls

In the pinned implementation, the borrow cap is read from the borrowed reserve's configuration. When it is nonzero, validation compares the reserve's post-borrow indexed variable debt with the cap multiplied by that token's decimal unit. A cap of zero disables this particular cap check. V3.6 borrow-cap validation.

Isolation accounting looks elsewhere: it identifies the account's isolated collateral reserve and updates that reserve's isolationModeTotalDebt. The borrowed asset must be permitted for isolation borrowing, and the resulting counter must not exceed the collateral reserve's debt ceiling. V3.6 isolation-accounting logic.

The third row is another gate. It prevents “under both aggregate limits” from becoming “the account can borrow.” The LTV versus liquidation-threshold guide explains that separate account calculation. The collateral-haircut guide also helps identify when a displayed amount is recognized support rather than borrowing permission.

Construct two collateral budgets and one shared debt reserve

Everything in this example is hypothetical. X, Y and D are invented assets; the ceilings and balances are teaching inputs, not live Aave parameters or a borrowing recommendation.

Assume two separate sets of accounts in the same V3.6-style pool. One set uses only X as collateral; the other uses only Y. No account combines the two isolated collaterals. D is the sole debt token considered, has six decimals, and is configured as borrowable in isolation. Both collateral assets have usable nonzero LTV, and all account, liquidity, permission and reserve-status checks pass.

Set the variable borrow index to exactly one ray, meaning 10^27, and assume no interest accrues between these snapshots. This removes index rounding from the main example. In actual V3.6 accounting, scaled debt is minted with upward rounding and reconstructed debt also rounds upward; preserve those rules near a boundary. Pinned V3.6 token arithmetic.

The isolation constant has two decimals. Thus 1,000,000 stored ceiling units display as 10,000.00 normalized units. This is a decimal conversion, rather than the six-decimal conversion for raw D. V3.6 reserve-configuration constants.

Separately, D's borrow cap is 50,000 D and its current aggregate debt is 48,500 D. The borrowed reserve has 1,500 D of room under these assumptions. Its debt includes borrowing against X, Y and any other collateral in the pool; its cap is not assigned separately to each collateral.

Adding the two displayed local budgets gives 4,800, but that does not create 4,800 D of shared borrowing capacity. The D reserve has only 1,500 D of cap room. The supply-cap versus borrow-cap comparison extends the same reserve-ownership check to the supply side.

Test the same request against both ledgers

For D, divide the raw requested amount by 10,000 to convert six token decimals into two isolation decimals. A request for 700 D is 700,000,000 raw units and adds 70,000 to X's counter.

The following rows are independent alternatives, each starting from the original snapshot. “Pass” means both modeled aggregate gates pass; the other checks remain assumed satisfied.

The 900-D request against X fits D's shared cap, but its isolation counter would exceed 1,000,000. The 1,600-D request against Y fits Y's ceiling, but D's aggregate debt would exceed 50,000 D. Increasing one limit would leave the other restriction intact.

These are transaction checks. Borrow validation and the isolation update belong to the same borrow execution; a failed check reverts that attempted transaction's changes. A failed 900-D request does not consume part of X's counter. Pinned V3.6 borrow execution.

Now make the order sequential. If X's 700-D request confirms first, D debt becomes 49,200 D. Y's previously passing 1,200-D request would then produce 50,400 D and fail the common cap. A request for 800 D instead reaches exactly 50,000 D and raises Y's counter to 1,680,000. Both collateral budgets still have local room, but D has none. A saved simulation cannot reserve that shared capacity against intervening borrowing.

Read the normalization without inventing a dollar oracle

The isolation conversion divides the borrowed token's raw amount by a decimal scale using integer division. For a separate illustrative request of 123.456789 D, the input is 123,456,789 raw units. Division by 10,000 produces 12,345 stored isolation units, displayed as 123.45. The discarded 0.006789 D remains part of the actual borrowed amount; it was not rounded out of the loan.

The borrow-cap calculation retains underlying debt precision through its own scaled arithmetic. Reusing the truncated 123.45 in that check would understate the request. Displayed isolation headroom is therefore insufficient to reconstruct an exact raw-token boundary.

There is also no oracle-price multiplication in this isolation conversion. A ceiling displayed in dollars must not be read as a continuously revalued dollar debt total. If D's oracle price changes, the account valuation can change even though the same raw borrow still produces the same isolation increment. An apparently stable counter does not prove stable economic exposure.

Interest and repayments move the ledgers differently

The pinned isolation counter does not independently accrue interest. By contrast, the reserve cap comparison uses indexed variable debt. As a separate hypothetical later snapshot, suppose the 49,200-D reserve debt after X's accepted loan grows to 50,100 D through aggregate interest accrual, with no intervening borrows or repayments. X's isolation counter remains 990,000. A new positive D borrow would fail the cap even though X still shows local room.

That constructed growth has no assumed time period or interest rate. Crossing the borrow cap through accrual is also distinct from the account health-factor test; this pair of aggregate limits does not itself establish liquidation eligibility.

A repayment reduces actual debt and can reduce the relevant isolation counter by its normalized amount. The isolation reduction floors the result at zero because a repayment including interest can exceed the recorded counter. Repaying debt associated with Y does not create local X ceiling room, although repayment of D can relieve D's shared reserve cap. Keep the collateral association beside each repayment. V3.6 isolation-counter updates.

For how collateral eligibility and account mode interact with these limits, use the version-scoped eMode versus isolation-mode comparison. Changing an account mode is not a substitute for identifying which aggregate ledger rejected a request.

Keep a reproducible rejection worksheet

Retain the following evidence together, preferably at one block:

Start by establishing whether the old isolation mechanism exists at that block. Then calculate the selected collateral's counter and the borrowed reserve's aggregate debt in their own units. Report the failed comparison with both operands and the governing limit. That record explains why the request fails and which shared state must change before the same request could pass.