> For the complete documentation index, see [llms.txt](https://docs.bsc.lista.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bsc.lista.org/for-developer/services/liquidation-logic.md).

# Liquidation (Service)

Lista operates its own liquidation keeper. Its scheduling, thresholds, and retry behaviour are internal and are not documented here.

Third-party liquidators do not need them. What you do need:

## Eligibility

A position is liquidatable when its loan-to-value exceeds the market's `lltv`:

```
borrowed  = convertBorrowSharesToAssets(borrowShares, totalBorrowAssets, totalBorrowShares)
maxBorrow = collateral × price / 1e36 × lltv / 1e18      // price = collateral denominated in the loan asset, 1e36-scaled; lltv is 1e18-scaled
isHealthy = maxBorrow ≥ borrowed
```

A position with no debt is always healthy. On a broker market the borrower's debt is replaced by the broker's total debt (Moolah principal plus interest accrued at the broker), while the collateral is still priced at the plain market price.

Use the same oracle and market parameters the contract uses, and match its rounding — `maxBorrow` is floored and `borrowed` rounded up, both in the protocol's favour. The exact scale factors, the `isHealthy` view and its caveats, and the liquidation-price formula are in [Consuming Oracle Prices](/for-developer/multi-oracle/consuming-prices.md).

Re-read the oracle and position state at execution time: Moolah accrues interest and re-checks health when your transaction lands, and reverts with the string `"position is healthy"` if the position has recovered — Moolah's health and input checks use `require` strings, not typed errors. (The inherited reentrancy guard is the exception: it reverts a typed `ReentrancyGuardReentrantCall()` — see [Events & Callbacks](/for-developer/lista-lending/events-and-callbacks.md).)

## Finding candidates

* `GET /api/moolah/redPositions` — liquidatable positions on one market. **Start here for open markets**, which are the common case: enumerate markets from `/api/moolah/allMarkets` and fan out.
* `GET /api/liquidation/zone/closeToLiquidate` — positions approaching the threshold.
* `GET /api/liquidation/zone/list` — the per-market **borrower** whitelist with each account's latest position snapshot. It applies **no** health test, so evaluate eligibility yourself, and it only finds candidates on *gated* markets.
* `GET /api/liquidation/zone/history` — settled liquidations.

Parameters and response fields are in [Positions, Liquidation & Emission](/for-developer/services/lending-api/position-liquidation-emission.md). Indexed data can lag; treat it as a candidate feed and confirm on-chain before submitting.

## Executing

Liquidations are executed through the `PublicLiquidator` contract. It has no role gate, but reachability is **per market** — an under-water position is not necessarily liquidatable by you, and there are both self-funded and flash-swap paths. Entry points, sizing, the eligibility gate, and the revert reference are in [Liquidator Integration](/for-developer/lista-lending/liquidator-integration.md).

Lista's keeper competes on the same public paths as anyone else. Running your own liquidator does not require, and does not receive, any knowledge of its configuration.

For the product-level explanation of liquidation, see [Liquidation](/introduction/lista-lending/liquidation.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.bsc.lista.org/for-developer/services/liquidation-logic.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.