Navi protocol

Navi protocol borrowing - Capacity, Debt and Repayment Checks

Navi protocol borrowing starts with collateral already counted by the selected lending market, unused capacity, pool liquidity and enough SUI for network gas. Before signing, confirm the proposed asset and amount, the projected health factor and the wallet address. After settlement, treat the debt position and transaction effects as evidence of success, then verify later repayment against the remaining on-chain debt balance.

A preview, a signed request and a recorded obligation are distinct stages. Each stage exposes different evidence, and only successful network execution changes the borrowing position in the account.

Conditions for the first bounded borrow

Five components determine whether a first borrow can proceed: an address on Sui, qualifying collateral, a supported debt asset, available pool liquidity and SUI for gas. The collateral must already belong to the lending position and count under the selected market or EMode configuration. Merely holding an asset in the wallet does not add borrowing power.

Account capacity limits what the collateral can support, while reserve conditions limit what the pool can release. A request must satisfy both at execution. If either state changes between preview and execution, a previously available amount can fail without creating new debt.


Capacity evidence before authorization

Available capacity is an account-level estimate built from eligible collateral values, applicable loan-to-value parameters and existing debt. The selected debt asset then converts that value limit into a borrowable quantity. Market settings, EMode settings, reserve caps and liquidity can narrow the amount further. A large supplied balance therefore does not imply the same amount is immediately ready to borrow.

Read the capacity beside the exact account and market involved in the transaction. Also inspect the projected position after the proposed amount, because the unused amount before borrowing does not describe the resulting safety margin. Oracle price updates, accrued interest or configuration changes can alter the usable figure without another wallet action. A recent preview is evidence for a decision, not a promise of execution.


How much borrowing headroom should remain?

No single headroom percentage suits every position. The relevant evidence is the health factor projected after borrowing, together with how collateral and debt prices could move. Taking the maximum available amount leaves little room for adverse valuation changes or additional interest. A smaller request preserves more unused capacity, although it does not prevent liquidation if the account later becomes undercollateralized.

A health factor below 1 makes the account eligible for liquidation. That boundary is not a target for ordinary operation. The displayed factor can move when collateral loses value, the debt asset gains value or interest increases the debt. A borrow amount should be reassessed whenever those inputs or the applicable market configuration change.

How much borrowing headroom should remain?: No single headroom percentage suits every position. The relevant evidence is the health factor projected after borrowing, together with how collateral and debt prices could move.; Taking the maximum available amount leaves little room for adverse valuation changes or additional interest. A smaller request preserves more unused capacity, although it does not prevent liquidation if the account later becomes undercollateralized.
How much borrowing headroom should remain?, illustrated

View image file


The wallet as the commitment boundary

The wallet request is the last point where the proposed borrow can be rejected without submitting it. Match the account, network, debt asset and amount to the fresh position preview. Check any current borrowing fee for the address and asset because protocol governance can change the rate. When the wallet exposes balance changes or a gas budget, review those fields too. The gas budget is not part of the borrowed quantity and is paid in SUI.

The wallet as the commitment boundary: A signature authorizes submission; it does not prove the borrow succeeded. Network execution can return success or failure, and the result has its own transaction digest and effects.; Keep the proposed amount distinct from the final account state. If the request is rejected, no borrowing transaction is submitted, although a later preview may still change as prices, rates or reserve conditions move.

View image file

A signature authorizes submission; it does not prove the borrow succeeded. Network execution can return success or failure, and the result has its own transaction digest and effects. Keep the proposed amount distinct from the final account state. If the request is rejected, no borrowing transaction is submitted, although a later preview may still change as prices, rates or reserve conditions move.

A bounded first borrow with independent checks

All amounts, capacity readings and health factors in this case are hypothetical. An account has 137 units of a supported collateral asset already counted by its market. The current preview shows capacity for 12.47 units of the selected debt asset. The reader considers borrowing 2.17 units and sees a projected health factor of 2.37.

Stopping leaves the full displayed capacity and creates no transaction. Reducing the request preserves more headroom than 2.17 units. On the stated preview, subtracting the 2.17-unit request from 12.47 leaves 10.30 units of headroom before any other input changes. Execution still determines whether the account records the requested debt, and later price or interest changes can reduce the margin. The 2.37 projected health factor applies to the 2.17-unit request, so another amount needs its own fresh preview.

The reader checks the asset, amount and projected position, then signs only the 2.17-unit request. In this hypothetical run, Sui reports success and the transaction effects include a borrow event for 2.17 units. An account query also returns debt for the selected asset. The wallet receipt alone would not establish that the obligation was recorded.

For the exit, the reader obtains the live debt instead of reusing the original 2.17-unit input. The full repayment succeeds, and the next account query shows zero debt for that asset. That result proves closure of this borrowing leg. The borrowing result can change if capacity, liquidity, valuation or the market configuration changes before it executes. The repayment amount can change as interest accrues before repayment.

The recorded debt after settlement

A completed borrow leaves two forms of evidence: Sui transaction effects and the updated lending position. The transaction status establishes whether execution succeeded, while its effects show what the transaction changed. The lending position identifies the borrowed asset and current obligation. Checking both separates an accepted wallet request from a debt the protocol actually recorded.

Debt should be reconciled in units of the borrowed asset, not only through a displayed fiat value. A fiat conversion depends on the price input used by the interface and can differ from a swap quote elsewhere. Repayment still concerns the live token-denominated obligation. Store the digest with the asset identifier and wallet address so a later repayment check refers to the same position. If the token quantity, transaction effects and account position disagree, pause before another borrow or repayment request.


Interest and a changing obligation

The amount owed can grow after the initial transaction because borrowing carries interest. The borrow rate is a live pool condition rather than a permanent quote attached to the first preview. Utilization and protocol configuration can change that rate, so the original principal is not a reliable full-repayment amount later. Read the current debt balance immediately before repayment and keep enough of the debt asset to cover it.

A changing fiat valuation is separate from a changing token obligation. The displayed currency value may move because the asset price changes even when the token debt changes only through interest. Conversely, the token amount can increase while a fiat display falls. Keeping those two measurements separate prevents a lower currency figure from being mistaken for fewer tokens owed.

Repayment evidence and collateral state

Repayment is verified against the remaining debt after the transaction settles. A successful partial repayment lowers the obligation but leaves a borrow position open. Full closure requires the live debt for that asset to reach zero, not merely a successful transaction badge or a wallet transfer matching the original principal. Accrued interest can make those amounts different.

Repaid debt and supplied collateral are separate account states. Clearing the debt does not automatically withdraw the supplied asset to the wallet. That collateral can remain in its pool until a separate withdrawal succeeds. If several debt assets or markets are present, confirm each relevant position individually before treating the entire borrowing account as clear.


What if the new debt does not appear?

Do not submit the same borrow again while the first transaction lacks a final status. Start with its digest and check whether Sui reports success or failure.

A successful result should have transaction effects consistent with borrowing. Refresh or query the lending position for the same address, market and asset before deciding the interface is stale.

A failed execution should not add the proposed debt, although the network can still charge SUI gas. Record the failure details before changing the amount or trying again.

If transaction success and the lending position still conflict, stop at that boundary. Preserve the digest and observed account state instead of creating a second obligation during uncertainty.

Exit evidence and the remaining account

Zero debt for the selected asset is the clearest evidence its borrowing leg has ended. Confirm the repayment transaction succeeded, then query the position after settlement. A historical borrow entry can remain in transaction history even when the current debt is zero, so history alone does not describe the present obligation.

A zero balance for one asset does not clear debt in another market or EMode position. Check the account's remaining positions before withdrawing collateral or treating the account as debt-free.

Exit evidence and the remaining account: Zero debt for the selected asset is the clearest evidence its borrowing leg has ended. Confirm the repayment transaction succeeded, then query the position after settlement.; A historical borrow entry can remain in transaction history even when the current debt is zero, so history alone does not describe the present obligation.

View image file

Can supplied collateral pay Sui network gas?

No. Sui gas must come from SUI available to the wallet, while supplied collateral remains in the lending pool. Even supplied SUI cannot serve as the wallet's gas coin until it is withdrawn, and that withdrawal itself requires gas. Keep a separate SUI balance available for account operations.

Must an ordinary repayment use the borrowed asset?

Yes. The repayment operation consumes the same asset type recorded as debt, and the required quantity is the live balance rather than only the original principal. Supplied collateral remains a separate position, so holding collateral does not by itself provide the token input for an ordinary repayment.

Does EMode need to be active for a first borrow?

No. Navi protocol supports regular lending positions as well as EMode positions. EMode applies a distinct configuration for eligible asset categories, so it should be used only when the intended collateral and debt belong to that configuration. A regular borrow does not require entering EMode first.

May capacity shown for one Navi market be reused for another?

No. Each market groups its own pools and lending settings, while EMode can apply another configuration within a market. Read capacity from the same market and account identity involved in the proposed borrow. A figure displayed for another position does not establish available capacity for this transaction.

Does disconnecting the wallet remove an existing debt?

No. The debt is part of the on-chain lending position associated with the address, so closing an interface or disconnecting a wallet does not erase it. Reconnect the same address and query its position to recover the current debt, collateral and health information.

Could a token symbol alone identify the repayment asset?

No. Use the exact asset identifier recorded in the debt position because a displayed symbol is not the full on-chain identity of a Sui coin type. Matching the identifier prevents a similarly labelled token from being mistaken for the asset the repayment operation requires.

Can collateral be withdrawn while some debt remains?

Possibly. A withdrawal can proceed only if the remaining eligible collateral still supports the outstanding debt under the applicable limits and the pool has enough liquidity. Preview the exact withdrawal against the current position. Existing debt does not forbid every withdrawal, but it can reduce or eliminate the withdrawable amount.

Updated ยท