Liquidations in a Portfolio-Native Lending Protocol

A better risk engine should not mean weaker risk controls.

Zodial is designed to make lending more portfolio-native, but the core lending invariant stays the same: debt must remain sufficiently backed by collateral.

Liquidations are how the protocol protects that invariant.

Why liquidations exist

When a borrower’s account becomes unhealthy, the protocol needs a way to reduce risk.

A liquidator can repay part of the borrower’s debt and receive collateral in return. The liquidator usually receives a discount or bonus for taking that action. This creates an incentive to restore solvency before losses reach lenders.

Liquidations are not optional infrastructure. They are part of the safety system.

What changes in a portfolio-native protocol

In a simple account, liquidation may depend on one collateral asset and one debt asset.

In Zodial, the account can contain many collateral assets and many debts. Liquidation has to consider the full portfolio:

• all supplied collateral;
• all borrowed assets;
• current prices;
• pairwise risk parameters;
• the verified health result;
• the valid coverage map.

That makes the model more expressive, but it also raises the bar for correctness.

64%

buffer remaining

Healthy

Current debt load

36% of threshold

Liquidation threshold

100%

The filled segment is current debt load. The unfilled segment is the remaining buffer before the liquidation threshold.

False liquidations must be impossible under valid rules

A portfolio-native system must not allow someone to liquidate an account just because they found a bad coverage assignment.

If a valid healthy assignment exists, a liquidator should not be able to claim the account is unhealthy by choosing a weaker assignment.

This is why Zodial’s witness approach matters. The program verifies the submitted health context instead of trusting arbitrary claims.

The role of pairwise thresholds

Borrow LTV and liquidation threshold are separate.

Borrow LTV controls how much debt a user can open. Liquidation threshold controls when the account can be liquidated. Keeping these separate creates a buffer.

In Zodial, these thresholds can be pairwise. That means the protocol can be more conservative for weaker collateral/debt relationships while allowing stronger relationships where risk supports it.

Unhealthy

Below threshold

Proof path

Verified coverage

Solvency

Debt reduced

Liquidation should follow a verified path from unhealthy debt to repayable collateral.

Risk controls around liquidation

A serious launch should combine the health engine with operational controls:

• conservative initial asset caps;
• borrow caps;
• fresh oracle checks;
• pairwise liquidation thresholds;
• liquidation penalties;
• public risk dashboards;
• monitoring for concentrated exposure;
• emergency pause or parameter controls where appropriate.

Portfolio-native lending should be more precise, not more reckless.

What users should monitor

Users should watch more than one number.

The app should make health simple, but advanced users should understand what drives it:

• account health;
• liquidation buffer;
• largest collateral exposure;
• debt composition;
• oracle-sensitive assets;
• pairwise coverage assumptions;
• market liquidity;
• correlation breakdown risk.

A healthy account is not only one with a high headline value. It is one with enough valid coverage under the protocol’s rules.

Why this matters for trust

Lending protocols live or die by risk management.

High borrow headroom is only valuable if users trust the liquidation system, lenders trust solvency, and liquidators can act reliably when needed.

Zodial’s architecture is built around that tradeoff: more expressive portfolio credit with strict, verifiable safety checks.

Takeaway

Portfolio-native lending expands what users can do, but liquidation discipline remains non-negotiable.

Zodial’s goal is to recognize real portfolio structure while keeping solvency enforced on-chain.