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.

Can liquidations stay fast during market stress?

Yes, that is a core design requirement.

Zodial’s primal and dual LP pipeline is optimized for large portfolios and uses the HiGHS solver library. For the expected account sizes in current and planned deployments, solve times are designed to remain in the millisecond range under normal execution conditions.

Adding certificates to liquidation does not change the liquidation model itself. The certificate acts as a verification layer on top of the same core liquidation mechanics, so it is not expected to add meaningful end-user latency in the critical path.

Rates, caps, and stress throttles

Risk controls are layered, not single-point:

• utilization-based borrow curves (with multiple control points) remain the primary mechanism;
• hard borrow caps are used to prevent deadlocks and concentration;
• inflow and outflow limiters can enforce hourly and daily throttles during stress;
• operational caps can be tightened at launch and expanded as liquidity deepens.

As utilization moves above target ranges, borrowing cost rises sharply by design. That is the main automatic brake on excess leverage.

Insurance reserves and bad-debt waterfall

Protocol take-rate allocation is used to build insurance reserves over time.

Loss handling follows a defined sequence:

1. Use insurance reserves first.
2. If reserves are exhausted, socialize remaining bad debt across affected lenders under protocol rules.

This keeps the loss path explicit in advance rather than discretionary after the fact.

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.