Aave V3 health factor is threshold-weighted enabled collateral value divided by the value of all outstanding debt. For several collaterals, weight each liquidation threshold by its oracle-valued contribution; exclude supplied assets that are disabled as collateral. Value every borrowed asset separately, including interest. A single liquidation price is conditional on the other collateral prices, debt prices, balances and applicable parameters staying as assumed.
The implementation details here are pinned to Aave V3.7.0, commit cff15de, checked on 28 October 2026. Check a market's deployed implementation and configuration separately. Match the chain, pool and implementation before applying the worksheet. The numerical account below is hypothetical throughout; its tokens and percentages are teaching assumptions, not current market parameters. Pinned Aave V3.7 account logic.
Begin with collateral flags, then count value
Assume one ordinary-mode account with no eMode category selected. Its supplied balances already include any accrual at this illustrative snapshot: 2 A priced at $2,000 each, 100 B priced at $20, and 1,000 C priced at $1. A and B are enabled as collateral; C is disabled.
Use the oracle's common valuation currency for every row. Dollars serve that role here. Do not add raw quantities of unrelated tokens or substitute the price on an unrelated exchange.
| Supplied asset | Oracle value | Collateral enabled? | Liquidation threshold | Weighted contribution |
|---|---|---|---|---|
| A | $4,000 | Yes | 80% | $3,200 |
| B | $2,000 | Yes | 70% | $1,400 |
| C | $1,000 | No | 85% if enabled | $0 |
| Counted total | $6,000 | — | — | $4,600 |
The account has $7,000 of supplied assets but only $6,000 in this collateral calculation. C's $1,000 is still a supplied balance. Its existence does not create liquidation support while its collateral flag is off. Aave's Pool exposes a control for enabling or disabling a supplied reserve as collateral; permission to change that setting has its own validation. Aave V3 collateral control.
The account also owes 2,500 D priced at $1 and 0.5 A priced at $2,000. Total debt value is therefore $2,500 plus $1,000, or $3,500. The A supply and A debt are separate entries.
This is already more information than a wallet's total balance can supply. The collateral valuation guide explains why market value, recognized support and borrowing capacity require distinct labels. Here, the first question is whether a supplied balance enters this account's collateral calculation at all.
Weight percentages by value
The liquidation numerator is the sum of the enabled contributions: $4,000 × 80% plus $2,000 × 70%, giving $4,600. Divide it by $3,500 of debt to obtain a health factor of approximately 1.3143.
The equivalent weighted liquidation threshold is $4,600 divided by $6,000, or 76.6667%. The collateral basket has twice as much A value as B value, so A's threshold receives twice the weight.
A simple average of 80% and 70% gives 75%. Multiplying $6,000 by that average produces only $4,500 of support and a health factor of 1.2857. The result is wrong even though it happens to be more conservative in this example. Reversing the values assigned to A and B would change the direction of the mistake.
Including disabled C would add a fictitious $850 contribution. That would inflate the numerator to $5,450 and health factor to 1.5571. A calculation can therefore look comfortably above 1 while counting collateral the protocol excludes.
Aave's published health-factor formula uses the value-weighted liquidation threshold, with eligibility for liquidation below 1. That threshold is different from the LTV parameter used for borrowing capacity. Aave's health-factor explanation. The LTV versus liquidation-threshold example covers that separate distinction.
Keep supplied A and borrowed A on separate sides
It is tempting to subtract the 0.5 A debt from the 2 A supply and enter a net holding of 1.5 A. That shortcut does not reproduce health factor.
At the starting prices, the shortcut leaves $3,000 of A collateral plus $2,000 of B collateral, against only the $2,500 D debt. It gives $3,000 × 80% plus $2,000 × 70%, divided by $2,500: a misleading health factor of 1.52.
The correct ledger retains all $4,000 of supplied A, weights it by 80%, and separately retains the full $1,000 A debt. Removing $1,000 from each side before applying an 80% threshold changes the ratio. A net economic exposure figure answers a different question.
The pinned V3.7 calculation accumulates collateral and borrow contributions separately, including when both flags belong to the same reserve. The article's gross-balance method follows that structure. Aave V3.7 reserve-by-reserve calculation.
A repayment is an actual state change. Netting two spreadsheet rows is not evidence that debt has been repaid. If funds are used to repay A, rebuild the account after confirmation using the resulting supply and debt balances. The repayment amount versus accrued debt guide follows that operational check.
Stress a set of prices, not one isolated number
Keep all token quantities and thresholds fixed. The following illustrative scenarios change only oracle prices. They are alternative snapshots before any repayment, withdrawal or liquidation.
| Scenario | A price | B price | D price | Weighted support | Debt value | Health factor |
|---|---|---|---|---|---|---|
| Starting account | $2,000 | $20 | $1 | $4,600 | $3,500 | 1.3143 |
| A falls | $1,500 | $20 | $1 | $3,800 | $3,250 | 1.1692 |
| Conditional boundary | $1,000 | $20 | $1 | $3,000 | $3,000 | 1.0000 |
| A and B fall | $1,500 | $10 | $1 | $3,100 | $3,250 | 0.9538 |
| D appreciates | $1,500 | $20 | $1.05 | $3,800 | $3,375 | 1.1259 |
When A falls to $1,500, its collateral contribution declines to $2,400, but its debt value also declines to $750. The account's denominator moves as well as its numerator. Holding the A debt at its original dollar value would misstate the scenario.
With B fixed at $20 and D at $1, let P denote A's price. Weighted support is 1.6 × P plus $1,400. Debt value is 0.5 × P plus $2,500. Equality occurs at P = $1,000: both sides are $3,000.
Freezing debt at its starting $3,500 instead would produce a false boundary of $1,312.50. That error comes from treating a token debt as a fixed dollar loan.
Even the correct $1,000 boundary depends on the other prices. With B at $10, its support falls to $700. The same equality then puts A's boundary at approximately $1,636.36. That explains why the combined-shock row is below 1 despite A trading above $1,000.
Equality marks the mathematical boundary in this simplified example. At A = $999, with B and D unchanged from the starting account, support is $2,998.40 against $2,999.50 of debt: health factor is about 0.99963. Read more than a rounded interface label when an account is close to the boundary.
These are valuation scenarios, not predictions of transaction timing, collateral seized or final losses. Accruing debt would also change the denominator even if prices stayed fixed; Aave V3's overview describes debt balances growing with interest. Aave V3 borrowing overview.
Reconcile the threshold without losing precision
The starting account's exact weighted threshold is 76.6666…%. In the pinned V3.7 implementation, the separately returned average threshold uses integer basis points, yielding 7,666, or 76.66%, for this example. Health factor is calculated from the accumulated weighted contributions before that average is truncated. Pinned V3.7 calculation order.
Rebuilding support as $6,000 × 76.66% gives $4,599.60 and health factor 1.3141714, slightly below the direct result of 1.3142857. That small mismatch does not establish a missing asset.
Retain precision and check the implementation's operation order before forcing agreement by adjusting balances. Large differences deserve a different investigation: an omitted debt, disabled collateral, wrong decimals, mismatched block or incorrect oracle price. Do not attribute a material discrepancy to rounding without measuring it.
Save an account snapshot you can reproduce
Aave V3's getUserAccountData returns collateral and debt totals, available borrowing, the account liquidation threshold, LTV and health factor. Reserve and user configuration views provide further inputs. Use those outputs as reconciliation targets for the appropriate deployment. Aave V3 account-data reference.
| Worksheet field | Evidence to retain |
|---|---|
| Account boundary | Chain, pool, wallet, implementation revision and observation block |
| Supply ledger | Current balances, token decimals and collateral flags |
| Debt ledger | Every borrowed reserve and current accrued balance |
| Valuation | Oracle address, base-currency unit and each asset price |
| Effective thresholds | Reserve parameters and any applicable mode overrides |
| Calculation | Each weighted contribution, total debt and health factor |
| Stress conditions | Prices and balances changed, plus inputs deliberately held fixed |
| Reconciliation | Protocol output, local result and quantified difference |
Use the same block for the state reads where possible. A balance from one block and an oracle price from another can describe an account that never existed.
The example excludes eMode. The pinned implementation can select a category threshold for qualifying collateral, so copying ordinary reserve percentages into a mode-specific account can invalidate the worksheet. Record the effective values before arithmetic.
Finally, distinguish a reconciled health factor from permission to withdraw a chosen asset. Available liquidity and the resulting account state require separate checks; the withdrawal liquidity versus headroom guide explains that next step.
For each account review, keep the enabled collateral contributions and every debt contribution visible. Then write the conditions beside any quoted liquidation price. Keep that ledger with the snapshot so the next review can identify which input changed.