Can supply APY and borrow APY be compared as the same kind of rate?

No, the two rates describe opposite sides of a lending pool. Supply APY estimates variable earnings on a deposited asset, while borrow APY estimates the variable interest cost attached to debt. Both can change with pool conditions. Compare them only within the intended action, and keep any separately displayed incentive rewards distinct from the base supply or borrowing rate.

How long should a pending Sui transaction remain unresolved before I retry?

There is no fixed delay that makes a retry safe. Use the transaction digest to determine whether the earlier request succeeded, failed or remains pending. If the wallet never submitted a transaction and produced no digest, a fresh request may be appropriate. When a digest exists, wait for its final status before signing the same action again to avoid an unintended duplicate.

Is a transaction digest enough to verify the exact lending action?

No, a digest identifies the Sui transaction but does not summarize whether its effect matches your intention. Check the execution status, operation type, coin changes and connected address, then compare them with the refreshed Navi protocol position. A successful digest paired with the wrong amount or an unexpected account effect requires inspection rather than an automatic retry.

Why can the confirmed health factor differ from the earlier preview?

The preview uses the account and protocol state available when the operation is estimated. Oracle prices, accrued debt and other relevant on-chain state can change before execution, so the confirmed position may have a different health factor. Treat the preview as a decision input. After execution, use the refreshed health factor and balances as the account's resulting state.

Does a partial repayment close the borrowing position?

No, a partial repayment reduces the debt by the amount successfully applied but leaves the remaining obligation open. Interest can also affect the live balance between an earlier estimate and execution. Confirm the transaction status first, then inspect the refreshed debt balance. A zero debt balance, rather than a successful repayment notification by itself, establishes a complete borrowing exit.

Can several Navi protocol operations share one Sui transaction digest?

Yes, when a transaction builder bundles supported operations into one Sui programmable transaction block. Review every command presented for signature. One digest then identifies the bundled transaction, while its effects and the refreshed position show the combined outcome. Do not assume an intended operation was included merely because another operation in the same request is visible.

Navi protocol lets you compare lending actions before signing and confirm the recorded position

Navi protocol lets you compare supplying, borrowing, repaying or withdrawing by checking the selected asset, amount, pool conditions and expected account effect before your wallet authorizes the transaction. The action is complete only after the Sui transaction succeeds and its effects match the intended balance and asset changes.

Compare each action on the same terms: its prerequisites, account consequences, the option to reject it before signing and the evidence available after execution for the connected Sui wallet.

Supply, borrowing, repayment and withdrawal on the same dimensions

Supply, borrowing, repayment and withdrawal differ in the assets they require and the account state they create. Supplying requires a supported asset in the wallet and available room in its pool. Every action also needs a SUI gas payment. Borrowing requires eligible collateral, unused borrowing capacity and sufficient pool liquidity. Repayment requires the borrowed asset, while withdrawal depends on the supplied claim, pool liquidity and any active debt constraints.

Choose the action by its intended state change: supply increases a deposited position, borrowing creates debt, repayment reduces debt and withdrawal reduces a supplied position. Compare the amount, live account effect and completion evidence for each option. A displayed rate is relevant to cost or earnings, but it does not establish whether the requested state change can execute.

Position components before commitment

A lending position connects the selected asset, its shared pool, the connected wallet and the account's risk state. Supplying an asset moves it into its pool and creates corresponding receipt-token accounting for the depositor. A borrow adds a debt balance secured by eligible collateral rather than consuming the collateral at the time of borrowing.

Each component answers a different pre-sign question. The wallet balance shows whether the input is available. Pool data shows liquidity and live parameters. The account view shows existing supply, debt and health factor. The proposed transaction should connect those inputs to one expected result, such as a larger supply balance, a new debt balance, lower debt or returned underlying assets.

Wallet review at the commitment boundary

The wallet request is the last reversible point before the proposed operation is submitted to Sui. Rejecting it leaves the proposed lending action unsigned.

The connected address and network should match the account used for the comparison. Review the operation, asset and amount presented for authorization. A different account can have different balances, collateral settings and borrowing capacity even when the selected pool is unchanged.

Borrowing and collateral-reducing withdrawals also require an updated view of the projected account state. If the health factor, available amount or transaction contents have changed materially since selection, return to the position view and rebuild the request from current data.

The signature authorizes the transaction contents, not the outcome shown by an earlier estimate. Live rates, asset prices, utilization and liquidity can move between initial comparison and execution. Keep the intended state change clear enough to recognize it after confirmation.

Wallet review at the commitment boundary: Borrowing and collateral-reducing withdrawals also require an updated view of the projected account state.; If the health factor, available amount or transaction contents have changed materially since selection, return to the position view and rebuild the request from current data.

View image file

Parameters for a like-for-like comparison

The comparison table applies the same questions to every core action. Its values describe durable operation effects, while live limits and rates still need to be read from the current pool and account.

Parameter	Documented value or effect	Control and confirmation
Supply	A supported asset enters its pool and the account receives a corresponding supplied claim.	The wallet authorizes the amount; a successful record and the expected increase in the supply balance confirm registration.
Borrow	The pool sends the borrowed asset and records debt against eligible collateral.	Collateral limits and available liquidity constrain execution; a successful record, the received asset and the expected debt increase confirm the result.
Repay	The applied repayment reduces debt and may leave a balance when the amount is partial.	The wallet controls the submitted amount; remaining debt shows whether the obligation stays open.
Withdraw	The supplied claim is redeemed for the underlying asset.	Pool liquidity and active debt constraints govern execution; the received asset and lower supply balance confirm it.
Health factor	The account metric reflects collateral, debt, oracle prices and applicable risk parameters.	A preview supports comparison; the refreshed post-action value describes the confirmed account state.
Transaction record	The record identifies the operation, execution status, coin changes, time and digest.	A successful status and matching position effects together confirm the intended operation.
Decision rule	Choose by the required position change, then require both successful execution and matching account evidence.

These rows separate authorization from completion. Wallet approval authorizes the request, a successful Sui result establishes execution and the refreshed position establishes whether the intended lending effect appeared.

How can you tell the transaction is complete?

A completed transaction requires a successful execution record and the expected account state. Supply should increase the supplied balance. Borrowing should add the received asset and debt. Repayment should reduce debt by the confirmed amount, while withdrawal should reduce the supplied claim and return the underlying asset.

Navi protocol transaction history records the operation type, execution status, coin changes, timestamp and transaction digest. The digest identifies a particular Sui transaction, but the status and effects show what it did. Match those details with the connected address and refreshed position instead of treating a wallet notification as the only proof.

How can you tell the transaction is complete?: A completed transaction requires a successful execution record and the expected account state. Supply should increase the supplied balance.; Borrowing should add the received asset and debt. Repayment should reduce debt by the confirmed amount, while withdrawal should reduce the supplied claim and return the underlying asset.

View image file

Confirmation when the interface lags

Confirmation during an interface delay comes from the successful transaction effects, followed by a fresh position query for the same account. A delayed screen alone does not establish failure.

For a normal supply, the record should identify a successful supply and the account should show the larger supplied balance. A repayment follows the same evidence pattern, except the expected position change is lower debt.

Sometimes a transaction succeeds before the position panel refreshes. Keep the digest, confirm its status and refresh the account data before submitting the same action again. If the account still meets current protocol conditions, submitting the action again can produce a second successful transaction.

An unsuccessful or rejected transaction does not create the intended lending position change, although an executed failure may still consume network gas. Resolve the failure reason and rebuild from current balances, liquidity and account parameters. The retry boundary is a known final status for the earlier request, not an arbitrary waiting period.

Failed execution before another attempt

Check the error and final transaction status before retrying a failed execution. An unavailable input balance points to the wallet state, while a changed borrow limit, insufficient pool liquidity or an unsafe projected position points to current protocol conditions. Recheck the same asset, amount and account rather than altering several inputs at once. Submit a new request only after the previous digest has a final status and the revised preview reflects current data.

View image file

Similar options with different consequences

Similar-looking actions should be compared by the position entry they create or remove. Supply and repayment both send assets from the wallet, yet supply creates a pool claim while repayment reduces an existing obligation. Borrowing and withdrawal both return assets to the wallet, but borrowing creates debt while withdrawal redeems part of an existing claim.

Confirmation may prove a partial change without proving a complete exit. For example, a confirmed partial repayment proves the debt decreased. Only a zero debt balance proves the borrowing position has closed.

Navi protocol: what people ask

Can supply APY and borrow APY be compared as the same kind of rate?: No, the two rates describe opposite sides of a lending pool. Supply APY estimates variable earnings on a deposited asset, while borrow APY estimates the variable interest cost attached to debt. Both can change with pool conditions. Compare them only within the intended action, and keep any separately displayed incentive rewards distinct from the base supply or borrowing rate.
How long should a pending Sui transaction remain unresolved before I retry?: There is no fixed delay that makes a retry safe. Use the transaction digest to determine whether the earlier request succeeded, failed or remains pending. If the wallet never submitted a transaction and produced no digest, a fresh request may be appropriate. When a digest exists, wait for its final status before signing the same action again to avoid an unintended duplicate.
Is a transaction digest enough to verify the exact lending action?: No, a digest identifies the Sui transaction but does not summarize whether its effect matches your intention. Check the execution status, operation type, coin changes and connected address, then compare them with the refreshed Navi protocol position. A successful digest paired with the wrong amount or an unexpected account effect requires inspection rather than an automatic retry.
Why can the confirmed health factor differ from the earlier preview?: The preview uses the account and protocol state available when the operation is estimated. Oracle prices, accrued debt and other relevant on-chain state can change before execution, so the confirmed position may have a different health factor. Treat the preview as a decision input. After execution, use the refreshed health factor and balances as the account's resulting state.
Does a partial repayment close the borrowing position?: No, a partial repayment reduces the debt by the amount successfully applied but leaves the remaining obligation open. Interest can also affect the live balance between an earlier estimate and execution. Confirm the transaction status first, then inspect the refreshed debt balance. A zero debt balance, rather than a successful repayment notification by itself, establishes a complete borrowing exit.
Can several Navi protocol operations share one Sui transaction digest?: Yes, when a transaction builder bundles supported operations into one Sui programmable transaction block. Review every command presented for signature. One digest then identifies the bundled transaction, while its effects and the refreshed position show the combined outcome. Do not assume an intended operation was included merely because another operation in the same request is visible.

Updated · Thu 17 Sep 2026