Methodology
Decision policy · Evidence · Uncertainty · Outcomes
How VerdictSwarm reaches a token-risk verdict.
VerdictSwarm is a pre-trade risk control. It turns available token evidence into one execution-oriented action—AVOID, CAUTION, or CLEAR—before an agent or person moves money.
It is not a price prediction, safety guarantee, investment recommendation, or replacement for the caller's other controls.
The decision comes first.
Integrations branch on verdict.action. Every other output explains that decision; none replaces it.
AVOID
A blocking risk signal was found.
Stop execution.
CAUTION
Material risk or uncertainty requires verification.
Pause, review, or escalate under your policy.
CLEAR
No policy blocker was identified in the available evidence.
Continue only if every other local control passes.
The evidence flow.
- 01
Normalize the request
Validate the token address and route it only on the configured solana or base boundaries. An invalid or unsupported request stops here.
- 02
Collect deterministic evidence
Inspect available contract, authority, tax, liquidity, market, and distribution signals. Each response identifies freshness and coverage so missing evidence remains visible.
- 03
Apply the requested analysis depth
Triage uses deterministic checks, fast adds heuristic and single-model adjudication, and deep uses the configured specialist panel.
- 04
Adjudicate one action
Return avoid, caution, or clear with supporting score, confidence, signals, freshness, and an observation identifier. The action is the execution control.
- 05
Observe what happens later
Record a bounded public observation when the data service is available. Later outcome fields describe what was observed; they do not turn the original verdict into a guarantee.
Three analysis depths, one decision vocabulary.
| Depth | Configured method |
|---|---|
| triage | Deterministic no-LLM triage lane for machine trials |
| fast | Cached data + heuristics + single-model adjudication |
| deep | Full 6-agent swarm — the token examined from every angle |
Score explains; action controls.
The score summarizes supporting analysis on a 0–100 scale. Grade, confidence, signals, freshness, and data coverage add context. They do not override verdict.action.
These are the checked-in base category weights. Configured asset profiles can adjust them dynamically, so this table is a starting profile—not the complete decision algorithm.
25%
Technical
25%
Safety
20%
Tokenomics
15%
Social
15%
Macro
The configured deep panel.
Deep analysis runs 6 active specialist roles. Their findings are combined and material disagreement is challenged before the final action is returned.
SCOUT
Technician
On-chain technical analysis
SCOUT
Security
Smart contract security audit
INVESTIGATOR
Tokenomics
Token distribution and economics analysis
INVESTIGATOR
Social
Social intelligence and sentiment analysis
INVESTIGATOR
Macro
Macro market conditions analysis
INVESTIGATOR
Devil's Advocate
Skeptical due-diligence contrarian analysis
Uncertainty never grants permission.
A caller must distinguish a valid CAUTION from a request that did not produce a verdict. Invalid input, unsupported routing, billing blocks, rate limits, dependency failures, and internal errors are explicit stop states—not CLEAR results.
| Failure | HTTP | Required response |
|---|---|---|
| invalid_address | 400 | Validate the address against the selected chain and stop the trade. |
| unsupported_chain | 400 | Route only supported-chain assets here; stop on every other chain. |
| level_unavailable | 400 | Read the enabled levels from service discovery and halt unless policy permits another depth. |
| payment_required | 402 | Pay the top-level x402 challenge or attach a funded key, then retry the identical request. |
| payment_invalid | 402 | Replace the payment proof or key. Do not retry unchanged credentials. |
| rate_limited | 429 | Wait for details.retry_after_s or Retry-After, then retry with bounded backoff. |
| upstream_data_unavailable | 503 | Halt execution and surface the dependency failure. Never fail open. |
| internal_error | 500 | Halt, use a retry voucher when returned, and alert if the retry fails. |
Outcome accounting is bounded and inspectable.
The public ledger separates the verdict recorded at scan time from later outcome observations. Pending observations are not settled outcomes, and missed observation windows are excluded from the settled denominator. The live proof surface publishes its current definition and totals so readers can inspect the boundary directly.
Inspect the public proof ledger →Direct answers
Common interpretation questions.
Does CLEAR mean a token is safe to buy?
No. CLEAR means the available evidence did not trigger a VerdictSwarm policy blocker. It permits the caller's next control to run; it is not a recommendation or guarantee.
Does the score decide the action?
No. The action is authoritative. Score, grade, confidence, signals, and freshness explain the result and help the caller decide whether to escalate.
What happens when evidence is insufficient?
Insufficient evidence cannot be converted into CLEAR. The service exposes data coverage, floors a would-be clear result to caution when core data is insufficient, or returns an explicit failure when it cannot produce a valid verdict.
Which chains does this methodology cover?
solana and base only. A caller must stop or route elsewhere for every other chain.
Is the public receipt an on-chain attestation?
No public immutable verdict-storage product is claimed. The receipt is a timestamped observation record for inspection and later outcome labeling.