Skip to main content

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​

AlchemyBitquery (GraphQL)
alchemy_getAssetTransfersEVM { Transfers(...) }
Token balances / metadataEVM { Balances(...) }, Currency fields
NFT APINFT API
eth_getLogs (raw)EVM { Events(...) } (decoded)
Webhooks / NotifyWebSocket subscriptions / Kafka
Trace/debug for internal txsEVM { 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​