top of page

Eta X Data

Data and metadata for smart order router project

1. Identifying the pools, DEXs and aggregators.

Pools

DEXs/Aggregators
  • Uniswap

  • Sushiswap

  • DexGuru

  • dYdX

  • 1inch.exchange

  • AirSwap

  • Bancor

  • CowSwap

  • Curve

  • Dodo

  • KyberSwap

  • Matcha

  • Mesa

  • Multichain

  • Oasis

  • Paraswap

  • RhinoFi

 

2. Employ our framework to systematically compare the top AMM protocols’ mechanics, illustrating their conservation functions, as well as slippage and divergence loss functions. 

 

Participants
  • Liquidity providers

  • Net Liquidity providers

  • Traders

  • MM

  • Protocols

 

Functions
  • Swap

  • Limit fill

  • SOR

  • Swap lot amount

  • Pairs

  • Net addresses

  • Total addresses

  • Total LPs

  • Net LPs

 

Economics
  • Liquidity reward

  • Staking reward

  • Fees fund

  • Liquidity withdrawal penalty

  • Swap fee - LPs fee for supplying exchange pairs

  • Gas fee

 

Core
  • Conservation function per pool

  • Pool mechanisms

    • Preset hyperparameters

    • State variables

    • Process variables

    • Functions

  • Pool structure

    • Asset-pair

    • Multi-asset

  • AMM mechanisms for liquidity providers

  • AMM mechanisms for traders.

Risk - LPs
  • Divergence loss

  • Volatility risk

  • Impermanent loss

  • Time lock - The loss of time value of locked funds

 

Risk - trader
  • Slippage

  • Impermanent loss

3. Data selection and classification

Raw

Pairs
Total Pairs
Liquidity concentration per pair (total QTY)
Liquidity concentration per pool (total assests) 
Total LPs
Unique LPs
Transactions - (15s)
Total address
Active addresses
Net addresses
Inflow assets (mempool and confirmed)
Total Inflow assets
Net Inflow assets
Outflow assets
Total outflow assets
Net outflow assets
Cumulative Vol
Total trading addresses
Unique trading addresses

Fees
Volume & Fees
ETH Gas fee

Enhanced

Liquidity Variation

Net Liquidity Variation

Market Depth

Inflow Volume

Total trading volume 1D

Total trading volume 7D

Total trading volume 30D

Total fees 1D

Total fees 7D

Total fees 30D

Average Transaction Size 1D

Average Transaction Size 7D

Average Transaction Size 30D

Indicators 

Trades Vol MA7
Trades Vol MA30
Volatility

Active Wallets Cnt

The sum count of unique wallets that were active in the network (either as a destination or source of a ledger change) that day. All unique wallets involved in a ledger change action (recipients and originators) are counted. This metric does not double-count wallets. In other words, if a wallet has been deemed active by being part of a ledger change, it is not counted again if it is subsequently involved in a transaction during the same time interval. Wallets represent groups of addresses that we estimate are owned by the same entity. They provide a better proxy for user behavior, since users often own more than one blockchain address.

Untitled spreadsheet - Google Sheets.jpg
Eta X Data
Identifying the Pools, DEXs and Aggregators.
Pools
DEXs/Aggregators
Employ our Framework...
Participants
Functions
Economics
Core
Risk - LPs
Risk - Trader
Data Selection and Classification
Raw
Enhanced
Indicator
Active Wallets Cnt
Data Collection

Data Collection (Jay)

Best source of data for Uniswap is their Subgraph API, which allows for queries of their entire history and indicators regarding swaps, tokens, pools, e.t.c. For the time being, this could be a good starting point for data collection, however it is insufficient for real-time data. 

 

For this to be done, we need to leverage an Ethereum node and set up event filters on specific smart contracts, namely the factory contract and individual pools. Each pool emits an event whenever a swap/mint/burn occurs, and provides information about the tokens and the amounts involved. By tracking each swap, we can get the live information we need. For indicators related to the platform itself, we could still rely on the Subgraph API, querying the factory to get things like total number of pools, total liquidity, total number of transactions, e.t.c. 

 

For reference, the Uniswap subgraph works in the same way I’m describing – it follows specific smart contracts and updates values stored in memory every block/event. Hence, an ideal solution would simply be a recreation of Uniswap’s subgraph but with live streaming capabilities. As of right now, we’re finalizing an engagement with Infura to get access to an Ethereum node and process an extremely high amount of daily requests (which we’ll need to interface with all of these contracts), and so that’s the main blocker for getting Ethereum data. I’ve already implemented a basic Uniswap data collector, but I’d like to overhaul it to get the data you guys are after. As I mentioned, we’re finalising the engagement with Infura, so this collector is currently offline as we are on the free tier and so can’t use as many requests as we need.

 

In terms of infrastructure, I was imagining a simple setup where these collectors would be running on EC2 instances, dockerized and deployed with EKS. It could be a better idea to break up the workload into different containers as we require different types of data (and for replication purposes). These would connect to an Infura node, sending requests and processing responses. They would then send this data over Kafka/Redis to our websocket server where live events could be subscribed to, as well as archiving data in S3 (and potentially stored in a database setup where it could be queried, maybe with our GraphQL server)

VnuaezxVr3aY8DVYtggi1Oz0MXwD99rtuA17sr5YBCsueVAfqKVSlOJVqTcyUwCI6K-Fm4XUgBq4sglZEz4z9xpPNE
bottom of page