Skip to main content

​
How to read a tier

The tier is the headline of any TrustGate read. It compresses everything the score looked at into one label you can act on at a glance. Five tiers cover behavior, from BLOCKED at the bottom to ELITE at the top, and a sixth, VERIFIED, sits outside that ladder. A tier is a snapshot of current behavior, not a permanent grade. It moves as behavior moves.
The read found strong reasons not to trust, or nothing to trust yet. That covers two different situations. One is active red flags in the behavior. The other is an address with no real track record to stand on.Treat it as do-not-proceed without your own checks. For a brand-new or empty address, BLOCKED is not an accusation. There is simply nothing earned yet, and the tier can climb as genuine behavior builds up.Pair it with confidence. A confident BLOCKED and a low-confidence BLOCKED mean different things.
A thin or concerning history. There is some activity here, but not enough depth to lean on, or patterns that give reason to pause.Treat it as caution. Worth a closer look before you rely on it for anything that matters. Discovery treats LOW as deprioritized: marked, never hidden.
A real, ordinary history. Nothing alarming, nothing exceptional. This is the broad middle where most legitimate, everyday addresses land.Treat it as reasonable to engage with normal care. Compact badges often shorten this to MID.
A strong, consistent track record. Behavior that is expensive to fake and has held up over a real stretch of time.Treat it as trusted, among the better addresses you will come across.
The rare top. A sustained, exceptional history that very few addresses ever reach.Treat it as the strongest behavioral read TrustGate gives. The two labels are aliases:
  • Discovery batch and widget-discovery.js emit ELITE
  • Arc oracle, Token Shield, and widget.js may emit HIGH_ELITE
At this level the badge often shows the tier alone, without a number.

​
VERIFIED is different

VERIFIED is not earned through behavior at all, which is why it sits apart from the ladder. It is reserved for tokens whose issuer is confirmed, an official stablecoin from a known issuer being the clearest case. It answers a different question. The behavioral tiers ask “how does this act.” VERIFIED asks “is this the real, official asset,” and when the answer is yes, that identity is the whole point. So a VERIFIED read short-circuits the behavioral path. You are not being told a token behaves well, you are being told it is authentic. On the widget endpoint a VERIFIED response looks like:

​
NTT is not a trust tier

NTT means Not a Tradeable Token. The single-token widget only scores ERC-20s. When you point it at an NFT contract, some other contract, or a wallet (EOA), it returns:
The badge renders nothing in that case. Use Token Shield, the NFT route, or the Trust Oracle instead of treating NTT as BLOCKED.

​
Three maps, do not mix them

Product APIs, the hosted homepage, and the payment contract do not share one cutoff table. A. Oracle / Token Shield / widget (behavioral bands) B. Onchain payment routing (TrustScoringPlaintext.getTrustTierPlaintext) C. Homepage / payment-docs marketing uses the contract 75/40 bands, not the oracle 60/80 bands. D. Sui ScoreRegistry uses four onchain values: LOW=0, MEDIUM=1, HIGH=2, HIGH_ELITE=3. That elite variant is real on Sui. Cap mint thresholds are 70 (standard) and 85 (elite), independent of Arc’s 75/40 payment bands.
Never treat API HIGH (score 60–74) as onchain HIGH. A wallet can show HIGH on the oracle and still take the 24-hour claim path, because claim() reads the 3-band contract map. HIGH_ELITE does not exist onchain; it shares contract HIGH only when the stored score is >= 75.
Payment-tier thresholds are not TrustGate’s recommended lending policy. They are how one application, the agent payment rails, consumes the score. Your protocol sets its own ladder.

​
Next

Signals

The categories of behavior that move an address between tiers.

Flags

The specific patterns a read can raise alongside a tier.