DeFi Superstars Uniswap, Sushiswap (+ more) now supported with OHLCV & Trades in Amberdata.io

Published in

amberdata

8 min readDec 11, 2020

We’re thrilled to finally showcase the DeFi exchange activity as a first class citizen in the Amberdata.io product offering! We’ve received so many requests for this feature, and have been meticulous about integrating to deliver best in class data for your business.

Decentralized Exchanges (DEX) are a way for automated market makers or liquidity providers to effectively establish an assets price by a blockchain-backed asset reserve pool. Amberdata.io is the first data provider to deliver the full on-chain DEX history for trades and metrics, as well as aggregations like OHLCV for all DEX assets.

TLDR; We’ve launched DEX Trades, OHLCV endpoints & more within our REST APIs. Please reference the docs:

There are quite a few things to understand with DEX, so let’s jump in high level, then look at what it looks like to add to your business.

DEX: Blockchain’s answer to asset exchange

Decentralized exchanges rely on blockchain token holders to provide collateral assets as liquidity. Traditional exchanges like CME are similar, where there are market makers that provide collateral, fill bids/asks and make profit based on the asset price spread. For decentralized liquidity providers, their opportunity is different as the code within the blockchain specifies how both price and fees happen. In the case of Uniswap, price is established by a constant product function based on the amount of reserves (collateral) backing the pair.

This leads us to DEX Prices, which are established one of two ways:

1. Collateral Liquidity

Price based on collateral pools of liquidity, where prices is calculated by a function of its inputs. You can imagine a simple equation:

BASE / QUOTE = PRICE

This simple math, backed by some amount of collateral is the real innovation in blockchain. Its simple for many parties to agree upon the price for some asset trade AND liquidity providers are incentivized to establish a fair market price by maintaining liquidity that matches the outcome of a centralized exchange rate. Here’s an example of what I’m talking about (purposefully leaving out fees for example simplicity):

PAIR: DAI_WETH
CEX Price: ~$594DAI Reserves: 1000000 // ~$1M USD
WETH Reserves: 1683.5 // ~$1M USD
Function: 1000000 / 1683.5DEX Price: ~$594

Quick note on this pair: DAI is ~$1 matching USD as a stablecoin, WETH is $594 which closely follows ETH price as an ERC20 tokenized Ether.

2. Market Orderbooks

The most traditional way to establish price is with trade orderbooks. Buyers and sellers post what they want an asset price to be, and market makers fill the trade orders if they are willing to accept those terms. Orderbook based exchanges usually require a seat license to establish a stake or claim that they can back the transactions of the market trades. In the case of blockchain, it’s similar but with a few key differences:

DEX Trades are backed by tokenized assets
DEX Orderbooks are a 100% public representations of bids/asks
Liquidity is provided by the exchange itself rather than the decentralized community

Quick note on exchange liquidity: This is not 100% the case, I am referring to the top volume types.

3. Barter?

I said there were only two, however I believe its worth mentioning there is a possibility of a third price establishment scenario — Bartering using BYOL (Bring your own liquidity). This is something that is only possible using blockchain, because you can verifiably prove you have an asset without revealing how much. This means a price can be established differently depending on the asset, the negotiation with liquidity provider and the protocol agreement layer itself. I won’t go too far into this, as we are watching this type of trade just starting with projects like Injective protocol and other Layer 2 DEX solutions.

Pair Definitions by Underlying Assets

It’s worth a quick mention about how blockchain pairs are established. Since each pair is based on underlying assets, there are actually 2 different tokenized contracts that make up a pair. It was hinted at above, but needs calling out: Pairs represent duality of asset collateral, thus traditional model of “BASE_QUOTE” is actually insufficient. Both assets can be either side of the pair, both assets can be traded for the other — therefore price can actually be established BASE_QUOTE or QUOTE_BASE. More on this below.

Uniswap Deep Dive

There have been quite a few DEXs over the past few years, Kyber Network, Bancor, etc, but the main winner this year is Uniswap. As the leader as defined both by Total Value Locked (I might critique this definition later…) and trading volume, Uniswap has simplified the blockchain exchange process. The most notable improvements include the simple UI in addition to the protocol UX. Uniswap made the easiest SDK both for developers and on-chain contract integrations. This lead to a burst of integrations with apps like Argent, aggregators like 1Inch.exchange, and collateral leverage products like Aave. Uniswap boomed this year, but when code is released publicly there is often rivalry based on copy-cat contracts.

Enter a new fork: Sushiswap 🍣🍱

Late August/September there was a lot of chatter about DeFi defensibility, and how utilizing simple mechanisms like a DAO was all you needed to keep your protocol defensible from rival forks. Sushiswap took this concept and bootstrapped a clone, with extremely similar UI/UX, however they tweaked a few key parameters to incentivize liquidity providers to switch to sushiswap. Almost overnight, sushiswap took over the majority amount of trade volume from uniswap! This sent developers a message: You can create forks of public code and create a competitive advantage without much effort.
Uniswap immediately replied by releasing their UNI token, to incentivize liquiditidy providers, traders, previous traders & the ongoing usage of Uniswap protocol. When UNI launched, sushiswap was then less profitable for liquidity providers and began to slow in trade volume. The word about forks was out…

Enter the Fork Frenzy! 🍴🍴🍴🍴🍴

We’ve cataloged over 73 forks of Uniswap, several of which actually utilize the swap protocol as an added feature to their already well established applications. Yearn.finance, for example has deployed several uniswap forks!
All of these forks have brought real competition to the DEX market, which effectively benefits all traders.

At Amberdata.io, we cover all forks since we already index the entirety of Ethereum. Technically speaking, you can get data for every single DEX on ethereum, however the underlying data within a transaction is in a hard to use format — even harder to use for understanding things like total liquidity for an asset. With the REST APIs, DEX data sets are easy to use, we built the data to look and act like traditional exchange data formats: OHLCV & trade. This way, instead of needing to know the specifics of each type of DEX, you can simply request a DEX traded pair and get full historical OHLCV at the minute, hour, day intervals. You can even request data across several DEX with a single request!

Phew! That’s a lot of back story — now let’s dive into how to understand and access the data.

DEX Best practices:

The following best practices are here as a guide to make sure your application gets exactly the data expected. In Ethereum, the ERC20 standard allows for duplicate token symbols, which actually breaks the traditional pair and ticker symbol standards.

The important takeaway for using DEX data: Use Contract Addresses rather than Pair Names

Example:

DAI_WETH — This pair name covers assets that trade on both Uniswap, Sushiswap and others. On Uniswap itself, DAI & WETH separately have several cloned/same symbol ERC20s. If you just request DAI_WETH the data will include assets that are not the popularly traded “DAI” or “WETH”.

You may be wondering — how this is possible?

Since anyone can deploy an ERC20 contract to Ethereum, and use the symbol “DAI”, DEX’s were forced to create a different way of creating a uniquely addressable pair. Uniswap created pairs by using a combination of asset addresses and contract deployment address. A quick example: DAI_WETH lives at the contract address 0xa478c2975ab1ea89e8196811f51a7b7ade33eb11, but underneath uses the DAI contract address 0x6b175474e89094c44da98b954eedeac495271d0f and the WETH contract address 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2. The pair contract address is actually pre-computable based on the underlying assets by a special function in Ethereum: CREATE2. This guarantees that there can only ever be 1 contract address for 1 pair. It also guarantees that there can only be 1 pair for a set of 2 assets. Lastly, in Uniswap there is one more unique thing — I mentioned BASE & QUOTE order above, Uniswap establishes pair order by using a comparison of the HEX based Ethereum addresses. This guarantees a unified ordering of pair assets for purposes of calculating price.

A quick example of asset ordering in Uniswap for a pair: DAI_WETH

0x6b175474e89094c44da98b954eedeac495271d0f (DAI) < 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 (WETH) = true

If you take away anything from this blog post — it’s very important to use the pair address when accessing DEX data!

It’s also important to look at DEX exchange addresses as well. I mentioned the forks that happen, let’s look at what that means for each DEX contract:

Uniswap Exchange Factory: 0x5c69bee701ef814a2b6a3edd4b1652cb9cc5aa6f

To establish a DEX simply means holding a registry of pairs & assets that all act the same way from the underlying factory definitions. When a new pair is established on Uniswap, it uses the main Uniswap Factory contract to tell the world there is a new pair AND there is new liquidity backing the pair price. This triggers a PairCreated event on the blockchain. The parameters that establish the pair include the exchange contract, which allows pairs to guarantee different contract addresses per-exchange for same asset pairs.

Sushiswap Exchange Factory: 0xc0aee478e3658e2610c5f7a4a2e1777ce9e4f2ac

Just a quick reference, this shows how a forked contract actually lives on a different location but can use the exact same code.

DEX Trade Data

All DEX Trades exist on chain, however it’s not straight forward to interpret and query. We’ve indexed DEX trades so your business can easily query any pair for any time range. DEX trade data includes the asset amounts, price, exchange info and pair info.

Some Sample Code: DAI_WETH

curl -L -X GET 'https://web3api.io/api/v2/market/trades/dai_weth/historical?timeFormat=iso&exchange=uniswapv2' -H 'x-api-key: AMBERDATA_API_KEY'Response:
{
    "status": 200,
    "title": "OK",
    "description": "Successful request",
    "payload": {
        "data": [
            [
                "0x5c69bee701ef814a2b6a3edd4b1652cb9cc5aa6f",
                "2020-12-10T22:20:38.000Z",
                0,
                true,
                559.940101191248,
                33.09805938141467,
                "0x730a1ef27ed4e672b261a7ab0541019925aecf9ea85261edb0c08e367d2f3b29",
                305,
                "0xa478c2975ab1ea89e8196811f51a7b7ade33eb11",
                "0",
                "0.05911",
                "33.098059381414670101",
                "0",
                "0x7a250d5630b4cf539739df2c5dacb4c659f2488d",
                "0xb20bd5d04be54f870d5c0d3ca85d82b34b836405"
            ],
            ...
        ],
        "metadata": {
            ...
        }
    }
}

Combination Example (both Centralized & Decentralized): DAI_USDT

curl -L -X GET 'https://web3api.io/api/v2/market/trades/dai_usdt/historical?timeFormat=iso&exchange=uniswapv2,kraken' -H 'x-api-key: AMBERDATA_API_KEY'Response:
{
    "status": 200,
    "title": "OK",
    "description": "Successful request",
    "payload": {
        "data": [
            [
                "kraken",
                "2020-12-10T22:20:09.000Z",
                375400,
                true,
                1.00392,
                570,
                1607638809375400
            ],
            [
                "0x5c69bee701ef814a2b6a3edd4b1652cb9cc5aa6f",
                "2020-12-10T22:18:39.000Z",
                0,
                false,
                0.9988848473488455,
                179.91088392009556,
                "0x5b000558764bd9aa3c014120e502e683f58ec309960597c696e88852547c545c",
                238,
                "0xb20bd5d04be54f870d5c0d3ca85d82b34b836405",
                "179.910883920095561833",
                "0",
                "0",
                "180.111736",
                "0x7a250d5630b4cf539739df2c5dacb4c659f2488d",
                "0x61b62c5d56ccd158a38367ef2f539668a06356ab"
            ],
            ...
        ],
        "metadata": {
            ...
        }
    }
}

DEX OHLCV Data