NAV
shell

Introduction

Chainalysis Know Your Transaction (KYT) is an automated cryptocurrency transaction monitoring and compliance solution. At the core of KYT is a REST-based API that provides you with transaction risk monitoring, alerts on risky transfers, and comprehensive user risk profiles, among other features. The API allows your internal business systems and Chainalysis's technology to communicate with each other.

Getting started

Registering transfers is required to get the total value of KYT: transaction screening, generating alerts, and building user and transaction risk profiles, among other features.

You can submit transfers via the API and KYT will provide insights on the transfer and counterparty involved. KYT will automatically monitor each transaction posted for changes in exposure and counterparty risk. All alerts, user risk scores, and transfer profile updates will be reflected in both the KYT Dashboard and API responses.

See the KYT integration guide below for information on integrating with the API including, various implementations and example compliance workflows.

About the KYT API

KYT’s API is a REST-based web service that:

After integrating your data into KYT, the API provides you a more comprehensive picture of risky activity. It returns additional information on transfers, alerts, and user risk that the KYT UI doesn't provide alone.

Sorting and filtering are available on many endpoints to help facilitate workflows. For example, you can query for all alerts created between certain dates, see exposure details on a specific user, or pre-screen for counterparty risk within your withdrawal workflow.

All times are in UTC.

What's new

See below for KYT API releases, updates, and changes.

August 18, 2021

We've released a new endpoint to assign alerts. You can now make a POST request to programmatically assign alerts to users in your organization. To unassign an alert, use null in the request body.

Additionally, we've added the following response body fields to the the GET /v1/alerts endpoint:

You can also sort and filter with these fields.

August 11, 2021

We've changed the requirement of certain request body fields for the POST /v2/users/{userId}/transfers endpoint. Now, transferTimestamp, assetAmount, outputAddress, inputAddress, assetPrice, and assetDenomination are optional for both CDN and fully-supported assets.

July 26, 2021

We've recently released a new endpoint that retrieves an alert's status and comment history.

We've also added two new parameters to the get alerts endpoint:

Use these parameters to retrieve alerts with statuses and comments that were recently updated.

You can also use the sort parameter with alertStatusCreatedAt to sort your alerts by the time their status was created.

July 9, 2021

We've updated our KYT API docs to restructure and reframe our endpoints. We believe the new structure brings more clairity to our API. It is important to note that both v1 and v2 endpoints are comptaible. We've included a new API implementation that details how you might integrate with our API. We've renamed our old integration guide to Legacy implementation.

May 27, 2021

We've recently released a new endpoint, POST: alert status and comment.

You can now make a POST request to change an alert's status and include a comment, giving you the ability to action historic alerts programmatically and ensure your case management syncs with KYT. View the endpoint here.

March 31, 2021

We've recently added Algorand as a supported asset.

For your transfers, KYT includes staking rewards where present. Algorand block explorers display staking rewards separately from the main payment transfer(s). Therefore, block explorers may introduce a discrepancy in the output index, e.g. a block explorer presents a counterparty at position 0, yet our representation shows the same counterparty at position 2. For this reason, you should include the output address, rather than output index, in transfer references for your KYT API requests.

View all the assets that Chainalysis supports here.

October 28, 2020

We’ve recently added support for another 16 ERC-20 tokens. These include DeFi tokens, one of the most exciting and talked about areas of crypto, and a tranche of stable coins. Chainalysis now supports over 100 cryptocurrency assets. See the complete list of assets that KYT suppports here.

June 8, 2020

Chainalysis has launched support for two notable cryptocurrencies: Dash and Zcash. As two of the most popular so-called “privacy coins” — cryptocurrencies with privacy enhancing features encoded into their protocols — they account for over $1.5 billion of reported daily trading volume.

Our latest blog post explains how these two privacy coins allow investigators and compliance professionals to investigate and monitor illicit activity using our products.

See all cryptocurrencies that Chainalysis supports here.

May 26, 2020

KYT has introduced a new user risk score calculation that's easier to understand, customize, and control.


March 12, 2020

Chainalysis has added 43 new tokens, more than doubling the number of ERC-20 tokens we support. KYT can now help you understand what’s happening with 97% of the total value in ERC-20s and over $1 billion of ERC-20 transfers every day. See a complete list of assets that KYT suppports here.


February 11, 2020


December 10, 2019


December 5, 2019


October 16, 2019


September 25, 2019


August 6, 2019


July 23, 2019

API configuration

API request header & authentication

Example request header:

curl -X GET "https://test.chainalysis.com/api/kyt/v1/assets" \
  --header "Token: <API_KEY>" \
  --header "Accept: application/json"

Note: Make sure to replace <API_KEY> with your API key.

KYT environments

Example test server request:

curl -X POST 'https://test.chainalysis.com/api/kyt/v1/users/user_547/transfers/sent' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --data '[{"asset": "BTC", "transferReference": "9aaaea1ce7d863e18d82f7ea331f9521a2c4fb7cbddd784001cd32ac28952cb5:0"}]'

We recommend using the Test Environment for initial API integration and validation. Once this is done, you can replace the API Key and URL to switch your integration to the KYT Production environment.

Security: All KYT API access is secured using HTTPS with TLS (v1.2) being supported.

Test environment URLs:

Production environment URLs:

Generating API keys

You can create API keys from the Setting option in KYT's Account menu.

To create an API key:

  1. Log into the KYT environment (Test or Production) for which you want to generate an API key
  2. From the Account drop-down menu, click Settings.
  3. Click the Generate API Key button. Your API key appears below.

You can also obtain an API key in the Settings menu in Chainalysis Reactor.

API response pagination

In the following example, the query parameters of "limit": 25 and "offset": 3 would display items 3-28 in the result set of 100 total items.

Note that the "data" array would typically display the data queried for these objects but has been truncated for this example.

The KYT API supports pagination for endpoints that return long lists of objects. Pagination allows you to retrieve a limited set (or subset) of results and to offset those results. Responses are displayed using total, limit, and offset. To see a different page, append the parameters limit and/or offset to the GET request.

{
  "total": 100,
  "limit": 25,
  "offset": 3,
  "data": [
    ...
  ]
}

Optional pagination parameters

Parameter Name Type Description
limit Int A limit on the number of objects returned.
offset Int The position of the first object returned in the response. The default is 0, which starts the page at the first result.

If there is no data to be returned, the data array will be empty.

Integration

You must complete an API integration to populate your data for risk reporting and case management in the KYT dashboard. The integration can be tested in a test environment, then once completed, moved to the production environment. See KYT Environments above for more information about the test and production environments.

Tips

Moving from test to production

  1. Access the test environment
    Log in with your test credentials (obtained via email) and generate your API key for the test environment (links above).

  2. Make successful requests on test server
    Ensure successful requests have been made on the test server (transfers/sent, transfers/received, etc).

  3. Set up compliance workflows and verify that requests are aligned in the test environment

  4. Move from the test environment to the production environment
    Log in with your production credentials (obtained via email) and generate your API key for the production environment (URLs provided above).

You will need to regularly post new transfers to the KYT API. Each transfer needs to be posted to the API only once, and KYT will continuously monitor counterparties and transaction flows. If transfers are accidentally posted more than once, this will not have an effect.

API implementation

The API implementation guide details three common use cases:

Crediting a user’s funds

Typically, services do not have control over received transfers. This guide details how to use KYT data to take programmatic action when receiving a user deposit. Outlined below is an example describing how to use the KYT API to navigate received deposits.

When you receive a user deposit:

  1. Call the POST /v2/users/{userId}/transfers endpoint. Be sure to indicate the "direction" as "RECEIVED" in the request body. If successful, you will:
    1. Receive a 202 response.
    2. Receive an external identifier (externalId). Store this external identifier in your system for later use.

  2. Call the GET /v2/transfers/{externalId} summary endpoint using the externalId received in step 1. You will need to poll this endpoint until updatedAt is no longer null. Once populated, KYT generates alerts according to your organization’s alert rules.

    Note: How quickly the updatedAt field populates depends on how many confirmations Chainalysis requires before processing transactions for a given asset. Some require fewer confirmations or are quicker than others. Learn more about polling the summary endpoints here.

  3. Once the updatedAt field populates, determine whether the asset is a mature or pre-growth asset and follow the corresponding procedure below.

Transfer API Workflow

User deposits and mature assets

With mature assets, you can retrieve the following additional information about the transfer, if available:

To retrieve additional information about the received transfer:

  1. Call the GET /v2/transfers/{externalId}/exposures endpoint to retrieve any available direct exposure information.
  2. Call the GET /v2/transfers/{externalId}/alerts endpoint to retrieve any generated alerts specific to this transfer.

Learn more about retrieving alert data for ongoing transaction monitoring here.

User deposits and pre-growth assets

For pre-growth assets, you can retrieve the following additional information about the transfer, if available:

To retrieve additional information about the received transfer:

  1. Call the GET /v2/transfers/{externalId}/alerts endpoint to retrieve any generated alerts specific to this transfer.
  2. Call the GET /v2/transfers/{externalId}/network-identifications endpoint to retrieve the counterparty name for any asset and transaction hash matches.

Learn more about retrieving alert data for ongoing transaction monitoring here.

Note: Depending on the transfer, direct exposure information may be available. You can check by calling the GET /v2/transfers/{externalId}/exposures endpoint.

Processing withdrawals

Sometimes services do not have information about the counterparty where their users attempt to make a withdrawal. This guide details how to use KYT data to take programmatic action when users attempt withdrawals. Outlined below is an example describing how to use the KYT API to navigate withdrawal attempts.

When a user attempts a withdrawal:

  1. Call the POST /v2/users/{userId}/withdrawal-attempts endpoint. If successful, you will:
    1. Receive a 202 response.
    2. Receive an external identifier (externalId). Store the external identifier in your system for later use.
  2. Call the GET /v2/withdrawal-attempts/{externalId} summary endpoint, using the externalId received in step 1. You will need to poll this endpoint until updatedAt is no longer null. Once populated, KYT generates alerts according to your organization’s alert rules.
  3. Once the updatedAt field populates, determine whether the asset is a mature or pre-growth asset and follow the corresponding procedure below.

Withdrawal Attempts API Workflow

Withdrawal attempts and mature assets

With mature assets, you can retrieve the following additional information, if available:

To retrieve additional information about the withdrawal attempt:

  1. Call the GET /v2/withdrawal-attempts/{externalId}/exposures endpoint to retrieve any counterparty exposure information.
  2. Call the GET /v2/withdrawal-attempts/{externalId}/alerts endpoint to retrieve any available alerts specific to this counterparty.
  3. Call the GET /v2/withdrawal-attempts/{externalId}/high-risk-addresses endpoint to check if the counterparty has any Chainalysis Identifications.
  4. After successfully processing a user’s withdrawal, call the POST /v2/users/{userId}/transfers endpoint and indicate the "direction" as "SENT" to register the transfer for ongoing monitoring.

Withdrawal attempts and pre-growth assets

With pre-growth assets, you can retrieve the following additional information, if available:

To retrieve additional information about the withdrawal attempt:

  1. Call the GET /v2/withdrawal-attempts/{externalId}/alerts endpoint to retrieve any alerts specific to the counterparty.
  2. Call the GET /v2/withdrawal-attempts/{externalId}/high-risk-addresses endpoint to check if the counterparty has any Chainalysis Identifications.
  3. Call the GET /v2/withdrawal-attempts/{externalId}/network-identifications endpoint to retrieve the counterparty name of any asset and transaction hash matches.
  4. After successfully processing a user’s withdrawal, call the POST /v2/users/{userId}/transfers endpoint and indicate the "direction" as "SENT"to register the transfer for ongoing monitoring.

Retrieving alerts for transaction monitoring

After you've decided whether to credit a user's funds or process a user's withdrawal attempt, KYT automatically monitors the transaction and generates alerts according to your Alert Rules. You can retrieve those alerts with the GET /v1/alerts endpoint.

If you call the endpoint without any query parameters, you will retrieve all of the alerts within your organization. To retrieve specific alerts, you can filter or sort with various query parameters.

Use the following query parameters to filter the alerts you wish to retrieve:

Use the sort parameter with one of the following items to sort the order in which you retrieve alerts:

After choosing the item you wish to sort by, you must add a URL encoded space character and indicate the order as either ascending (asc) or descending (desc). For example, sort=createdAt%20asc.

Retrieving high severity alerts for a specified user

You can specify a combination of these query parameters to retrieve a specific result. As an example, to retrieve only HIGH severity alerts of a specific userId generated after a particular timestamp (createdAt_gte), call GET /v1/alerts?level=HIGH&userId=user001&createdAt_gte=2020-01-06

This will return all high severity alerts for user001 after January 6th, 2020. Notice the timestamp includes only the date. You can filter even further with the inclusion of time to retrieve alerts down to the microsecond: &createdAt_gte=2020-01-06T12:42:14.124Z

If you want to sort the alerts by their creation date, add sort=createdAt%20asc as a query parameter.

Retrieving severe alerts for a specified date range

You can use both createdAt_gte andcreatedAt_lte to retrieve alerts for a determined time period. As an example, to retrieve only SEVERE alerts within your organization between the hours of 1:00AM and 2:00AM, call GET /v1/alerts?level=SEVERE&createdAt_gte=2021-05-01T00:00:00.00Z&createdAt_lte=2021-05-07T00:00:00.00Z

You can adjust these parameters to then retrieve all SEVERE alerts between the hours of 2:00AM and 3:00AM, so on and so forth. Alternatively, you can discard the time information (T00:00:00Z) from the query parameters altogether to retrieve alerts for certain days, weeks, or even months. The level of frequency you choose to call these endpoints depends on your organizational needs.

Polling the summary endpoints

How long to poll the summary endpoints ultimately depends on the particular Blockchain and its number and speed of confirmations.

Transfers example

For the /transfer endpoints, assuming you have made the initial POST request after a Bitcoin block has been mined, most transfers process in less than a minute. However, we still suggest polling for at least a few minutes if the updatedAt field has not yet populated. In cases when the updatedAt field is still null after a number of minutes, we suggest setting a policy about how long to wait before crediting a user's account.

Most services require at least a few confirmations before crediting a user's funds, which usually takes many minutes. It is during this time that you can begin polling the GET /transfers/{externalId} endpoint.

Withdrawal attempts example

The /withdrawal-attempts endpoints do not depend on a new block being mined. Therefore, the expected polling time is shorter. Nonetheless, we still recommend setting a policy for how long to wait in the case where updatedAt returns null for an extended amount of time.

Processing times for each chain

The number of confirmations required to process a transfer differs for each chain. Assuming a block has been mined, typically, BTC, ETH and ERC-20s, LTC, and BTC are processed within five seconds of the first confirmation. However, both DASH and ZEC require 30 confirmations and those confirmations take approximately 80 minutes for DASH and approximately 30 minutes for ZEC. On the other hand, DOGE requires 40 confirmations which take approximately 40 minutes.

Legacy implementation

Suggested implementations of the Chainalysis KYT API are detailed below, increasing in complexity and the amount of functionality you will receive. You can choose to work entirely in the KYT user interface (UI), or build a response within your own internal systems based on feedback and analysis from Chainalysis.

Building the analysis and data from the KYT API into your internal system provides robust functionality and gives you a more comprehensive picture of your risk. We suggest reviewing example compliance workflows to help assess which implementation best meets your needs.

At minimum, the two major endpoints required for integration are: /transfers/sent and /transfers/received. For basic functionality, you must execute at least those two requests.

Overview

The following graphic serves as a preview and comparison for the various KYT implementations. The implementations are described in detail in the sections below, including benefits and drawbacks as well as required endpoints for each.

Implementations overview

To help you visualize a compliance workflow using data from the KYT API, here is a basic KYT implementation.

Customer lifecycle

Prepare for launch 1

KYT UI only

This is the minimum implementation and keeps all data and functionality entirely within Chainalysis’s environment. It does not pull data into your internal systems.

You will receive the full functionality of the KYT UI, but you will not have the ability to automate actions on transfers within your internal systems based on the information from KYT.

Prepare for Launch 1

This implementation requires registering /transfers/sent and /transfers/received. /depositaddresses is optional.

POST /users/{userId}/transfers/received

POST /users/{userId}/transfers/sent

POST /users/{userId}/depositaddresses

Transactions must be associated with a User ID for user risk score calculation.

Prepare for launch 2

Internal systems only

While you can work entirely in the Chainalysis environment (see above), this implementation pulls Chainalysis’s data into your own system where you can incorporate KYT into your automated payments workflow.

Integrating Chainalysis’s data into your internal system helps you to get a more comprehensive picture of your risk activity and automate actions on transfers based on Chainalysis data. However, you will be missing out on functionality and convenience by not working within the KYT UI.

Prepare for Launch 2

This implementation requires registering /transfers/sent and /transfers/received (described above), as well as /withdrawaladdresses.

For example, if you want to stop the withdrawal of funds to a sanction or terrorist financing entity, you would use this request.

POST /users/{userId}/withdrawaladdresses

Lift off

KYT UI & Internal systems

This setup is more robust than the previous implementations, as it encompasses both the KYT UI and your internal systems. You will be able to take action on transfers within your system and also have the full functionality of the UI, helping to provide continuity in the data you review between systems.

However, it does not take advantage of all the KYT features, such as alerts.

Lift off implementation

This implementation requires registering /transfers/sent, /transfers/received, and /withdrawaladdresses (described above).

With this implementation you can:

Cruising altitude

KYT UI & Internal systems

This implementation pulls Chainalysis data into both the KYT UI and your internal systems with an additional API endpoint, /alerts.

Cruising Altitude brings the most powerful data that KYT offers - alerts - into your internal system. You can perform the actions mentioned above (setting flags, pulling the risk score into payments queues, etc) with the benefit that the data you are using is the most robust. This implementation can also help you match the alerts workflows that your compliance team is likely doing in the UI.

Cruising altitude implementation

This implementation requires registering /transfers/sent, /transfers/received, /withdrawaladdresses (described above), as well as /alerts.

GET /alerts

To the moon

KYT UI & Internal systems

This implementation pulls Chainalysis data into both the KYT UI and your internal systems. It builds on the implementations above with an additional endpoint, /users. GET /users provides you with a user risk score for each of your users.

Alerts and user risk score are two powerful analytic metrics that are provided by the KYT API for assessing your risk activity. User risk scores allow you to perform user-level automated review in your internal system on top of the transfer-level review from above.

To the Moon implementation

This implementation requires registering /transfers/sent, /transfers/received, /withdrawaladdresses, /alerts (described above), as well as /users.

GET /users

Complianace workflows

Below are example compliance workflows using KYT’s most powerful risk assessment features to help you formulate policies and procedures based on the information provided by the KYT and Reactor UIs, and the KYT API.

The workflows below focus on three KYT features that help you prioritize risk activity: alerts, user risk score, and counterparty screen:

We suggest using alerts as a notification and starting point for review and interacting with user risk profiles. The KYT Dashboard in the UI gives you a high-level overview of your risk for managerial and organizational reporting/monitoring, while alerts is where an analyst will spend most of their time.

Deposit workflow

This is a suggested workflow for funds that are received by a user at your organization. Note that in most cases, you cannot stop an incoming transfer from occurring. However, KYT helps you to detect the risk associated with the transfer and take appropriate compliance action. For example, if a user receives funds directly from a cluster categorized as child abuse material, you can decide how you want to react (e.g. freeze funds, investigate, and likely file a SAR).

Integration graphic

1. Register the transfer
When funds arrive at a user address, POST the received transfer.

2. Check alerts and/or user risk score

You can check alerts:

We suggest checking alerts first to assess risky transfer activity and then moving to review all alerts at the user level by clicking the unique URL for the user. You can also check the user’s risk score to see if the user is high risk.

You can check user risk score:

3. Take action

Take action on the received funds. For example, you can hold the transfer and submit it to be manually reviewed, immediately freeze the user’s funds, or deem the transfer non-risky.

Chainalysis continually monitors for risk on each registered transfer.

Withdrawal workflow

This is a suggested workflow for funds that are being sent by a user at your organization. Unlike deposits, you can stop a risky withdrawal from occurring if at the time of the withdrawal, the withdrawal address has been identified as risky. For example, if a user requests a withdrawal towards a sanctioned address, you can decide to block this request.

Integration graphic

1. Check Withdrawal Address

The withdrawal prescreen is used in real-time to pre-screen for counterparty risk. When a user requests a withdrawal, register the withdrawal address by making a POST request to the /withdrawaladdresses endpoint. For known counterparties, a risk rating of high risk or low risk will be provided, as well as the counterparty’s name.

Note that it is common to withdraw to a previously unknown address, so the majority of addresses you check may have an unknown rating.

2. Take action

After performing the withdrawal address counterparty screen, take action on the pending transfer. You may choose to block a transfer that is high risk, or flag it for further review.

3. Register the transfer

Always be sure to register an approved withdrawal as a sent transfer upon completion so that your team can access it in the compliance dashboard and KYT can monitor the transfer. Note that KYT updates risk for transfers on an ongoing basis, but does not update withdrawal addresses. The latter will always return the rating when the address was first screened.

As with deposits, Chainalysis monitors sent transfers for you over time.

4. Check alerts

Look at the user information page in the UI for the user's associated withdrawal addresses and alerts. Alerts that have a sent direction mean that the withdrawal was approved.

Example compliance actions

Here are some examples of compliance actions taken by our customers when following the workflows above:

“If we notice a withdrawal request towards terrorism financing, we will show the user the withdrawal request is processing and call our Financial Intelligence Unit hotline to ask if they want us to block the transaction (and likely tip off the user) or allow it to occur (for ongoing monitoring).”

“If we detect a direct deposit from a darknet market, we will silently freeze the account. Typically we will file a SAR report, offboard the user, and allow the user to withdraw their funds via a fiat conversion to their bank account.”

“If we detect a pattern of risky (in)direct darknet market transactions, we will freeze the account. Typically we will file a SAR report, offboard the user, and allow the user to withdraw their cryptocurrency.”

“Transfers to mixing services are prohibited on our platform. If we see a withdrawal request to a mixer, we flag the transfer for review and ask the user to explain the purpose of the withdrawal.”

Internal systems

Note that instead of performing these checks manually, you can automate the process by building a response within your own internal systems. See the suggested implementations above for more information. The benefits of automating compliance include:

transferReference syntax

UTXO based cryptocurrencies

UTXO based transfer example

Transfer is a sent transfer with hash 9022c2d59d1bed792b6449e956b2fe26b44b1043bbc1662d92ecd29526d7f34e and user output address 18SuMh4AFgTSQRvwFzdYGieHtgKDveHtc. The output address is in the 5th place in the transaction.

Select either output address method or output index method.

1. Output address method:

"asset": "BTC",
"transferReference":"2d9bfc3a47c2c9cfd0170198782979ed327442e5ed1c8a752bced24d490347d4:1H7aVb2RZiBmdbnzazQgVj2hWR3eEZPg6v"

2. Output index method:

"asset": "BTC",
"transferReference":"2d9bfc3a47c2c9cfd0170198782979ed327442e5ed1c8a752bced24d490347d4:4"

UTXO based cryptocurrencies, such as Bitcoin, must reference a transaction hash and a corresponding output address or transaction hash index.

Note that the output address is the destination address for funds within the transaction; i.e. where funds are being sent (for a sent transfer) or where funds are being received (in a received transfer). The output for received transactions will be an address you control.

When an output address is used to specify a transfer, the index of the first matching output is used regardless of value.

Account based cryptocurrencies

Account based transfer example

Basic ether transfer:

"asset": "ETH",
"transferReference":"0xe823c9b7895f9c47985c80e4611272f8194403e885c9cc603422cd609d738098:0x3d21a92285bf17cbdde5f77531b8b58ac400288a"

User is sending funds to a smart contract (note that the output address is the smart contract):

"asset": "USDC",
"transferReference":"0xeb8cff0b134a93da1c8e3ee263ff7a60ed836489a57e38a56c77bd0d0ab8995d:0x39aa39c021dfbae8fac545936693ac917d5e7563”

User is receiving funds from a smart contract (note that the output address belongs to the user):

"asset": "ETH",
"transferReference":"0xce5c4a31b2b6265f2373b5abf319d092ed8d659fa5ba41edf62d9ad61db570d4:0xE1DaC2E83a7Fc3B1C21a6F740eCd8e28cB965F14"

Account based cryptocurrencies, such as Ethereum or ERC-20 tokens, require a valid transaction hash and output address (see note above about output addresses).

In the case of a smart contract, this format still holds. The output address can possibly be the smart contract itself if it is receiving funds from a user, or a customer if the smart contract is sending funds out.

Assets

You can send data for additional assets that are not yet fully supported with the POST /v2/users/{userId}/transfers/ endpoint. As soon as KYT supports the coin, the system will automatically backfill any data you've sent and you only have to upload this data once. A list of all assets you can send appears below.

V2 endpoints

User registration

These endpoints create a user and register their transfer or withdrawal attempt.

POST /v2/users/{userId}/transfers

POST /v2/users/{userId}/withdrawal-attempts

Register a transfer

ENDPOINT

POST /v2/users/{userId}/transfers

The following is an example cURL request to create a user and register a transfer for a mature asset:

curl -X POST 'https://test.chainalysis.com/api/kyt/v2/users/new_user_01/transfers' \
  --header 'Token: <API_KEY>' \
  --header 'Content-type: application/json' \
  --data '{
    "asset": "BTC",
    "transferReference":"2d9bfc3a47c2c9cfd0170198782979ed327442e5ed1c8a752bced24d490347d4:1H7aVb2RZiBmdbnzazQgVj2hWR3eEZPg6v",
    "direction":"received"
}'

The following is an example cURL request to create a user and register a transfer for a pre-growth asset:

curl -X POST 'https://test.chainalysis.com/api/kyt/v2/users/new_user_02/transfers' \
  --header 'Token: <API_KEY>' \
  --header 'Content-type: application/json' \
  --data '{
    "asset": "TRX",
    "transferReference": "d559d5c64118fdeb16f0abe8b42ffcceae3c4dd16be1f762684f0b9d6995f6a6:TYbSzw3PqBWohc4DdyzFDJMd1hWeNN6FkB",
    "direction": "SENT",
    "transferTimestamp": "2021-01-06T13:49:34.013597",
    "assetAmount": "100.0",
    "outputAddress": "TYbSzw3PqBWohc4DdyzFDJMd1hWeNN6FkB",
    "inputAddresses": ["TYbSzw3PqBWohc4DdyzFDJMd1hWeNN6FkB"],
    "assetPrice": "50.0",
    "assetDenomination": "USD"
}'

This endpoint registers a transfer. Once you make a request for a transfer, KYT stores it and begins processing.

For transfers that are valid and KYT can process, the transfer should process within 30 seconds.

This endpoint returns the below response:

Path parameters

Parameter Type Required Description
userId String Yes A unique string that identifies your user. If creating a transfer for an existing user, use their existing userId.

Request body schema

Property Type Required Description
asset String Yes The cryptocurrency or token used in this transfer. The value must be the asset's symbol, e.g., BTC for Bitcoin, ETH for Ether, UNI for Uniswap etc.
transferReference String Yes A combination of the transaction hash and output address or index of the transaction, seperated with a colon. For example, {transaction_hash}:{output_address} or {transaction_hash}:{output_index}. Learn more about the transferReference property here.
direction String Yes This value defines whether the transfer is sent or received. This value is case insensitive.
transferTimestamp String No The timestamp when the transfer occured, in the UTC ISO 8601 format. This timestamp should correspond to the timestamp of the block that included the transaction.
assetAmount Number No The amount of cryptocurrency funds used in this transfer.
outputAddress String No The destination address for funds within the transaction.
inputAddresses Array No A list of input addresses of the transfer. Note: This property is available only for pre-growth assets.
assetPrice Number No The converstion of the assetAmount into a US Dollar price at the time of the transfer.
assetDenomination String No The denomination of the assetPrice property. Available only as USD.

Response schema

The following is an example JSON response body from either of the above commands:

{
    "updatedAt": null,
    "asset": "BTC",
    "transferReference": "2d9bfc3a47c2c9cfd0170198782979ed327442e5ed1c8a752bced24d490347d4:1H7aVb2RZiBmdbnzazQgVj2hWR3eEZPg6v",
    "tx": null,
    "idx": null,
    "usdAmount": null,
    "assetAmount": null,
    "timestamp": null,
    "outputAddress": null,
    "externalId": "fc8e053e-8833-344d-b025-40559eafd16f"
}

A successful request will return the following JSON response and properties:

Property Type Description
updatedAt String or null The timestamp when the transfer was last updated, in the UTC ISO 8601 format. From your POST request, this value will be null.
asset String An echo back of the asset type you defined in the request body. This is the asset's symbol, e.g., BTC for Bitcoin, ETH for Ether, etc.
transferReference String An echo back of the transfer reference you defined in the request body.
tx String or null The transaction hash of the transfer. From your POST request, this value will be null.
idx Integer or null The transfer’s index. From your POST request, this value will be null.
usdAmount Number or null The US Dollar amount of funds used in this transfer. From your POST request, this value will be null.
assetAmount Number or null The amount of cryptocurrency funds used in this transfer. From your POST request, this value will be null.
timestamp String or null The timestamp when the transfer occured, in the UTC ISO 8601 format. From your POST request, this value will be null.
outputAddress String or null The destination address for funds within the transaction. From your POST request, this value will be null.
externalId String A Chainalysis-generated identifier of this transfer.

Register a withdrawal attempt

ENDPOINT

POST /v2/users/{userId}/withdrawal-attempts

The following is an example cURL request to register a withdrawal attempt:

curl -X POST 'https://test.chainalysis.com/api/kyt/v2/users/new_user_01/withdrawal-attempts' \
  --header 'Token: <API_KEY>' \
  --header 'Content-type: application/json' \
  --data '{
    "asset": "BTC", 
    "address": "1EM4e8eu2S2RQrbS8C6aYnunWpkAwQ8GtG", 
    "attemptIdentifier": "attempt11", 
    "assetAmount": 5.0, 
    "assetPrice": 1000.0, 
    "assetDenomination": "USD", 
    "attemptTimestamp": "2020-12-09T17:25:40.008307"
}'

This endpoint registers a withdrawal attempt. Once you make a request for a withdrawal attempt, KYT stores it and begins processing.

For a valid address, KYT will process the withdrawal attempt immediately after receiving the POST request.

This endpoint returns the below response:

Path parameters

Parameter Type Required Description
userId String Yes A unique string that identifies your user. If creating a withdrawal attempt for an existing user, use their existing userId.

Request body schema

Property Type Required Description
asset String Yes The cryptocurrency or token used in this withdrawal attempt. The value must be the asset's symbol, e.g., BTC for Bitcoin, ETH for Ether, UNI for Uniswap etc.
address String Yes The cryptocurrency address of the wallet to which the withdrawal attempt is being made.
attemptIdentifier String Yes A unique string that identifies this withdrawal-attempt request. Keys can be any valid string but must be unique for every withdrawal-attempt request.
assetAmount Number Yes The amount of cryptocurrency funds used in this withdrawal attempt.
assetPrice Number Yes The converstion of the assetAmount into a US Dollar price at the time of the withdrawl attempt.
assetDenomination String Yes The denomination of the assetPrice property. Available only as USD.
attemptTimestamp String Yes The timestamp when the withdrawal attempt occured, in the UTC ISO 8601 format.

Response schema

The following is an example JSON response body from the above command:

{
    "asset": "BTC",
    "address": "1EM4e8eu2S2RQrbS8C6aYnunWpkAwQ8GtG",
    "attemptIdentifier": "attempt11",
    "assetAmount": 5.0,
    "usdAmount": null,
    "updatedAt": null,
    "externalId": "e27adb25-7344-3ae3-9c80-6b4879a85826"
}

A successful request will return the following JSON response and properties:

Property Type Description
asset String An echo back of the asset type you defined in the request body. This is the asset's symbol, e.g., BTC for Bitcoin, ETH for Ether, etc.
address String An echo back of the address you defined in the request body.
attemptIdentifier String An echo back of the identifier you created in the request body.
assetAmount Number An echo back of the asset amount defined in the request body.
usdAmount Number or null The US Dollar amount of funds used in this transfer. From your POST request, this value will be null.
updatedAt String or null The timestamp when the withdrawal attempt was last updated, in the UTC ISO 8601 format. From your POST request, this value will be null.
externalId String A Chainalysis-generated identifier of the withdrawal attempt.

Transfers

These endpoints return a transfer's summary, direct exposure, alerts, and any available network identifications.

GET /v2/transfers/{externalId}

GET /v2/transfers/{externalId}/exposure

GET /v2/transfers/{externalId}/alerts

GET /v2/transfers/{externalId}/network-identifications

Get a summary

ENDPOINT

GET /v2/transfers/{externalId}

The following is an example cURL request to retrieve a summary for a registered transfer:

curl -X GET 'https://test.chainalysis.com/api/kyt/v2/transfers/393905a7-bb96-394b-9e20-3645298c1079' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json'

This endpoint returns the summary of the transfer you registered in your POST /transfers request.

Note: You must register your transfer using the Transfer Registration endpoint before you implement the below.

Path parameters

Parameter Type Required Description
externalId String Yes The Chainalysis-generated identifier of this transfer. This is returned in the response body of the POST /transfers request.

Request body schema

This call has no accompanying request body.

Response schema

The following is an example JSON response body from the above command:

{
    "updatedAt": "2021-03-22T23:16:00.022657",
    "asset": "TRX",
    "transferReference": "d559d5c64118fdeb16f0abe8b42ffcceae3c4dd16be1f762684f0b9d6995f6a6",
    "tx": "d559d5c64118fdeb16f0abe8b42ffcceae3c4dd16be1f762684f0b9d6995f6a6",
    "idx": null,
    "usdAmount": 5000.00,
    "assetAmount": 100.0,
    "timestamp": "2021-01-06T12:49:34.013+00:00",
    "outputAddress": "TYbSzw3PqBWohc4DdyzFDJMd1hWeNN6FkB",
    "externalId": "393905a7-bb96-394b-9e20-3645298c1079"
}

Tip: If the updatedAt property returns null, KYT has not finished processing the transfer and other properties will also return null. We suggest you poll this GET request until the property populates.

A successful request will return the following JSON response and properties for a given externalId:

Property Type Description
updatedAt String The timestamp of when the transfer was last updated, in the UTC ISO 8601 format. If null, the transfer has not yet processed, or couldn’t process as it has not appeared in the blockchain.
asset String The asset used in the transfer.
transferReference String The transferReference you defined in the POST call's request body.
tx String The transaction hash of the transfer.
idx Integer or null The transfer's index. If null, either KYT has not finished processing the transfer or the transaction does not contain indexed transfers.
usdAmount Number or null The US Dollar amount of funds used in this transfer. If null, either KYT has not finished processing the transfer or the information was not sent to Chainalysis in the GET request.
assetAmount Number or null The amount of cryptocurrency funds used in this transfer. If null, either KYT has not finished processing the transfer or the information was not sent to Chainalysis in the GET request.
timestamp String or null The blockchain timestamp when the transfer occured, in the UTC ISO 8601 format. If null, either KYT has not finished processing the transfer or the information was not sent to Chainalysis in the GET request.
outputAddress String or null The destination address for funds within the transaction. If null, either KYT has not finished processing the transfer or the information was not sent to Chainalysis in the GET request.
externalId String The Chainalysis-generated identifier of this transfer. This is returned in the response body of the POST /transfers request.

Get direct exposure

ENDPOINT

GET /v2/transfers/{externalId}/exposures

The following is an example cURL request to retrieve direct exposure from a registered BTC transfer:

curl -X GET 'https://test.chainalysis.com/api/kyt/v2/transfers/ae5e6b88-ad59-3688-ac2d-2b5a251e799e/exposures' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json'

This endpoint returns a transfer's cluster information on direct exposures.

You will receive a successful response after KYT has processed your transfer.

To ensure a successful response, call the Transfer Summary endpoint to view if the updatedAt property in your response body is populated before examining your transfer's direct exposure.

Path parameters

Parameter Type Required Description
externalId String Yes The Chainalysis-generated identifier of this transfer. This is returned in the response body of the POST /transfers request.

Request body schema

This call has no accompanying request body.

Response schema

The following is an example JSON response body from the above command:

{
    "direct": {
        "name": "BitPay.com",
        "category": "merchant services"
    }
}

A successful request will return the following JSON response and properties for a given externalId:

Property Type Description
direct Object or null Contains information of a given cluster's direct exposure. If null, the entiy has neither a name and category or Chainalysis has identified neither the name and category.
direct.name String The name of a given cluster's counterparty as identified by Chainalysis. If null, the entity has no name or Chainalysis has not identified the entity.
direct.category String The category of a given cluster's counterparty as identified by Chainalysis. If null, the entity has no category or Chainalysis has not identified the entity's category.

Get alerts

ENDPOINT

GET /v2/transfers/{externalId}/alerts

The following is an example cURL request to retrieve alert information of a registered transfer:

curl -X GET 'https://test.chainalysis.com/api/kyt/v2/transfers/393905a7-bb96-394b-9e20-3645298c1079/alerts' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json'

This endpoint returns a transfer's alerts, if available.

You will receive a successful response after KYT has processed your transfer.

To ensure a successful response, call the Transfer Summary endpoint to view if the updatedAt property in your response body is populated before examining your transfer's alerts.

Note: Alerts for transfers generate according to your organization's alert rules. Learn more about how to define these rules in the KYT UI here.

Path parameters

Parameter Type Required Description
externalId String Yes The Chainalysis-generated identifier of this transfer. This is returned in the response body of the POST /transfers request.

Request body schema

This call has no accompanying request body.

Response schema

The following is an example JSON response body from the above command:

{
    "alerts": [
        {
            "alertLevel": "HIGH",
            "category": "custom address",
            "service": "Play Royal",
            "externalId": "906ff226-8b64-11eb-8e52-7b35a3dc1742",
            "alertAmount": 5000.00,
            "exposureType": "DIRECT"
        }
    ]
}

A successful request will return the following JSON response and properties for a given externalId:

Property Type Description
alerts Array Contains alert information for a given transfer. If no alerts have been generated, the array will be empty.
alerts.alertLevel String Defines the alert's risk as SEVERE, HIGH, MEDIUM, or LOW.
alerts.category String The category of the service as identified by Chainalysis.
alerts.service String The name of the service as defined by Chainalysis.
alerts.externalId String A unique identify of the alert.
alerts.alertAmount Number The USD amount that caused the alert to trigger.
alerts.exposureType String Defines the exposure direction as DIRECT or INDIRECT.

Get network identifications

ENDPOINT

GET /v2/transfers/{externalId}/network-identifications

The following is an example cURL request to retrieve the count of network identifications from a registered transfer:

curl -X GET 'https://test.chainalysis.com/api/kyt/v2/transfers/94d72448-6963-3536-9996-1637f6756f0b/network-identifications' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json'

This endpoint returns network identifications for transfers of pre-growth assets. If attempting to use this endpoint with mature assets, you will receive a 400 response.

You will receive a successful response after KYT has processed your transfer.

To ensure a successful response, call the Transfer Summary endpoint to view if the updatedAt property in your response body is populated before examining your transfer's alerts.

Path parameters

Parameter Type Required Description
externalId String Yes The Chainalysis-generated identifier of this transfer. This is returned in the response body of the POST /transfers request.

Request body schema

This call has no accompanying request body.

Response schema

The following is an example JSON response body from the above command:

{
    "count": 1,
    "networkIdentificationOrgs": [
        {
            "name": "XYZ Cryptocurrency Exchange"
        }
    ]
}

A successful request will return the following JSON response and properties for a given externalId:

Property Type Description
count Number The number of other organizations in the Chainalysis's data network that registered the transfer in the opposing direction.

For example, if you registered the transfer in the SENT direction, you will receive the count of registered transfers in the RECEIVED direction.
networkIdentificationOrg Array Contains the names of the organizations that registered the transfer in Chainalysis's data network. If there are no network identifications, the array will be empty.
networkIdentificationOrg.name String The name of the organization that registered the transfer in Chainalysis's data network.

Withdrawal attempts

These endpoints return a transfer's summary, direct exposure, alerts, and any available network identifications.

GET /v2/withdrawal-attempts/{externalId}

GET /v2/withdrawal-attempts/{externalId}/exposure

GET /v2/withdrawal-attempts/{externalId}/alerts

GET /v2/withdrawal-attempts/{externalId}/high-risk-addresses

GET /v2/withdrawal-attempts/{externalId}/network-identifications

Get a summary

ENDPOINT

GET /v2/withdrawal-attempts/{externalId}

The following is an example cURL request to retrieve a summary for a withdrawal attempt:

curl -X GET 'https://test.chainalysis.com/api/kyt/v2/withdrawal-attempts/e27adb25-7344-3ae3-9c80-6b4879a85826' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json'

This endpoint returns the summary of the withdrawal attempt you registered in your POST /withdrawal-attempts request.

Note: You must register your withdrawal attempt using the Withdrawal Attempt Registration endpoint before you implement the below.

Path parameters

Parameter Type Required Description
externalId String Yes The Chainalysis-generated identifier of this withdrawal attempt. This is returned in the response body of the POST /withdrawal-attempts request.

Request body schema

This call has no accompanying request body.

Response schema

The following is an example JSON response body from the above command:

{
    "asset": "BTC",
    "address": "1EM4e8eu2S2RQrbS8C6aYnunWpkAwQ8GtG",
    "attemptIdentifier": "attempt11",
    "assetAmount": 5.0,
    "usdAmount": 5000.00,
    "updatedAt": "2021-03-23T15:21:10.835+00:00",
    "externalId": "e27adb25-7344-3ae3-9c80-6b4879a85826"
}

Tip: If the updatedAt property returns null, KYT has not finished processing the withdrawal attempt and other properties will also return null. We suggest you poll this GET request until the property populates.

A successful request will return the following JSON response and properties for a given externalId:

Property Type Description
asset String The asset used in the withdrawal attempt.
address String The address where the withdrawal attempt is being made.
attemptIdentifier String An echoback of the attemptIdentifier you created in the POST request.
assetAmount Number The amount of cryptocurrency funds used in this withdrawal attempt.
usdAmount Number The amount of US Dollars used in this withdrawal attempt.
updatedAt String The timestamp of when the withdrawal attempt was last processed, in the UTC ISO 8601 format. If null, the withdrawal attempt has not yet processed.
externalId String A Chainalysis-generated identifier of this withdrawal attempt. This is returned in the response body of the POST request.

Get direct exposure

ENDPOINT

GET /v2/withdrawal-attempts/{externalId}/exposures

The following is an example cURL request to retrieve direct exposure information from a registered BTC withdrawal attempt:

curl -X GET 'https://api.chainalysis.com/api/kyt/v2/withdrawal-attempts/e27adb25-7344-3ae3-9c80-6b4879a85826/exposures' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json'

This endpoint returns a withdrawal attempt’s cluster information on direct exposures.

You will receive a successful response after KYT has processed your withdrawal attempt.

To ensure a successful response, call the Withdrawal Attempt Summary endpoint to view if the updatedAt property in your response body is populated before examining your withdrawal attempt's direct exposure.

Path parameters

Parameter Type Required Description
externalId String Yes The Chainalysis-generated identifier of this withdrawal attempt. This is returned in the response body of the POST /withdrawal-attempts request.

Request body schema

This call has no accompanying request body.

Response schema

The following is an example JSON response body from the above command:

{
    "direct": {
        "name": null,
        "category": null
    }
}

A successful request will return the following JSON response and properties for a given externalId:

Property Type Description
direct Object Contains information of a given cluster's direct exposure.
direct.name String The name of a given cluster's counterparty as identified by Chainalysis. If null, the entity has no name or Chainalysis has not identified the entity.
direct.category String The category of a given cluster's counterparty as identified by Chainalysis. If null, the entity has no category or Chainalysis has not identified the entity's category.

Get alerts

ENDPOINT

GET /v2/withdrawal-attempts/{externalId}/alerts

The following is an example cURL request to retrieve alert information from a registered withdrawal attempt:

curl -X GET 'https://test.chainalysis.com/api/kyt/v2/withdrawal-attempts/eb67cbdc-8bea-11eb-83d5-378cec3052c2/alerts' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json'

This endpoint returns a withdrawal attempt's alerts, if available.

You will receive a successful response after KYT has processed your withdrawal attempt.

To ensure a successful response, call the Withdrawal Attempt Summary endpoint to view if the updatedAt property in your response body is populated before examining your withdrawal attempt's alerts.

Note: Alerts for withdrawal attempts generate according to your organization's alert rules. Learn more about how to define these rules in the KYT UI here.

Path parameters

Parameter Type Required Description
externalId String Yes The Chainalysis-generated identifier of this withdrawal attempt. This is returned in the response body of the POST /withdrawal-attempts request.

Request body schema

This call has no accompanying request body.

Response schema

The following is an example JSON response body from the above command:

{
    "alerts": [
        {
            "alertAmount": 5000.0,
            "alertLevel": "HIGH",
            "category": "custom address",
            "exposureType": "DIRECT",
            "externalId": "eb67cbdc-8bea-11eb-83d5-378cec3052c2",
            "service": "Play Royal"
        }
    ]
}

A successful request will return the following JSON response and properties for a given externalId:

Property Type Description
alerts Array Contains alert information for a given transfer.
alerts.alertAmount Number The USD amount that caused the alert to trigger.
alerts.alertLevel String Defines the alert's risk as SEVERE, HIGH, MEDIUM, or LOW.
alerts.category String The category of the service as identified by Chainalysis.
alerts.exposureType String Defines the exposure direction as DIRECT or INDIRECT.
alerts.externalId String A unique identifier of the alert.
alerts.service String The name of the service as defined by Chainalysis.

Get address identifications

ENDPOINT

GET /v2/withdrawal-attempts/{externalId}/high-risk-addresses

The following is an example cURL request to retrieve custom address information from a registered withdrawal attempt:

curl -X GET 'https://test.chainalysis.com/api/kyt/v2/withdrawal-attempts/high-risk-addresses' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json'

This endpoint returns address identification for the withdrawal attempt, either a user’s upload of custom addresses or Chainalysis identified addresses.

You will receive a successful response after KYT has processed your withdrawal attempt.

To ensure a successful response, call the Withdrawal Attempt Summary endpoint to view if the updatedAt property in your response body is populated before examining your withdrawal attempt's high risk address information.

Path parameters

Parameter Type Required Description
externalId String Yes The Chainalysis-generated identifier of this withdrawal attempt. This is returned in the response body of the POST /withdrawal-attempts request.

Request body schema

This call has no accompanying request body.

Response schema

The following is an example JSON response body for a withdrawal attempt with Chainalysis Identifications:

{
    "chainalysisIdentifications": [
        {
            "addressName": "SANCTIONS: OFAC SDN: Xiaobing Yan",
            "categoryName": "sanctions",
            "description": "This specific address 12QtD5BFwRsdNsAZY76UVE1xyCGNTojH9h within the cluster has been identified as belonging to an individual on OFAC's SDN list. YAN, Xiaobing (Chinese Traditional: 顏曉兵; Chinese Simplified: 颜晓兵) (a.k.a. \"YAN, Steven\"; a.k.a. \"ZHOU, William\"), Wuhan, Hubei, China (Chinese Simplified: 武汉市, 湖北省, China; Chinese Traditional: 武漢市, 湖北省, China); DOB 25 Mar 1977; POB Wuhan City, Hubei, China; citizen China; Gender Male; Chinese Commercial Code 7346 2556 0365; Citizen's Card Number 421002197703250019 (China) (individual) [SDNTK]."
        }
    ],
    "customAddresses": []
}

The following is an example JSON response body for a withdrawal attempt with custom address information:

{
    "chainalysisIdentifications": [],
    "customAddresses": [
        {
            "addressName": "Play Royal",
            "categoryName": "gambling",
            "description": "This address belongs to playroyal.com"
        }
    ]
}

A successful request will return the following JSON response and properties for a given externalId:

Property Type Description
chainalysisIdentifications Array A Chainalysis Identified Address, representing an address-level identification that is part of a larger cluster. The array will be empty if there are no Chainalysis Identifications.
chainalysisIdentifications.addressName String The name designated to the Chainalysis Identification.
chainalysisIdentifications.categoryName String The category of the Chainalysis Identification.
chainalysisIdentifications.description String The OSINT description of the Chainalysis Identification.
customAddresses Array Contains custom address information that matches the addresses in the withdrawal attempt. The array will be empty if there are no Custom Addresses.
customAddresses.addressName String The name of the address the custom address was registered under.
customAddresses.categoryName String The category of the custom address as identified by Chainalysis.
customAddresses.description String The description of the custom address.

Get network identifications

ENDPOINT

GET /v2/withdrawal-attempts/{externalId}/network-identifications

The following is an example cURL request to retrieve the count of network identifications from a registered withdrawal attempt:

curl -X GET 'https://test.chainalysis.com/api/kyt/v2/withdrawal-attempts/159cc56a-ae87-3aab-a2fc-2d4f9f42885f/network-identifications' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json'

This endpoint returns network identifications for withdrawal attempts of pre-growth assets. If attempting to use this endpoint with mature assets, you will receive a 400 response.

You will receive a successful response after KYT has processed your withdrawal attempt.

To ensure a successful response, call the Withdrawal Attempt Summary endpoint to view if the updatedAt property in your response body is populated before examining your withdrawal attempt's network identifications.

Path parameters

Parameter Type Required Description
externalId String Yes The Chainalysis-generated identifier of this withdrawal attempt. This is returned in the response body of the POST /withdrawal-attempts request.

Request body schema

This call has no accompanying request body.

Response schema

The following is an example JSON response body from the above command:

{
    "count": 1,
    "networkIdentificationOrgs": [
        {
            "name": "XYZ Cryptocurrency Exchange"
        }
    ]
}

A successful request will return the following JSON response and properties for a given externalId:

Property Type Description
count Integer The number of other organizations in Chainalysis's data network that registered the withdrawal attempt.
networkIdentificationOrgs Array Contains the names of the organizations that registered the withdrawal attempt in Chainalysis's data network.
networkIdentificationOrgs.name String The name of the organization that registered the withdrawal attempt in Chainalysis's data network.

V1 endpoints

Received transfers

These endpoints either post or get a received transfer.

POST /v1/users/{userId}/transfers/received

GET /v1/users/{userId}/transfers/received

With them, you can:

A list of assets that are currently supported by KYT appears below.

Note that you can send data for more assets in addition to this list through the transfers/received endpoint. As soon as KYT fully supports the coin, the system will automatically backfill any data you've sent. Therefore, you only have to upload this data once. See a list of all the assets you can send to KYT below.

Register a received transfer

ENDPOINT

POST /v1/users/{userId}/transfers/received

The following is an example cURL request to register a received Bitcoin transfer for user 005 using output address in the transferReference.

curl -X POST 'https://test.chainalysis.com/api/kyt/v1/users/005/transfers/received' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --data '[{"asset": "BTC", "transferReference": "2d9bfc3a47c2c9cfd0170198782979ed327442e5ed1c8a752bced24d490347d4:1H7aVb2RZiBmdbnzazQgVj2hWR3eEZPg6v"}]'

The following is an example cURL request to register a received Bitcoin transfer for user 005 using output index in the transferReference.

curl -X POST 'https://test.chainalysis.com/api/kyt/v1/users/005/transfers/received' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --data '[{"asset": "BTC", "transferReference": "2d9bfc3a47c2c9cfd0170198782979ed327442e5ed1c8a752bced24d490347d4:0"}]'

Path parameters

Parameter Type Required Description
userId String Yes A unique string that identifies your user associated with this transfer. If creating a transfer for an existing user, use their existing userId.

Query parameters

Parameter Type Required Description
bulkImport Boolean No Determines whether to register transfers in bulk. You can submit either true or false. If set to true, no real-time response is returned and the request executes faster. We suggest using this parameter if you do not require the real-time response. There is a limit of 100 transfers when bulkImport is false or unspecified and 1000 transfers when bulkImport is true.

Request body schema

Property Type Required Description
asset String Yes The cryptocurrency or token used in this transfer. The value must be the asset's symbol, e.g., BTC for Bitcoin, ETH for Ether, UNI for Uniswap etc.
transferReference String Yes A combination of the transaction hash and output address or index of the transaction, seperated with a colon. For example, {transaction_hash}:{output_address} or {transaction_hash}:{output_index}. Learn more about the transferReference property here.
transferTimestamp String No The blockchain timestamp when the the transfer occured, in the UTC and ISO 8601 format. Note: Available only for pre-growth assets.
assetAmount Number No The amount of cryptocurrency funds used in this transfer. Note: Available only for pre-growth assets.

Response schema

The following is an example JSON response body from the above commands:

[
  {
    "transferReference": "2d9bfc3a47c2c9cfd0170198782979ed327442e5ed1c8a752bced24d490347d4:1H7aVb2RZiBmdbnzazQgVj2hWR3eEZPg6v",
    "asset": "BTC",
    "cluster": {
      "name": "Coinbase.com",
      "category": "exchange"
    },
    "rating": "lowRisk"
  }
]

A successful request will return the following JSON response and properties for a given userId, asset, and transferReference.

Property Type Description
transferReference String An echo back of the transfer reference you defined in the request body.
asset String An echo back of the asset type you defined in the request body. This is the asset's symbol, e.g., BTC for Bitcoin, ETH for Ether, etc.
cluster Object or null The identification of a group of addresses estimated by Chainalysis to be controlled by a single entity. This value will be null if the cluster has not yet been identified.
cluster.name String The name of a named Cluster.
cluster.category String The category the named Cluster belongs to, ie. Exchange.
rating String The risk rating of the transfer, either highRisk, lowRisk, or unknown. The rating corresponds to the service's category. Learn more about services here and highRisk services here . unknown means Chainalysis has not yet identified the service or the service is Unnamed.

Get a received transfer

ENDPOINT

GET /v1/users/{userId}/transfers/received

The following is an example cURL request to retrieve all received transfers for user BTC_01

curl -X GET 'https://test.chainalysis.com/api/kyt/v1/users/BTC_01/transfers/received' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json'

The response body will be a list with the same length as the number of transfers in the request.

Path parameters

Parameter Type Required Description
userId String Yes A unique string of the user associated with this transfer.

Query parameters

Parameter Type Required Description
limit Integer No A limit on the number of objects returned.
offset Integer No The position of the first object returned in the response. The default is 0, which starts the page at the first result.

Request body schema

This call has no accompanying request body.

Response schema

The following is an example JSON response body from the above command:

{
  "limit": 100,
  "offset": 0,
  "total": 1,
  "data": [
        {
            "asset": "BTC",
            "transferReference": "2d9bfc3a47c2c9cfd0170198782979ed327442e5ed1c8a752bced24d490347d4:1H7aVb2RZiBmdbnzazQgVj2hWR3eEZPg6v",
            "amount": "4",
            "amountUSD": "561.64",
            "timestamp": "2021-07-07T18:29:14Z",      
            "rating": "lowRisk",
            "cluster": {
                "name": "Coinbase.com",
                "category": "exchange"
            }
        }
    ]
}

A successful request will return the following JSON response and properties for a given userId.

Property Type Description
limit Integer An echo back of the limit query parameter.
offset Integer An echo back of the offset query parameter.
total Integer The total number of transfer objects returned.
data Array An array containing transfer data.
data.asset String The asset associated with the Transaction associated with the user.
data.transferReference String The transferReference you defined in the POST call's request body.
data.amount Number The amount of cryptocurrency funds used in this transfer.
data.amountUSD Number The US Dollar amount of funds used in this transfer.
data.timestamp String The blockchain timestamp when the transfer occured, in the UTC and ISO 8601 format.
data.rating String The risk rating of the transfer, either highRisk, lowRisk, or unknown. The rating corresponds to the service's category. Learn more about services here and highRisk services here . unknown means Chainalysis has not yet identified the service or the service is Unnamed.
data.cluster Object or null The identification of a group of addresses estimated by Chainalysis to be controlled by a single entity. This value will be null if the cluster has not yet been identified.
data.cluster.name String The name of a named Cluster.
data.cluster.category String The category the named Cluster belongs to, e.g., an exchange.

Sent transfers

These endpoints either post or get a sent transfer.

POST /v1/users/{userId}/transfers/sent

GET /v1/users/{userId}/transfers/sent

With them, you can:

A list of assets that are currently supported by KYT appears below.

Note that you can send data for more assets in addition to this list through the transfers/sent endpoint. As soon as KYT fully supports the coin, the system will automatically backfill any data you've sent. Therefore, you only have to upload this data once. See a list of all the assets you can send to KYT below.

Register a sent transfer

ENDPOINT

POST /v1/users/{userId}/transfers/sent

The following is an example cURL request to register a sent Bitcoin transfer for the user 005 using output address in the transferReference.

curl -X POST 'https://test.chainalysis.com/api/kyt/v1/users/005/transfers/sent' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --data
  '[{
    "asset": "BTC",
    "transferReference": "7c2238d4de91472061d66f918bda68541f33bd84ce994bcf191cd1315fa41118:16HgQB937BRDk3PyS9nSUuHE2P6CbjNuAe"
  }]'

The following is an example cURL request to register a sent Bitcoin transfer for the user 005 using output index in the transferReference.

curl -X POST 'https://test.chainalysis.com/api/kyt/v1/users/005/transfers/sent' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --data
  '[{
    "asset": "BTC",
    "transferReference": "7c2238d4de91472061d66f918bda68541f33bd84ce994bcf191cd1315fa41118:0"
  }]'

Path parameters

Parameter Type Required Description
userId String Yes A unique string that identifies your user associated with this transfer. If creating a transfer for an existing user, use their existing userId.

Request body schema

Property Type Required Description
asset String Yes The cryptocurrency or token used in this transfer. The value must be the asset's symbol, e.g., BTC for Bitcoin, ETH for Ether, UNI for Uniswap etc.
transferReference String Yes A combination of the transaction hash and output address or index of the transaction, seperated with a colon. For example, {transaction_hash}:{output_address} or {transaction_hash}:{output_index}. Learn more about the transferReference property here.
transferTimestamp String No The blockchain timestamp when the transfer occured, in the UTC ISO 8601 format. Note: Available only for pre-growth assets.
assetAmount Number No The amount of cryptocurrency funds used in this transfer. Note: Available only for pre-growth assets.

Response schema

The above commands return an empty JSON response.

The response will be an empty zero byte response, indicated by a response header Content-Length: 0.

Get a sent transfer

ENDPOINT

GET /v1/users/{userId}/transfers/sent

An example request for retrieving all sent transfers for user BTC_01.

curl -X GET 'https://test.chainalysis.com/api/kyt/v1/users/BTC_01/transfers/sent' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json'

Path parameters

Parameter Type Required Description
userId String Yes A unique string of the user associated with this transfer.

Query parameters

Parameter Type Required Description
limit Integer No A limit on the number of objects returned. If unspecified, the default is 100.
offset Integer No The position of the first object returned in the response. The default is 0, which starts the page at the first result.

Request body schema

This call has no accompanying request body.

Response schema

The following is an example JSON response body from the above command:

{
    "limit": 100,
    "offset": 0,
    "total": 1,
    "data": [
        {
            "asset": "ETH",
            "transferReference": "0x41af697d34230e084ff5fb74fab30fc878a14567ac8f97573ba98c401adc4d97:0x30FF461f7f077E6E18CE0670D352c0c54CA3D102",
            "amount": 6.31049917,
            "amountUSD": 1195.71,
            "timestamp": "2019-09-16T09:36:09Z",
            "cluster": {
                "name": "Kraken.com",
                "category": "exchange"
            }
        }
    ]
}

The response body will be a list with the same length as the number of transfers in the request.

A successful request will return the following properties in JSON format for a given userId.

Property Type Description
limit Integer An echo back of the limit query parameter.
offset Integer An echo back of the offset query parameter.
total Integer The total number of transfer objects returned.
data Array An array containing transfer data.
data.asset String The asset associated with the Transaction associated with the user.
data.transferReference String The <transaction_hash:output_address OR index> combination associated with the transaction.
data.amount Number The amount of cryptocurrency funds used in this transfer.
data.amountUSD Number The US Dollar amount of funds used in this transfer.
data.timestamp String The timestamp when the transfer occured, in the UTC and ISO 8601 format.
data.cluster Object or null The identification of a group of addresses estimated by Chainalysis to be controlled by a single entity. This value will be null if the cluster has not yet been identified.
data.cluster.name String The name of a named Cluster.
data.cluster.category String The category the named Cluster belongs to, ie. Exchange.

Withdrawal pre-screening

These endpoints allow you to post, get, or delete a withdrawal address.

POST /v1/users/{userId}/withdrawaladdresses

GET /v1/users/{userId}/withdrawaladdresses

DELETE /v1/users/{userId}/withdrawaladdresses

With them, you can:

Note that KYT updates risk for transfers on an ongoing basis, but does not update withdrawal addresses. The withdrawaladdresses endpoint returns the cluster information that was available when the API was called. For ongoing monitoring, you should register the transfer with the transfers/sent endpoint.

The list of assets that KYT supports appears below. Note that this endpoint only accepts the assets from this list. To send data on additional assets (including assets that KYT may support in the future), use the transfers/sent and transfers/received endpoints.

Register withdrawal addresses

ENDPOINT

POST /v1/users/{userId}/withdrawaladdresses

This endpoint posts a withdrawal addresses and risk ratings for a single User ID.

The following is an example cURL request to register a Bitcoin Withdrawal Address of 1MCPcGbnrv4Uv9HcrjoQwzJaEFGrwzE6Pk for user BTC_01:

curl -X POST 'https://test.chainalysis.com/api/kyt/v1/users/BTC_01/withdrawaladdresses' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --data '[{"asset": "BTC", "address": "1MCPcGbnrv4Uv9HcrjoQwzJaEFGrwzE6Pk"}]'

Path parameters

Parameter Type Required Description
userId String Yes The userId to associate with the withdrawal address.

Query parameters

Parameter Type Required Description
bulkImport Boolean No Determines whether to register withdrawal addresses in bulk. You can submit either true or false. If set to true, no real-time response is returned and the request executes faster. We suggest using this parameter if you do not require the real-time response. There is a limit of 100 items when bulkImport is false or not specified and 1000 items when bulkImport is true.

If using bulkImport, it should be passed in as a parameter in the URL, not sent in the request body:

https://test.chainalysis.com/api/kyt/v1/users/BTC_01/withdrawaladdresses?bulkImport=true

Request body schema

Property Type Required Description
asset String Yes The asset to screen. The value must be the asset's symbol, i.e., BTC for Bitcoin, ETH for Ether, UNI for Uniswap.
address String Yes The asset's address used to determine counterparty risk.

Response schema

The following is an example JSON response body from the above command:

{
  "asset": "BTC",
  "address": "1MCPcGbnrv4Uv9HcrjoQwzJaEFGrwzE6Pk",
  "cluster": {
    "name": "Coinbase",
    "category": "Exchange"
  },
  "rating": "lowRisk",
  "customAddress": null,
  "chainalysisIdentification": null
}

The following is an example JSON response body for an unknown recipient:

{
  "asset": "BTC",
  "address": "1MCPcGbnrv4Uv9HcrjoQwzJaEFGrwzE6Pk",
  "cluster": null,
  "rating": "unknown",
  "customAddress": null,
  "chainalysisIdentification": null
}

The following is an example JSON response body for a Custom Address:

{
   "asset": "BTC",
   "address": "1LRtBLSGLnhnhXiWenZWYkWZJnxZo282Ug",
   "cluster": null,
   "rating": "highRisk",
   "customAddress": {
       "addressName": "XYZ Darknet Market",
       "description": "Example description of darknet market",
       "categoryName": "darknet market"
   },
   "chainalysisIdentification": null
}

The following is an example JSON response body for a Chainalysis Identification:

{
  "asset": "LTC",
  "address": "LaizKtS5DUhPuP1nTQcc83MS7HwK6vk85z",
  "cluster": {
      "name": "Gatecoin.com",
      "category": "exchange"
  },
  "rating": "highRisk",
  "customAddress": null,
  "chainalysisIdentification": {
      "addressName": "OFAC SDN Guanghua Zheng",
      "description": "ZHENG, Guanghua (Chinese Traditional: 鄭广華; Chinese Simplified: 郑广华); DOB 04 Nov 1955; POB Shanghai, China; nationality China; citizen China; Email Address zhenguanghua1955@outlook.com; alt. Email Address zhenguanghua1955@gmail.com; Gender Male; Passport E51809923 (China) issued 25 May 2015 expires 24 May 2025; Identification Number 310108195511041616 (China); Chinese Commercial Code 6774 1639 5478 (individual) [SDNTK]. https://www.treasury.gov/resource-center/sanctions/OFAC-Enforcement/Pages/20190821.aspx",
      "categoryName": "sanctions"
  }
}

A successful request will return the following JSON response for known recipients.

Property Type Description
asset String The asset associated with the withdrawal address. The value is the asset or token's symbol, e.g. BTC, ETH, UNI, etc.
address String The asset's withdrawal address.
cluster Object or null The identification of a group of addresses estimated by Chainalysis to be controlled by a single entity. This value will be null if the cluster has not yet been identified.
cluster.name String The name of the named cluster.
cluster.category String The category of the named cluster.
rating String The risk rating of the known recipient address.
customAddress Object or null An address you've uploaded through the KYT UI that allows you to receive alerts on activity. This value will be null if not applicable.
customAddress.addressName String The name you've given to the Custom Address in the CSV file.
customAddress.description String The description you've provided for the Custom Address in the CSV file.
customAddress.categoryName String The category name you provided for the Custom Address in the CSV file.
chainalysisIdentification Object or null A Chainalysis Identified Address, representing an address-level identification that is part of a larger cluster. This value will be null if not applicable.
chainalysisIdentification.addressName String The name designated to the Chainalysis Identification.
chainalysisIdentification.description String The OSINT from the Chainalysis Identification.
chainalysisIdentification.categoryName String The category of the Chainalysis Identification.

Note that the responses are not mutually exclusive. For example, you can have a known or unknown recipient and a Custom Address and/or a Chainalysis Identification.

Retrieve withdrawal addresses

ENPOINT

GET /v1/users/{userId}/withdrawaladdresses

This endpoint retrieves all withdrawal addresses and risk ratings for a single User ID.

The following is an example cURL request to list all Withdrawal Addresses for user BTC_01:

curl -X GET 'https://test.chainalysis.com/api/kyt/v1/users/BTC_01/withdrawaladdresses' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json'

Path parameters

Parameter Type Required Description
userId String Yes The userId to retrieve withdraw addresses for.

Query parameters

Parameter Type Required Description
limit Integer No A limit on the number of objects returned.
offset Integer No The position of the first object returned in the response. The default is 0, which starts the page at the first result.

Request body schema

This call has no accompanying request body.

Response schema

The following is an example JSON response body for the above command:

{
  "total": 100,
  "limit": 25,
  "offset": 3,
  "data": [
    {
      "asset": "BTC",
      "address": "1MCPcGbnrv4Uv9HcrjoQwzJaEFGrwzE6Pk",
      "cluster": {
        "name": "Coinbase",
        "category": "Exchange"
      },
      "customAddress": null,
      "chainalysisIdentification": null,
      "rating": "lowRisk",
    },
    ...
  ]
}

The following is an example JSON response body for a Custom Address:

{
    "limit": 100,
    "offset": 0,
    "total": 1,
    "data": [
        {
            "asset": "BTC",
            "address": "12gzta6sTonaMy5mozWhStMMSet1FxFA7L",
            "cluster": null,
            "customAddress": {
                "addressName": "Darknet",
                "description": "User is operating store on darknet market",
                "categoryName": "darknet market"
            },
            "chainalysisIdentification": null,
            "rating": "highRisk"
        }
    ]
}

The following is an example JSON response body for a Chainalysis Identification:

{
    "limit": 100,
    "offset": 0,
    "total": 1,
    "data": [
        {
            "asset": "LTC",
            "address": "LaizKtS5DUhPuP1nTQcc83MS7HwK6vk85z",
            "cluster": {
                "name": "Gatecoin.com",
                "category": "exchange"
            },
            "customAddress": null,
            "chainalysisIdentification": {
                "addressName": "OFAC SDN Guanghua Zheng",
                "description": "ZHENG, Guanghua (Chinese Traditional: 鄭广華; Chinese Simplified: 郑广华); DOB 04 Nov 1955; POB Shanghai, China; nationality China; citizen China; Email Address zhenguanghua1955@outlook.com; alt. Email Address zhenguanghua1955@gmail.com; Gender Male; Passport E51809923 (China) issued 25 May 2015 expires 24 May 2025; Identification Number 310108195511041616 (China); Chinese Commercial Code 6774 1639 5478 (individual) [SDNTK]. https://www.treasury.gov/resource-center/sanctions/OFAC-Enforcement/Pages/20190821.aspx",
                "categoryName": "sanctions"
            },
            "rating": "highRisk"
        }
    ]
}

A successful request will return the following JSON response for a known recipient.

Property Type Description
limit Integer The limit of the data set.
offset Integer The offset of the data set.
total Integer The total number of results in the data set.
data Array An array containing address information.
data.asset String The asset associated with the withdraw address.
data.address String The asset withdraw address.
data.cluster Object or null The identification of a group of addresses estimated by Chainalysis to be controlled by a single entity. This value will be null if the cluster has not yet been identified.
data.cluster.name String The name of the named cluster.
data.cluster.category String The category of the named cluster, i.e., Exchange.
data.customAddress Object or null An address you've uploaded through the KYT UI that allows you to receive alerts on activity. This value will be null if not applicable.
data.customAddress.addressName String The name you've given to the Custom Address in the CSV file.
data.customAddress.description String The description you've provided for the Custom Address in the CSV file.
data.customAddress.categoryName String The category name you provided for the Custom Address in the CSV file.
data.chainalysisIdentification Object or null A Chainalysis Identified Address, representing an address-level identification that is part of a larger cluster. This value will be null if not applicable.
data.chainalysisIdentification.addressName String The name designated to the Chainalysis Identification.
data.chainalysisIdentification.description String The OSINT from the Chainalysis Identification.
data.chainalysisIdentification.categoryName String The category of the Chainalysis Identification.
data.rating String The risk rating of the known recipient address.

Delete withdrawal addresses

ENPOINT

DELETE /v1/users/{userId}/withdrawaladdresses

This endpoint deletes a specific Withdrawal Address for a given user.

The following is an example cURL request to delete a Bitcoin Withdrawal Address of 1MCPcGbnrv4Uv9HcrjoQwzJaEFGrwzE6Pk for user BTC_01:

curl -X DELETE 'https://test.chainalysis.com/api/kyt/v1/users/BTC_01/withdrawaladdresses/BTC/1MCPcGbnrv4Uv9HcrjoQwzJaEFGrwzE6Pk' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json'

Path parameters

Parameter Type Required Description
userId String Yes The userId to retrieve withdraw addresses for.

Request body schema

Property Type Required Description
asset String Yes The asset name associated with the withdraw address. The value must be the asset or token's symbol, e.g., BTC for Bitcoin, ETH for Ether, UNI for Uniswap.
address String Yes The asset's withdraw address associated with the userId requested.

Response schema

The above command returns an empty JSON response body.

The call has an empty Response Body. ie. a zero byte response, indicated by a response header Content-Length: 0.

Deposit addresses

These endpoints allow you to register, retrieve, or delete a cryptocurrency address for a given user that receives fund into your organization.

POST /v1/users/{userId}/depositaddresses

GET /v1/users/{userId}/depositaddresses

DELETE /v1/users/{userId}/depositaddresses/{asset}/{address}

These endpoints are not currently required for integration. For ongoing monitoring, you should register transfers with the transfers/sent and transfers/received endpoints.

Note: In the future, KYT will be able to detect deposits (but not withdrawals) based on the deposit address. While this endpoint is not currently required for monitoring or integration, you can implement it now for use with this upcoming functionality.

The list of assets that KYT supports appears below. Note that this endpoint only accepts the assets from this list. To send data on additional assets (including assets that KYT may support in the future), use the transfers/sent and transfers/received endpoints.

Register deposit addresses

ENDPOINT

POST /v1/users/{userId}/depositaddresses

The following is an example cURL request to register a Bitcoin deposit address of 1MCPcGbnrv4Uv9HcrjoQwzJaEFGrwzE6Pk for user BTC_01:

curl -X POST 'https://test.chainalysis.com/api/kyt/v1/users/BTC_01/depositaddresses' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --data '[{"asset": "BTC", "address": "1MCPcGbnrv4Uv9HcrjoQwzJaEFGrwzE6Pk"}]'

Path parameters

Parameter Type Required Description
userId String Yes The userId to associate with the deposit address.

Request body schema

Property Type Required Description
asset String Yes The asset to associate with the deposit address.
address String Yes The deposit address to be associated with the userId and asset.

Response body

The above command returns an empty JSON response.

The response will be empty, i.e. a zero byte response, indicated by a response header Content-Length: 0.

Retrieve deposit addresses

ENDPOINT

GET /v1/users/{userId}/depositaddresses

Retrieves all deposit addresses for a single User ID.

The following is an example cURL request to list all deposit addresses for user BTC_01:

curl -X GET 'https://test.chainalysis.com/api/kyt/v1/users/BTC_01/depositaddresses' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json'

Path parameters

Parameter Type Required Description
userId String Yes The userId from which you wish to retrieve the deposit addresses.

Query parameters

Parameter Type Required Description
limit Integer No A limit on the number of objects returned.
offset Integer No The position of the first object returned in the response. The default is 0, which starts the page at the first result.

Request body

This call has no accompanying request body.

Response body

The following is an example JSON response body from the above command:

{
  "total": 1000,
  "limit": 0,
  "offset": 0,
  "data": [
    {
      "asset": "BTC",
      "address": "1MCPcGbnrv4Uv9HcrjoQwzJaEFGrwzE6Pk"
    },
    {...}
  ]
}

A successful request will return the following JSON response and properties for a given userId.

Property Type Description
total Integer The total number of results in the data set.
limit Integer The limit of the data set.
offset Integer The offset of the data set.
data Array An array that contains the deposit address information
data.asset String The asset associated with the deposit address for the user.
data.address String The deposit address associated with the user.

Delete deposit addresses

ENDPOINT

DELETE /v1/users/{userId}/depositaddresses/{asset}/{address}

The following is an example cURL request to delete an associated Bitcoin deposit address of 1MCPcGbnrv4Uv9HcrjoQwzJaEFGrwzE6Pk for user BTC_01:

curl -X DELETE 'https://test.chainalysis.com/api/kyt/v1/users/BTC_01/depositaddresses/BTC/1MCPcGbnrv4Uv9HcrjoQwzJaEFGrwzE6Pk' \
--header 'Token: <API_KEY>' \
--header 'Accept: application/json'

This endpoint deletes the associated deposit address for a single User ID.

Path parameters

Parameter Type Required Description
userId String Yes The userId associated with the deposit address.
asset String Yes The asset associated with the deposit address.
address String Yes The deposit address to be deleted.

Request body

This call has no accompanying request body.

Response body

The response will be empty, ie. a zero byte response, indicated by a response header Content-Length: 0.

Users

These endpoints allow you to retrieve either all your users or a single user, as well as rename a user.

GET /v1/users/

GET /v1/users/{userId}

POST /v1/users/rename

Users are aggregations of transfers, tagged by User ID. Users in KYT should map 1:1 to users on your platform. Analyzing risk at a user level allows you to compare all the historical transfers made by a user to their current transfer.

The Users endpoint generates risk score reports for all users submitted to Chainalysis KYT. The endpoint supports both a summary format of all users and detailed reporting on specific users when passed a corresponding user ID. You are also able to rename User IDs via the API.

In determining User IDs, it is important to keep the following information in mind:

Get all users

ENDPOINT

GET /v1/users/

This endpoint retrieves and lists all User IDs in your KYT system.

The following is an example cURL request to list all User IDs in the KYT system:

curl -X GET 'https://test.chainalysis.com/api/kyt/v1/users/' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json'

Query parameters

Parameter Type Required Description
limit Integer No Places a limit on the number of returned user objects.
offset Integer No The position of the first user object returned in the response. The default is 0, which starts the page at the first result.

Response schema

The following is an example JSON response body from the above command:

{
  "limit": 100,
  "offset": 0,
  "total": 127,
  "data": [
    {
      "userId": "new_user_01",
      "score": "green",
      "lastActivity": "2021-01-06T13:49:34.013Z",
      "scoreUpdatedDate": "2021-07-29T21:20:18.008030Z",
      "riskScore": "LOW"
    },
    {...}
  ]
}

The response body will be a brief summary of the list of User IDs in the Chainalysis KYT system.

score is based on the legacy user risk model, while riskScore reflects the current model that was implemented in late May 2020. We recommend using the riskScore property going forward. Find more information about the user risk model here (login required).

A successful request will return the following JSON response and properties for all users.

Property Type Description
total Integer The total number of user objects returned.
limit Integer An echo back of the limit query parameter.
offset Integer An echo back of the offset query parameter.
data Array An array containing user data.
data.userId String The User ID of the user.
data.score String The score of the User ID as green, amber, or red. Based on the legacy user risk model.
data.lastActivity String The timestamp of the User ID's last tracked activity, in the UTC ISO 8601 format.
data.scoreUpdatedDate String The timestamp when the score was last calculated, in the UTC ISO 8601 format. This field will update whenever activity occurs that could affect the user risk score, including: a new transfer is registered, a new alert is generated, or an alert status is changed.
data.riskScore String The overall score of the User ID as LOW, MEDIUM, HIGH, or SEVERE. Based on the new user risk model. We recommend using this property going forward.

Note: If a user is created in KYT but has no associated transfers or activity, score, lastActivity, scoreUpdatedDate, and riskScore will return withnull values.

Get a single user by {userId}

ENDPOINT

GET /v1/users/{userId}

This endpoint retrieves detailed information on a single user in the Chainalysis KYT system.

The following is an example cURL request to list a single User ID, BTC_01, in the KYT system:

curl -X GET 'https://test.chainalysis.com/api/kyt/v1/users/new_user_01' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json'

Path parameters

Parameter Type Required Description
userId String Yes The unique KYT identifier of the user.

Response schema

The following is an example JSON response body from the above command:

{
  "userId": "new_user_01",
  "score": "green",
  "lastActivity": "2021-01-06T13:49:34.013Z",
  "scoreUpdatedDate": "2021-07-29T21:20:18.008030Z",
  "riskScore": "LOW",
  "creationDate": "2017-09-23T11:44:51.00Z",
  "exposureDetails": [
    {
      "cluster": {
        "name": "Coinbase.com",
        "category": "exchange"
      },
      "sentIndirectExposure": 25,
      "sentDirectExposure": 0,
      "receivedIndirectExposure": 25,
      "receivedDirectExposure": 0
    }
  ]
}

A successful request will return the following JSON response and properties for all users.

Property Type Description
userId String The User ID of the user.
score String The score of the User ID as green, amber, or red. Based on the legacy user risk model.
lastActivity String The timestamp of the user's last tracked activity, in the UTC ISO 8601 format.
scoreUpdatedDate String The timestamp when the score was last calculated, in the UTC ISO 8601 format. This field will update whenever activity occurs that could affect the user risk score, including: a new transfer is registered, a new alert is generated, or an alert status is changed.
riskScore String The overall score of the User ID as LOW, MEDIUM, HIGH, or SEVERE. Based on the new user risk model. We recommend using this property going forward.
creationDate String or null The timestamp when the user was created in the KYT system, in the UTC ISO 8601 format.
exposureDetails Array An array of details about the user's exposure to risk.
exposureDetails.cluster Object The identification of a group of addresses estimated by Chainalysis to be controlled by a single entity.
exposureDetails.cluster.name String The name of the named cluster.
exposureDetails.cluster.category String The category the named cluster belongs to.
exposureDetails.sentIndirectExposure Number Total Sent Indirect Exposure for the user in USD.
exposureDetails.sentDirectExposure Number Total Sent Direct Exposure for the user in USD.
exposureDetails.receivedIndirectExposure Number Total Received Indirect Exposure for the user in USD.
exposureDetails.receivedIndirectExposure Number Total Sent Indirect Exposure for the user in USD.

Note: If a user is created in KYT but has no associated transfers or activity, score, lastActivity, scoreUpdatedDate, and riskScore will return withnull values and the exposureDetails array will be empty.

score is based on the legacy user risk model, while riskScore reflects the current model that was implemented in late May 2020. We recommend using the riskScore property going forward. Find more information about the user risk model here (login required).

Rename users

ENDPOINT

POST /v1/users/rename

This endpoint renames a userId in the KYT system. The request supports up to 1000 renames at a time.

An example request for renaming a User ID from test_1 to user_1 in the KYT system using curl would look like the following.

curl -X POST 'https://test.chainalysis.com/api/kyt/v1/users/rename' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json'
  --header 'Content-Type: application/json' \
  --data '[
      {
        "from": "test_1",
        "to": "user_1"
      },
      {
        "from": "test_2",
        "to": "user_2"
      }
]'

The above command returns an empty JSON response.

Request body schema

Property Type Description
from String The userId that you wish to rename.
to String The new userId that you wish to use. This must be a new userId and not currently exist in the KYT system. Using an existing userId will return a 400 error.

Response schema

The endpoint returns an empty JSON response.

Alerts

These endpoints allow you to retrieve alerts, assign an alert, update an alert status or comment, and retrieve an alert's history.

GET /v1/alerts/

POST /v1/alerts/{alertIdentifier}/assignment

POST /v1/alerts/{alertIdentifier}/statuses

GET /v1/alerts/{alertIdentifier}/activity

Alerts in KYT are raised for risky transfers on your platform. A single transfer can trigger multiple alerts. Alert levels include Severe, High, Medium, and Low, and are based on factors such as category, service, direct versus indirect exposure, direction, and amount.

Get all alerts

This endpoint retrieves information on all alerts that have been raised within your organization.

ENDPOINT

GET /v1/alerts/

The following is an example cURL request to retrieve all the alerts in your KYT system:

curl -X GET 'https://test.chainalysis.com/api/kyt/v1/alerts/' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json'

The following is an example cURL request to retrieve all Bitcoin alerts with a high alert level:

curl -X GET 'https://test.chainalysis.com/api/kyt/v1/alerts/?asset=BTC&level=HIGH' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json'

The following is an example cURL request to retrieve all Bitcoin alerts with a severe alert level for a particular user:

curl -X GET 'https://test.chainalysis.com/api/kyt/v1/alerts/?level=SEVERE&userId=User017&asset=BTC' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json'

Query parameters

Parameter Type Required Description
asset String No Returns all alerts for a specific asset.
createdAt_gte String No Returns all alerts created greater than or equal to a specific date and time. Must be in the UTC ISO 8601 format.
createdAt_lte String No Returns all alerts created less than or equal to a specific date and time. Must be in the UTC ISO 8601 format.
alertStatusCreatedAt_gte String No Returns all alert statuses and comments greater than or equal to a specific date and time. Must be in the UTC ISO 8601 format.
alertStatusCreatedAt_lte String No Returns all alert statuses and comments less than or equal to a specific date and time. Must be in the UTC ISO 8601 format.
level String No Filters alerts by alert level as SEVERE, HIGH, MEDIUM, and LOW (values must be in caps).
transferReference String No Returns all alerts associated with a specific transfer reference. See Transfer Reference Formats sorted by timestamp, createdAt, level, and alertAmountUsd. For example, createdAt sorts alerts by the date the alert was created. See below for more information about the sort parameter.
userId String No Returns all alerts for a specific user.
limit Integer No Places a limit on the number of returned alert objects.
offset Integer No Indicates the position of the first alert object returned in the response. The default is 0, which starts the page at the first result.
sort String No Used to sort the order which alerts are returned in the response. You can sort by timestamp, level, alertAmountUsd, alertStatusCreatedAt, assignedTo, assignedBy, and assignedAt. Your parameter must include a direction specifier of either desc or asc preceded by a URL-encoded space character. For example: sort=timestamp%20desc.


Using the createdAt_gte and createdAt_lte parameters
You can use createdAt_gte and createdAt_lte to specify a date range. You can also keep track of your newest alerts by querying for all alerts after a given time (createdAt_gte), store the time you made the query, then query it again later for all alerts since the initial query.

Using the alertStatuscreatedAt_gte and alertStatuscreatedAt_lte parameters
You can use these parameters to specify a date range for the alert status and periodically retrieve alerts with recent status changes or comments. You can keep track of alerts with recent status and comment updates by storing the timestamp of when you made the query, then using it in subsequent queries.

Using the sort parameter
The sort parameter determines the order that the alerts are returned. You can sort by timestamp, createdAt, level, alertAmountUsd, alertStatusCreatedAt, and the assignedTo, assignedBy, and assignedAt parameters. For example, to return all alerts sorted by amount from highest to lowest value (descending), use: ?sort=alertAmountUsd%20desc.

Get all alerts from a single transfer
To return all alerts on a single transfer, it is recommended to use the userId, asset, and transferReference parameters all at once. In rare circumstances, the same transferReference can exist for multiple assets or multiple users.

Request body schema

This call has no accompanying request body.

Response schema

The following is an example JSON response body from the alerts endpoint:

{
  "total": 1000,
  "limit": 0,
  "offset": 0,
  "data": [
    {
      "alertAmountUsd": 132.50,
      "transactionHash": "b765440e872ab6e2521694d10465415bda4adf8ed7fc2fdafb6d39bd17c5fddf",
      "level": "HIGH",
      "exposureType": "DIRECT",
      "alertStatus": "Flagged",
      "transferReportedAt": "2017-01-05T14:23:00.397Z",
      "alertIdentifier": "a6a5d0f8-9753-11e9-a517-ebce3e967522",
      "service": "Silk Road Marketplace",
      "alertStatusCreatedAt": "2020-01-14T13:57:58.713226Z",
      "transferReference": "b765440e872ab6e2521694d10465415bda4adf8ed7fc2fdafb6d39bd17c5fddf:1",
      "userId": "mtgox_ghosts",
      "alertStatusCreatedBy": null,
      "valid": true,
      "createdAt": "2019-06-17T17:39:41.550575Z",
      "transferOutputAddress": "1DP38CC2kf6ewUDaaVd9nBfuAD8SP15g2T",
      "validity": "VALID",
      "category": "darknet market",
      "transactionIndex": 1,
      "asset": "BTC",
      "direction": "SENT",
      "timestamp": "2011-06-18T08:22:21Z",
      "rule": ">$100 sent directly to darknet market",
      "minThreshold": 100,
      "maxThreshold": null
    },
    ...
  ]
}

The response is sorted by alertStatusCreatedAt by default. Note that when an alert is created, the alertStatus is set to Unreviewed and the alertStatusCreatedAt is set to the time the alert was created.

A successful request will return the following JSON response and properties for all alerts:

Property Type Description
total Integer The total number of alert objects returned.
limit Integer An echo back of the limit query parameter.
offset Integer An echo back of the offset query parameter.
data Array An array containing alert data.
data.alertAmountUsd Integer The amount of the transfer that triggered the alert in USD.
data.transactionHash String The transaction hash of the transfer that triggered the alert.
data.level String The level of the alert as SEVERE, HIGH, MEDIUM, or LOW.
data.exposureType String The type of exposure of the transfer that triggered the alert as DIRECT or INDIRECT.
data.alertStatus String The status of the alert as Unreviewed, In Review, Flagged, No Review, or Dismissed.
data.transferReportedAt String The timestamp when the transfer was registered in KYT, in the UTC ISO 8601 format.
data.alertIdentifier String The alert ID.
data.service String or null The name of the counterparty in the transfer that triggered the alert. Note that the service will be null for indirect exposure alerts, as you can have multiple indirect counterparties contributing to one alert.
data.alertStatusCreatedAt String The timestamp when the alert status was last changed, in the UTC ISO 8601 format.
data.transferReference String The transaction hash and index or output address of the transfer that triggered the alert.
data.userId String The User ID of the user.
data.alertStatusCreatedBy String or null The username of the person in your organization that changed the alert status. This will be null if the alert's statis has not yet been updated.
data.valid Boolean Indicates whether the alert is valid.
data.createdAt String The timestamp when the alert was created, in the UTC ISO 8601 format.
data.transferOutputAddress String The destination address for funds within the transaction.
data.validity String The status of the alert, either VALID, INVALID, or REVALID.
data.category String The alert category.
data.transactionIndex String The 0-indexed number of the transfer in the transaction that caused the alert.
data.asset String The asset used in the transfer.
data.direction String The direction of the transfer that triggered the alert as SENT or RECEIVED.
data.timestamp String The time when the transfer on the blockchain that caused the alert, in the UTC ISO 8601 format.
data.rule String An explanation of why the transfer caused an alert.
data.minThreshold Integer The minimum amount in USD of the alert rule.
data.maxThreshold Integer or null The maximum amount in USD of the alert rule. This value will be null if a maxThreshold is not set for the rule.
data.assignedTo String The email address of the user assigned to the alert.
data.assignedAt String The timestamp when the alert was last assigned, in the UTC IS0 8601 format.
data.assignedBy String The email address of the user who assigned the alert.

Assign an alert

This endpoint assigns an alert to a member of your organization.

ENDPOINT

POST /v1/alerts/{alertIdentifier}/assignment

The following is an example cURL request to assign someone to an alert:

curl -X POST 'https://test.chainalysis.com/api/kyt/v1/alerts/{alertIdentifier}/assignment' \
--header 'Token: <API_KEY' \
--header 'Content-Type: application/json' \
--data '{"alertAssignee":"user.email@example.com"}'

Path parameters

Parameter Type Required Description
alertIdentifier String Yes A unique identifier that references the alert.

Request body schema

Property Type Required Description
alertAssignee String Yes The email address of the user you wish to assign the alert to. Note: to unassign an alert, return this value with null.

Response schema

The following is an example JSON response body from the above command:

{
    "alertIdentifier": "bdc1f806-f5ad-11eb-8540-2b716172c24d",
    "assignedBy": "admin.email@example.com",
    "assignedTo": "user.email@example.com",
    "alertAssignedAt": "2021-08-11T21:21:59.806Z"
}

A successful request will return the following JSON response and properties for the given alert:

Property Type Description
alertIdentifier String A unique identifier that references the alert.
assignedBy String The email address of the user who assigned the alert.
assignedTo String The email address of the user assigned to the alert.
alertAssignedAt String The timestamp when the alert was assigned, in the UTC IS0 8601 format.

Post alert statuses and comments

This endpoint sends and changes an alert status and comment you provide for a given alert.

ENDPOINT

POST /v1/alerts/{alertIdentifier}/statuses

An example request to send an alert status and comment in the KYT system using curl would look like the following.

curl -X POST 'https://test.chainalysis.com/api/kyt/v1/alerts/1a895b44-2a78-11eb-978c-5bb1dd49843e/statuses' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json' \
  --data '{
    "status":"No Review",
    "comment":"Test comment"
}'

Path parameters

Parameter Type Required Description
alertIdentifier String Yes A unique identifier that references the alert.

Request body schema

Property Type Required Description
status String Yes Define the alert status, whether Unreviewed, In Review, Flagged, No Review, or Dismissed.
comment String No Include the comment you want to specify for the given alert.

Response schema

The following is an example JSON response body from the above command:

{
    "alertIdentifier": "1a895b44-2a78-11eb-978c-5bb1dd49843e",
    "alertStatus": "No Review",
    "alertComment": "Test comment",
    "alertStatusCreatedBy": "user@example.com",
    "alertStatusCreatedAt": "2021-05-24T19:36:08.593571Z"
}

A successful request will return the following JSON response and properties for the given alert:

Property Type Description
alertIdentifier String A unique identifier that references the alert.
alertStatus String The alert status you submitted in your request body whether Unreviewed, In Review, Flagged, No Review, or Dismissed.
alertComment String or null The comment you submitted in your request body. This value will be null if no comment was left.
alertStatusCreatedBy String The email address of the KYT account that changed the alert status and/or added a comment.
alertStatusCreatedAt String The timestamp when the the alert status was created, in the UTC ISO 8601 format.

Get alert statuses and comments

This endpoint retrieves an alert's comment and status history.

ENDPOINT

GET /v1/alerts/{alertIdentifier}/activity

The following is an example cURL request to retrieve an alert's comment and status history.

curl -X POST 'https://test.chainalysis.com/api/kyt/v1/alerts/17124a04-cadf-11eb-9921-0bdd1e279318/statuses' \
  --header 'Token: <API_KEY>'

Path parameters

Parameter Type Required Description
alertIdentifier String Yes A unique identifier that references the alert.

Request body schema

This call has no accompanying request body.

Response schema

The following is an example JSON response body from the above command:

{
    "alertIdentifier": "17124a04-cadf-11eb-9921-0bdd1e279318",
    "statusItems": [
        {
            "alertStatusIdentifier": "17124a04-cadf-11eb-9921-0bdd1e279318-10857095",
            "status": "Unreviewed",
            "updatedBy": "user1@yourCrytpoService.com",
            "comment": ">$500 received indirectly from scam. Should review ASAP.",
            "updated": "2021-07-01T06:42:23.881301Z"
        },
        {
            "alertStatusIdentifier": "17124a04-cadf-11eb-9921-0bdd1e279318-11554113",
            "status": "Flagged",
            "updatedBy": "user2@yourCrytpoService.com",
            "comment": "This is a definitely a scam.",
            "updated": "2021-07-21T21:57:33.343724Z"
        }
    ]
}

A successful request will return the following JSON response and properties for the given alert:

Property Type Description
alertIdentifier String A unique identifier that references the alert.
statusItems Array An array that contains the alert status items. If the array is empty, the alert status has never been been updated or the alert has not yet been commented upon.
statusItems.alertStatusIdentifier String A unique identifier that references the alert status.
statusItems.status String The alert's status at the time of update, either Unreviewed, In Review, Flagged, No Review, or Dismissed.
statusItems.updatedBy String The email address of the KYT account that updated the alert's status and/or comment.
statusItems.comment String The alert's comment at the time of update.
statusItems.updated String The timestamp when the alert's status and/or comment was updated, in the UTC ISO 8601 format.

Resources

Error handling

All successful requests to the KYT API will return a 200 response code.

The KYT API uses the following error codes to identify a bad request:

Error code Meaning Description
400 Bad request May refer to using testnet data, or data in an illegal format - for example non-valid JSON or an object instead of a list.
403 Forbidden May indicate that your API Key is expired or not being sent properly as the value of the Token HTTP header.
404 Not found Indicates that you have attempted to reach a page which does not exist - for example either a nonexistent endpoint or a user that does not exist.
406 Not acceptable Means you are requesting a response format that the API cannot produce. We currently only support JSON output.
409 Conflict Indicates that there is a conflict of association with another user, such as overlapping addresses.
500 Internal server error Indicates an error with the server. For POST /transfers/sent and /transfers/received, you should try the request again to ensure the transaction has been screened by Chainalysis. Contact support@chainalysis.com with questions.
503 Service unavailable error Indicates that the server may be unavailable or not ready to handle the request. For POST /transfers/sent and /transfers/received, you should try the request again later to ensure the transaction has been screened by Chainalysis. Contact support@chainalysis.com with questions.

Data types

Timestamp

2017-09-23T21:44:51.01Z

2017-09-23T21:44:51.01+00.00

Unless specified otherwise, the KYT API returns all timestamps in the ISO 8601 format and adheres to the UTC time standard. Sometimes UTC is indicated by +00.00, Z, or in cases where no timezone information is provided, the timestamp is still UTC. Please ensure your system can parse the ISO 8601 format. Most modern languages and libraries will handle ISO 8601 timestamps without issue.

Whenever submitting data to KYT, please ensure your timestamps adhere to the UTC time standard.

Glossary

The Chainalysis KYT API uses the following terms for all Asset types tracked:

Address

An Address is a cryptographic hash of a Public and Private key pair that holds value for a given cryptocurrency or token Asset. Bitcoin and other cryptocurrencies that use UTXO based transactions use what is called an "Address". Ethereum and other currencies that use Account based transactions use what is known as an "Account".

Asset

An Asset in KYT is the cryptocurrency or token being tracked (Bitcoin, Tether, etc).

A current list of supported assets by the KYT API can retrieved using the assets endpoint. You can also send data for additional assets and as soon as KYT fully supports the coin, the system will automatically backfill any data you've sent. A list of all assets you can send appears below.

Transfer

A Transfer is the part of a transaction that transfers value from one address to another address. For some asset types like Ethereum each transaction is one transfer, but for asset types like Bitcoin a transaction can contain multiple transfers.

Deposit Address

Deposit addresses are addresses that you manage on behalf of your users, where they can deposit value to your service. A deposit address is always associated with exactly one user, and should never be reused for another user, but a user can have multiple deposit addresses. Deposit addresses can be registered even before they have received value.

Withdrawal Address

Withdrawal addresses are foreign Bitcoin addresses outside your service, to which the user intends to send value. Multiple users might send value to the same withdrawal addresses.

Withdrawal addresses should be registered as early as possible for best results, for instance right when the address is pasted into a withdrawal form. When registering a withdrawal address a real-time rating of the address as a recipient of value is returned. This allows you to take action on suspicious behavior immediately.

Output Address

Output addresses are the destination addresses of where cryptocurrency is sent. A correct output address depends on whether the transfer is RECEIVED or SENT.

For RECEIVED transfers, the output address is internal to your service (the address where your service received funds).

For SENT transfers, the output address is external to your service (the address where your service sent funds).

Sent Transfer

Sent transfers are the value that your service sends on behalf of a user when the user makes a withdrawal from your service. Regardless of asset type, the transfer will be part of a transaction. A transfer can be registered as soon as its transaction has been created, and even before it has been broadcast to a blockchain. Once a transfer has been registered, KYT will track it.

For some asset types, the transfer will have to “settle” before it is processed by KYT; in Bitcoin we will wait until the transaction is 5 blocks deep to make sure the risk score reflects stable data. Registered transfers that remain unsettled for too long will automatically discard the registered transfer after a timeout of several days.

Received Transfer

Received transfers are the value transfers that your service receives on behalf of a user into their deposit address. Received transfers are registered and processed according to the same rules as sent transfers.

User IDs

All user activity is recorded in the KYT API under a user ID. The API allows you to use any unique user ID within the following constraints:

KYT

KYT is the abbreviation for Know Your Transaction.

Cluster

A cluster is a collection of cryptocurrency addresses that Chainalysis has identified to be controlled by one entity

UTXO

UTXO is the abbreviation for Unspent Transaction Output. UTXO is the method that some cryptocurrencies use to keep track of transactions in their transaction ledger in the Blockchain. UTXO is the amount of unspent cryptocurrency that can be spent in new transactions.

Examples of UXTO transaction based cryptocurrencies include:

Account

An Account, sometimes known as a Balance, is the method that some cryptocurrencies and tokens use to keep track of transactions in their transaction ledger in the Blockchain. The Account transaction method keeps track of the total currency in the Account in a global state. This transaction method allows for Smart Contracts to be created that keep track of different states to perform different tasks based on the state.

Examples of Account transaction based cryptocurrencies include:

Assets

HTTP request

An example request for listing all assets.

curl -X GET 'https://test.chainalysis.com/api/kyt/v1/assets' \
  --header 'Token: <API_KEY>' \
  --header 'Accept: application/json'

The above command returns JSON structured as below. Note that the "data" array would typically display the data for all assets but has been truncated for this example.

[
    {
        "symbol": "AUDX",
        "name": "Etoro AUD"
    },
    {
        "symbol": "BCH",
        "name": "Bitcoin Cash"
    },
    {
        "symbol": "BNB",
        "name": "Binance Coin"
    },
    {
        "symbol": "BTC",
        "name": "Bitcoin"
    }
    ...
]

GET https://test.chainalysis.com/api/kyt/v1/assets

Returns a list of cryptocurrencies supported in the KYT API and the corresponding symbol.

For each asset, we return the asset’s symbol in canonical form, ie. BTC, not btc or btx, and the name of the asset, ie. Bitcoin. See a list of all supported assets below.

Mature assets

You can register transactions of mature assets with either the v2 or v1 registration endpoints with only a transferReference. With a correct transferReference property, KYT backfills the transaction information with blockfhain data. To learn more about how to construct the transferReference property, see the syntax guide.

The following is a list of current mature assets:

Symbol Asset ERC-20 token? Transfer format reference
AAVE Aave ✓ "transaction hash:output address"
ALGO Algorand "transaction hash:output address"
AMPL Ampleforth ✓ "transaction hash:output address"
AUDX Etoro AUD ✓ "transaction hash:output address"
BAT Basic Attention Token ✓ "transaction hash:output address"
BCH Bitcoin Cash Output address format
"transaction hash:output address"

Or

Output index format
"transaction hash:output index"
BNB Binance Coin (ERC-20) ✓ "transaction hash:output address"
BNT Bancor ✓ "transaction hash:output address"
BSV Bitcoin SV "transaction hash:output address"
BTC Bitcoin Output address format
"transaction hash:output address"

Or

Output index format
"transaction hash:output index"
BUSD Binance USD ✓ "transaction hash:output address"
CADX Etoro CAD ✓ "transaction hash:output address"
cBAT Compound Basic Attention Token ✓ "transaction hash:output address"
cDAI Compound Dai ✓ "transaction hash:output address"
CEL Celsius ✓ "transaction hash:output address"
CELR Celer Network ✓ "transaction hash:output address"
cETH Compound Ethereum ✓ "transaction hash:output address"
CGT CACHE Gold ✓ "transaction hash:output address"
CHFX Etoro CHF ✓ "transaction hash:output address"
CHZ chiliZ ✓ "transaction hash:output address"
CNYX Etoro CNY ✓ "transaction hash:output address"
COMP Compound ✓ "transaction hash:output address"
cREP Compound Augur ✓ "transaction hash:output address"
CRO Crypto.com (CRO) ✓ "transaction hash:output address"
CRPT Crypterium ✓ "transaction hash:output address"
CRV Curve ✓ "transaction hash:output address"
cSAI Compound Sai ✓ "transaction hash:output address"
cUSDC Compound USD Coin ✓ "transaction hash:output address"
CVC Civic ✓ "transaction hash:output address"
cWBTC Compound Wrapped BTC ✓ "transaction hash:output address"
cZRX Compound ZRX ✓ "transaction hash:output address"
DAI Dai ✓ "transaction hash:output address"
DASH Dash Output address format
"transaction hash:output address"

Or

Output index format
"transaction hash:output index"
DOGE Dogecoin "transaction hash:output address"
DRGN Dragonchain ✓ "transaction hash:output address"
ELF aelf ✓ "transaction hash:output address"
ENG Enigma ✓ "transaction hash:output address"
ENJ Enjin Coin ✓ "transaction hash:output address"
EOS EOS Output address format
"transaction hash:output address"

Or

Output index format
"transaction hash:output index"
ETH Ethereum ✓ "transaction hash:output address"
ETHLend Aave ✓ "transaction hash:output address"
EURS Stasis Euro ✓ "transaction hash:output address"
EURX Etoro EUR ✓ "transaction hash:output address"
FTT FTX Token ✓ "transaction hash:output address"
GBPX Etoro GBP ✓ "transaction hash:output address"
GLDX Etoro GLD ✓ "transaction hash:output address"
GNO Gnosis ✓ "transaction hash:output address"
GNT Golem ✓ "transaction hash:output address"
GUSD Gemini Dollar ✓ "transaction hash:output address"
GYEN GMO Yen ✓ "transaction hash:output address"
HOT Holo Token ✓ "transaction hash:output address"
HT Huobi Token ✓ "transaction hash:output address"
HUSD Hot USD ✓ "transaction hash:output address"
IDRT Rupiah Token ✓ "transaction hash:output address"
JPYX Etoro YEN ✓ "transaction hash:output address"
KCS Kucoin Shares ✓ "transaction hash:output address"
KNC Kyber Network ✓ "transaction hash:output address"
LEO UNUS SED LEO ✓ "transaction hash:output address"
LINK Chainlink ✓ "transaction hash:output address"
LOOM Loom Network ✓ "transaction hash:output address"
LRC LoopringCoin ✓ "transaction hash:output address"
LTC Litecoin Output address format
"transaction hash:output address"

Or

Output index format
"transaction hash:output index"
MANA Decentraland ✓ "transaction hash:output address"
MATIC Matic Network ✓ "transaction hash:output address"
MCO Crypto.com (MCO) ✓ "transaction hash:output address"
MKR Maker ✓ "transaction hash:output address"
MLN Melon ✓ "transaction hash:output address"
MTL Metal ✓ "transaction hash:output address"
NEXO Nexo ✓ "transaction hash:output address"
NMR Numeraire ✓ "transaction hash:output address"
NPXS Pundi X ✓ "transaction hash:output address"
NZDX Etoro NZD ✓ "transaction hash:output address"
OKB Okex Exchange Token ✓ "transaction hash:output address"
OMG OmiseGO ✓ "transaction hash:output address"
OXT Orchid ✓ "transaction hash:output address"
PAX Paxos Standard ✓ "transaction hash:output address"
PAXG Paxos Gold ✓ "transaction hash:output address"
PAY TenX ✓ "transaction hash:output address"
POWR PowerLedger ✓ "transaction hash:output address"
QNT Quant ✓ "transaction hash:output address"
RCN Ripio Credit Network ✓ "transaction hash:output address"
REN Republic ✓ "transaction hash:output address"
RENBTC renBTC ✓ "transaction hash:output address"
RLC iExec Token ✓ "transaction hash:output address"
RUBX Etoro RUB ✓ "transaction hash:output address"
SAI Single Collateral DAI ✓ "transaction hash:output address"
SALT SALT ✓ "transaction hash:output address"
SENT Sentinel ✓ "transaction hash:output address"
SLVX Etoro SLV ✓ "transaction hash:output address"
SNT Status ✓ "transaction hash:output address"
STORJ Storj ✓ "transaction hash:output address"
sUSD SynthetixUSD ✓ "transaction hash:output address"
SUSHI SushiSwap ✓ "transaction hash:output address"
TGBP TrueGBP ✓ "transaction hash:output address"
TUSD TrueUSD ✓ "transaction hash:output address"
UNI UniSwap ✓ "transaction hash:output address"
USDC USD Coin ✓ "transaction hash:output address"
USDEX Etoro USD ✓ "transaction hash:output address"
USDT USD Tether Omni "transaction hash"
USDT_ETH USD Tether Ether ✓ "transaction hash:output address"
VGX Voyager Token ✓ "transaction hash:output address"
WBTC Wrapped Bitcoin ✓ "transaction hash:output address"
WETH Wrapped Ether ✓ "transaction hash:output address"
WTC Waltonchain ✓ "transaction hash:output address"
XAUT Tether Gold ✓ "transaction hash:output address"
XCHF CryptoFranc ✓ "transaction hash:output address"
XRP XRP "transaction hash"

Or

“transaction hash:output address”

The output address is required when there is more than one receiving party, otherwise KYT records the receiving party as the 0 index (the first listed).
YFI Yearn.finance ✓ "transaction hash:output address"
ZEC Zcash Output address format
"transaction hash:output address"

Or

Output index format
"transaction hash:output index"
ZRX 0x ✓ "transaction hash:output address"
ZUSD Z.com USD ✓ "transaction hash:output address"

Pre-growth assets

You can register transactions of pre-growth assets with either the POST /v2/users/{userId}/transfers/ endpoint or the POST /v1/users/{userId}/transfers/{sent-OR-received}/ endpoint, but you will need to submit additional information in the request body. We require additional information (timestamp, asset amount, etc.) since Chainalysis does not backfill pre-growth asset transactions with blockchain data. Once Chainalysis supports the asset, KYT will automatically backfill any data you've sent.

A list of all pre-growth assets appears below. Some ERC-20 tokens may require additional input, which are specified below. All ERC-20 tokens must have a valid transaction hash. UTXO based cryptocurrencies must reference a transaction hash and a corresponding output address or transaction hash index. Read more about transfer formats here.

Note that the response when sending additional assets via the API is an empty JSON object. The KYT API does not validate addresses for coins we do not yet support.

Symbol Asset ERC-20 token? Transfer reference format
1INCH 1inch ✓ transaction hash:output address
1ST Firstblood ✓ transaction hash:output address
2KEY 2key.network ✓ transaction hash:output address
ABT ArcBlock ✓ transaction hash:output address
ABYSS Abyss ✓ transaction hash:output address
ADA Cardano transaction hash:output address
ADD ADD ✓ transaction hash:output address
ADT adToken ✓ transaction hash:output address
ADX AdEx ✓ transaction hash:output address
AE Aeternity transaction hash:output address
AERGO Aergo ✓ transaction hash:output address
AGI SingularityNET ✓ transaction hash:output address
AID AidCoin ✓ transaction hash:output address
AION AION ✓ transaction hash:output address
AKRO Akropolis ✓ transaction hash:output address
ALICE MyNeighborAlice ✓ transaction hash:output address
ALPHA Alpha Finance Lab ✓ transaction hash:output address
AMP Amp ✓ transaction hash:output address
ANKR Ankr ✓ transaction hash:output address
ANT Aragon ✓ transaction hash:output address
API3 API3 ✓ transaction hash:output address
ARDR Ardor transaction hash:output address
ARK Ark transaction hash:output address
ART Maecenas ✓ transaction hash:output address
ASD ASD (AscendEx token) ✓ transaction hash:output address
AST AirSwap ✓ transaction hash:output address
ATD Atidium ✓ transaction hash:output address
ATM Atonomi ✓ transaction hash:output address
ATOM Cosmos transaction hash
AUC Auctus ✓ transaction hash
AUDIO Audius ✓ transaction hash:output address
AVA Travala.com ✓ transaction hash:output address
AVAX Avalanche transaction hash:output address
AVT AVT ✓ transaction hash
AXS Axie Infinity ✓ transaction hash:output address
BADGER Badger DAO ✓ transaction hash:output address
BAL Balancer ✓ transaction hash:output address
BAND Band Protocol ✓ transaction hash:output address
BAX BABB ✓ transaction hash:output address
BBN BBN ✓ transaction hash:output address
BCD Bitcoin Diamond transaction hash:output address
BCI Bitcoin Interest transaction hash:output address
BCPT BlockMason Credit Protocol ✓ transaction hash:output address
BEAM Beam transaction hash:output address
BFT BnkToTheFuture ✓ transaction hash:output address
BIFI Beefy.Finance ✓ transaction hash:output address
BKX Bankex ✓ transaction hash:output address
BLK BlackCoin transaction hash:output address
BLOC Blockcloud ✓ transaction hash:output address
BLT Bloom ✓ transaction hash:output address
BLZ Bluzelle ✓ transaction hash:output address
BNB Binance Native transaction hash:output address
BNB_BNB Binance Coin Binance Chain transaction hash:output address
BNB_BSC Binance Coin Binance Smart Chain transaction hash:output address
BOND BarnBridge ✓ transaction hash:output address
BORA BORA ✓ transaction hash:output address
BOX ContentBox Token ✓ transaction hash:output address
BOXX Blockparty ✓ transaction hash:output address
BRZ BRZ Token ✓ transaction hash:output address
BTC0 Bitcoin Zero transaction hash:output address
BTG Bitcoin Gold transaction hash:output address
BTM Bytom transaction hash:output address
BTS BitShares transaction hash:output address
BTT BitTorrent transaction hash:output address
BTU BTU Protocol ✓ transaction hash:output address
BWX Blue Whale eXchange ✓ transaction hash:output address
BZRX bZx Protocol ✓ transaction hash:output address
CAKE PancakeSwap( transaction hash:output address
CBC CashBet ✓ transaction hash:output address
CBT CommerceBlock ✓ transaction hash:output address
CELO Celo transaction hash:output address
CFI Cofoundit ✓ transaction hash:output address
CGG Chain Guardians ✓ transaction hash:output address
CHR Chromia ✓ transaction hash:output address
CKB Nervos Network transaction hash:output address
CLO Callisto ✓ transaction hash:output address
CMCT Crowd Machine ✓ transaction hash:output address
CND Cindicator ✓ transaction hash:output address
CNHT Tether CNH ✓ transaction hash:output address
CNN CNN Token ✓ transaction hash:output address
COTI COTI transaction hash:output address
CPT Contents Protocol ✓ transaction hash:output address
CREAM Cream Finance ✓ transaction hash:output address
CRU Crust Network transaction hash:output address
CS Credits ✓ transaction hash:output address
CTK CertiK transaction hash:output address
CTPT Contents Protocol ✓ transaction hash:output address
CTSI Cartesi ✓ transaction hash:output address
CTXC Cortex ✓ transaction hash:output address
CUSD Celo Dollar ✓ transaction hash:output address
CUSDT Compound USDT ✓ transaction hash:output address
CVT CyberVein ✓ transaction hash:output address
DADI DADI ✓ transaction hash:output address
DATA Steamr DATAcoin ✓ transaction hash:output address
DCR Decred transaction hash:output address
DEGO Dego Finance ✓ transaction hash:output address
DENT Dent ✓ transaction hash:output address
DGB DIGIBYTE ✓ transaction hash:output address
DGD DigixDAO ✓ transaction hash:output address
DGX Digix Gold Token ✓ transaction hash:output address
DIA DIA ✓ transaction hash:output address
DIEM Facebook Diem transaction hash:output address
DMD Diamond transaction hash:output address
DMT DMarket ✓ transaction hash:output address
DNT district0x ✓ transaction hash:output address
DOCK Dock ✓ transaction hash:output address
DODO DODO ✓ transaction hash:output address
DOT Polkadot transaction hash:output address
DPI DeFi Pulse Index ✓ transaction hash:output address
DT Dragon Token ✓ transaction hash:output address
DTA Data ✓ transaction hash:output address
DTH Dether ✓ transaction hash:output address
DUSK Dusk Network ✓ transaction hash:output address
EDG Edgeless ✓ transaction hash:output address
EDGE DADI ✓ transaction hash:output address
EDO Eidoo ✓ transaction hash:output address
EDR Endor ✓ transaction hash:output address
EGLD Elrond transaction hash:output address
EOX EOX ✓ transaction hash
EPIQ Everipedia ✓ transaction hash:output address
ESS Essentia ✓ transaction hash
ETC Ethereum Classic transaction hash:output address
ETHOS Ethos (now rebranded to Voyager) ✓ transaction hash:output address
ETP Ethereum Platinum ✓ transaction hash
EURT Tether EUR ✓ transaction hash
EVT Ethfinex Voting Token ✓ transaction hash
FEI Fei Protocol ✓ transaction hash:output address
FIL Filecoin transaction hash:output address
FIRO Firo transaction hash:output address
FLM FolmCoin transaction hash:output address
FLOW Flow transaction hash:output address
FOA Foam Token ✓ transaction hash:output address
FOR FORCE transaction hash:output address
FORTH Ampleforth Governance Token ✓ transaction hash:output address
FRONT Frontier ✓ transaction hash:output address
FSN Fusion ✓ transaction hash:output address
FTM Fantom ✓ transaction hash:output address
FUN FunFair ✓ transaction hash:output address
FX Function X ✓ transaction hash:output address
FXC Flexacoin ✓ transaction hash:output address
FXF Finxflo ✓ transaction hash:output address
GAM Gambit ✓ transaction hash:output address
GAS Gas (Neo) ✓ transaction hash:output address
GEN DAOStack ✓ transaction hash:output address
GEO GeoCoin ✓ transaction hash:output address
GHST Aavegotchi ✓ transaction hash:output address
GO GoChain transaction hash:output address
GOT GOToken ✓ transaction hash:output address
GRT The Graph ✓ transaction hash:output address
GTO Gifto ✓ transaction hash:output address
GTX Gate IO ✓ transaction hash:output address
GUP Guppy ✓ transaction hash:output address
GVT Genesis Vision ✓ transaction hash:output address
GXC GXChain transaction hash:output address
HARD Hard Token (Kava Lend) ✓ transaction hash:output address
HBAR Hedera Hashgraph transaction hash:output address
HEDG HedgeTrade ✓ transaction hash:output address
HEX HEX ✓ transaction hash:output address
HINT Hintchain ✓ transaction hash:output address
HIVE HIVE transaction hash:output address
HMQ Humaniq ✓ transaction hash:output address
HNT Helium transaction hash:output address
HOLD Hold ✓ transaction hash:output address
HORD Hord ✓ transaction hash:output address
HPT Huobi Pool Token ✓ transaction hash:output address
HST Decision Token ✓ transaction hash:output address
HXRO Hxro ✓ transaction hash:output address
HYDRO Hydro ✓ transaction hash:output address
ICE Popsicle Finance ✓ transaction hash:output address
ICON Iconic transaction hash:output address
ICX ICON transaction hash:output address
IDEX IDEX ✓ transaction hash:output address
IHT I-House Token ✓ transaction hash:output address
IMP Ether Kingdoms Token ✓ transaction hash:output address
INJ Injective Protocol ✓ transaction hash:output address
INT Internet Node Token ✓ transaction hash:output address
IOST IOST transaction hash:output address
IOTA IOTA transaction hash:output address
IOTX IoTeX ✓ transaction hash:output address
IQX Everipedia ✓ transaction hash:output address
IRIS IRISnet transaction hash:output address
ITM Intimate ✓ transaction hash:output address
JNT Jibrel ✓ transaction hash:output address
JST JUST transaction hash:output address
KAN Kan ✓ transaction hash:output address
KAVA Kava transaction hash:output address
KEEP Keep Network ✓ transaction hash:output address
KEY KEY ✓ transaction hash:output address
KLAY Klaytn transaction hash:output address
KMD Komodo transaction hash:output address
KP3R Keep3rV1 ✓ transaction hash:output address
KSM Kusama transaction hash:output address
LABS LABS Group ✓ transaction hash:output address
LAMB Lambda ✓ transaction hash:output address
LBA Cred ✓ transaction hash:output address
LBTC Liquid BTC ✓ transaction hash:output address
LDO Lido DAO Token ✓ transaction hash:output address
LEO-EOS UNUS SED LEO (EOS) transaction hash:output address
LEO-ERC20 UNUS SED LEO (ERC-20) ✓ transaction hash:output address
LIT Litentry ✓ transaction hash:output address
LOO Loom Network ✓ transaction hash:output address
LPOOL Launchpool ✓ transaction hash:output address
LPT Livepeer ✓ transaction hash:output address
LSK Lisk transaction hash:output address
LTO LTO Network transaction hash:output address
LUN Lunyr ✓ transaction hash:output address
LUNA Terra transaction hash:output address
LXT Litex ✓ transaction hash:output address
LYM Lympo tokens ✓ transaction hash:output address
MAN Matrix AI Network ✓ transaction hash:output address
MATIC_POLYGON Polygon (Matic) transaction hash:output address
MDT Measurable Data Token ✓ transaction hash:output address
MEDX MediBloc ✓ transaction hash:output address
MEME Meme ✓ transaction hash:output address
MET Metronome ✓ transaction hash:output address
MFG SyncFab ✓ transaction hash:output address
MFT Mainframe ✓ transaction hash:output address
MGO MobileGo ✓ transaction hash:output address
MIOTA IOTA transaction hash:output address
MIR Mirror Protocol ✓ transaction hash:output address
MITH Mithril Token ✓ transaction hash:output address
MOC Mossland ✓ transaction hash:output address
MOC Mossland ✓ transaction hash:output address
MOF Molecular Future ✓ transaction hash:output address
MONA MonaCoin transaction hash:output address
MORE More ✓ transaction hash:output address
MTN MedicalChainToken ✓ transaction hash:output address
MTO Meetone ✓ transaction hash:output address
MXC MXC ✓ transaction hash:output address
MYB MyBit ✓ transaction hash:output address
NANO NANO ✓ transaction hash:output address
NAS Nebulas transaction hash:output address
NAV transaction hash:output address transaction hash:output address
NCASH Nucleus Vision ✓ transaction hash:output address
NEAR NEAR Protocol transaction hash:output address
NEBL Neblio transaction hash:output address
NEC Ethfinex Nectar Token ✓ transaction hash:output address
NEO NEO transaction hash:output address
NGC Naga ✓ transaction hash:output address
NIO Autonio ✓ transaction hash:output address
NIOX Autonio ✓ transaction hash:output address
NKN NKN ✓ transaction hash:output address
NLG Gulden transaction hash:output address
NU NuCypher ✓ transaction hash:output address
NULS NULS transaction hash:output address
NXC Nexium ✓ transaction hash:output address
OCEAN Ocean Protocol ✓ transaction hash:output address
OCN Odyssey ✓ transaction hash:output address
ODE ODEM Token ✓ transaction hash:output address
OGN Origin Protocol ✓ transaction hash:output address
OGO Origo ✓ transaction hash:output address
OKT OKExChain transaction hash:output address
OM MANTRA DAO ✓ transaction hash:output address
OMNI OMNI ✓ transaction hash:output address
ONE Harmony transaction hash:output address
ONG Ontology Gas transaction hash:output address
ONL On.Live ✓ transaction hash:output address
ONT Ontology transaction hash:output address
ORBS Orbs ✓ transaction hash:output address
ORS ORS Token ✓ transaction hash:output address
OST Simple Token ✓ transaction hash:output address
PAI PAI Project ✓ transaction hash:output address
PASS Blockpass ✓ transaction hash:output address
PERL Perlin (Pearl.eco) transaction hash:output address
PERP Perpetual Protocol ✓ transaction hash:output address
PI PCHAIN ✓ transaction hash:output address
PICKLE Pickle Finance ✓ transaction hash:output address
PIVX PIVX transaction hash:output address
PLA PlayChip ✓ transaction hash:output address
PLR Pillar ✓ transaction hash:output address
PMA PumaPay ✓ transaction hash:output address
PNK Kleros Token ✓ transaction hash:output address
PNT pNetwork ✓ transaction hash:output address
POA POA Network ✓ transaction hash:output address
POLS Polkastarter ✓ transaction hash:output address
POLY Polymath ✓ transaction hash:output address
POLY_BSC Poly BSC Bridge transaction hash:output address
POLY_POLYGON Polygon transaction hash:output address
PPC Peercoin transaction hash:output address
PPT POPULOUS(Populous ✓ transaction hash:output address
PRO Propy ✓ transaction hash:output address
PROM Prometeus ✓ transaction hash:output address
PST Primas ✓ transaction hash:output address
PTON Foresting ✓ transaction hash:output address
PTOY Patientory ✓ transaction hash:output address
PTT Proton Token ✓ transaction hash:output address
PXL Pixel ✓ transaction hash:output address
QASH QASH ✓ transaction hash:output address
QKC QuarkChain ✓ transaction hash:output address
QSP Quantstamp ✓ transaction hash:output address
QTUM Qtum ✓ transaction hash:output address
QUICK QuickSwap ✓ transaction hash:output address
QWARK Qwark ✓ transaction hash:output address
RAI RAI Finance ✓ transaction hash:output address
RAMP RAMP ✓ transaction hash:output address
RARI Rarible ✓ transaction hash:output address
RAY Raydium ✓ transaction hash:output address
RBTC RBTC ✓ transaction hash:output address
RDD ReddCoin transaction hash:output address
RDN Raiden ✓ transaction hash:output address
REEF Reef transaction hash:output address
REQ Request Network ✓ transaction hash:output address
RFR Refereum ✓ transaction hash:output address
RIF RIF ✓ transaction hash:output address
RLY Rally ✓ transaction hash:output address
ROOK KeeperDAO ✓ transaction hash:output address
ROSE Oasis Network transaction hash:output address
RRB RenrenBit Token ✓ transaction hash:output address
RRT Recovery Rights Token transaction hash:output address
RSR Reserve Rights ✓ transaction hash:output address
RTE Rate3 ✓ transaction hash:output address
RUFF Ruff ✓ transaction hash:output address
RUNE THORChain transaction hash:output address
RVN Ravencoin transaction hash:output address
SAN SANtiment Network Token ✓ transaction hash:output address
SAND The Sandbox ✓ transaction hash:output address
SC Siacoin transaction hash:output address
SCRT SECRET_NETWORK(
SEE SEER ✓ transaction hash:output address
SEELE Seele-N ✓ transaction hash:output address
SEN ConsenusAI transaction hash:output address
SEND Social Send transaction hash:output address
SERV Serve ✓ transaction hash:output address
SFP SafePal transaction hash:output address
SHIB SHIBA INU ✓ transaction hash:output address
SKL SKALE Network ✓ transaction hash:output address
SLP Smooth Love Potion ✓ transaction hash:output address
SNGLS SingularDTV ✓ transaction hash:output address
SNX Synthetix ✓ transaction hash:output address
SOL Solana transaction hash:output address
SOLVE Solve.Care ✓ transaction hash:output address
SPANK Spank ✓ transaction hash:output address
SPC SpaceChain ✓ transaction hash:output address
SPHR Sphere ✓ transaction hash:output address
SPIN SPIN Protocol ✓ transaction hash:output address
SPND Spendcoin ✓ transaction hash:output address
SRM Serum transaction hash:output address
SRN Sirin Token ✓ transaction hash:output address
STAKE xDai ✓ transaction hash:output address
STEEM Steem ✓ transaction hash:output address
STMX StormX ✓ transaction hash:output address
STORM Storm ✓ transaction hash:output address
STOX Stox ✓ transaction hash:output address
STPT Standard Tokenization Protocol ✓ transaction hash:output address
STX Stacks transaction hash:output address
SUPER SuperCoin transaction hash:output address
SWAP TrustSwap ✓ transaction hash:output address
SWFTC SwftCoin ✓ transaction hash:output address
SWM Swarm ✓ transaction hash:output address
SWRV Swerve ✓ transaction hash:output address
SWT Swarm City Token ✓ transaction hash:output address
SXP Swipe ✓ transaction hash:output address
SYS Syscoin transaction hash:output address
TBTC tBTC ✓ transaction hash:output address
TCT TokenClub ✓ transaction hash:output address
TEMCO TEMCO ✓ transaction hash:output address
TFUEL Theta Fuel transaction hash:output address
THETA THETA transaction hash:output address
TIX Blocktix ✓ transaction hash:output address
TKN TokenCard ✓ transaction hash:output address
TNB Time New Bank ✓ transaction hash:output address
TOMO TomoChain ✓ transaction hash:output address
TRAC OriginTrail ✓ transaction hash:output address
TRB Tellor ✓ transaction hash:output address
TRIO Tripio ✓ transaction hash:output address
TROY TROY transaction hash:output address
TRST Trustcoin ✓ transaction hash:output address
TRUE Truechain transaction hash:output address
TRX TRON transaction hash:output address
TSHP 12Ships ✓ transaction hash:output address
TT Thunder Token transaction hash:output address
TUDA Tutor's Diary ✓ transaction hash:output address
TVK Terra Virtua Kolect ✓ transaction hash:output address
UBT Unibright ✓ transaction hash:output address
UFR Upfiring ✓ transaction hash:output address
UKG UnikoinGold ✓ transaction hash:output address
UMA UMA ✓ transaction hash:output address
UOS Ultra ✓ transaction hash:output address
UP UpToken ✓ transaction hash:output address
UPBTC Universal Bitcoin ✓ transaction hash:output address
UPCO2 Universal Carbon ✓ transaction hash:output address
UPEUR Universal Euro ✓ transaction hash:output address
UPP Sentinel Protocol ✓ transaction hash:output address
UPT Universal Protocol Token ✓ transaction hash:output address
UPUSD Universal USD ✓ transaction hash:output address
UPXAU Universal Gold ✓ transaction hash:output address
URAC Uranus ✓ transaction hash:output address
USDK USDK ✓ transaction hash:output address
USDS StableUSD ✓ transaction hash:output address
USDT_ALGO USD Tether Alogrand transaction hash:output address
USDT_LIQUID USD Tether Liquid( transaction hash:output address
USDT_SLP USD Tether SLP transaction hash:output address
USDT_SOL USD Tether Solana transaction hash:output address
USDT_TRX USD Tether Tron transaction hash:output address
UST TerraUSD ✓ transaction hash:output address
UTK UTRUST ✓ transaction hash:output address
UTNP Universa ✓ transaction hash:output address
VCO Voucher Coin transaction hash:output address
VDX Vodi X ✓ transaction hash:output address
VEE BLOCKv ✓ transaction hash:output address
VEN VeChain ✓ transaction hash:output address
VET VeChain ✓ transaction hash:output address
VIB Viberate ✓ transaction hash:output address
VISR Visor.Finance ✓ transaction hash:output address
VITE Vite ✓ transaction hash:output address
VLD Vetri ✓ transaction hash:output address
VOX Vox.Finance ✓ transaction hash:output address
VSP Vesper ✓ transaction hash:output address
VSYS v.systems transaction hash:output address
VTHO VeThor Token ✓ transaction hash:output address
VTI Vetri ✓ transaction hash:output address
WABI Tael (Wabi) transaction hash:output address
WAN Wanchain transaction hash:output address
WAVES WAVES transaction hash
WAX Worldwide Asset Exchange ✓ transaction hash:output address
WAXP WAX transaction hash:output address
WIB Wibson ✓ transaction hash:output address
WICC WaykiChain transaction hash:output address
WINGS Wings DAO ✓ transaction hash:output address
WLO Wollo ✓ transaction hash:output address
WNXM Wrapped NXM Mutual ✓ transaction hash:output address
WOO Wootrade Network transaction hash:output address
WOO_BSC Woo Network BSC transaction hash:output address
WOO_ETH Woo Network ETH transaction hash:output address
WPR WePower ✓ transaction hash:output address
WRX WazirX transaction hash:output address
XCH Chia Network transaction hash:output address
XD Data Transaction Token ✓ transaction hash:output address
XDB DigitalBits ✓ transaction hash:output address
XEM NEM transaction hash:output address
XLM Stellar Lumens transaction hash
XMR Monero Deposits - "transaction hash:tx index:receiving address:payment ID"

Withdrawals - "transaction hash:tx index:withdrawal address:payment ID"

The asset amount must be included as another field in the JSON
XNK Ink Protocol ✓ transaction hash:output address
XOR Sora ✓ transaction hash:output address
XRA MasterXriba ✓ transaction hash:output address
XTZ Tezos transaction hash:output address
XVG Verge ✓ transaction hash:output address
XVS Venus transaction hash:output address
XYO XYO ✓ transaction hash:output address
YAX yAxis ✓ transaction hash:output address
YEE YEE ✓ transaction hash:output address
YEED YGGDRASH ✓ transaction hash:output address
YFII DFI.Money ✓ transaction hash:output address
YOYOW YOYOW ✓ transaction hash:output address
YUSDC Yearn USDC transaction hash:output address
ZBT ZBToken ✓ transaction hash:output address
ZCN 0Chain ✓ transaction hash:output address
ZEN Horizen transaction hash:output address

Historic assets

Historic assets are assets that we have supported until a certain date due to factors such as coin migration, paused ingestion, or coin deprecation. For the assets listed below, KYT provides only the historical transaction values up to their specified date and does not yield new transfers.

Symbol Asset Date Notes ERC-20? Transfer format reference
ETC Ethereum Classic 2020-08-06 Paused ingestion following 51% attack. "transaction hash:output address"
FET Fetch.ai 2020-10-14 Migrated smart contract. ✓ "transaction hash:output address"
ICN Iconomi 2019-12-31 Coin deprecation. ✓ "transaction hash:output address"
REP Augur 2020-07-29 Migrated smart contract. ✓ "transaction hash:output address"
ZIL Zilliqa 2020-02-26 Migrated to native chain. ✓ "transaction hash:output address"
shell