Aggregator Trades

• The aggregators use a variety of fill sources to fill the trade order. These can be found in the column FILL_SOURCES.
• This table has a USD_AMOUNTS column to gain visibility of the amounts traded at each of the hops.

​

Notes on referrers

• There is a class of aggregators termed ‘referrers’ who do not using a custom program to call their fill sources. Instead, the referrers call existing aggregators/AMMs in a direct instruction, but attach a subsequent instruction to transfer a fee for usage. e.g. of a pumpfun initiated by photon
• In our dataset, aggregator trades are represented with aggregator=<aggregator> and program_id=<aggregator's program_id>
• In contrast, referrer initiated trades are represented with aggregator=<referrer> and program_id=<underlying aggregator/amm's program id>

​

Known gaps

• Due to lack of the most updated IDL, okx aggregator decoding fails for instruction methods FillOrderByResolver PlatformFeeSplProxySwap PlatformFeeSolProxySwap CommissionFillOrder. Trades for these methods will be backfilled when IDL is available. Collectively, it is estimated that these methods take up 0.5-1% of okx aggregator swaps
• In dflow, there are cases such as this tx where the series of swaps resulted in excess intermediate assets leftover. These are currently termed as partial swaps and we do not include them in the final table. Partial swaps could be a result of:
  • one of the swap legs giving an output less than expected, resulting in the next swap leg not executing
  • one of the swap legs consuming less than expected inputs, resulting in leftover of the input asset

​

Data coverage

• dflow, jupv6, okx: All transactions are included, regardless of whether the fill source is part of our coverage in solana.dex.trades.
• All other aggregators: We rollup dex trades to get aggregator trades, so coverage is limited to that of solana.dex.trades.

​

Table Columns