Lending Protocol Audit: Collateral, Liquidation, Debt and Credit Scope

Collateral factor and LTV parameters

A lending protocol audit tests whether the system can account for a loan, enforce its agreed limits and allocate a shortfall without inventing assets. The first scoping decision is the lending model. An overcollateralized money market needs liquidation analysis. A fixed-term credit pool also needs repayment and default state machines, with a separate review of the off-chain underwriting assumptions.

LTV describes borrowing relative to collateral value. A liquidation threshold answers a different question: when intervention becomes permitted. Keep the fields separate in the specification, even if a particular protocol uses related values. Confusing the admission limit with the liquidation condition can make a parameter change appear harmless while changing an existing borrower's exposure.

Compound III's liquidation specification explicitly separates borrowing factors from higher liquidation factors. Our repository survey below checks that relationship in configuration artifacts. It does not establish whether the gap is sufficient for a particular asset's volatility or executable depth.

Use asset-specific scenarios. A collateral token can remain transferable while its redemption mechanism is delayed or its secondary market becomes shallow. The audit should identify where the implementation obtains value and where the risk model assumes that value can be realized. Request both artifacts when the collateral factor depends on that assumption.

The Comet collateral guide also describes supply caps and principal-based accounting. A cap check at the wrong point in a transfer can disagree with the balance actually received. Include fee-bearing or rebasing token behavior only where the integration claims to support it; otherwise document and enforce the supported asset assumptions.

Our inventory compared 28 Comet configuration files

Before testing lending math, establish what the configuration files actually say. We enumerated the deployment configuration paths in Compound's public Comet repository at a pinned revision, then compared the borrowing and liquidation factors for every listed collateral row. This is an artifact inventory, not a query of deployed contracts.

Method

Source population

Every path matching deployments/<network>/<market>/configuration.json in the complete recursive tree of the official Comet repository.

Retrieved

September 5, 2026. The result stores the resolved commit, full tree and raw configuration objects.

Exclusion

Of 29 matching files, the single hardhat local-development fixture was excluded. The remaining 28 files span 10 network folders.

Observation unit

92 market-asset rows. A token used by different markets contributes a row in each market; these are not 92 unique token contracts.

Comparison

Use decimal arithmetic to compare borrowCF and liquidateCF. Retain zero supply caps and missing fields rather than filtering them away.

Results

The last row is a scoping clue. A missing priceFeed key in a deployment configuration does not prove that the deployed collateral has no oracle. The build or deployment process can resolve information elsewhere. Ask for that resolution path and the resulting on-chain address, then check the code at that address.

Likewise, a positive difference between the factors is a field comparison. It does not measure liquidation latency, collateral quality or losses under stress. The inventory is useful because it supplies a complete set of recorded cases against which the reviewer can reconcile the deployment manifest.

Limits

• We did not query live market parameters.
• Repository files can lag governance changes or describe a deployment process rather than current state. A zero cap is therefore not a live market-status verdict.
• Only raw field presence was measured for price feeds. The 42 absent keys require follow-up resolution; they are not 42 oracle failures.
• The deterministic comparisons need no manual finding classification. None of the rows is labeled a vulnerability or a clean security result.

The script seo/research/lending-config-survey.py and evidence seo/research/lending-config-survey-2026-09-05.json are retained in the repository and are not published as site downloads.

Liquidation incentive and close factor

Permission to liquidate does not ensure someone can profitably perform the work. A liquidator needs the repayment asset, an executable route for the received collateral and enough expected proceeds to cover costs. Ask the audit team to distinguish a valid transaction from a viable liquidation strategy under the conditions being modeled.

The close factor limits how much debt can be repaid in a liquidation where that model applies. Compound v2 exposes it through the Comptroller interface. Compound III instead documents absorption into protocol reserves followed by collateral sales. Importing a v2 close-factor checklist into a Comet review would miss the reserve accounting and sale path.

Aave's health-factor guidance also makes liquidation size depend on position conditions and includes a residual-dust rule. Pin the implementation version and configuration before testing those boundaries. A percentage copied from a general explainer is not a specification for every deployment.

1. Identify who supplies repayment liquidity.
2. Execute a partial liquidation and reconcile the remaining debt with the collateral actually transferred. Repeat at the smallest supported unit.
3. Test a stressed exit where the collateral cannot be sold at its oracle value. Include the costs and route assumptions used to call the liquidation profitable.
4. Run the terminal case: either clear the position or identify where its residual liability is recorded. A revert caused by an uneconomic remainder must not be counted as successful risk reduction.

Review the route a liquidator actually uses. A helper contract can impose slippage limits or consume a different price from the core market. Those differences can explain why a core liquidation function passes tests while production liquidators stop participating. Include the helper when the protocol relies on it for liveness.

Bad-debt accrual paths

Bad debt is a liability the system can no longer cover through its permitted recovery mechanisms. Model its arrival as a sequence. A price gap can make collateral insufficient before a keeper executes; a frozen asset can make apparently valuable collateral unavailable; a reserve draw can leave a later position without the support assumed in an isolated test.

Write down the conservation rule for each transition. After absorption or default, the borrower's debt may disappear from their account while the loss remains elsewhere. Inspect the reserve balance, depositor claim or explicit deficit field that receives it. Removing an account-level liability is not the same as recovering the asset.

Collateralized recovery

Compare the debt removed with realized liquidation proceeds and the reserve contribution actually permitted.

Credit default

Reconcile outstanding principal and interest against available cover under the agreed default rule.

Residual claim

Identify which balance changes when recovery is insufficient and how a depositor can inspect that change.

Test concurrent losses. If several borrowers depend on the same reserve, a scenario that resets the reserve before each run hides competition for that capital. Preserve the sequence and review the aggregate outcome. Use the perpetual-market loss-allocation guide for the related distinction between restoring accounting solvency and preserving a user's expected return.

Interest accrual correctness

Interest bugs often appear at transitions rather than during a steady borrow. Focus on repayment that crosses from debt into a positive supply balance, a rate change after an idle interval and a very small amount that rounds differently when processed repeatedly. The reference calculation should use the protocol's stated rounding rule, not whichever result a spreadsheet produces by default.

Compound III's interest-rate documentation describes separate supply and borrow models driven by utilization, with accrual based on the block timestamp. Its principal accounting uses different indices for supplied and borrowed base assets. Collateral assets themselves do not earn interest in that model. These distinctions belong in the expected results.

Ask for invariant-based tests as well as examples. Total claims and liabilities should evolve only through documented interest, fees and asset movements. When a deliberate rounding difference exists, bound and assign it. Our smart contract fuzzing guide explains how a stateful sequence can expose a failure that a single repayment test misses.

Keep rewards outside the base-interest reconciliation unless the design combines them. An incentive token distribution may be correct while the borrow index is wrong, or the reverse. Separate expected balances make that disagreement visible to the reviewer.

Oracle source count and staleness

An oracle address is the start of the review, not the end. Resolve the proxy, adapter and upstream feed that produce each collateral value. Then record the unit, quote asset and freshness policy. A price in the wrong quote currency can be current and still make the borrowing calculation wrong.

The Chainlink data-feed interface exposes an update timestamp and decimal information. The consuming protocol still needs an appropriate policy for accepting those values. The existence of updatedAt does not establish that a caller checks it, and a timestamp test alone does not establish that the chosen feed covers the intended asset.

1. Resolve every feed dependency from the deployed addresses.
2. Record units and accepted age per asset. Explain whether a wrapper or conversion rate adds a dependency that can become stale independently.
3. Test borrowing, withdrawal and liquidation with an unavailable or unacceptable price. These operations may need different failure behavior, so preserve their expected results separately.
4. Review recovery after the feed resumes, including whether pending operations observe a consistent value. Attach the source configuration used by the test.

Do not turn source count into a safety score. Multiple adapters may ultimately read the same underlying market or publisher. The relevant questions are what can fail together and how that failure reaches borrowing capacity. Our oracle attack review examines that distinction in more detail.

The configuration survey's absent price-feed keys illustrate a separate evidence problem: a source-file inventory cannot substitute for tracing the live resolution path. Mark unresolved dependencies as unresolved. A missing field should trigger a request for evidence, not a claim that the protocol has no price protection.

Isolated vs cross-collateral blast radius

Isolation can restrict collateral combinations, borrowing choices or the pool of assets that absorbs a loss. Those are different controls. Require the design to state which one it implements. A separate user-interface market does not prove a separate reserve, and a separate reserve does not remove shared administrator or oracle dependencies.

Aave's isolation-mode explanation describes limits on eligible borrowed assets and concurrent collateral use. It also describes repayment before leaving the mode. Test those transitions directly: switching collateral status should not bypass a restriction that applies when the position is first opened.

Collateral boundary

List which assets may jointly support a position and how the system prevents an unsupported combination.

Debt boundary

Identify the assets and aggregate amounts that the isolated collateral may support.

Loss boundary

Trace reserves and depositor claims after default rather than inferring separation from market names.

Control boundary

Map shared upgrades, pause authority and price dependencies that can affect otherwise separate pools.

For a protocol adding a volatile collateral asset, compare a restricted admission path with a broad cross-collateral path using the same stressed prices and liquidity assumptions. The result should explain what exposure each restriction removes. It should also identify what remains shared, so a team does not advertise isolation more broadly than the implementation supports.

Use the audit request builder to capture those boundaries in the engagement brief. Reviewers need the intended combinations and prohibited transitions before they can decide whether a discovered path violates the design.

Worked example: XRPL lending engagements

The current XRPL lending concept documentation describes fixed-term, uncollateralized loans funded through a Single Asset Vault. It explicitly excludes automated on-chain collateral and liquidation management from that described implementation. Underwriting is off-chain. A generic money-market audit checklist would therefore spend effort on a mechanism the design does not contain.

Reframe the scope around the loan lifecycle: authorized origination, payment accounting, missed-payment handling and the use of first-loss capital. A buffer can be optional and limited. It does not eliminate borrower credit risk, and an issuer freeze can affect the ability to repay an issued asset. Those dependencies need their own operating procedures.

These are historical findings from the published Halborn report, not claims of current exploitable defects. Its scope included lending interactions and invariant testing. An older introductory description differs from the current XRPL concept page on collateralization; use the current specification to define a new engagement and the report to inspect demonstrated review work.

RippleX also describes a post-Attackathon re-audit process. Treat a software release, a published report and amendment activation as separate events. This article does not independently determine live validator approval.

When shortlisting a firm, compare a relevant report with the evidence available in the Halborn company analysis. Check the reviewed revision and finding status, then ask for the same precision in your own scope. The deliverable should say which loan states and configuration transitions were tested, who reviewed them and which assumptions remain outside code verification.