Just lend in jToken markets by reading account state, making one valid adjustment and verifying closure
For a JustLend jToken position, treat the account record as the acceptance test for every credit action. Read the supplied balance, collateral status, outstanding debt, borrow capacity and health or risk field as one snapshot before signing. Then choose one supported change, such as repaying debt or reducing a planned withdrawal. A wallet confirmation alone does not prove successful execution or the intended account state change. Refresh the same address and market after the transaction executes successfully. Closure requires the debt, collateral and supplied-asset records to match the intended endpoint, with no shortfall, pending operation or unreconciled balance.
In short: A JustLend jToken position is closed only when its records match the intended endpoint, not when the wallet merely confirms a transaction.
Supply, collateral and debt appear as distinct account states
JustLend DAO's jToken markets record supply, collateral designation and borrowing as separate conditions. A supply-only balance is not a debt position. It may accrue supply interest under the market rules, while the corresponding jTokens represent the claim on supplied assets. Designating an eligible supply as collateral changes how the account supports borrowing. Borrowing then adds an obligation whose current balance reflects accrued interest.
Supply without debt
A supply-only account should show both its jToken balance and the equivalent underlying balance. The collateral or entered-market field may remain inactive. That distinction matters because a completed supply does not automatically establish borrowing capacity. The account can retain a supplied position without any outstanding borrow or liquidation exposure from debt.
Collateral-backed borrowing
When borrowing is intended, the useful fields expand to collateral status, available capacity, current debt and health or risk. Oracle valuation and the applicable collateral rule connect those fields. Market liquidity imposes another limit: acceptable account health does not guarantee that enough underlying tokens are available to borrow.
A missing prerequisite blocks a valid borrow
The earliest useful check is whether the supplied market actually supports the proposed credit action. A supplied asset does not count toward borrowing capacity until its market has been entered as collateral. A supply transaction can therefore succeed while the available borrowing capacity remains unchanged. Finding that mismatch before signing separates a missing prerequisite from a problem with the requested amount.
Collateral status before amount
Read the entered-market flag before changing the borrow size. Then inspect account liquidity, available capacity and any shortfall. If the market is not entered, repeatedly lowering the amount does not repair the missing collateral designation. A separate collateral action must complete before the supply can support debt.
Market capacity before signature
The account can pass its collateral check while the market lacks enough available liquidity. The wallet must use the correct network, and the sending account needs enough TRON energy and bandwidth or enough TRX to cover a resource shortfall. These are different failure causes, so changing collateral cannot solve a market-liquidity shortage. Read each prerequisite in its own field.
Which fields show real progress?
Progress appears when the account fields change in the direction required by the selected action. Read them from the same address, network and reasonably current snapshot:
- The supplied balance and corresponding jToken balance show the active supply claim.
- The entered or collateral flag shows whether that claim supports borrowing.
- The current borrow balance includes the debt that remains after accrued interest.
- Account liquidity, capacity or shortfall shows room for the proposed change.
- The health or risk field relates collateral support to the outstanding obligation.
Do not combine an old collateral value with a newer debt balance. That mixture can make the position appear safer or riskier than one coherent snapshot would show. When a timestamp or block reference is available, use it to identify stale reads. Otherwise, refresh all position fields together after the transaction reaches a final state.
One adjustment should produce one expected change
A useful adjustment has a named target field and a predictable direction. Changing several inputs at once makes reconciliation harder because the account may move for more than one reason. Choose the smallest action that addresses the observed constraint, then reread the whole position before considering another change.
Repay the current debt
Repayment targets the current borrow balance rather than the original borrowed amount. The account may accrue interest between the first read and execution, so a manually entered amount can leave a remainder. A TRC20 repayment also requires sufficient token balance and allowance for the relevant contract.
Add eligible collateral support
Additional supply affects borrowing support only when the asset is eligible and entered as collateral. Confirm both changes instead of assuming that a larger supplied balance improved health. If the entered flag remains inactive, the new supply can exist without increasing the account's usable collateral.
Reduce a planned withdrawal
Withdrawing collateral lowers the support available to an active debt position. A smaller request may satisfy the account-liquidity check when the original request would create a shortfall. Reserve liquidity remains a separate constraint, so a safer account state does not guarantee immediate redemption.
Pending, failed and confirmed are different outcomes
A broadcast transaction is only a submitted request. While it remains pending, the dashboard may still show the earlier position. A failed or reverted transaction produces no intended account change, even if the wallet retains its transaction identifier. Inspect execution status before deciding that the application merely needs more time.
A confirmed successful call is the point to query the account again. The new snapshot should show the expected balance, collateral flag or debt change. An indexer may briefly display older data, so compare its block or timestamp when available. Do not resubmit an adjustment solely because one cached display has not refreshed.
Why can a healthy account move toward liquidation?
Account health can deteriorate when debt grows, collateral valuation falls or a relevant market parameter changes. The current borrow balance includes accrued interest, so it can rise without a new wallet transaction. A wallet that remains idle can therefore hold a position whose risk has changed since the previous snapshot.
The appropriate adjustment follows the field that moved. Higher debt can be addressed through repayment, while reduced collateral support may require more eligible collateral or less exposure. Read the threshold defined for the relevant market and account version. A V1 health factor and a V2 risk ratio should not be treated as interchangeable labels.
Account records and transaction receipts answer different questions
A transaction receipt shows whether a submitted contract call executed on the selected network. The account record shows the economic state that followed. Match the wallet address, market and operation across both records. Otherwise, a valid receipt from another action can be mistaken for evidence that this position changed.
Approval is a common source of confusion. A successful token approval authorizes a spender, but it does not repay debt. Likewise, a successful supply does not prove that collateral was enabled. Reconciliation should connect the executed operation with the specific account field that operation was meant to change.
Similar operations leave different state changes
Supply, collateral entry, borrowing, repayment and redemption affect different parts of the position. The expected account condition helps distinguish a completed action from a nearby prerequisite.
| Operation | Account condition to verify |
|---|---|
| Supply | The supplied balance and jToken claim appear; collateral status may remain unchanged. |
| Enable collateral | The entered status changes and borrowing capacity reflects the eligible supplied value. |
| Borrow | The borrowed asset arrives, current debt rises and health or risk reflects the obligation. |
| Repay | Current debt falls after execution; a TRC20 repayment also needs sufficient allowance. |
| Redeem | jTokens burn and underlying assets return, subject to liquidity and remaining collateral support. |
| Complete closure | No unintended debt or supply claim remains, and the wallet balance reconciles with the final account record. |
The rows are not interchangeable completion signals. For example, repayment can close the debt while leaving a valid supplied position. Redemption can remove supply only when reserve liquidity and the remaining collateral requirements permit it.
What proves that the position is closed?
Closure depends on whether the intended endpoint is debt repayment or removal of the entire lending position. Zero current debt proves the borrowing obligation has ended. It does not prove that supplied assets were redeemed, collateral status was cleared or underlying tokens returned to the wallet.
Debt record settled
Read the current borrow balance after repayment instead of comparing only the submitted amount with an earlier figure. Accrued interest or a prior partial payment can leave a small balance. Repayment changes the borrow record, while redemption changes the supplied-asset record. The health field may become irrelevant to debt risk once no borrow remains.
Supply and collateral reconciled
A complete account exit also requires the intended supplied balance and jToken claim to clear. The underlying asset should return to the same wallet. If the protocol permits market exit, confirm that the collateral designation no longer persists. Reserve liquidity can delay redemption even after the debt reaches zero.
A final reconciliation catches stale or partial state
Compare the intended endpoint with the executed operation and the refreshed account record. Keep the address, network, market and transaction identifier together so that another position cannot be confused with this one. Unresolved debt, missing redeemed assets, an unexpected collateral flag or a remaining shortfall each identifies a specific incomplete state.
The stopping condition changes with the original intent. If the goal was debt-only closure, a retained supply balance is expected and should not be treated as an unfinished withdrawal. If the goal was a full exit, both debt and the intended supply claim must be absent before the position is complete.
Practical questions about Just lend
Does a zero wallet balance mean my supplied position disappeared?
No. Supplying moves the underlying asset into the market and creates a corresponding jToken claim. The wallet may show no remaining underlying balance while the account still records supplied assets. Compare the jToken balance and its underlying equivalent for the same address and network. A wallet balance alone does not reveal collateral status or outstanding debt.
Which token must be available before repaying a TRC20 borrow?
The wallet needs the same underlying token that the account borrowed. It must also provide sufficient allowance to the relevant repayment contract. Read the current borrow balance shortly before signing because accrued interest may change the required amount. Submitting the original principal can leave debt when the current balance is higher.
Is an unlimited token approval required for repayment?
No. The allowance needs to cover the intended token transfer, but it does not have to be unlimited. A lower allowance can cause the repayment to fail, while a larger unused allowance may remain after completion. Confirm the spender, network and requested amount before approving, then verify the debt through the refreshed account record.