Health Factor

The health factor is the single number a lending protocol uses to decide whether a borrower's position is safe. It divides the position's collateral, weighted for risk, by its debt. A health factor above 1 means the collateral still covers the debt with the margin the protocol requires. At or below 1, the position can be liquidated: someone else repays part of the debt and takes collateral in exchange, usually at a discount.

Protocols name it differently; Euler v1, for example, called it the health score. The mechanics are the same: weight each collateral asset by its collateral factor, add them up, and compare the result with what the account owes.

How the health factor is calculated

In its simplest form, the health factor is the sum of each collateral balance times its price times its collateral factor, divided by the value of the debt. Some designs also apply a borrow factor to the debt side, so riskier borrowed assets need more collateral. Because prices move, the health factor moves with them, even when the borrower does nothing.

A falling price is the case everyone plans for. The case that breaks protocols is a user action that lowers the health factor without the protocol noticing: a withdrawal, a transfer of collateral tokens, a donation, or any new function that reduces collateral or adds debt.

The health check after every risky action

Lending protocols defend the health factor with a check at the end of every function that can weaken an account. If the account's health factor is below 1 when the function finishes, the whole transaction reverts. This check has to run after every such action, not most of them.

The Euler Finance hack is the textbook case. Euler v1's withdraw and mint both ended with checkLiquidity(account), but donateToReserves, added later as part of a fix, lowered the donor's collateral and never ran it. The attacker used it to push their own account below 1 on purpose, then liquidated it themselves.

Testing it

A useful invariant for any lending protocol is that no sequence of user calls can take a healthy account below a health factor of 1 unless prices change. Invariant testing with random sequences of calls is one way to find the function that forgets the check, before it becomes bad debt.