Why Zodial Uses Off-Chain Solving and On-Chain Verification

Solana is fast, but blockspace is not free.

A portfolio-native lending protocol should not spend excessive compute solving a complex optimization problem inside every transaction. It needs the expressiveness of a portfolio health engine without turning every borrow, repay, or liquidation into an expensive onchain operation.

Zodial solves this by separating solving from verification.

The compute problem

A real portfolio can contain many collateral assets and many debts.

Each collateral/debt pair may have separate risk parameters. The health engine must respect collateral values, debt values, pairwise limits, liquidation thresholds, and freshness checks.

Solving the full optimization problem directly onchain would be expensive. It would also put pressure on memory and compute budgets, especially during liquidations where speed and reliability matter.

The split

Zodial uses a two-step architecture.

First, the health problem is solved off-chain. This can happen in the client, by a keeper, by a liquidator, or by supporting infrastructure.

Second, the result is submitted to the Solana program with a compact witness. The program verifies that the witness satisfies the protocol rules.

The chain does not need to search through every possible allocation. It checks that the submitted allocation and certificate are valid.

Compute

Client solver

Answer + proof

Witness

Onchain check

Solana verifier

Complex health solving happens offchain. The chain verifies a compact witness.

The homework analogy

Think of it like submitting an answer with proof.

The solver does the work. The program checks the proof.

If the proof is wrong, incomplete, or inconsistent with the account state, verification fails. If the proof is valid, the program can safely use the health result.

This keeps the expensive part off-chain while preserving onchain enforcement.

What the witness shows

At a high level, the witness proves that:

• collateral is not overused;
• debts are sufficiently covered;
• pairwise limits are respected;
• the reported health result matches the rules;
• the account state and risk context are the ones being checked.

In optimization terms, this is a primal-dual witness. The primal side shows a coverage allocation. The dual side helps certify that the result is correct.

Users do not need to manage this manually. The app should make it feel like a normal transaction.

Why this improves safety

Off-chain solving does not mean trusting the solver.

A malicious solver cannot simply claim an account is healthy or unhealthy if the submitted witness does not satisfy the onchain checks. The Solana program enforces the rules.

This is especially important for liquidations. A liquidator should not be able to present a fake unhealthy result if a valid healthy coverage allocation exists.

The verification layer is what turns off-chain computation into safe onchain execution.

Why this improves scalability

The architecture makes advanced portfolio risk practical.

Zodial can support richer collateral/debt relationships, more asset types, and more complex accounts while keeping onchain work bounded.

That matters for Solana, where protocols compete for compute and users expect transactions to remain fast.

Takeaway

Zodial solves complex portfolio health off-chain and verifies the result on-chain.

The user gets portfolio-native lending. The chain gets compact, deterministic checks. The protocol keeps security where it belongs: enforced by the program.