Ethereum has a complex system for compacting smart contract data so that the network can operate efficiently.

This creates a problem: Developers need to know how to parse the data in order to use it in applications.

Normally, to interact with an Ethereum smart contract, applications load a map that helps the application know how to interpret and interact. This is called an ABI (Application Binary Interface). If the application has the ABI, it can know how to use/read the contract data.

What if the application interacts with 10s, 100s, 1000s of different contracts? It becomes simply impossible to keep track of all these ABIs.

The blockchain stores data in primitive data types.

At Amberdata, we created the perfect solution for developers — our REST APIs now interpret the data into an ABI parsed format in addition to the raw data. This allows the application to no longer need an ABI for every single contract, and be able to transact with all the information it needs.

Amberdata does this by indexing all publicly available contract ABIs, keeping a large database of all 4 byte signatures and their arguments, as well as support the ERC specifications. This allows us to cover 99% of all data interpretations, and return relevant ABI information within the REST payloads.

With, data is now parsed into easily usable formats!

Now for the best part —

How easy is it to integrate?

As simple as a single REST call.

Let’s look at an example of how to get interpreted transactions from a Uniswap trade:

// DAI_WETH Uniswap Pair
curl -X GET '' -H 'x-api-key: UAK...'

You’ll notice the extra information returned:

"function": {
  "signature": "Swap(address,uint256,uint256,uint256,uint256,address)",
  "parameters": [
    "0xb5f1FAB5832Aa0b3F4d2563E684668603504b999", // Sender
    "10882893794444259746222", // Tokens to trade
    "17871744578493874176", // Tokens to receive
    "0x749010AB5E25bcf6728e60A7a0cA69Bf38e299Da" // receiver
    "call": "Swap(0xb5f1FAB5832Aa0b3F4d2563E684668603504b999, 10882893794444259746222, 0, 0, 17871744578493874176, 0x749010AB5E25bcf6728e60A7a0cA69Bf38e299Da)"

The data here is decoded from its hex stored type into parse addresses and integer.

Uniswap trades aren’t the only thing supported, lets look at a more extensive example using the infamous CryptoKitties:

// request CK Data
curl -X GET '' -H 'x-api-key: UAK...'

"data": "0x000000000000000000000000c14ce04b0b76261b2153767f49a6ddd5747618ab00000000000000000000000000000000000000000000000000000000001e5cd7000000000000000000000000000000000000000000000000000000000006bc78000000000000000000000000000000000000000000000000000000000006c0da000062168298e7318ce50d4e29d8c086617194e0102419c51118a3631ca6ad89"

// With Amberdata:
"function": {
  "signature": "Birth(address,uint256,uint256,uint256,uint256)",
  "parameters": [
  	"0xc14Ce04B0B76261b2153767F49a6Ddd5747618aB", // Owner
    "1989847", // NFT ID
    "441464", // NFT Parent 1
    "442586", // NFT Parent 2
    "676978014310756376821881862788291853774644622432271838614341702964915593" // Genetics
   "call": "Birth(0xc14Ce04B0B76261b2153767F49a6Ddd5747618aB, 1989847, 441464, 442586, 676978014310756376821881862788291853774644622432271838614341702964915593)"

The response shows several new data formats for Birth, Auction, Transfer and more. Looking deeper you can also see the function signature, which represents all the data needed for a library like Ethers.js to create (& sign!!!) an ethereum transaction or RPC call! Awesome!

What endpoints support this data interpretation?

For every REST endpoint that supports Ethereum Logs, Amberdata is able to add parsed data context. Here are the endpoints supported:

With this level of parsed data, it is possible to directly interact and use data for all Ethereum contracts without needing to load ABIs, understand how to interact or read from the contract and load human readable data.

Other useful endpoints:

If you’re new to, you can

Get Started for Free here →

Email support if you have questions about migration at:

Until the next update, stay safe & healthy.