TRONSCAN token reputation is an explorer-assigned classification. It is one piece of information about a token, not proof of its identity, source-code safety, reserves or investment quality. Record the exact label with the network, full token address and observation time before interpreting it.
The current rule page lists five levels: Unknown, Neutral, OK, Suspicious and Unsafe. A missing response is a separate condition. This guide shows how to preserve those distinctions using one actual public page observation and a tested local worksheet, without connecting a wallet or changing a rating.
Table of Contents
What the five reputation labels describe
The official reputation rules describe a system based on project information, community feedback and trading-related criteria. Their disclaimer says the classification is a reference, may be inaccurate and is not a definitive value judgment or a warranty. The table below summarizes the reading boundary, rather than reproducing every application requirement.
| Reputation label | Policy-level meaning | Conclusion it does not establish |
|---|---|---|
| Unknown | Default for a newly listed token; basic information alone does not remove it | Not a finding that the token is safe or fraudulent |
| Neutral | Information and transparency requirements under the stated rules | Not a neutral investment recommendation |
| OK | Additional conditions beyond Neutral, including trading and distribution criteria | Not a guarantee of future price, reserves or suitability |
| Suspicious | Unresolved reports or other warning signs identified by the explorer | Not our independent legal finding about every reported allegation |
| Unsafe | Stronger warning category under the explorer’s policy | Not a reason to sign a transaction to “repair” the label |
These are the explorer’s classifications. We are not assigning new reputations to projects or deciding which assets a reader should purchase. Consult the linked policy for its current requirements; a copied table cannot guarantee that the policy or a token’s classification remains unchanged.
A dated reputation observation, not an endorsement
On 1 November 2026, the Mainnet TrueUSD token page displayed Reputation: OK. Its contract field was TUpMhErZL2fhh4sVNULAbNKLokS4GjC1F4. We saved the visible page and checked the network and address, without using a wallet connection.
That observation establishes the displayed reputation for that record at that time. It does not establish the issuer’s current reserve position or an account’s redemption access. The separate TUSD identity and proxy-field worksheet documents what we actually read about the token and why those metadata fields answer different questions.
A future visitor may see a different reputation label. Preserve the date rather than treating a screenshot as a permanent attribute. Our example is a record of a public classification, not an investment endorsement or a financial backing assessment.
Five practical reputation checks
- Identify the object first. Save the network and complete contract address. The same ticker can appear in unrelated contexts; a reputation label attached to another contract is not evidence about the intended token.
- Read the label literally. Write Unknown, Neutral, OK, Suspicious or Unsafe as displayed. Do not translate OK into “audited,” Neutral into “no risk,” or a blank field into Unknown.
- Separate the evidence layers. Keep reputation, code verification, token identity and issuer-service support in different rows. Each needs a source appropriate to its question.
- Preserve the observation context. Record the page URL, check time and whether the page finished loading. A cropped badge without its token address leaves the object unresolved.
- Choose the next evidence source. Use the current rules for label interpretation and the relevant issuer or technical record for other questions. A reputation badge does not replace those checks.
Success is a bounded evidence note, not a single “safe” verdict. If the page is unavailable or the address does not match, stop at that specific gap. A reader should not need a transfer, signature or new account simply to preserve the public label.
Reputation and verified source code are separate
A contract source match answers a technical correspondence question. Reputation is the explorer’s token classification under another policy. Even when a policy includes source-verification requirements, that relationship does not make the two labels interchangeable or turn either one into a complete audit.
The verified-contract evidence guide explains that narrower source-code claim. For a proxy, the code view can also concern a different layer from the implementation used for token reads. Keep the exact contract and layer with the verification observation.
In a report, write two sentences if you have two sources: one for the reputation label and one for the source-verification state. Do not compress them into “verified token” unless you also specify what was verified. The shorter phrase hides the distinction a reader needs to assess the claim.
Missing data is not the Unknown reputation
An explicit Unknown label is a displayed or documented classification. A network error, an empty field, a loading placeholder or a missing key is an absence of usable evidence. These conditions must remain separate, even if a dashboard designer prefers to show one generic grey badge.
| What you have | What the note should say | What to avoid |
|---|---|---|
| Visible Unknown label for the matched token | Explicit explorer reputation: Unknown, with date | Calling it a successful safety check |
| Page did not finish loading | Reputation unavailable in this observation | Recording a default zero as a measured value |
| API field is absent | Missing field under the expected schema | Replacing absence with a known reputation code |
| New or wrong-type field value | Unmapped raw value, retained for review | Guessing the nearest familiar label |
This distinction matters when comparing two dates. If yesterday showed a label and today’s request failed, you have not observed a reputation change. You have one earlier label and one later availability failure. Preserve both events rather than reporting a downgrade or an upgrade.
Optional: read documented reputation codes carefully
The token-list API reference documents a string field named reputation. Its mapping is 0 = UNKNOWN, 1 = NEUTRAL, 2 = OK, 3 = SUSPICIOUS and 4 = UNSAFE. These are category codes, not a five-point investment score.
The token-security reference uses token_level for the same listed categories, alongside separate fields for other attributes. It also warns that an invalid address can return default values without raising an error. A successful HTTP response therefore cannot substitute for validating the requested object.
We did not call an authenticated API or test live API values for this article. The public token-page label is the live observation; the code mapping comes from the documentation. The local code below tests preservation of supplied values only. It does not validate a contract address, identify an issuer, obtain a current reputation or make a security decision.
LEVELS = {"0": "UNKNOWN", "1": "NEUTRAL", "2": "OK",
"3": "SUSPICIOUS", "4": "UNSAFE"}
def read_level(record, field):
if field not in record:
return {"state": "missing", "raw": None}
value = record[field]
if type(value) is not str or value not in LEVELS:
return {"state": "unmapped", "raw": value}
return {"state": "mapped", "raw": value,
"label": LEVELS[value]}
Pass the field name belonging to the documented record you actually have. A record with reputation will appear missing if you ask the function for token_level; that result identifies a schema mismatch, not a token downgrade. Do not silently rename unrelated fields to make the output look complete.
Ten local reputation fixtures and their limits
We ran the displayed function against ten invented records. Five carried the documented string codes, and five tested absent or unexpected values. All tests were local; no fixtures are real token-security responses.
| Invented token_level input | Local output state | Interpretation |
|---|---|---|
| “0” | mapped: UNKNOWN | Explicit documented code, still not a safety finding |
| “1”, “2”, “3”, “4” | mapped to their four documented labels | Four separate normal-code fixtures |
| Key absent | missing | Do not invent a code |
| null | unmapped | Unexpected type |
| Empty string | unmapped | No documented category supplied |
| false | unmapped | Boolean is not the documented string code |
| “5” | unmapped | Not in this checked mapping; preserve for review |
The unmapped output is deliberate. If the service later introduces a new category, a stale parser should expose that change instead of pretending that the new value means Unknown or OK. Updating a mapping requires checking the new documentation and retaining the old observation, not guessing from a numeral.
A successful transaction is another separate field
A transfer record and a token reputation answer different questions. A completed chain operation can involve a token whose identity or economic claims still need investigation. Conversely, a familiar reputation label does not establish that a particular proposed transaction was broadcast or executed successfully.
Use the TRON transaction-receipt reference for the execution-record side of that distinction. Read the actual receipt for a genuine transaction hash; do not substitute the reputation from a token’s profile. This guide did not send a transaction to generate a new receipt.
In a two-row note, the first row can preserve the transaction’s result and the second the token’s dated reputation. An unresolved field stays unresolved. Writing “successful, therefore safe” would join two conclusions that the records do not establish. Writing “Unknown, therefore the transfer never happened” would make the opposite mistake.
This separation is especially useful when a screenshot shows a green execution status beside a token label. Preserve both labels and their context. Color and proximity do not make one field an explanation or a guarantee for the other.
Who can change the public information?
The official token-information guide, updated 24 October 2026, distinguishes issuer metadata updates, reputation review requests and price-information submissions. Its described rating request requires an account and review. We did not submit a correction, register an account, connect an issuer wallet or test that workflow.
This is relevant to a reader because different page fields have different provenance. A description, website link, price display and reputation label should not be combined into one assumed on-chain fact. The existence of a correction route also does not give an ordinary visitor the authority to edit a token’s identity or reputation.
If you believe a label is wrong, preserve the exact contract, source, observed label and factual discrepancy. Do not pay a stranger to “unlock” an asset or sign an unrelated request to alter an explorer display. This publication does not operate TRONSCAN’s review queue and cannot promise a rating change or review time.
Copyable reputation evidence note
Network / full token address: Source URL / observation date and time: Visible label or documented field name: Raw value / result type: State: observed / missing / unavailable / unmapped Code-verification evidence, separately: Issuer or service-support evidence, separately: Unsupported conclusions left unknown: Next source needed:
For the actual TUSD example, the visible-label row says OK and the identity row contains the Mainnet contract. The reserve and redemption rows remain outside this reputation check. This prevents the note from expanding a narrow explorer observation into a broader financial claim.
When the task starts with a link in an unsolicited message, verify its destination before using the note. The explorer-link inspection worksheet addresses that earlier step. A reputation badge copied onto a different website does not authenticate the website or the record it claims to show.
Frequently asked questions
Does OK reputation mean a token is safe?
No. It is an explorer classification under stated rules, not a guarantee of investment quality, reserves or future outcomes.
Does Unknown reputation prove a scam?
No. Unknown is the stated default category. Preserve it as the explorer’s label and keep other evidence separate.
Is a missing reputation field the same as code 0?
No. A missing field is absent evidence. The documented string “0” is an explicit category value; neither is a safety certification.
Can a token reputation change?
The policy allows updates. Keep the observation date and compare matching token records; a failed request alone does not show a change.
Must I connect a wallet to read a reputation label?
Our public-page observation did not require a wallet connection. Rating correction and issuer-information workflows are separate actions and were not performed.
Independent Tronscan News editorial review, with AI-assisted drafting and source checks on 1 November 2026. Two original diagrams, the evidence matrices and ten local synthetic parser fixtures were created for this article. No live API response, security audit, financial-account test or rating request is claimed. Browse the Tronscan News homepage; use About & Standards in the navigation for corrections with a specific claim and source.
Leave a Reply