Migrating from Alchemy to Bitquery

Alchemy is node-and-enhanced-API centric; Bitquery is a decoded, multi-chain data layer queried with GraphQL. This guide maps the common enhanced-API calls.

note

Verify chain/cube coverage against the coverage matrix.

Concept mapping

Alchemy	Bitquery (GraphQL)
alchemy_getAssetTransfers	EVM { Transfers(...) }
Token balances / metadata	EVM { Balances(...) }, Currency fields
NFT API	NFT API
eth_getLogs (raw)	EVM { Events(...) } (decoded)
Webhooks / Notify	WebSocket subscriptions / Kafka
Trace/debug for internal txs	EVM { Calls(...) } (decoded internal calls)

Example: asset transfers for an address

{
  EVM(network: eth, dataset: combined) {
    Transfers(
      where: { Transfer: { Receiver: { is: "0x..." } } }
      orderBy: { descending: Block_Time }
    ) {
      Block { Time }
      Transfer { Amount Currency { Symbol SmartContract } Sender }
      Transaction { Hash }
    }
  }
}

What differs

• Decoded, not raw. Events and internal calls come decoded, so you often skip client-side log parsing.
• Multi-chain in one schema. The same cube shape works across supported EVM chains (and Solana/Tron have parallel cubes).
• Delivery. Real-time via WebSocket/Kafka/gRPC.

Frequently Asked Questions

What replaces alchemy_getAssetTransfers?

The EVM Transfers cube with sender/receiver filters, ordered by Block_Time. It returns decoded transfers with currency metadata.

How do I get internal transactions?

Use the Calls cube, which returns decoded internal calls — no separate trace endpoint required.

Does Bitquery run nodes / RPC?

Bitquery is a decoded data layer queried via GraphQL and streams, not a JSON-RPC node provider. For decoded historical + real-time data, use the cubes.

Next steps

• Getting started
• Smart contract calls
• Data Coverage & Retention