> ## Documentation Index
> Fetch the complete documentation index at: https://docs.webacy.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Tokenized RWA due diligence walkthrough

> Assemble a full due-diligence picture for a tokenized real-world asset with a worked example covering the Webacy MCP tools and REST API endpoints.

This walkthrough shows you how to assemble a complete due-diligence (DD) picture for a tokenized
real-world asset — stablecoins, tokenized treasuries and money-market funds, private-credit
funds, and commodity tokens — using the Webacy MCP tools and REST API.

It walks **one real asset end to end: USDY** (Ondo US Dollar Yield), a USD, yield-bearing token
backed by US Treasuries — `0x96F6eF951840721AdBF46Ac996b59E0235CB985C` on `eth`.

<Note>
  This page **builds on** the other integration guides — it does not repeat them. For MCP client
  setup see [MCP Server](/integrations/mcp-server); for the full endpoint reference and common
  workflows see [Agent Reference](/integrations/agent-reference). Scoring methodology is served
  live by `GET /v3/framework` (public, no key).
</Note>

## Prerequisites

* An API key from [developers.webacy.co](https://developers.webacy.co/). Base URL:
  `https://api.webacy.com`. All requests send the `x-api-key` header.

<Warning>
  Keep your API key secret. Never commit it to version control. Examples below use
  `YOUR_API_KEY`.
</Warning>

## Start Here: One Call, Most of the Checklist

For any pegged / RWA token, the MCP tool `get_rwa_token_risk` or `GET /v3/rwa/{address}` returns
a **per-criterion pass / warn / fail scorecard** plus an A+→F grade — answering most of a
structural DD in a single request.

<CodeGroup>
  ```bash cURL theme={null}
  curl -X GET "https://api.webacy.com/v3/rwa/0x96F6eF951840721AdBF46Ac996b59E0235CB985C?chain=eth" \
    -H "x-api-key: YOUR_API_KEY"
  ```

  ```text MCP prompt theme={null}
  Use get_rwa_token_risk for USDY on eth. Give me the composite grade, then list every
  category criterion with its pass/warn/fail status — which are warn/fail, and which are
  not yet covered?
  ```
</CodeGroup>

Response (trimmed to the DD-relevant fields):

```json theme={null}
{
  "schema_version": "3.3",
  "metadata": { "symbol": "usdy", "name": "Ondo US Dollar Yield", "market_cap_usd": 1103538158 },
  "composite": { "grade": "A", "stars": 5, "score": 10 },
  "categories": {
    "smart_contract":         { "criteria": { "audited": { "status": "pass" }, "mint_cap_present": { "status": "warn" } } },
    "operational_governance": { "criteria": { "owner_is_multisig": { "status": "warn" }, "timelock_present": { "status": "warn" }, "admin_key_changes": { "status": "pass" } } },
    "asset_collateral":       { "criteria": { "share_price_stable": { "status": "pass" }, "mint_burn_anomaly": { "status": "pass" } } },
    "market_liquidity":       { "criteria": { "large_holder_concentration": { "status": "pass" }, "market_cap_adequate": { "status": "pass" }, "dex_liquidity_depth": { "status": "warn" } } }
  },
  "coverage": { "framework_version": "v1", "total_criteria": 21, "live_criteria": 17 }
}
```

Read each `criteria.*.status` as one line of the checklist. Here is what the scorecard tells you
about USDY:

| Field                                                                 | What it checks                                                                                                                      | USDY                  |
| --------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | --------------------- |
| `composite.grade` / `composite.score`                                 | A+→F letter grade and a 0–100 score where **higher = worse** (`A+` ≈ 0, `F` ≈ 100)                                                  | grade `A`, score `10` |
| `smart_contract.audited`                                              | Are the contracts audited?                                                                                                          | `pass`                |
| `smart_contract.mint_cap_present`                                     | Is an enforceable minting cap detected?                                                                                             | `warn`                |
| `operational_governance.owner_is_multisig` / `timelock_present`       | Is the admin a multisig, behind a timelock?                                                                                         | `warn` / `warn`       |
| `asset_collateral.share_price_stable` / `mint_burn_anomaly`           | Is the NAV / share price stable, with no mint-vs-backing anomaly?                                                                   | `pass` / `pass`       |
| `market_liquidity.large_holder_concentration` / `dex_liquidity_depth` | Holder concentration and DEX depth                                                                                                  | `pass` / `warn`       |
| `coverage`                                                            | `total_criteria` vs `live_criteria`. Roadmap criteria are not scored — never silently passed. Full definitions: `GET /v3/framework` | 17 of 21 live         |

## Fan Out for Depth

The scorecard is the headline; these endpoints add the underlying detail.

### Peg Stability and Depeg

```bash theme={null}
curl -X GET "https://api.webacy.com/rwa/0x96F6eF951840721AdBF46Ac996b59E0235CB985C?chain=eth" \
  -H "x-api-key: YOUR_API_KEY"
```

USDY is USD-denominated but **yield-bearing**, so its reference peg is not \$1.00 — in the
July 29, 2026 capture it was \~\$1.14. The engine knows this (`peg_value: 1.14`), so a price of \$1.139 reads as *at
peg*. The `snapshot` returns `score`, `tier`, a \~12-factor `drivers[]` decomposition, and
`abs_dev_clean` (USDY: \~0.0007, \~7 bps off its yield-adjusted peg). Add `&hours=168` for up to 7
days of `history`. This response also carries the **liquidity** block (`liquidity_tier`,
`total_dex_liquidity_usd`, `cost_to_move_up_usd` / `cost_to_move_down_usd`, per-DEX `markets[]`)
and any on-chain **NAV** fields (`rwa_nav_usd`, `rwa_classification`, `rwa_nav_as_of`).

### Supply and Mint/Burn Velocity

```bash theme={null}
curl -X GET "https://api.webacy.com/rwa/supply/USDY" -H "x-api-key: YOUR_API_KEY"
```

Returns `supply`, `net_24h_usd`, and `pressure_vs_30d` / `pressure_tier` to spot supply stress.
The list form `GET /rwa/supply` sorts the whole universe by mint/burn pressure.

### Holder Concentration

```bash theme={null}
curl -X GET "https://api.webacy.com/rwa/hci?chain=eth" -H "x-api-key: YOUR_API_KEY"
```

Per token: `top10Index`, `top30Index` (Herfindahl-style), `riskBand`, `holderCount`. For deeper
holder forensics (first buyers, snipers, minter) use the `get_holder_analysis` MCP tool.

### Backing, Attestation, and Controls

The v3 scorecard already answers the yes/no control and collateral questions
(`audited`, `mint_cap_present`, `owner_is_multisig`, `timelock_present`, `share_price_stable`,
`mint_burn_anomaly`). Deeper **reserve composition and third-party attestation freshness**
(issuer, provider, attestation type and lag, redemption capacity) are available for covered
assets — reach out to Webacy for access to the reserves surface.

## Browse the Universe

```bash theme={null}
curl -X GET "https://api.webacy.com/rwa?q=USDY&chain=eth" -H "x-api-key: YOUR_API_KEY"      # resolve
curl -X GET "https://api.webacy.com/v3/rwa/grades" -H "x-api-key: YOUR_API_KEY"             # graded list
```

`GET /rwa` filters the RWA + stablecoin universe (by `chain`, `denomination`, `tags`, score);
`GET /v3/rwa/grades` returns the graded list. In MCP, use `list_rwa_tokens`.

## Coverage Isn't Binary

Not every asset is fully covered. The list-item fields tell you which state an asset is in:

| State                         | How to detect (list-item fields)                                                                                | You get                                | Action                       |
| ----------------------------- | --------------------------------------------------------------------------------------------------------------- | -------------------------------------- | ---------------------------- |
| Fully covered                 | `assetType` set, `has_monitor_data: true`, `price` **and** `market_cap_usd` present                             | Everything above                       | Run the DD                   |
| Classified & priced, mcap gap | `assetType` set, `has_monitor_data: true`, `price` present, `market_cap_usd: null`                              | Depeg + price now                      | Supply/market-cap completing |
| Classified but unpriced       | `assetType` set, `price: null` **and** `market_cap_usd: null` — a permissioned fund with no public market price | Identity + classification, no peg/mcap | On-chain NAV source needed   |
| Not indexed                   | `GET /rwa?q=SYMBOL` → `items: []`; `GET /rwa/{addr}` → `404`                                                    | Nothing                                | Request coverage             |

The list-item classification field is **`assetType`**; `has_monitor_data` distinguishes "in the
depeg monitor" from merely "asset-type tagged" — check both.

**Requesting coverage.** There is no self-service coverage endpoint. Send Webacy the **symbol +
contract address + chain** (and issuer, if niche). RWA classification and monitor coverage are
added by Webacy; coverage lands in stages (monitor / depeg first, then classification + pricing,
then NAV / attestation for permissioned funds). Track it by re-running `GET /rwa?q=SYMBOL`:
`has_monitor_data: true` and `assetType` land first (monitor + classification), then `price` and
`market_cap_usd` fill in for full coverage, with NAV / attestation last for permissioned funds.

## Read the Provenance, Not Just the Number

Where a value isn't independently confirmed, the API returns `null` or `404` rather than guessing.
An empty field is a real DD signal — *unconfirmed, ask the issuer* — not a gap to paper over.
Rule of thumb: on-chain and graded criteria are **independently confirmed**; a populated
attestation is **confirmed as of its date and lag**; a `null` / `404` is **unconfirmed**. That
combination clears most of a structural checklist in one or two calls, leaving the
judgment-heavy, issuer-specific questions for a human.

## Asset-Level vs. Contract-Level

Use **asset-level** (`/rwa/*`, `/v3/rwa/*`) to ask *"is this RWA sound?"* (peg, NAV, grade,
holders). Use **contract-level** (`/tokens/*`, `/contracts/*`, `/addresses/*`, and the
`get_token_risk` / `get_address_risk` MCP tools) to ask *"is this contract or admin address
dangerous?"* (bytecode, honeypot, deployer, sanctions). Do both — they complement, not substitute.

<CardGroup cols={2}>
  <Card title="MCP Server setup" href="/integrations/mcp-server" icon="plug">
    Connect Claude Code, Cursor, or any MCP client, and the tool reference.
  </Card>

  <Card title="Agent Reference" href="/integrations/agent-reference" icon="book">
    Full endpoint reference, response shapes, and common workflows.
  </Card>
</CardGroup>