Read the risk signals

A score is a number someone else chose. risk_signals is the list of reasons behind it, and it is the part you can act on: each entry names one thing observed about the pair, and for almost every one of them there is another field in the same response that lets you check it yourself.

The shapeCopy Anchor Link

score.risk_signals arrives with every pair, in the list and in the single-pair response:

{
  "score": {
    "value": 32,
    "title": "Risky",
    "updated_at": "2026-09-20T09:14:02Z",
    "risk_signals": [
      { "kind": "lp_unlocked",         "weight": 17, "observed_at": "2026-09-20T08:40:11Z" },
      { "kind": "supply_concentrated", "weight": 24, "observed_at": "2026-09-19T22:03:57Z" },
      { "kind": "liquidity_drop",      "weight": 11, "observed_at": "2026-09-18T14:26:30Z" }
    ]
  }
}

The weights above are one snapshot, not a table: they are what those signals cost this pair at that moment. The same list reaches you as score.signals on /chains/{chain}/tokens/{address}/brief, keyed by the same kind strings.

Three rules that outlive any catalogueCopy Anchor Link

The set is open. kind is a string, not a closed enum. New reasons are added as they are found, and a kind your client does not recognise arrives as the reason it is, or as unknown when it has no published spelling yet. Switch on the kinds you handle and keep a default branch — never assume the list below is complete, and never let an unrecognised kind read as "no problem".

weight is now, not always. It is the penalty this signal subtracts from the score at the moment of the response. Signals that describe market behaviour fade as the event ages; signals that describe a present condition hold their weight while the condition is true and disappear when it stops being true. A weight of 0 means the signal is disclosed to you without being applied — something else about the pair already answers it. Read the number we send; do not hardcode a table of your own.

An absent signal is not a clearance. A signal appears when something was observed. A check that could not run, or returned nothing, raises nothing — so the absence of lp_unlocked does not mean the LP is locked, it means look at security.burned_pct and security.locked_pct yourself. This is the same rule the brief states for flags: absent means not observed, never ruled out.

Verdicts — the pair is finishedCopy Anchor Link

These arrive with a terminal status. There is no reading of the market that changes them.

only_trustable=true on /pairs drops these for you, and verdict.status on one pair answers the same question for it as a single blocked / ok. blocked covers a terminal status on the pair or on either of its tokens.

Pool stateCopy Anchor Link

Most drained pools never get a rug_confirmed, because the wallet that took the liquidity out is not always the wallet that put it in. no_exit records the part that needs no attribution.

Who built itCopy Anchor Link

These describe the wallet behind the pair, not the pair. They are history, which is exactly what makes them useful — and exactly why they say nothing about today's candle.

abuse_cluster_funder is the clearest case of a signal you will sometimes see at a reduced or zero weight: when the liquidity is structurally locked, evidence about a wallet two hops away no longer changes what can happen to the pool, so it is disclosed to you without being applied.

What the contract can doCopy Anchor Link

Properties of the token and the pool. A chart cannot outrun any of them.

On lp_unlocked, read Spot a rug before it pulls for how the four security fields relate: burned beats locked, locked-with-a-date beats unlocked, and a lock expiring tomorrow is not a lock.

What the market didCopy Anchor Link

These describe events rather than properties, so their weight falls as the event ages and rises when it repeats. One is noise. Three, or one that keeps returning, is a shape.

What we could not measureCopy Anchor Link

Not claims about the pair — statements about our own coverage. They still belong in your decision, because trading on a figure we could not confirm is your risk, not ours.

In the vocabulary, not on a pairCopy Anchor Link

Using itCopy Anchor Link

Set your own threshold, server-side. min_score and max_score filter the list before it is sent, which is cheaper than filtering after:

curl -G 'https://api.preview.avee.tech/api/v1/chains/bsc/pairs' \
  -d min_score=70 \
  -d only_trustable=true \
  -d min_liquidity_usd=25000

But do not let the score be the whole gate. The bands (title) are a summary, and a summary loses the difference between one small reason and one serious one. Keep an explicit block list and check it whatever the score says:

const NEVER = new Set([
  'honeypot', 'rug_confirmed', 'confiscation_confirmed',
  'no_exit', 'privileged_transfer', 'forged_approval', 'sell_side_blocked',
]);

function tradable(pair) {
  if (pair.status === 'scam' || pair.status === 'unresolved') return false;

  for (const s of pair.score?.risk_signals ?? []) {
    if (NEVER.has(s.kind)) return false;
    if (s.kind === 'unknown') return false;   // a reason we have not published yet is still a reason
  }
  return pair.score?.value >= YOUR_THRESHOLD;
}

Read the reasons when the number moves. Sorted by current weight, the list is an ordered explanation:

curl -s 'https://api.preview.avee.tech/api/v1/chains/bsc/pairs/0x…' \
  | jq '.score | {value, title,
        why: [.risk_signals[] | {kind, weight, observed_at}] | sort_by(-.weight)}'

What these signals are notCopy Anchor Link

They are a record of what was observed, with the field that carries the observation named next to each one. They are not a prediction, not a rating, and not financial advice. A pair with no signals is a pair nothing has been recorded against — which is a different sentence from "this pair is safe", and the difference is the whole point of publishing the reasons instead of only the number.