USD1 Market: Avoid 4 Critical Offboarding Assumptions

The USD1 market offboarding notice, a visible JustLend market page and a contract status flag answer different questions. A planned restriction is not a dated execution receipt. A page loading is not proof that a particular account can open a position. One pause flag is not a complete permission check.

We checked the public English page and made read-only Mainnet calls on November 2, 2026. At 05:02:12 UTC, the two market-specific pause getters returned false, while the market record returned listed=true and a zero collateral-factor value. These are narrow observations, not a conclusion that the service is open, closed, safe or suitable for anyone. No wallet, signature, supply, borrow, repayment or withdrawal was used.

1. A USD1 market offboarding notice is not an execution date

The official September 16, 2026 notice describes an initial offboarding phase. It says new supply and borrowing will be restricted after a forthcoming change, with existing positions managed during the transition and further parameter proposals to follow. The notice does not supply an exact effective block or deadline.

September 16 is the announcement date; November 2 is our check date. We have not reconstructed enactment history or proved whether an earlier restriction was ever applied and later changed. A current false flag cannot resolve those historical questions. Keep the notice and the runtime observation as separate entries instead of inventing a completed transition date.

2. A market page is not personal eligibility

Following the notice’s SBM-USD1 link opened the official USD1 market detail page. It displayed USD1, jUSD1, Supply and Borrow controls, market figures and a collateral-factor label of 0%. We did not use the displayed rates as an executable offer.

Clicking Supply only opened a wallet-connection dialog. We closed that dialog without choosing a wallet or accepting terms. This establishes a connection gate, not the outcome of a connected-account check. A visible button, market balance or interest-rate label is insufficient evidence that a new position can be created.

The useful stopping point for a reader doing research is a note about what was visible and what remained behind the gate. Repeatedly clicking a button or connecting an account merely to resolve a documentation question would change the scope of the task. This guide provides no account-specific transaction instructions.

3. Keep the market, underlying and controller apart

The market link identifies a jToken contract. The official protocol repository explains jTokens and the separate controller policy role. Here, minting refers to the lending-market supply workflow; it is not a statement about the USD1 issuer’s global token issuance.

The returned underlying address is protocol-reported evidence, not independent certification of issuer identity. We did not match deployed implementation bytecode to repository source. Addresses and relationships in this table are dated observations and can change. In particular, substituting the underlying token for the jToken argument would ask a different question.

The proxy’s own supplied ABI did not include the three market getters below. We retrieved its reported implementation’s ABI, verified the view methods and address argument, then called the proxy. Reading implementation storage directly would not be the same check. A missing method in one ABI is an information gap, not a false pause flag.

4. A false pause flag is not complete permission

Our three sequential calls used the jToken address as the market argument. They were current-state Mainnet reads through one public provider, not a single block-pinned historical snapshot. Their saved timestamps were 05:02:12.884, 05:02:12.931 and 05:02:12.999 UTC on November 2.

A zero collateral factor concerns the collateral policy represented by that field. It does not mean that every action is paused, that an existing loan is zero or that a withdrawal succeeds. The listed flag does not erase other guards, caps, liquidity conditions or account constraints. We did not test those additional conditions or any personal position.

Likewise, the reward flag is not a complete inventory of incentives, and we make no return or yield claim. The page and reads do not establish whether all controls align with an announcement’s future intent. Resolving implementation timing would require further dated governance and execution evidence that this check did not obtain.

Repeat the evidence check without a wallet

1. Start at the official dated notice and follow its market link. Preserve the exact host, language, market address and observation time.
2. Record the public labels. Distinguish a visible button from an operation result; our Supply check ended at the connection dialog.
3. If using an API, obtain the market’s underlying and controller relationships with their verified view methods. Preserve each response and timestamp.
4. Confirm the controller target, implementation ABI, address input and output types before reading its market getters. Do not reuse another market’s argument or read implementation storage as proxy state.
5. Record each returned value beside the precise question it answers. Leave unavailable responses, missing ABI entries and untested account conditions unresolved.

The TRON constant-call reference describes simulation without broadcasting and explains that the node’s current view can change. Our calls were limited to verified view methods. A returned simulation transaction object or identifier is not a broadcast receipt. We used the market address only as simulation caller context, not as a reader’s wallet.

Check response success and typed output, not HTTP status alone. An empty result, provider error or undecodable word cannot be normalized to false. Our bool outputs were full 32-byte zero words; the listing tuple began with a one word. The ABI type supplies their meaning. Treating a nonempty zero-filled string as JavaScript truthiness would give the wrong result.

Optional decoder check for one bool word

The ABI specification defines bool using zero and one. This small offline helper accepts one unprefixed 32-byte hexadecimal word, rejects other values and preserves false separately from a decoding error. It does not validate the provider response or an entire tuple.

function decodeBoolWord(word) {
  if (typeof word !== 'string' || !/^[0-9a-fA-F]{64}$/.test(word))
    throw new Error('Expected one unprefixed 32-byte hex word');
  const n=BigInt('0x'+word);
  if (n !== 0n && n !== 1n) throw new Error('Not canonical ABI bool');
  return n===1n;
}

We tested six synthetic format fixtures: canonical zero and one, plus rejection of an empty string, a prefixed word, non-hex characters and a word containing two. We then compared the first words of our three saved actual getter results with their decoded values: false, false and true. All six format cases and three actual comparisons passed. The remaining tuple fields were decoded separately from their verified ABI.

These local cases show the helper’s narrow input boundary. They do not prove a contract safe, establish that a query is current, detect all provider errors or authorize a market operation. In particular, an unavailable response must remain an error rather than be replaced by a zero word. A successfully decoded false value and missing evidence are different outcomes.

Our original status worksheet

Notice title, date and any explicit effective boundary:
Official market URL and jToken argument:
Public page labels / whether a wallet gate was reached:
Underlying / controller proxy / reported implementation:
Getter signature / input / output ABI:
Provider, network and timestamp for each call:
Raw result / decoded value / request or decoding errors:
Question answered / historical or personal question unresolved:
Next dated governance or execution evidence required:

For a missing result, retain the error and stop the inference. For changing values across times or providers, compare the method, address roles and state view before calling it a contradiction. For a personal position question, these public observations cannot substitute for the relevant account record or an actual authorized result.

Choose the next record

The USDJ sunset record guide concerns a different asset and service history; a USD1 market notice proves nothing about USDJ conversion conditions. The contract owner and proxy-role guide helps distinguish an implementation from current authority. The jUSDT receipt-token guide explains why a lending receipt and an underlying token are separate records; its USDT-specific addresses and quantities must not be reused for USD1.

Frequently asked questions

Was the USD1 market closure confirmed in this check?

No. We verified a dated notice, a public page and narrow current-state fields. We did not establish a final closure or effective block.

Did false pause flags prove new positions were available?

No. They describe two market-specific guards at the observation time, not every policy or account condition.

Did a visible Supply button prove a successful supply?

No. Our click opened a wallet-connection dialog, which we closed. No position or transaction was created.

Is the jToken address the underlying USD1 address?

They were different addresses in our saved reads. Preserve the jToken as the market argument and identify the underlying separately.

Does this notice also announce the USDJ sunset?

No. USD1 market offboarding and the USDJ system sunset involve different assets and service histories.

Independent Tronscan News guide, AI-assisted drafting with primary-source and read-only checks on November 2, 2026. Two original diagrams, an address-role map, three recorded getter results and a status worksheet support the method. No wallet, financial action, bytecode audit, full policy audit, enactment history or personal eligibility test is claimed. Browse the Tronscan News homepage; use About & Standards for corrections.