NAVI Protocol (NAVX) Price

NAVX is the native token of NAVI Protocol. NAVI is a decentralized liquidity protocol on Sui whose core service lets users deposit assets to earn lending interest or borrow other supported assets against collateral. Holding NAVX itself does not mean depositing in the protocol, holding nTokens, or owning the collateral for a particular loan. The official tokenomics documentation describes the native token as a governance and utility token. Its listed uses include participating in protocol proposals and parameter updates, staking-related rewards and fee discounts, and incentives for providing liquidity. Available functions, eligibility, and amounts depend on the protocol interface and the governance or contract settings in effect at the time; holding NAVX alone does not imply a fixed return or fee share.

NAVI is built around “one shared liquidity pool for each supported asset,” rather than one-to-one matching between depositors and borrowers. Depositors place an asset into its corresponding pool, and the pool supplies that asset to borrowers; interest paid by borrowers is the basic source of deposit returns. After a deposit, the protocol mints the corresponding nToken as evidence of the depositor’s share in that pool; the documentation uses nSUI as an example. To withdraw the underlying asset, the user calls the withdrawal function to redeem the corresponding amount of underlying asset, and the relevant nToken is burned. When withdrawing to another address, the address sending the transaction must still hold the nToken that will be burned. An nToken therefore represents a deposit position in a specific pool, not NAVX, and should not be confused with NAVX’s governance and incentive functions.

Borrowing on NAVI first requires depositing and enabling an asset that can serve as collateral. The protocol calculates remaining borrowing capacity from oracle prices for the account’s collateral and debt, together with parameters such as the loan-to-value ratio (LTV) configured for each market. Borrowed assets are sent to the wallet that initiates the transaction; when repaying, the corresponding debt asset is returned to the pool. Collateral ratios are not uniformly fixed for every asset. Protocol market configurations can separately set LTV, liquidation threshold, liquidation bonus, and whether borrowing is allowed; oracles convert assets into relative prices so collateral value and debt value can be compared. A fall in collateral, a rise in the borrowed asset, accrued debt interest, or changes to relevant parameters can all reduce a position’s safety. Enabling collateral does not eliminate these risks.

NAVI calculates borrowing and deposit rates separately for each asset, so neither is a fixed return guaranteed to NAVX holders. The official documentation expresses an asset pool’s utilization as U = B / (C + B): B is total borrowing of that asset and C is total cash in that asset’s pool. Changes in total borrowing or total cash change utilization, an input to the calculation. The protocol also stores interest-rate-model parameters for specific assets, including the base rate, slope, optimal utilization, jump-rate slope, and reserve factor, and provides methods to calculate borrowing and deposit rates separately. Thus, the rate displayed for a market depends on that market’s pool state at that time and its interest-rate-model parameters; a rate for one market or a page value at one point in time is not a yield commitment applicable to every asset and every period.

When an account’s health factor falls below 1, any NAVI participant can initiate liquidation. A liquidator repays part of the debt on the account’s behalf and receives collateral at a discount in the form of a liquidation bonus. This incentive gives external participants a reason to cover debt when collateral is insufficient, reducing the risk of bad debt in the pool. The health factor is determined jointly by collateral value, debt value, and market risk parameters, so price movements and accrued interest can trigger liquidation. The current single-liquidation close factor listed in the official technical documentation is 0.5, meaning one valid liquidation can repay at most 50% of the position’s outstanding debt, rather than automatically clearing all debt at once; the health factor improves after liquidation. The collateral that can actually be liquidated, the bonus, and the repayment amount are also constrained by the relevant market parameters, oracle prices, and transaction execution conditions.

NAVI sets risk boundaries by asset and by collateral–borrowed-asset combination. Official documentation lists supply caps, debt caps, blacklists for specific collateral paired with specific borrowed assets, and borrowing caps calculated as a proportion of collateral value. Their purpose is to limit the risk transmission to pools from volatile or thinly liquid assets. A supply cap limits the scale at which a particular collateral asset can enter the money market, avoiding accumulation of illiquid assets to a level that may be difficult to liquidate. A debt cap limits total borrowing in a given borrowing market backed by a specified collateral asset, measured in the underlying token of the borrowed asset. A blacklist prevents that collateral asset from borrowing a specified asset, effectively setting the debt cap for that combination to zero. These controls change which collateralized borrowing positions users can open or expand, but do not mean that the relevant assets no longer carry price, liquidity, or smart-contract risk.

Under the design described in NAVI’s official tokenomics documentation, the native token’s governance role is not limited to voting on general direction: holders can participate in protocol proposals and updates. The technical documentation gives setting interest rates, onboarding new assets, and changing collateral ratios as examples of governance matters. These respectively affect borrowing costs, available borrowing capacity, and liquidation risk, so governance decisions affect conditions for depositors and borrowers through market rules. The documentation also describes a vote-escrowed veNAVI mechanism. After users lock native tokens, they receive veNAVI voting power related to the amount and duration of the lock. veNAVI can be directed to gauges for different liquidity pools or assets, and gauges with more voting power receive greater native-token incentive emissions. The logic is to transmit token lockers’ preferences over where incentives go into liquidity incentives. Because the cited documentation does not provide the current lock duration, weights, emission amount, or applicable scope here, it cannot be used to infer a particular address’s return or voting power.