Hello builders!

If you have ever tried to get data on translations, you probably had to handle numerous block calls for a long time 😡

We at WatchData 👀 can give you the ability to simplify this approach and get this data in 1 API call you only need to know the address you want to track. With our data you can create many different services, such as your monitoring service (pictured below):

Looks interesting?

Well, let's look at the capabilities of the watch_getTransfersByAddress endpoint. To learn more, visit our Documentation.

All you have to do is make a request and get information on how ETH and ERC20 transfers are received.

Let's now look at an example of how it all works.

Open the API client, we processed the request through Postman. If you're having trouble, check out our Quick start guide on how to get started with our API.

Request:

{
    "id": 1,
    "method": "watch_getTransfersByAddress",
    "jsonrpc": "2.0",
    "params": [
        {
        "addresses": "0xc7d15E3aE9442baD3E0B3689b835fDd035479B52",
        "transferDirection": "to",
        "fromBlock": 1,
        "offset": 0,
        "limit": 100
    }
    ]
}

• For example you want to monitor your address for sending transactions . Suppose it is 0xc7d15E3aE9442baD3E0B3689b835fDd035479B52.

• To get the transfers that were received at the specified address, add the parameter: "transferDirection": "to", and to get the transfers that were sent from this address, add the parameter "transferDirection": "from".

By the way, in the "addresses" parameter you can use several address values to get more information in one query, for example "addresses": ["0xc7d15E3aE9442baD3E0B3689b835fDd035479B52","0x6aE6d807E57964D5DaC79CF07D43AA0B458CB0dB"],

Now we make 1 request to the API and get information on all transfers of a given address.

Let's find out what we get in response.

Response:

{
    "id": 1,
    "jsonrpc": "2.0",
    "result": [
        {
            "blockNumber": 12591647,
            "blockTimestamp": "2021-06-08T04:07:30",
            "transactionIndex": 25,
            "logIndex": null,
            "contractAddress": null,
            "transferType": "trx",
            "from": "0xea674fdde714fd979de3edf0f56aa9716b898ec8",
            "to": "0xc7d15e3ae9442bad3e0b3689b835fdd035479b52",
            "value": 100055406833350373
        },
        {
            "blockNumber": 12664741,
            "blockTimestamp": "2021-06-19T12:13:15",
            "transactionIndex": 19,
            "logIndex": null,
            "contractAddress": null,
            "transferType": "trx",
            "from": "0xea674fdde714fd979de3edf0f56aa9716b898ec8",
            "to": "0xc7d15e3ae9442bad3e0b3689b835fdd035479b52",
            "value": 100050819506085117
        },
        {
            "blockNumber": 12731449,
            "blockTimestamp": "2021-06-29T21:56:32",
            "transactionIndex": 115,
            "logIndex": null,
            "contractAddress": null,
            "transferType": "trx",
            "from": "0xea674fdde714fd979de3edf0f56aa9716b898ec8",
            "to": "0xc7d15e3ae9442bad3e0b3689b835fdd035479b52",
            "value": 100022202551483258
 ............................................................................
        }
    ]
}

We obtained a dataset that transmits information on transfers.

From these values, we can determine that the:

• transferType "trx" - is the native ETH token transfer.

• Value - parameter gives the value with the uint256 format.

To convert this value into a usable format, we need to divide it by 10^18, because the decimals parameter at ETH = 18.

⚠️ For different tokens there is a different decimals parameter be careful!

After processing the entire data set, we were able to get transfers that came and went from the address we specified. We have shown you just one example of how you can interact with a watch_getTransfersByAddress endpoint, try it yourself.

Log in to WatchData.

Our API is available in a free format, you can read more about the limits here → Documentation.

1. Join to our Discord server

2. Please leave your feedback in the #feedback channel. If you have any problems or you think that some functionality is not working correctly, we are waiting for your feedback.

3. Want a new feature or you miss some functionality, tell us about it in the #general channel. We are always open to your ideas!

HELPFUL LINKS

• WatchData main

• Raw Data

• Structured data

• Metrics for analysis

• For Miners

• WatchData Twitter

• WatchData Discord

• WatchData Docs

You can create Ethereum Applications in different programming languages. In this article, we will connect to the Ethereum network using Python.

Preinstalled

• You have Python (version >=3.5.3) and Pip3 installed on your system.

• Install web3.py (A Python wrapper for Ethereum node APIs).

• A text editor

Adding web3.py

Note: We need Python version >=3.5.3 and install web3.py using pip3 install web3.

Python and other library versions cause common installation problems. So if you face any problems, try setting up a virtual environment and troubleshooting the installation of web3.py.

Get API Key WatchData

To create an API key, you need to do the following steps: On the Dashboard.watchdata.io tab, click Create API key.

Your API key will be automatically created.

Once you have created the API key, copy it and combine it with the HTTP provider's endpoint in this format:

https://ethereum.api.watchdata.io/node/jsonrpc?api_key=YOUR_API_KEY_HERE

For example:

https://ethereum.api.watchdata.io/node/jsonrpc?api_key=83ab245b-ae08-43a4-97db-85903d35652f

Using web3.py

We will use web3.py to get the last Ethereum block number. To do this we will use the code below.

from web3 import Web3
watchdata_url = 'https://ethereum.api.watchdata.io/node/jsonrpc?api_key=83ab245b-ae08-43a4-97db-85903d35652f'
w3 = Web3(Web3.HTTPProvider(watchdata_url))
last_block_number = w3.eth.block_number
print(f'last block number in eth = {last_block_number}')

Let's take a closer look at the code:

In this code snippet, we import the web3.py library, declare a watchdata_url variable to which we assign the URL of our watchdata node in Ethereum. And then we create an instance of the web3 class with our watchdata_url.

In this code snippet, we retrieve the last Ethereum block number using the w3.eth.blockNumber API and display it.

That's it, you are connected via the Ethereum network using Python. You can also learn more about the web3.py APIs for building complicated applications on Ethereum.

At the moment, only sets of methods described in Ethereum API documentation are available from API interfaces, when working through WatchData node, and we are actively working on adding new methods.

1. Join to our Discord server

2. Please leave your feedback in the #feedback channel. If you have any problems or you think that some functionality is not working correctly, we are waiting for your feedback.

3. Want a new feature or you miss some functionality, tell us about it in the #general channel. We are always open to your ideas!

HELPFUL LINKS

• WatchData main

• WatchData Twitter

• WatchData Discord

• WatchData Docs

Hi, welcome to WatchData!

If you've never heard of us before, WatchData gives developers and enterprises easy and reliable access to Web3 tools and infrastructure. In this article, we will tell you how to get started with WatchData so you can connect to the Ethereum blockchain and get started building awesome applications.

We'll take a look at:

• Registering an account

• Creating an API Key

• Creating API queries via Postman

Step One: Register

The first thing you need to do is go to WatchData.io and create an account. The only information needed to register your account is your email address.

First of all, you need to register.

Go to the Sign Up page and enter your email address.

Go to your email client and click on the link in the email to confirm your registration.

Click the button or the link and then go back to your original tab. You'll be automatically redirected to your personal dashboard.

Step Two: Create an API Key

To create an API key, you need to do the following steps: On the Dashboard.watchdata.io tab, click Create API key.

Your API key will be automatically created.

Step Three: Create API queries via Postman

In the example, we'll show step-by-step instructions for sending some sample queries via Postman. In addition to Postman, you can use data from the WatchData API in any application, using post and curl queries.

First, after you get the API key you have to connect to the blockchain.

The URL for Ethereum mainnet:

https://ethereum.api.watchdata.io/node/jsonrpc

The URL for Ropsten testnet:

https://ropsten.api.watchdata.io/

Go to Postman and create a new request.

The request type is POST, in the Request url field enter the address specified above. On the Headers tab in the Key field type in "key_api", in the value field type in your API key.

Now everything is ready to send a request and receive data from the API. For the example, we'll look at the eth_blockNumber method first. Let's go to the documentation and copy the body of the example POST request.

In Postman select the Body tab, set Raw and JSON on it, insert the request, then click send.

Then we can see the answer at the bottom of the page.

A similar example of the request sent and response received for the eth_getBlockByNumber method. You can work in exactly the same way with any of the methods in our documentation.

You now know how to send requests and receive data from WatchData API :)

In addition, the WatchData API can be used by being integrated into web3 SDK's. Read an example of how to use the WatchData API to connect to the Ethereum network via Web3.py.

If you have any questions on using the WatchData API you can always get help from the technical support via online chat on the website or in our discord.

1. Join to our Discord server

2. Please leave your feedback in the #feedback channel. If you have any problems or you think that some functionality is not working correctly, we are waiting for your feedback.

3. Want a new feature or you miss some functionality, tell us about it in the #general channel. We are always open to your ideas!

HELPFUL LINKS

• WatchData main

• Raw Data

• Structured data

• Metrics for analysis

• For Miners

• WatchData Twitter

• WatchData Discord

• WatchData Docs

Hello everyone 🖖

We continue our series of articles about our API and today we want to take a look at the often used eth_getLogs.

eth_getLogs has a lot of useful options that developers often don't know about. Let's give you an example of how to work with this query.

For more information about the request/response specifications for eth_getLogs, see our documentation

What are Logs?

Logs and events are used synonymously - smart contracts generate logs by triggering events, so logs provide insight into the events that occur within a smart contract. Logs can be found on transaction recipes.

Query eth_getLogs

When you make a request to eth_getLogs, all parameters are OPTIONAL, that is, you don't need to specify fromBlock, toBlock, address, topics or blockHash

Let’s look at an example of a request. Take the USDT address and limit the search parameters from 10,000,000 block to 10,000,001 block. Let's add a topic on event transfers. We'll describe it in more detail below

{
    "id": 1,
    "method": "eth_getLogs",
    "jsonrpc": "2.0",
    "params": [
        {
    "address": "0xdAC17F958D2ee523a2206206994597C13D831ec7", 
    "fromBlock": 10000000, 
    "toBlock": 10000001,
    "topics": ["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"]
        }
    ]
}

In our paramshere we have specified theaddress, fromBlockand toBlock

⚠️ We use fromBlock and toBlock in our params. It is important to understand that you can use either fromBlockand toBlockor blockHash, not both.

The fromBlock and toBlock parameters specify the start and end block numbers to limit the search. The address field represents the address of the contract that creates the log.

Topicsis an ordered array of data. Notice how the first item in the topics  field above matches the event signature of our Transfer(address,address,uint256).

This means that we specifically request the Transfer event. So I will get all transfers in USDT from 10,000,000 block to 10,000,001 block.

Now that we have a better understanding of how to make queries, let's look at the answer.

Response

You will get a list of logs in a given range (You will get a response with much more data than the following):

{
    "id": 1,
    "jsonrpc": "2.0",
    "result": [
        {
            "address": "0xdac17f958d2ee523a2206206994597c13d831ec7",
            "blockHash": "0xaa20f7bde5be60603f11a45fc4923aab7552be775403fc00c2e6b805e6297dbe",
            "blockNumber": "0x989680",
            "data": "0x00000000000000000000000000000000000000000000000000000000121eac00",
            "logIndex": "0x3",
            "topics": [
                "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
                "0x00000000000000000000000039bb7d39a395e0ce36875244ad48bcaec54faf03",
                "0x0000000000000000000000009354de9e63674f3e44303b8cc3853d7f10f97d06"
            ],
            "transactionHash": "0x80e195cabafd0358a35cec5fadc9b304734ac1f0ed6edf607d170dab13f5e069",
            "transactionIndex": "0x7",
            "removed": false
        }
..............................
}

The interesting fields to watch out for are data - which is an unrestricted field for encoding hexadecimal data related to a specific event. By default, if the information is not indexed in the other topics field, it is automatically placed in the data field. This requires more work to analyze the individual hex string information rather than their indexed topics.

And topics - can contain up to 4 topics. The first topic is mandatory and will always contain hash keccak 256 event signature. As you may see the example above shows a Transfer event between address 0x39bb7d39a395e0ce36875244ad48bcaec54faf03 and 0x 9354de9e63674f3e44303b8cc3853d7f10f97d06(the second and third topics).

We can check this data on etherscan

Now you know a bit more about the eth_getLogs.

But if you want to receive and process transfers and not spend a lot of time processing logs, you can use our watch_getTransfers method.

We will tell you about it in one of our next articles, but for now you can read about it in the documentation.

1. Join to our Discord server

2. Please leave your feedback in the #feedback channel. If you have any problems or you think that some functionality is not working correctly, we are waiting for your feedback.

3. Want a new feature or you miss some functionality, tell us about it in the #general channel. We are always open to your ideas!

HELPFUL LINKS

• WatchData main

• Raw Data

• Structured data

• Metrics for analysis

• For Miners

• WatchData Twitter

• WatchData Discord

• WatchData Docs

Get stats by day

Hello everyone!

We at WatchData are in the business of making life better for developers and the entire crypto community. Our API is a simple and easy way to interact with blockchain and we want to tell and show you what you can get by using WatchData.

Here is a brief analysis of our endpoints.

In this series of articles, you can get answers to the following questions:

• What is it?

• What is it for?

• What can I do with it?

Today we'll start with watch_getStatsByDay. We added this endpoint recently, but now we want to tell you what its value and usefulness are.

1. watch_getStatsByDay - is a set of parameters collected in a single endpoint. This is the statistical data used in the ETH blockchain. By the way, this method will be available for other blockchains in the near future.

2. With this data you can get all the statistical information for 1 day in 1 click. This removes a headache for many users, because using this method you don't have to collect and process data from different sources.

3. There are many ways to use and process this data, for example, you can use it in the following cases:

• You can build a graph and estimate the statistics, on which day there were more transactions and on which day more commission was paid.

All you have to do is get a key and process the request through any API interaction tool, you can find a detailed guide → here. In the parameters, select the date you need and get an answer. To convert the unix timestamp you can use https://www.epochconverter.com/

Example request

{
    "jsonrpc":"2.0",
    "method":"watch_getStatsByDay",
    "params":[1646053739],
    "id":0
}

Example response

{
    "id": 0,
    "jsonrpc": "2.0",
    "result": {
        "transactionCount": 1108112,
        "averageGasPrice": 74184332107.8433,
        "totalGasUsed": 99340469987,
        "uncleBlockReward": 628250000000000000000,
        "minersReward": 13744624508661043931629,
        "blockCount": 6424
    }
}

Returns explanation

Object - A block object with the following fields, or null when no block was found:

• transactionCount: QUANTITY - number of transactions per day

• averageGasPrice: QUANTITY, - average gas price per day.

• totalGasUsed: QUANTITY, - total gas used per day

• uncleBlockReward: QUANTITY, - uncle block reward by day

• minersReward: QUANTITY, - miner's reward per day

• blockCount: QUANTITY, - number of blocks per day

This way you can collect data for the time period you need. For example

Using this data, you can build any graphs you want as well as serving specific information. Of course presented here is only a small part, it all depends on your product, you are free to work with any type of data, and we will help you with this!

This example shows the method, which gives the data within one day, if you need other ranges, please contact us marketing@thewatch.io

Or join our discord community, there, in the channel #general you can ask any questions that interest you, as well as in the channel #feature-request suggest a feature or statistical information that you need in the first place.

HELPFUL LINKS

• WatchData main

• Raw Data

• Structured data

• Metrics for analysis

• For Miners

• WatchData Twitter

• WatchData Discord

• WatchData Docs

QuickNode, Alchemy, Moralis, Infura or WatchData which provider demonstrates high speed of interaction with the API?

Comparison

Our product is in beta test and we continue to actively develop. For this purpose, we have tested among the 4 major market players, like Alchemy, Infura, Moralis, QuickNode. We can’t stress enough that both Alchemy, Infura and QuickNode are reliable blockchain node providers and serve many users well.

⚠️ Important notice! This test is conducted under certain assumptions. We are aware that test results may vary or may not give completely reliable results due to the remoteness of the servers.

The conditions for the test are identical - Make queries consecutively as many times as possible and free plans from each of the providers except for QuickNode, since they only have a 7-day trial. The testing time for all providers was the same

To check, we took some of the most common endpoints: eth_blockNumber, eth_getLogs.

First, for eth_blockNumber endpoint, we compare the median response time. An identical tests will also be conducted for eth_getLogs.

The first endpoint in our test is - eth_blockNumber

This endpoint returns the latest block number of the blockchain.

In the table we compared on several indicators for clarity.

The parameter by which we compare is the median response time - the lower the index, the better the result.

After obtaining this data, we immediately conduct a second test, but with a different endpoint - eth_getLogs

The second endpoint in our test is - eth_getLogs

This endpoint returns an array of all logs matching a given filter object.

A similar series of tests for this method. We calculated as follows: we take all logs for USDT smart contract in one block. The block for each query is chosen randomly from the last 100000 blocks.

The parameter by which we compare is the median response time - the lower the index, the better the result.

As you can see QuickNode is firmly in the lead. It shows excellent results, as you can see from the numbers they have shown over the course of the test. All values do not have sharp deviations. But do not forget that QuickNode has only a 7-day trial, after this service will be charged.

Nevertheless, the positions of WatchData, in relation to other participants in the test also show very good results.

Final Thought

It is still too early to declare a high competitive advantage of WatchData. But it also speaks volumes. The team has released the product into beta test, and it is already showing good results at this stage. At watchData we're always looking for growth and quality in our products. And in the near future, we'll continue with a series of articles where we compare our product on other metrics, under more fair conditions.

High speed of query processing has been achieved by adding indexes to queries and a detailed architecture.

Moreover, we are a 100% free service - do not miss the opportunity to try our API.

Shortcuts:

• RpS = API requests per second,

• Median = For data set it’s "the middle" value ,

• Percentile = is a certain part of the data sample,

• Web3.0 = Web 3.0 is the upcoming third generation of the internet.

Join our community

Join our discord server, where you can ask any questions and suggest a feature that will help close your needs.

HELPFUL LINKS

• WatchData main

• Raw Data

• Structured data

• Metrics for analysis

• For Miners

• WatchData Twitter

• WatchData Discord

• WatchData Docs

Calypso Pay is a payment service provider that allows any business to accept payments and make settlements in crypto.

Summary

The Calypso Pay team is developing a payment service for cryptocurrencies and faced the problem of receiving notifications from the blockchain about completed transactions.

Initially, the team tried to develop and maintain the infrastructure for blockchain monitoring on their own, but faced with a few problems with the infrastructure and being on the verge of losing a key customer, they turned to WatchData.

WatchData developed an API for receiving notifications, which was quickly implemented and has worked stable to this day.

Problem

Calypso Pay needs to get data on the status of transactions, which requires constant monitoring of the blockchain for new transactions.

There have been many problems with the in-house infrastructure to retrieve data from the blockchain:

• When using their in-house infrastructure, there were missed transactions received and delays in the blockchain update. The in-house infrastructure was several blocks behind and it took up to three hours to update balances. Calypso Pay users did not understand the status of the transfer, and such problems risked the loss of a key client.

• Owning its in-house infrastructure required maintaining its blockchain nodes, the team had expenses because in-house support required a lot of effort and resources of administrators and developers.

• It was necessary to connect new blockchains. The connected blockchains needed to give their data in a single unified format. At the same time, it is possible to flexibly customize each blockchain.  For example, a different number of transaction confirmations depends on the blockchain.

The challenge was that Calypso Pay needed to receive information from multiple blockchain addresses in a short time.

The internal infrastructure of the payment service does not allow for external requests. Therefore it was decided to provide information in a long-polling format. When there is constant communication between systems, only really interesting transactions are sent for processing.

After analyzing the market it became clear that there are no solutions that support the full list of requirements, so Calypso Pay turned to WatchData to develop such an API.

Solution

The WatchData team quickly responded to the request and in no time at all developed an API to meet Calypso Pay's requirements.

They made lists of events taking into account the specifics of the task, set up constant monitoring of the blockchain, and created an API that allows getting all the relevant transactions data with a single request.

Example of a query that creates two filters that track transactions for specific contracts and wallet addresses:

/calypso/last_block_number
IN:
{
  "blockchain": "TRON"
}
OUT:
{
  "block_number": 38212529,
  "blockchain": "TRON"
}
/calypso/filters/add
IN:
{
  "blockchain": "TRON",
  "address": "TEnxtXJhMXXgPrchm8Qv6F7m4WQ4vRhSJ1", - wallet adress
  "contract_address": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t" - contract adress (USDT)
} 
OUT:
{
  "filter_id": "bc3d3ee1-3fbd-479e-aaf8-b7885b890602"
}
IN:
{
  "blockchain": "TRON",
  "address": "TMpFZy1vCv3xmtJDQp9dnxX8aaK8hgAUyc",
  "contract_address": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t"
}
OUT:
{
  "filter_id": "11af35c3-27e8-497c-b098-f8b0276980e1"
}

Example of applying filters to a specific block:

/calypso/filters/check
IN:
{
  "block_number": 38212506,
  "blockchain": "TRON"
}
OUT:
{
  "filters": [
    {
      "from_address": [
        "TEnxtXJhMXXgPrchm8Qv6F7m4WQ4vRhSJ1"
      ],
      "to_address": [
        "TNHK9ygsDPjeCikL9RR9AmNJDAps4osYKk"
      ],
      "contract_address": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t",
      "type": "trc20",
      "value": 1128,
      "currency": "USDT",
      "transaction": {
        "hash": "55dddcebf4207a9a33649c3c541b62adf6d45364aa5f1f7b48878716055f71ec",
        "fee_value": 4.44168,
        "fee_symbol": "TRX"
      },
      "filter_id": "bc3d3ee1-3fbd-479e-aaf8-b7885b890602",
      "filter_target": {
        "address": "TEnxtXJhMXXgPrchm8Qv6F7m4WQ4vRhSJ1",
        "direction": "withdrawal"
      },
      "block": {
        "hash": "000000000247139a8c6e637b7d7daf20193f574d99dfb296ff4d2fb2df1c59b9",
        "number": 38212506,
        "created_at": "2022-02-18T11:17:00+00:00"
      }
    },
    {
      "from_address": [
        "TPgtDGXdFvEaG23JVSH5Ra9tpp8mh24LXZ"
      ],
      "to_address": [
        "TMpFZy1vCv3xmtJDQp9dnxX8aaK8hgAUyc"
      ],
      "contract_address": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t",
      "type": "trc20",
      "value": 29.7,
      "currency": "USDT",
      "transaction": {
        "hash": "b504ebb33e82297a3f80b221a05b5a616d5d9d5bcf25bd525ee7889e1106c942",
        "fee_value": 4.09668,
        "fee_symbol": "TRX"
      },
      "filter_id": "11af35c3-27e8-497c-b098-f8b0276980e1",
      "filter_target": {
        "address": "TMpFZy1vCv3xmtJDQp9dnxX8aaK8hgAUyc",
        "direction": "deposit"
      },
      "block": {
        "hash": "000000000247139a8c6e637b7d7daf20193f574d99dfb296ff4d2fb2df1c59b9",
        "number": 38212506,
        "created_at": "2022-02-18T11:17:00+00:00"
      }
    }
  ]
}

The data for all addresses can be received in a single request, which takes on average 90 ms, while for one of our competitors this data could only be obtained by requesting each of the blockchain addresses separately and with an average speed of 200 ms for each of the requests.

The system works stably and without interruptions, completely covering Calypso Pay's tasks. Data accuracy is ensured by the proper processing of blockchain forks.

The problem of transaction data loss was successfully solved.

After switching to WatchData infrastructure the company stopped spending money for the maintenance of its in-house infrastructure. This allowed saving over 300 hours of development time.

A unified dataset for all connected blockchains was implemented, which allowed the team to easily input data into the product and reduce development time.

Different blockchains have different data structures within them and many peculiarities. The variability of data in different blockchains cannot be completely ignored, but WatchData offers an abstraction that makes working with transactions in different networks similar to each other.

The scaling problem is being successfully solved right now; the Tron blockchain has already been added, and transaction data is already being tracked in it as well. New blockchains are in the process of being connected.

The quick addition of new blockchains allows Calypso Pay to give its customers new payment methods with minimal effort to connect them.

The WatchData infrastructure is easy to scale, as the current technical developments and system architecture allow new blockchains to be added quickly.

After a long search for a solution on the market, we found that good, reliable APIs for retrieving basic information from the blockchain were simply not available. Some of the solutions on the market were unstable, and once we encountered an API that returned a transaction that didn't really exist.

So we decided to make the solution ourselves. But it turned out to be a very difficult task, especially considering the level of reliability we needed.

Then we came across the WatchData solution, which pleasantly surprised us in several aspects at once:

1. Universal interface for different blockchains.

2. Reliable operation without interruptions, even for test networks.

3. Comfortable work for real cases. For example, we need to get only a transaction that is guaranteed to pass, which means the different number of confirmations for different blockchains.

4. The team's commitment to meet us and improve their API. The polling mechanism we needed was non-standard, but WatchData quickly adapted their interfaces to our decision.

5. Active development and addition of new blockchains.

That is why we now use the WatchData solution exclusively. Which covers almost all blockchain interaction tasks. And we are very happy to continue cooperating with them.

Maxim Zhizhin

CTO in Calypso Pay

HELPFUL LINKS

• Calypso Pay

• WatchData main

• Raw Data

• Structured data

• Metrics for analysis

• For Miners

• WatchData Twitter

• WatchData Discord

• WatchData Docs