Can a successful allowance approval be matched to a later supply?

Yes, but the approval and supply remain separate transactions. Match both to the same account, underlying asset and approved spender, then retain each transaction identifier. The approval proves the spending allowance changed. Only the later supply confirmation and increased jToken, vault-share or market-share position prove assets entered the selected lending market.

Does a confirmed transaction identifier prove the expected position amount was applied?

No. The identifier proves a particular transaction exists and lets you inspect its confirmed result. Compare its sender, called contract, amount and decoded action with the saved input, then read the resulting position. Unit conversion, wrong-market selection or a different account can still make the economic result differ from the user's intention.

Which state proves an exact-underlying redemption completed?

The wallet should receive the requested underlying amount and the supplied receipt position should decrease by the quantity required at the applicable exchange rate. For V1, redeemUnderlying uses the underlying asset's decimals and burns the necessary jTokens. This differs from redeem, whose input is a jToken quantity using eight decimals.

Is a wallet balance enough to confirm a borrowed asset arrived correctly?

A wallet balance confirms receipt only when its change can be tied to the borrowing transaction. The stronger record also shows increased debt in the selected market and the revised collateral or risk state. Saving all three prevents an unrelated transfer from being mistaken for a successful borrow and exposes a borrow recorded under another market.

How can V1 and V2 position records be kept distinct?

Label V1 records with the relevant jToken market and account-level collateral state. Label V2 records with the vault or isolated-market identifier and its share balances. V2 debt and collateral belong to a specific isolated market, while V1 positions use the Comptroller's entered-market context. The two accounting models should not be merged into one balance row.

Can another account repay a V1 borrower's debt?

Yes. V1 supports repayment on behalf of a borrower. The record should identify the paying account separately from the borrower whose debt changes. After confirmation, compare the payer's repayment-asset balance with the borrower's current debt. Do not expect the payer's own borrow position to fall unless the payer and borrower are the same account.

How does accrued interest affect a full-repayment check?

Accrued interest can increase the debt between the initial read and transaction confirmation. A manually copied balance may therefore leave a small remainder. Verify the current borrow balance after confirmation instead of assuming the earlier amount closed the position. For V1 TRC20 markets, repayBorrow(uint256(-1)) uses the freshly accrued balance during execution; the token allowance must cover the current debt.

Justlend actions connect recorded inputs with a confirmed position change

Updated · Thu, Sep 17, 2026

Justlend gives each lending action two records worth comparing: the state before signing and the state after confirmation. Save the connected account, TRON network, market identifier, asset, amount, unit basis and relevant position values before signing. After the transaction confirms, match its result with the updated wallet and protocol position. A changed allowance alone does not prove a supply, and a transaction identifier alone does not establish the expected debt or receipt-token balance. The action is complete when the confirmed on-chain state shows the asset moved, the correct shares or debt changed and, where collateral is involved, the account remains within its intended risk boundary.

In this guide

The starting record before a signature

A starting record should identify the intended action precisely enough to distinguish it from another market, asset or account after the wallet prompt appears.

Action identity

Action identity begins with the connected account, selected network and exact market. Record whether the transaction targets V1, a V2 vault or a V2 isolated market. Symbols alone are weak identifiers because interfaces can abbreviate names. A contract address, jToken address, vault address or V2 market identifier gives the comparison a stable anchor.

Connected account and TRON network
V1 market, V2 vault or isolated-market identifier
Underlying asset and intended action
Displayed amount and raw-unit amount
Relevant allowance before a TRC20 transfer
Wallet balance, supplied claim, debt and collateral state

Units and live state

Unit handling determines whether two equal-looking records describe the same quantity. Every V1 jToken uses eight decimals, while the underlying asset keeps its own decimal setting. Preserve raw integers beside readable amounts when precision matters. Also timestamp live values such as available cash, exchange rates, debt and borrowing capacity. Those fields may change between the initial read and confirmation, so they describe a snapshot rather than a permanent promise.

Transaction proof and position proof

Transaction proof answers whether the requested contract call reached the network and received a final status. Position proof answers whether the intended economic state now exists. Both records matter because they resolve different questions.

Transaction proof

Transaction proof includes the transaction identifier, sending account, called contract, confirmed status and block context. Decoded events can add the transferred amount, minted receipt units or updated debt. Compare those fields with the saved intent. A successful allowance approval remains an approval transaction; it does not become evidence of a later supply merely because both operations concern the same asset.

Position proof

Position proof comes from a fresh account read after confirmation. For a supply, inspect the underlying balance and the V1 jToken or V2 share position. For a borrow, inspect the received asset, current debt and revised risk state. Repayment requires a lower debt balance, while redemption requires returned underlying and fewer receipt units. This second read catches wrong-market selections, unit mistakes and interfaces displaying cached data.

Three actions and their correction boundaries

Supply, borrow and repay operations change different fields, so each needs its own starting evidence, completion test and bounded response to a mismatch.

Table: Three actions and their correction boundaries
Action	Starting evidence	Confirmed state	Correction boundary
Supply	Underlying balance, allowance and selected market or vault	Underlying leaves the wallet and the supplied claim increases	An approval without a supplied position still requires a separate supply transaction
Borrow	Collateral status, available market cash, debt and borrowing capacity	The loan asset arrives and account debt increases in the selected market	A failed borrow requires fresh cash and risk reads before another attempt
Repay	Current debt, repayment asset balance and required allowance	The payer spends the asset and the borrower debt decreases	A residual balance requires a current debt read before a full-close retry

The table separates reversibility from correction. An unbroadcast request can be changed freely. A pending transaction must first reach a known outcome. Once a write confirms, correction usually requires another valid protocol action rather than editing the original record.

How do you verify a completed supply?

A completed supply appears as a confirmed write followed by an increased supplied position in the selected market. The comparison must use the correct accounting model. In V1, supplying mints jTokens, whose exchange rate to the underlying rises as interest accrues. Therefore, the jToken quantity and its underlying value are related but are not interchangeable fields.

Save the pre-supply underlying balance, jToken balance and exchange-rate context. After confirmation, read them again from the same account and market. The underlying wallet balance should reflect the transfer and the supplied claim should increase. Interest accrual can change the underlying-equivalent value, so verify the minted receipt position rather than demanding a permanently fixed conversion ratio.

V2 uses different evidence. A vault deposit produces vault shares, while direct isolated-market supply updates that market's supply shares. Record the selected vault or market identifier before signing. A share increase in another location does not validate the intended action, even if the underlying asset matches.

Borrow verification without stale limits

Borrow verification starts with the exact collateral context supporting the debt. In V1, a supplied market must be entered before its balance counts as collateral. Record entered markets, current debt, account liquidity and the requested loan asset before signing. The final read should show the borrowed asset and a larger current debt balance for that account.

View image file

The saved borrowing limit explains why the request looked possible, but it is not completion evidence. Oracle values, accrued interest, market cash and governance-controlled parameters can change. Recalculate the risk state after confirmation, especially when the new debt leaves little unused capacity. The post-transaction position determines the next safe action, not the earlier preview.

V2 evidence stays inside the selected isolated market. Its market identifier binds the loan asset, collateral asset, oracle, interest-rate model and liquidation loan-to-value setting. Check debt and collateral within that identifier. A position elsewhere cannot offset the market merely because both records belong to the same wallet.

Repayment and redemption leave different evidence

Repayment reduces debt, while redemption converts a supplied claim back into its underlying asset. Keep the operations separate in the final record, even when an interface submits them together. Verify current debt after repayment, then verify returned underlying and reduced receipt units after redemption. Remaining debt may constrain collateral redemption, and available market cash can constrain the underlying amount returned.

One mismatch branch from confirmation to recovery

Before requesting another signature, determine whether the mismatch comes from transaction status, the decoded action or the account state.

Normal confirmation

Normal confirmation begins with one signed action and ends with a fresh state read. Match the account, network, market identifier, asset and raw amount to the saved input. Then compare only the fields the action should change. A supply affects the wallet and supplied claim; a borrow affects the wallet, debt and risk state.

Keep the transaction identifier with that comparison. It connects the intent to the observed state without treating a screen message as final proof.

Confirmed chain state with a delayed display

A delayed display can show an old position after the transaction has confirmed. Query the same account and market again before assuming failure. If the direct state reflects the intended change, preserve that evidence and allow the interface to catch up. Do not submit the same action again merely to force a visual update, because the second write can create another real position change.

Retry only after the first outcome is known

Retry only after the first transaction is confirmed as failed or rejected before broadcast. If its status remains unknown or the expected position has not appeared, keep checking the transaction and account state instead of signing again. Read the allowance, wallet balance, debt, collateral and available cash again because the original inputs may be stale. Keep the retry within the original intent. If an apparently absent first transaction later appears as confirmed, stop and reconcile its result with the account state before making another change.

The final record worth retaining

The final record should retain the transaction identifier, block context, account, network, market identifier, asset, raw amount and relevant before-and-after values. Add the confirmed status and any remaining debt, collateral constraint or allowance requiring attention. This compact record lets the next action start from the current on-chain position rather than the earlier interface preview.

Quick answers about Justlend

Can a successful allowance approval be matched to a later supply?: Yes, but the approval and supply remain separate transactions. Match both to the same account, underlying asset and approved spender, then retain each transaction identifier. The approval proves the spending allowance changed. Only the later supply confirmation and increased jToken, vault-share or market-share position prove assets entered the selected lending market.
Does a confirmed transaction identifier prove the expected position amount was applied?: No. The identifier proves a particular transaction exists and lets you inspect its confirmed result. Compare its sender, called contract, amount and decoded action with the saved input, then read the resulting position. Unit conversion, wrong-market selection or a different account can still make the economic result differ from the user's intention.
Which state proves an exact-underlying redemption completed?: The wallet should receive the requested underlying amount and the supplied receipt position should decrease by the quantity required at the applicable exchange rate. For V1, redeemUnderlying uses the underlying asset's decimals and burns the necessary jTokens. This differs from redeem, whose input is a jToken quantity using eight decimals.
Is a wallet balance enough to confirm a borrowed asset arrived correctly?: A wallet balance confirms receipt only when its change can be tied to the borrowing transaction. The stronger record also shows increased debt in the selected market and the revised collateral or risk state. Saving all three prevents an unrelated transfer from being mistaken for a successful borrow and exposes a borrow recorded under another market.
How can V1 and V2 position records be kept distinct?: Label V1 records with the relevant jToken market and account-level collateral state. Label V2 records with the vault or isolated-market identifier and its share balances. V2 debt and collateral belong to a specific isolated market, while V1 positions use the Comptroller's entered-market context. The two accounting models should not be merged into one balance row.
Can another account repay a V1 borrower's debt?: Yes. V1 supports repayment on behalf of a borrower. The record should identify the paying account separately from the borrower whose debt changes. After confirmation, compare the payer's repayment-asset balance with the borrower's current debt. Do not expect the payer's own borrow position to fall unless the payer and borrower are the same account.
How does accrued interest affect a full-repayment check?: Accrued interest can increase the debt between the initial read and transaction confirmation. A manually copied balance may therefore leave a small remainder. Verify the current borrow balance after confirmation instead of assuming the earlier amount closed the position. For V1 TRC20 markets, repayBorrow(uint256(-1)) uses the freshly accrued balance during execution; the token allowance must cover the current debt.