DeFi and DEX data: swaps, liquidations, and full execution traces
A DEX swap settles its token movement in nested internal calls; an event-log-only feed sees the receipt, not the execution. SQD serves logs, transactions, traces, and state diffs from one endpoint, across 225+ networks, so the path of a swap or a liquidation is in scope, not out of reach.
A DeFi transaction's real work happens in its internal calls, not its event logs
A Uniswap swap routed through three contracts is one submitted transaction and a tree of internal calls underneath; a Compound liquidation moves value through delegate calls across several contracts. An indexer that only reads event logs sees the receipt each contract emitted, never the calls that moved the value, so the swap path and the liquidation path stay out of reach. Reconstructing them, or catching a new pool the moment its factory deploys it, means reading the execution itself. SQD serves logs, transactions, traces, and state diffs from one endpoint across 225+ networks.
Most indexers stop at event logs. That is the receipt, not the execution.
The gap between the receipt and the execution is measurable. Over 20 Ethereum blocks (21,000,000 to 21,000,020), USDC was the direct recipient of 66 transactions but was called 260 times once internal calls are counted. The 194-call difference happened inside transactions aimed at routers, aggregators, and multisigs, and a transaction filter cannot see any of it.
- transactions where to = USDC66
- calls where callTo = USDC260
- internal calls a tx filter misses194
Trace-level data is what production indexers run on: GMX moved multichain perp data off subgraphs, Curvance indexes on Monad, and Levr.Bet runs prediction-market data on SQD.
The query that finds every internal call into a contract filters the trace stream by call type and callee:
Two gotchas: the response nests fields under action (callTo arrives as action.to, the call type as action.callType, which separates a call from a delegatecall), and a trace carries a transactionIndex, not a transaction hash, so to tie a hop to a hash you request the transaction. callValue on each hop is the ETH moved there.
Catch new pools the moment they deploy
A contract deployment is a create trace, so the same trace stream is a deployment registry. Filter traces by type create and you get the deployer and the new address, including pools created by a factory or by CREATE2 that a transaction list never surfaces as deployments. The first deployment in block 21,000,000:
Deployer 0xcdc1…89b8 created 0x521d…7f23. For DeFi that means tracking a factory's new pools from the trace stream, no hand-maintained address list. The full walkthrough is in the internal transactions guide.
Try the Portal API
Live queries against real blockchain data. Pick a network, choose a query, hit run.
The public endpoint is free for development. See plans for dedicated portals and higher limits.
Ethereumethereum-mainnet/streamTeams already running this on SQD
Built for DeFi & Trading at scale
Cross-chain swap and pool indexing
Track swap, mint, burn, and sync events across AMMs on any EVM chain with one query shape. The same handler reads Uniswap V3 on Ethereum and PancakeSwap on BNB Chain; Solana AMMs use the Solana instruction shape, not EVM logs.
Liquidation and risk monitoring
Stream borrow, repay, and liquidation events from Aave, Compound, Morpho, and any lending protocol. Combine state diffs with event logs to recompute collateralization per block, the inputs a liquidation keeper or risk engine runs on.
Traces and state diffs, not just logs
Full execution traces and state diffs expose the internal calls and storage writes event logs omit. Reconstruct the exact execution order in a block, the swap path, the liquidation path, the value an event-only feed never sees.
MEV and order-flow analysis
Transaction traces and state diffs expose sandwich attacks, arbitrage paths, and front-running. Reconstruct the execution order within a block, including the internal and delegate calls basic event indexing misses entirely.
What you would build yourself
The events are public onchain; the work a provider saves you is reading the execution underneath them, the internal calls and storage writes a log-only feed omits.
- Internal calls Yourself A log-only indexer sees the receipt each contract emitted, never the nested internal calls a swap or a delegate-call liquidation moved value through.With SQD The trace stream returns every internal call, filtered by call type and callee, so the full swap or liquidation path is in scope.
- New pool discovery Yourself Pools created by a factory or by CREATE2 never surface as deployments in a transaction list, so tracking them falls back to a hand-maintained address list.With SQD A contract deployment is a create trace: filter traces by type create and a factory's new pools arrive with deployer and address.
- Liquidation inputs Yourself Event logs alone give the liquidation event but not the storage writes behind the collateralization that triggered it.With SQD State diffs and event logs arrive together, the inputs to recompute collateralization per block that a keeper runs on.
- MEV reconstruction Yourself Basic event indexing misses the internal and delegate calls entirely, so sandwiches and arbitrage paths stay hidden.With SQD Transaction traces and state diffs expose sandwich attacks, arbitrage paths, and the execution order within a block.
See this on your own contracts
Tell us the chains and contracts you care about, and we will show you the query that returns them.
What teams build with SQD
- Protocol analytics dashboards with cross-chain aggregation
- Yield and APY backends computed from onchain events
- Liquidation keepers and risk engines from event and state-diff streams
- DEX aggregator data feeds across 225+ networks
- MEV and order-flow reconstruction from traces
- PnL and accounting from decoded swap and transfer history
Robinhood issues tokenized stocks as plain ERC-20s on its Arbitrum Orbit L2: the contracts behind TSLA, NVDA, and the SpaceX token, issuance and redemptions at the zero address, and a real after-hours trade read straight from the chain.
An agent answers whole-market Hyperliquid perp questions through the same analytics, OHLC, and query tools it uses for every other chain.
One declarative query reads Solana program activity by program ID and discriminator, and surfaces the failed and uncommitted calls most tools drop.
A worked Pipes SDK example: stream the full Hyperliquid fills tape into your own ClickHouse, rank traders by realized PnL, and split volume into crypto versus TradFi markets.
The Hyperliquid fills dataset: what a fill record holds, maker and taker fees, realized PnL from closing trades, and how to separate crypto markets from the TradFi and HIP-3 listings on the same venue.
What an internal transaction is, why event logs and the transaction list miss it, what a trace record contains, and why traces are one of the most expensive things to pull from an RPC node.
Frequently asked questions
What DEX data does SQD serve?
Does SQD support liquidation events?
Which DEXes are pre-indexed?
Other ways teams use SQD
See all solutionsDecoded events and traces streamed into the warehouse you already run.
Pre-decoded onchain data for agents, over MCP or plain HTTP.
Address-keyed history: transfers, native and internal value, NFT moves.
Traces and state diffs, the execution footprint logs alone never show.
Mints, transfers, and marketplace sales, decoded from one log stream.
Your blockchain data infrastructure, handled.
Private Portal. Dedicated. Validated. Managed. Tell us what you're building, we'll show you what it looks like on SQD.
validated data
for Enterprise
serving data