Sandwich Trades

Table Details

Property	Value
Table Name	`ethereum.dex.sandwich_trades`
Table Status	Production-Ready
Unique Key	`block_timestamp`, `unique_id`
Clustering Key(s)	`block_timestamp::date`

Table Columns

Column Name	Data Type	Description
direction	VARCHAR(134217728)	Indicates
project	VARCHAR(134217728)	Business name of the protocol being used (e.g. `uniswap`, `aave`, `lido`, `paraswap`). Consistent across verticals — every table with a `project` column uses this field to identify the top-level protocol brand.
protocol	VARCHAR(134217728)	The protocol used within the project
block_timestamp	TIMESTAMP_NTZ(9)	The timestamp of the block containing the trade
block_number	NUMBER(38,0)	The block number containing the trade
transaction_index	NUMBER(38,0)	The index of the transaction within the block
sandwich_transaction_index	NUMBER(38,0)	The transaction index of the corresponding sandwich within the block (back/front)
log_index	NUMBER(38,0)	The index of the log within the block
transaction_hash	VARCHAR(66)	The hash of the transaction
sandwich_transaction_hash	VARCHAR(66)	The hash of the corresponding end of sandwich (back/front)
liquidity_pool_address	VARCHAR(42)	The address of the liquidity pool involved in the trade
transaction_from_address	VARCHAR(42)	The address initiating the transaction
transaction_to_address	VARCHAR(42)	The address receiving the transaction
token_sold_address	VARCHAR(42)	The address of the token sold in the transaction
token_sold_symbol	VARCHAR(134217728)	The symbol of the token sold in the transaction
token_sold_name	VARCHAR(134217728)	The name of the token sold in the transaction
token_sold_amount	FLOAT	The amount of the token sold
token_sold_amount_str	VARCHAR(134217728)	The amount of the token sold, in string format for precision.
token_sold_amount_raw	VARCHAR(134217728)	The raw string representation of the amount of the token sold
token_bought_address	VARCHAR(42)	The address of the token bought in the transaction
token_bought_symbol	VARCHAR(134217728)	The symbol of the token bought in the transaction
token_bought_name	VARCHAR(134217728)	The name of the token bought in the transaction
token_bought_amount	FLOAT	The amount of the token bought
token_bought_amount_str	VARCHAR(134217728)	The amount of the token bought, in string format for precision.
token_bought_amount_raw	VARCHAR(134217728)	The raw string representation of the amount of the token bought
usd_amount	FLOAT	The USD value of the swap log
sender_address	VARCHAR(42)	The address of the sender in the swap
recipient_address	VARCHAR(42)	The address of the recipient in the swap
unique_id	VARCHAR(134217728)	The unique identifier for the transaction
_created_at	TIMESTAMP_NTZ(9)	Timestamp of when the entry was created in the database.
_updated_at	TIMESTAMP_NTZ(9)	Timestamp of when the entry was last updated in the database.

Sandwich Trades Table

The Sandwich Trades table captures DEX events where sandwich trading activity is detected. Sandwich trading involves placing two trades (a front-run and a back-run) around a victim’s trade to manipulate the market price for profit.

Sample Query

Finding the total USD amount of sandwich trades by project and date:

select 
  date_trunc('week', block_timestamp) as date,
  project,
  sum(usd_amount) as sandwich_trade_volume_usd
from ethereum.dex.sandwich_trades
group by date, project

Methodology

We use the dex.trades table to construct this table. This table contains all trade events from DEX protocols. We identify sandwich trades using the following criteria:

Trade Pair Identification:
- The sandwich trade (swap1 , swap2) must occur within the same block.
- It must be executed in the same liquidity pool (same liquidity_pool_address).
- It must be executed by the same signer (transaction_from_address).
- The transaction indices must be different (transaction_index).
Direction Determination:
- If s1.transaction_index > s2.transaction_index, the trade is a “back” part of the sandwich.
- If s1.transaction_index < s2.transaction_index, the trade is a “front” part of the sandwich.
Token Matching:
- The token bought in the first trade (s1) must match the token sold in the second trade (s2).
- Alternatively, the token sold in the first trade (s1) should be the token bought in the second trade (s2).

Exclusion of Non-Applicable Projects:

Exclude DEXs without the concept of liquidity pools, such as RFQ protocols like Airswap.

Overview

Data Verticals

Solana

Hyperliquid

Lighter

Bitcoin Ecosystem

EVM

Cosmos Ecosystem

Move Ecosystem

Other Ecosystems

Table Details

Table Columns

Sandwich Trades Table

Sample Query

Methodology

​Table Details

​Table Columns

​Sandwich Trades Table

​Sample Query

​Methodology

Table Details

Table Columns

Sandwich Trades Table

Sample Query

Methodology