Skip to content
Integrating PancakeSwap into HuFi Using a Custom Subgraph: Why We Built Our Own Subgraph

Integrating PancakeSwap into HuFi Using a Custom Subgraph: Why We Built Our Own Subgraph

HuFi has always aimed to provide its users with the most reliable and comprehensive insight into decentralized finance. Integrating PancakeSwap into our platform was a natural step toward expanding our DeFi offerings—after all, PancakeSwap remains one of the largest automated market makers on the BNB Smart Chain. However, the process was far from straightforward. We encountered repeated issues with publicly hosted subgraphs (the indexing services that power data queries for smart contracts), which resulted in stale data, incomplete records and frequent outages. To solve this, we decided to build and operate our own PancakeSwap subgraph tailored for HuFi’s needs.

Why Subgraphs Matter in DeFi#

Blockchain applications generate massive amounts of on‑chain data. Querying this data efficiently is critical for modern Web3 products. Hosted subgraph indexing platforms solve this by running managed indexing pipelines that process blockchain data in real time and expose the indexed data through GraphQL APIs. These APIs power everything from price charts and liquidity dashboards to portfolio trackers. Without an up‑to‑date subgraph, user interfaces can display outdated values or fail entirely.

Problems with the Official PancakeSwap Subgraphs and Other Public Indexers#

When we began integrating PancakeSwap, we relied on the official subgraphs and third‑party hosts. Unfortunately, they consistently fell short:

  • Stuck Syncs: A public issue on the PancakeSwap V3 exchange subgraph noted that the indexing progress stalled at 70-80 % and never completed. As a result, data never reached the latest block.
  • Unreliable Endpoints: The StreamingFast endpoint later returned 504 gateway errors and “panic processing query” messages. Even alternative hosted solutions like Nodereal produced 500 internal server errors.

Beyond the official subgraph, we explored several community‑hosted alternatives. One of the most popular public subgraphs seemed promising at first, but during development we encountered “bad indexer” errors on certain queries, especially when the BNB network experienced heavy load. Another reliable option hosted by Messari provided stable results for recent data, yet attempting to query historical data older than about 10 days triggered similar “bad indexer” errors. These experiences highlighted that even well‑maintained public subgraphs might not meet our needs for long‑range queries or high‑traffic scenarios.

Why We Built a Custom Subgraph#

We concluded that relying on existing public subgraphs would compromise user experience. By defining our own subgraph and deploying it to The Graph network, we control the schema, the start block and the data we index, ensuring data freshness and allowing us to quickly adapt to protocol changes.

In addition, publicly hosted subgraphs often index every event from the protocol’s inception. While comprehensive, this approach increases sync times and stores data we don’t need. For HuFi, we primarily require swap events and recent liquidity information. Syncing from the contract’s genesis block would take weeks and lead to huge databases. We also wanted flexibility to restart the subgraph from a recent block (e.g., one week ago) and redeploy regularly to keep the dataset lean. Existing subgraphs didn’t offer that level of customization.

Implementation of the HuFi PancakeSwap Subgraph#

Our custom subgraph focuses almost entirely on swap events from PancakeSwap V3. This is the data we actually need for HuFi: who traded, when they traded, and how much volume was generated.

Instead of building and running our own indexing infrastructure, we define the subgraph schema and mappings and deploy them directly to The Graph network. The Graph takes care of indexing the blockchain and serving queries, while we stay in control of which events are indexed and how the data is shaped.

A few important details about how this works:

  • Swap-focused indexing (PancakeSwap V3): We primarily track Swap events emitted by PancakeSwap V3 pools. These events give us reliable, real-time trade data that can be used for verification and reward logic.
    We also index liquidity pool contracts, but mainly for linking purposes (for example, mapping swaps to pools and tokens). We intentionally do not rely on pool state to calculate liquidity amounts or balances, as that data is not always reliable or needed for our use case.
  • Deployment on The Graph: We deploy the subgraph using the standard Graph CLI (graph deploy) to the decentralized Graph network. This gives us availability and redundancy without having to operate our own Graph Node.
  • Selective synchronization with a recent start block: The subgraph is configured to start indexing from a recent startBlock. This keeps the dataset small and allows the subgraph to sync very quickly.
    Because we subscribe directly to swap events, redeploying the subgraph with a new start block still captures all relevant trades, without needing to replay the entire PancakeSwap history.
  • Token and pool filtering: We explicitly filter out tokens and pools we don’t want to track (for example, spam tokens or unsupported assets). This reduces noise and prevents unnecessary data ingestion.

By periodically redeploying the subgraph with an updated start block and configuration, we keep the indexed data focused on recent, relevant PancakeSwap V3 activity, while avoiding the cost and complexity of indexing every historical event.

Integration with HuFi#

Once operational, our subgraph became the backbone of HuFi’s PancakeSwap integration. It provides a dedicated GraphQL endpoint that feeds real-time, detailed trade data from PancakeSwap directly to HuFi’s oracles. This constant and reliable data flow is essential for two main reasons:

  • Trade verification: The oracles use this data to confirm that each relevant user trade actually happened and was executed correctly. This helps prevent manipulation and keeps the system honest.
  • Payout calculation: By using exact trade volumes, prices, and timestamps, the oracles can correctly calculate how much each user should be paid, ensuring rewards are fair and transparent.

Benefits for Users#

Our custom subgraph, deployed on The Graph network, delivers several tangible benefits:

  • Data Freshness: Because our subgraph starts from a recent block and resides on the decentralized Graph network, it stays synchronized with the latest BSC blocks.
  • Customization: We define the schema and mappings, so we can add new entities or metrics specific to HuFi.
  • Efficiency: Selective synchronization and targeted entities keep the subgraph lightweight, allowing it to sync quickly and serve queries efficiently.

By owning our indexing layer, HuFi can deliver the real‑time DeFi experience our users expect.