DeFi Lending Position Tracking: Collateral, Debt, and a Liquidation Risk

What defines a DeFi lending position, across every protocol, is that it is never one balance but a pair: an asset you supplied that quietly accrues, an asset you owe that accrues faster, and a health metric that can liquidate both at once. Trackers that read only the supply side miss two-thirds of it. This guide is the general lending shape and how to track it across Aave, Compound, Morpho and Spark-type protocols, one spoke of the wider multi-wallet aggregation problem; for the single-protocol deep dive see Aave V3 position tracking.

What a lending position is, in any protocol

• A lending position is a pair: a collateral leg (supply, accruing supply interest) and a debt leg (borrow, accruing borrow interest).
• A health metric and liquidation threshold can liquidate both legs on an oracle move.
• The verified Aave V3 model (aTokens, variableDebtTokens, Health Factor) is the clearest instance; the same shape recurs across Compound, Morpho and Spark-type lending, differing only in detail.
• Supply-only views overstate the net position and miss both the growing liability and the liquidation risk.
• Balances often change without a transfer (interest accrual), so read derived state, not transfer events.
• Tax is jurisdiction-specific: track the mechanics, confirm tax separately.

The general shape

Concrete protocols differ, but a DeFi lending position almost always has the same skeleton:

The verified concrete instance is Aave V3: aTokens (supply, balance grows), variableDebtTokens (debt, grows), and the Health Factor (risk). The same collateral/debt/health shape recurs in Compound, Morpho and Spark-type lending. The detail differs by protocol, so confirm each protocol's specifics, but the tracking discipline is the shape, not one protocol's token names.

Protocol comparison: how the general shape maps

The token names differ; the collateral/debt/health skeleton is the same.

Why supply-only tracking fails

Reading only the supply leg:

• overstates the net economic exposure, ignoring the debt;
• misses a growing liability, since the debt accrues too;
• misses liquidation risk, because an oracle move can seize collateral and clear debt.

A correct lending view always nets collateral against debt and models the health metric, the same "track the pair, not one side" rule as the Aave V3 article.

Accrual without a transaction

Many lending protocols accrue interest into the position rather than via discrete transfers (the Aave scaled-balance and aToken model is the verified example). So a tracker that ingests only explicit transfer events misses interest accrual on both sides. It must read the derived position state and attribute the changes, the same lesson as stETH rebasing and Aave accrual.

Compound V3 (Comet) accrual model

Compound V3 uses a different accrual mechanism from Aave. The Comet contract stores a baseSupplyIndex and a baseBorrowIndex that increase over time. A user's supply balance is computed as principal × baseSupplyIndex / principalIndex_at_deposit. A tracker must read the current index from the Comet contract rather than storing only the principal amount, or it will freeze the balance at the deposit-time value.

Liquidation is its own event

A liquidation is a distinct economic event: collateral is seized (part or whole), debt is reduced or cleared, usually with a penalty. A tracker that does not model liquidation shows an unexplained collapse in both legs. Liquidation is not a transfer to classify casually; it is its own event with its own consequences for the position and any gain or loss (the same "model the event, not a mystery balance change" point as internal transfer vs disposal).

Partial vs full liquidation

Most protocols allow partial liquidations (seizing only the minimum collateral to restore the health metric) as well as full liquidations. The tracker must distinguish:

• Partial: collateral leg decreases by liquidatedCollateralAmount; debt leg decreases by debtToCover. Health Factor improves but position remains open.
• Full: both legs approach zero; position is effectively closed after a final Collect or Withdraw call by the liquidator.

A tracker that treats a partial liquidation as a position close will incorrectly zero out an active position.

Step-by-step: how to track a DeFi lending position

1. Confirm the protocol and deployment. Each protocol has distinct contract addresses per chain. For Aave V3 use getUserAccountData() on the Pool. For Compound V3, query the Comet contract. For Morpho, query the MorphoBlue contract. Never hardcode one address across chains.
2. Read the collateral leg. For Aave, getUserReserveData(asset, user).currentATokenBalance. For Compound V3, balanceOf(user) on the Comet contract (gives the supply balance including interest). For Morpho, position(marketId, user).supplyShares converted to assets via the market's totalSupplyAssets / totalSupplyShares.
3. Read the debt leg. For Aave, currentVariableDebt from getUserReserveData. For Compound V3, borrowBalanceOf(user). For Morpho, position(marketId, user).borrowShares converted to assets.
4. Compute the health metric. For Aave, getUserAccountData().healthFactor (18-decimal, value below 1e18 is liquidatable). For Compound V3, compare collateralValue ÷ borrowValue to the collateral factor. Monitor this metric at each snapshot.
5. Subscribe to liquidation events. For Aave: LiquidationCall on the Pool. For Compound V3: AbsorbDebt on Comet. For Morpho: Liquidate on MorphoBlue. Record both legs' changes on each event.
6. Snapshot balances at regular intervals and attribute the delta to interest accrual (no corresponding user transaction).
7. Apply the jurisdiction cost-basis method to supplies, withdrawals, and liquidation events; confirm interest and liquidation characterisation with an adviser.

Common errors and how to fix them

Error 1 — Treating different protocols as interchangeable. Aave and Compound have the same conceptual shape but different token interfaces and accrual mechanisms. A tracker that hardcodes Aave's aToken logic for Compound V3 (which has no aTokens) will fail to read Compound positions entirely. Fix: implement per-protocol adapters; never apply one protocol's ABI to another.

Error 2 — Reporting only the supply leg. A user who supplied $10,000 of ETH and borrowed $5,000 of USDC has a net position of ~$5,000, not $10,000. Supply-only views overstate the position and can generate incorrect PnL figures. Fix: always net supply against borrow at the per-user level.

Error 3 — Missing protocol-level fee accrual. Some protocols charge a reserve factor on interest, routing a portion of supply interest to the protocol treasury. The user receives supply interest minus the reserve factor. A tracker using the gross interest rate instead of the net rate will overstate accrued yield. Fix: apply the net rate (supply APY visible in the protocol UI, not the gross borrow rate).

Error 4 — Not handling stablecoin borrow rate changes. Borrow rates on variable-rate positions float and can change dramatically with market conditions. A tracker that snapshots the rate once and extrapolates will diverge from the actual accrued debt. Fix: read the actual borrow balance directly from the protocol contract at each snapshot rather than computing from a cached rate.

Tax is jurisdiction-specific

Whether supplying, accrual, borrowing, repaying or liquidation is taxable is framework- and jurisdiction-specific and must not be assumed (see cost-basis methods). The collateral, debt, health and liquidation mechanics are the tracking layer; the tax characterisation is separate and adviser-confirmed.

Practical guidance

1. Track the pair: net collateral against debt, never supply-only.
2. Read derived state, not transfer events, because accrual is silent on both legs.
3. Model the health metric so liquidations are explained, not mysteries.
4. Treat liquidation as its own event (seizure, debt clearing and penalty).
5. Confirm each protocol's specifics; the shape generalises, the detail does not.
6. Confirm tax characterisation per jurisdiction and apply the mandated cost-basis method.

Choosing a tool for DeFi lending positions

Koinly and CoinTracker both claim lending support across major protocols, but the cross-protocol shape is where coverage gets uneven. Before you trust a lending figure, confirm the tool:

• nets the collateral leg against the debt leg at the per-user level, rather than reporting supply alone;
• reads derived, accruing balances on both legs (the aToken/index value, Compound's baseSupplyIndex, Morpho's share-to-asset conversion), not just transfer events;
• ingests the protocol-specific liquidation event (LiquidationCall on Aave, AbsorbDebt on Compound V3, Liquidate on Morpho) and distinguishes a partial liquidation from a position close;
• uses per-protocol adapters instead of applying one protocol's ABI everywhere, and applies the net supply rate after the reserve factor.

Supply-only tracking is the recurring lending error, and it silently inflates the reported position.

How Wag3s handles it

Wag3s Folio tracks DeFi lending as a collateral/debt pair, reads accruing derived balances on both legs, models the health metric and liquidations as events across Aave-, Compound-, Morpho- and Spark-type protocols, and surfaces the result for the jurisdiction-specific tax characterisation. See the Folio product page.

Further reading

• Aave V3 Position Tracking
• Rebasing vs Non-Rebasing Token Tracking
• DeFi Position Reconciliation
• Yield Farming Tracking
• Crypto Cost Basis Methods 2026
• Internal Transfer vs Disposal in Crypto

Sources

• Aave — Aave V3 documentation: the verified concrete instance of the collateral/debt/health shape (aTokens, variableDebtTokens, scaled balances, Health Factor) on which the general model is anchored.
• General DeFi lending model: a collateral leg plus a debt leg with a health metric and liquidation, with protocol-specific detail across Compound, Morpho and Spark-type lending. Confirm each protocol's mechanics in its own documentation; interest accrual is read from derived state, and liquidation is a distinct event (seizure, debt clearing, penalty). Tax characterisation is jurisdiction-specific.