> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dataspike.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Result Fields & Coverage
> Every KYT result field mapped across dashboard, PDF, and API — plus supported networks and assets, and current feature availability.
One check, three surfaces: the **dashboard**, the **AML PDF report**, and the **API response**. The tables below are the lookup between them — useful when an analyst and a developer are looking at the same case and using different words for the same field. This page also documents what KYT covers today: [supported networks](#supported-networks) and [feature availability](#feature-availability).
For the interpretation of these fields in context, see [How to read a KYT report](/wallet-checks-kyt/how-to-read-a-kyt-report).
***
## Address check
| Dashboard | PDF report | API field | Meaning and how to use it |
| ---------------------- | --------------------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Check ID | — | `id` | Identifier of the check. Store it: it is required to re-fetch the result and to download the PDF. |
| — | — | `status` | Processing status: `pending` (still computing) or `success` (ready). Not a risk value. |
| Network | Header, e.g. *USDT Address (TRX)* | `blockchain` | `btc`, `eth`, or `trx`. Screening is per network. |
| Token | Header | `token` | `""` for the native asset, or `USDT` / `USDC`. |
| Address | Header | `address` | The address that was screened. |
| Owner | Owner | `name` | Entity name if the address is attributed; `null` / *Undefined* otherwise. Undefined is normal for individual wallets. |
| Type | Type | `type`, `type_label` | Entity category. `type` is machine-readable (`EXCHANGE_LICENSED`), `type_label` is for display (*Licensed exchange service*). |
| Balance | Balance | `balance` | Balance in the selected token at the moment of the check. A snapshot. |
| Sent | Sent | `sent` | Lifetime total sent from the address. |
| Received | Received | `received` | Lifetime total received by the address. |
| Risk score badge | Risk Score | `risk_score` | **0–1 coefficient in the API**, 0–100% in the dashboard and PDF. `"0.227"` = 23%. |
| Risk level | Grade next to the score | `risk_score_grade` | `low`, `moderate`, `high`, `undefined`. Use this for decision logic. |
| Direct transfers table | Direct transfers | `direct_entities` | Named entities one hop away, with amounts. Each item: `name`, `type`, `type_label`, `incoming_amount`, `outgoing_amount`. |
| Category breakdown | Payments | `indirect_payments` | Entity categories across the fund trail. Each item: `type`, `type_label`, `risk_score_grade` (the tier), `total_count` (% share), `total_count_coef` (same as coefficient), `total` (absolute amount). |
| — | Footer | — | Generation timestamp (UTC) and the ID of the generating account, printed on every page. |
`indirect_payments[].risk_score_grade` is the **tier of that category** (`low` / `moderate` / `high` / `undefined`), not the score of the check. The tier totals shown in the PDF are the sums of the categories in each tier.
***
## Transaction check
Same fields as above, minus balance-related ones, plus:
| Dashboard | PDF report | API field | Meaning |
| ------------------ | --------------- | ---------------------- | ----------------------------------------------------------------- |
| TxID | Header | `tx_id` / header value | The transaction that was screened. |
| Block | Block number | `block_number` | Block containing the transaction. |
| Date | Date | `timestamp` | Transaction time, UTC. |
| Senders | — | `inputs` | Number of senders in the transaction. Can be large on Bitcoin. |
| Recipients | — | `outputs` | Number of recipients in the transaction. |
| Sender | Sender / Type | `from_entity` | Sender attribution, if identified. Empty array when unattributed. |
| Receiver | Receiver / Type | `to_entity` | Recipient attribution, if identified. |
| Category breakdown | Payments | `indirects` | Same structure as `indirect_payments`. |
Transaction reports contain **no balance field** — a transaction has an amount, not a balance.
***
## Transfer check (API only)
Isolates one sender → recipient pair inside a transaction. Useful on UTXO chains and in multi-party transactions.
| API field | Value | Note |
| ------------------ | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `risk_score` | `null` | A single leg does not receive an overall score. |
| `risk_score_grade` | `null` | Use the exposure breakdown instead. |
| `indirects` | populated | Exposure breakdown for that specific flow of funds. Shares are relative to the transferred amount, so a single-counterparty transfer can legitimately show `100`. |
***
## Request parameters that change the result
| Parameter | Values | Effect on what you read |
| ------------ | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `blockchain` | `btc` / `eth` / `trx` | Screening context. The same address string on another chain is a different subject. |
| `token` | `""` / `USDT` / `USDC` | Empty means the native asset. Balances, amounts, and exposure are all denominated in the selected asset. |
| `directs` | `false` (default) / `true` | `false` analyzes indirect (n-hop) payments; `true` restricts the analysis to direct interactions only, which usually lowers the amount of exposure surfaced. |
When comparing two results for the same address, confirm that `token` and `directs` match. Different parameters produce legitimately different scores.
***
## Statuses and response codes you will see
| Code / value | Meaning | What to do |
| ------------------------------ | -------------------------------------------------------------------------- | ------------------------------------------------------------- |
| `status: "pending"` | Check submitted, analysis running. | Poll `GET .../{id}` again after 2–5 seconds. |
| `status: "success"` | Result is final for this point in time. | Read the result; download the PDF. |
| `404` No data, try again later | Still processing. | Retry with exponential backoff. Not an integration error. |
| `404` Empty address | No transaction history on the selected network. | Verify network and token. An unused address cannot be scored. |
| `404` Not Found | Address / TX does not exist on chain, or the check ID is unknown. | Validate the input. |
| `400` / `422` | Invalid parameters, or valid JSON with semantically incorrect values. | Check parameter values against the tables above. |
| `401` | Missing or invalid `ds-api-token`. | Verify the header. Never expose the key client-side. |
| `403` | Expired license, insufficient check balance, or no access to the resource. | Contact `service@dataspike.io`. |
| `429` | Rate limit exceeded (24 requests/second per key). | Back off and retry. |
| `500` / `503` | Server error or temporary downtime. | Retry with exponential backoff. |
***
## Supported networks
KYT currently supports three blockchain networks. All check types — address, transaction, and transfer — work on all supported networks.
| Network | API value | Native asset | Supported tokens |
| -------- | --------- | ------------ | ---------------------------- |
| Bitcoin | `btc` | BTC | — |
| Ethereum | `eth` | ETH | USDT (ERC-20), USDC (ERC-20) |
| TRON | `trx` | TRX | USDT (TRC-20), USDC (TRC-20) |
**Selecting the asset**
* **Dashboard:** choose the Network, then the Token. Leave the token empty to screen the native asset (BTC/ETH/TRX).
* **API:** set `blockchain` to `"btc"`, `"eth"`, or `"trx"`, and `token` to `""` (native), `"USDT"`, or `"USDC"`.
**Network-specific behavior**
* **Bitcoin (UTXO model).** A single transaction can include many senders (inputs) and recipients (outputs). To score one specific flow of funds inside such a transaction, use the transfer check — for Bitcoin, only the `recipient_address` is required to isolate the flow.
* **Ethereum and TRON (account model).** Transfer checks require both `sender_address` and `recipient_address`. Token transfers (USDT/USDC) are screened with the same endpoints — just set the `token` parameter.
An address is screened **per network**: the same entity may control addresses on several chains, and each is checked in its own network context. If an address has no transaction history on the selected network, the API returns `404 Empty address`.
Additional blockchain networks are on the Dataspike roadmap. Only Bitcoin, Ethereum, and TRON are supported today — if you need another chain for your integration, tell us at `service@dataspike.io` so we can factor it into prioritization.
***
## Feature availability
KYT capabilities ship to the API and the dashboard on their own schedules. This table is the single source of truth for what you can rely on today.
| Feature | Dashboard | API |
| ----------------------------------- | --------- | --------- |
| Address check | Available | Available |
| Transaction check | Available | Available |
| Transfer check (specific fund flow) | Not yet | Available |
| PDF report download | Available | Available |
| List and search past checks | Available | Available |
**Coming soon**
| Feature | Status |
| ----------------------------- | ------- |
| Risk profile configuration | Planned |
| Address monitoring and alerts | Planned |
| Custom risk thresholds | Planned |
**Risk profiles** will let you define what *your* business considers risky — entity types, threshold amounts, and the acceptable share of high-risk exposure — and apply different profiles per product line or jurisdiction. **Address monitoring** will track subscribed addresses in the background and raise **alerts** when the risk score changes, new suspicious activity appears, or a risk-profile condition triggers. Further ahead, the roadmap includes additional blockchain networks and deeper integration between KYT and Dataspike's AML Screening module.
Timelines are indicative and may change. Until a feature appears in the **Available now** table, don't build production logic that depends on it — and if one of these capabilities is blocking your integration, tell us at `service@dataspike.io`.