How Zodial Calculates Portfolio Health

If a user has one collateral asset and one debt asset, health is easy to explain.

If a user has five collateral assets and three debt assets, the protocol needs to solve a harder problem:

What is the best valid way to assign collateral coverage to debt?

That is the core of Zodial’s portfolio health engine.

From assets to coverage

A Zodial account can contain multiple collateral assets and multiple borrowed assets.

For each collateral/debt pair, the protocol has risk parameters. Some pairs are strong. Some are weak. Some may be disabled.

The health engine needs to answer whether the collateral can cover the debt under those pairwise rules.

This is not just a sum.

USDC collateral may be excellent for USDC debt. SOL collateral may support USDC debt with a lower threshold. Tokenized equity collateral may support USDC debt more conservatively. Some collateral may not be allowed to cover some debt at all.

Inputs

Prices + balances

Constraints

Pairwise limits

Health

Optimized coverage

Zodial evaluates how collateral can be assigned to cover debt under pairwise constraints.

The coverage map

The easiest way to imagine Zodial’s model is a flow diagram.

Collateral assets sit on the left. Debt assets sit on the right. Arrows connect collateral to debt wherever coverage is allowed.

The protocol tries to build a coverage map:

• how much SOL covers USDC debt;
• how much ETH covers USDC debt;
• how much USDC covers SOL debt;
• how much tokenized stock covers USDC debt;
• and so on.

Every arrow must respect its pairwise risk limit. Every collateral asset can only be used up to its value. Every debt must be sufficiently covered.

Collateral	USDC debt	SOL debt	RWA debt
USDC collateral	84%	62%	48%
SOL collateral	70%	58%	42%
Equity collateral	55%	38%	34%

The exact values here are illustrative. The primitive is the shape: collateral quality is defined relative to the debt asset.

Why allocation matters

A naive protocol might use collateral in a fixed order. That can produce inefficient or misleading results.

Zodial instead evaluates the portfolio as an optimization problem.

The goal is not to guess which collateral should count. The goal is to find a valid allocation that proves the account is healthy, or determine that no such allocation exists under the rules.

This is where the LP comes in.

LP, without the jargon

LP stands for linear program. In this context, it is a structured way to solve a coverage problem with linear constraints.

Zodial uses it to answer:

What is the strongest valid coverage result for this portfolio?

The LP respects collateral values, debt values, and pairwise risk parameters. It searches for a coverage map that satisfies the protocol’s rules.

Users do not need to understand optimization theory. They only need the result: account health, borrow headroom, and liquidation buffer.

Why this is useful

The LP-backed health engine enables:

• multi-collateral accounts;
• multi-debt accounts;
• risk-aware borrow headroom;
• better recognition of diversified collateral;
• support for assets with different risk relationships;
• more precise liquidation checks.

It is the difference between checking a list of assets and evaluating a portfolio.

26%

buffer remaining

Watch

Current debt load

74% of threshold

Liquidation threshold

100%

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

Why this is not reckless

More precise does not mean more permissive by default.

Pairwise parameters can be conservative. Unknown relationships can be disabled or assigned strict limits. Asset caps can limit exposure. Liquidation thresholds can remain separate from borrow LTVs.

The LP does not decide risk appetite. It enforces the risk rules given to it.

Takeaway

Zodial calculates portfolio health by finding a valid collateral-to-debt coverage map across the full account.

That is what turns pairwise risk into practical portfolio-native lending.