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.

Table of Contents
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
- Confirm Mainnet and the full market address. Compare the token page with the official market mapping.
- 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.
- Expand only the relevant no-argument read methods. We read name, symbol, decimals, underlying, exchangeRateStored and getCash.
- Record each raw return and its type. A large uint256 value is not automatically a whole-token amount.
- Check the underlying separately. We opened the linked USDT asset’s public token page and confirmed its full address and six-decimal field.
- 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.

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.
Leave a Reply