Skip to main content

Overview

The v3 RWA Risk endpoints give you a Webacy-native structural risk score for stablecoins and real-world asset tokens. Unlike the Depeg Monitor — which tracks real-time price deviation — v3 RWA Risk evaluates the structural health of a token: collateral quality, smart contract governance, liquidity depth, exploit history, and more. Scores are updated on a 24-hour cadence and computed against a versioned grading scheme you can pin for consistency.

Endpoints

Token Detail

GET /v3/rwa/{address} — Full structural risk decomposition: composite grade, seven weighted categories, criterion-level pass/warn/fail status, and coverage metadata.

Batch Structural Health

POST /v3/rwa/batch/structural-health — Check up to 100 tokens in one call. 24h cadence. Always returns 200 with per-token results.
GET /v3/rwa/{address} requires a chain query parameter (for example eth); grading_scheme is optional and defaults to v2 (the standard scale). The batch endpoint takes { address, chain } pairs in the request body.

Key Concepts

Score Polarity

Higher score = more risk. This is the opposite of yield or performance scores.composite.score and all categories.*.score values are in the range 0–100, where 0 means no structural risk and 100 means maximum structural risk. The letter grade A+ corresponds to a score near 0 (best); F corresponds to a score near 100 (worst).

Composite Grade

Each token receives a composite score derived from seven weighted risk categories. The weights below are shared across both grading schemes (v2 reuses the v1 category weights — only the score-to-letter band mapping differs between schemes): The detail response also returns two composite-level fields, upstream_risk and clamped_by_upstream. When a token’s composite score is raised by risk inherited from an upstream dependency, upstream_risk carries that contributing score and clamped_by_upstream is true; when no upstream adjustment applies — as in the example below — they are null and false.

Letter Grades and Stars

The composite risk score maps to a letter grade on the standard 11-band scale (grading scheme v2). It is a risk rating: lower risk earns a better grade — A+ is the lowest risk, F is the highest. Bands are tighter at the safe end and widen as risk rises.

Criterion Status

Each criterion in a category has one of three statuses:

large_holder_concentration — Herfindahl Grading

The large_holder_concentration criterion is graded on the Herfindahl Concentration Index (HCI) computed across the top-10 holders:

Data Quality

Every criterion carries a data_quality block:
confidence is "high", "medium", or "low". Use last_observed_at to surface data staleness to your users.

Coverage — Live vs. Planned

The v3 framework defines more criteria than are currently live. The coverage block in every detail response tells you exactly which criteria are active today vs. pending producer data. Planned criteria are excluded from scoring until their producer tables are ready. When they go live, scores will shift — pin a grading scheme (see below) if you need stability.

Grading Scheme Versioning

grading_scheme defaults to v2, the standard 11-band scale (lower risk = better grade) shared across every Webacy grade surface. The scheme version is reflected in:
  • The composite.grading_scheme field in the response body
  • The Webacy-Grading-Scheme response header
v1 is the frozen legacy scale — it uses an E band and has no C+. Pin ?grading_scheme=v1 to keep v1-computed grades byte-for-byte. v1 is now deprecated with a minimum 9-month sunset window; responses pinned to v1 carry RFC 8594 Deprecation / Sunset headers. Both schemes appear in supported_schemes.
The batch endpoint (POST /v3/rwa/batch/structural-health) emits raw criterion data only — no composite score, no grading scheme parameter. It is always scheme-neutral. Today it evaluates two live criteria — mint_burn_anomaly and large_holder_concentration; additional structural criteria will be added as their producer data goes live.

Authentication

All v3 RWA endpoints require an x-api-key header. Requests without a valid key return 403.

Response Headers

Every response (including 4xx errors) includes:

Batch Partial-Success Semantics

The request is validated first. A malformed batch returns 400 Bad Request and no tokens are evaluated:
  • empty tokens array
  • more than 100 tokens
  • unknown or unexpected properties in the body
Once the request is well-formed, the batch endpoint always returns HTTP 200. Check each result’s ok field:
  • ok: true — criterion data is present
  • ok: false — token could not be evaluated; read error_code

Code Examples

Example: Token Detail Response

Example: Batch Response (partial success)


Depeg Monitor

Real-time price-deviation risk for stablecoins — pairs well with v3 structural scores

Holder Concentration Index

Deeper HCI data and historical concentration trends

Scoring Methodology

How Webacy computes risk scores across all product lines

API Authentication

How to obtain and use your x-api-key