What Is jUSDT? Read the Receipt and Its USDT Amount

Written by

in

jUSDT is JustLend’s USDT-market receipt token on TRON, not the USDT token itself. The two assets have different contracts and different decimal precision. A large jUSDT quantity should not be read as the same number of USDT, and a market’s available cash is not an individual account balance.

This beginner guide identifies the asset, reads six public contract fields and works through one explicitly hypothetical conversion. We checked the explorer on 31 October 2026 without connecting a wallet. We did not deposit, borrow, approve, redeem or transfer assets.

jUSDT role map separating an eight-decimal receipt token, six-decimal USDT underlying and market-level cash
Original role worksheet. Each quantity answers a different question.

What jUSDT represents in the lending market

The official JustLend market-address reference maps jUSDT to the USDT market at TXJgMdjVX5dKiQaUi9QobwNxtSQaFqccvd. This is the receipt-token contract. It should not be substituted for the underlying asset’s contract or for a receiving account’s deposit instructions.

The project’s Supply and Borrow Market reference distinguishes jToken quantities from underlying-asset quantities. In this exercise the receipt token uses eight decimals while the underlying USDT uses six. Matching the standard TRC20 does not make their amounts or roles interchangeable.

Our TRON USDT introduction owns the ordinary stablecoin, native-asset and transfer-record task. The present question concerns a lending receipt and the evidence needed to interpret its amount.

Identify jUSDT before reading its amount

Role Full contract Observed precision
JustLend receipt token TXJgMdjVX5dKiQaUi9QobwNxtSQaFqccvd 8 decimals
Underlying TRON USDT TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t 6 decimals

We opened the public Mainnet receipt-token page. It displayed JustLend USDT (jUSDT), type TRC20 and Decimal 8. Following its full contract address led to a page identified as CErc20Delegator. We then used its Read Contract view.

The displayed name is useful orientation, but the full address is the identity reference. A shortened label in a wallet or a familiar logo is insufficient for comparing balances. If the contract differs, leave the identity unresolved rather than borrowing the rate from this guide.

How we read the jUSDT fields without signing

  1. Confirm Mainnet and the full market address. Compare the token page with the official market mapping.
  2. Open the linked Contract page and choose Read Contract. The interface we checked exposed the methods below directly; it did not require the separate proxy read view used in our earlier staking-token example.
  3. Expand only the relevant no-argument read methods. We read name, symbol, decimals, underlying, exchangeRateStored and getCash.
  4. Record each raw return and its type. A large uint256 value is not automatically a whole-token amount.
  5. Check the underlying separately. We opened the linked USDT asset’s public token page and confirmed its full address and six-decimal field.
  6. Keep personal state outside the conclusion. We did not supply an account address to a balance method or execute a redemption.

Success is a labeled set of asset and unit observations. It is not receiving funds or proving that a particular account can withdraw. These steps describe the interface tested on the check date; if a later interface differs, re-identify the target and read methods before interpreting a return.

Our jUSDT read-result worksheet

Read method Observed return Scope
name() JTOKEN_USDT, string Contract-returned name, separate from the explorer’s friendly label
symbol() jUSDT, string Receipt-token symbol
decimals() 8, uint8 Receipt-token precision
underlying() TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t Underlying token address, not a receiving account
exchangeRateStored() 108907289435238, uint256 Stored scaled ratio for the raw-unit calculation below
getCash() 161708478581513, uint256 Market cash in the underlying asset’s smallest units

The six reads were sequential, not pinned to one block, and were not independently reproduced through another node. The word Stored matters: this is not a fresh market bid, a newly accrued personal balance or a completed withdrawal quote. We do not turn the observed rate into a future yield claim.

Convert jUSDT with both decimal scales present

Begin with an explicitly hypothetical holding of 10,000 whole jUSDT. At eight decimals, that quantity is 1000000000000 smallest receipt-token units. The quantity is invented for this arithmetic exercise; it is not a balance observed in a real account.

For the raw-unit convention, multiply that receipt integer by the observed rate integer and divide by 10^18. Integer flooring gives 108,907,289 smallest USDT units. Divide that result by 10^6 to read 108.907289 USDT.

Equivalently, the human-readable underlying-per-receipt ratio for these eight-versus-six decimal scales is the mantissa divided by 10^(18 + 6 - 8), or 10^16. That yields 0.0108907289435238 USDT per whole receipt token. Multiplying by the hypothetical 10,000 gives 108.907289435238 USDT before reducing to the underlying’s smallest-unit precision.

We checked both routes using exact decimal and integer arithmetic. Their final precision difference is not a second token movement. These calculations explain units; they do not incorporate personal collateral constraints, costs, market conditions or the state changes that an actual redemption would require.

jUSDT calculation example converting a hypothetical ten thousand receipt tokens through an observed stored rate into six-decimal USDT units
Original arithmetic example, not an account holding or executed withdrawal.

Two common jUSDT conversion mistakes

Copying the receipt count as a USDT amount: 10,000 receipt tokens and 10,000 USDT describe different quantities. The contract identity and exchange-rate convention are missing from that shortcut. Do not infer a loss or profit merely because the two numbers differ.

Using one decimal divisor everywhere: treating the hypothetical receipt integer as a six-decimal USDT balance would produce 1,000,000 USDT. That would be an interpretation error, not an observed stablecoin holding. Conversely, dividing a raw rate by 10^18 and then treating the result as a whole-token ratio ignores the difference between the two assets’ decimals.

The TRC20 decimal-reading guide covers the basic precision distinction. This exercise adds the two-contract ratio, so the input unit, rate convention and output unit remain explicit throughout the calculation.

A unit-only training table: identical digits, different assets

The rows below deliberately reuse the same raw integer in two different asset contexts. They are synthetic precision exercises, not observed balances or transfers. They do not apply the exchange rate and therefore are not a conversion between the assets.

Invented raw integer Read as jUSDT, 8 decimals Read as USDT, 6 decimals
100000000 1 jUSDT 100 USDT
1000000 0.01 jUSDT 1 USDT

The digits do not contain their own asset identity. The contract and decimal field supply that context. This is why copying a raw balance into a note labeled only “amount” loses information another reader needs. Preserve the asset contract and unit beside the integer, even when the formatted number looks familiar.

Do not use this table to claim that one receipt token is worth 100 USDT. That would confuse a precision demonstration with an exchange-rate calculation. For the actual ratio example, use both the identified market and its stored rate as shown above. For a real account, also preserve the observation time and keep any untested personal constraints separate.

Why getCash is not your redeemable balance

At six decimals, the observed getCash return reads 161,708,478.581513 USDT. That is a market-level cash observation. We did not query a personal receipt balance, debt, collateral setting or account liquidity.

A pool-level number cannot establish what a particular account may redeem. Even a correct reference conversion of an actual token balance would answer a narrower quantity question. It would not by itself settle the relevant protocol checks or prove that an operation executed successfully.

Our sTRX receipt, rate and withdrawal-state comparison demonstrates a different protocol receipt with different units and timing questions. Its rate, 18-decimal token scale and unbonding observation should not be copied into the USDT lending market.

Keep a reproducible jUSDT note

Use separate fields for the network, receipt contract, underlying contract, both decimal counts, method name, raw rate, observation time and calculation convention. Mark a hypothetical input as hypothetical. Preserve the original integers alongside formatted values so another reader can reproduce the conversion.

If two observations disagree, compare full contracts and times before investigating the arithmetic. A stored contract return and a preformatted API field may use different unit conventions. In an earlier 31 October check, the separate documented market API refused our anonymous request with HTTP 403; we did not retry or use a successful API response as evidence here.

If the purpose is investigating an existing transfer, retain that transaction’s own hash, result and relevant token row. A market’s reference ratio does not replace a receipt. If the question is personal withdrawal eligibility, leave it unresolved until the actual account-specific evidence is checked through the official service.

Five frequently asked questions

1. Is jUSDT the same token as USDT?

No. It is the lending-market receipt token, with a different contract and quantity scale from its underlying USDT.

2. Did the jUSDT page show eight decimals?

Yes. Both the token page and our decimals() read showed 8; the underlying USDT page showed 6.

3. Does 10,000 jUSDT mean 10,000 USDT?

No. Use the correct rate and both unit scales. Our worked holding is explicitly hypothetical.

4. Does getCash show my personal USDT balance?

No. It is a market-level cash field, not the result of a personal balance or withdrawal check.

5. Did this jUSDT guide redeem or approve anything?

No. We read public fields and checked arithmetic. No wallet was connected and no financial action was performed.

Sources, method and corrections

The independent Tronscan News editorial team compared the cited project documentation, two public token pages and six contract reads on 31 October 2026. The result table, conversion worksheet and diagrams are original; AI assisted drafting and diagram preparation. The reads were sequential and not block-pinned. No personal position, current execution quote, asset-safety audit or redemption outcome is claimed. Editorial standards and corrections are linked from the Tronscan News homepage.

Rate this post

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *