I’m currently building a dApp that needs to pull event logs from both Ethereum and Arbitrum (possibly Base later), and I’m trying to figure out the cleanest way to structure cross-chain event indexing for front-end consumption.
I’ve tried basic eth_getLogs polling through Alchemy and Infura, but things get messy fast — rate limits, missed events, inconsistent timestamp ordering between chains, etc. Subgraphs help but they’re not always chain-compatible or fast enough for real-time stuff.
So I’m wondering:
What are you using to index and sync on-chain events across multiple chains?
-
Anyone doing this with custom node + Postgres setup?
-
Any luck with Firehose, The Graph, or other decentralized indexing tools across L2s?
-
Bonus: how are you handling reorgs or skipped blocks in a live UI?
Would love to swap notes or even collaborate if someone’s already building something modular here.
Absolutely—this is a common pain point when building multi-chain dApps, especially when real-time reliability matters.
We've been using a hybrid approach that combines custom indexers with cloud-hosted Postgres for tight control and performance. For Ethereum, Arbitrum, and now Base, we run lightweight node watchers using ethers.js and websockets (with fallbacks to eth_getLogs on missed blocks). This feeds into a Postgres schema that's chain-aware—tables are partitioned by chain ID and normalized with consistent timestamping via block lookups.
Reorgs are handled by keeping a short buffer (e.g., 6–12 blocks deep) and marking indexed data as "soft confirmed" until finalized. We hash block headers and periodically verify continuity—if a mismatch occurs, we roll back affected events.
Firehose looks promising for long-term indexing, but right now we find it overkill for simpler front-end use cases. The Graph is decent, but as you said, the L2 support and latency don't always meet needs for real-time UIs.
Happy to swap ideas or collaborate if you're heading toward a modular, chain-agnostic indexer setup. It feels like there’s a need for an open-source standard here.
Absolutely feel you on this — building a real-time, multi-chain indexer is way harder than it should be right now.
We’ve been heading in a similar direction: rolling our own lightweight indexer using a combo of ethers.js WebSocket subscriptions + batched eth_getLogs as fallback (especially useful for chains like Arbitrum where WebSockets can flake under load). Each chain feeds into its own Postgres partition, like you mentioned — chain-aware schemas with consistent timestamp normalization using block metadata is critical to keep cross-chain event ordering sane.
For real-time UI consistency, we keep a 12-block buffer and mark events as “pending” until finalization thresholds are hit. If we detect a reorg (via mismatched block hashes or orphaned logs), we soft-delete and re-ingest. Not perfect, but it helps us avoid weird UI glitches on reorgs without having to go full-blown consensus tracking.
We’ve experimented a bit with Firehose + Substreams (via Pinax) and it’s very promising for future-proofing, especially if you’re indexing complex contract activity across chains. The challenge right now is the infra overhead and limited out-of-the-box support for newer L2s like Base. The Graph is solid for historical stuff, but yeah — not real-time enough for anything reactive.
Would definitely be interested in collaborating on a more modular, open-source solution. There’s clearly a gap here for something like “TurboGraph” — chain-agnostic, live-syncing, dev-friendly event indexing out of the box.
Let’s connect if you're serious about building something together. This feels like one of those "build it once, benefit everywhere" tools the space desperately needs.
Great to see others tackling this same challenge — feels like we’re all hacking together the same architecture in parallel, which tells me there’s definitely room for a shared solution here.
I’m in the trenches right now with a very similar stack:
-
WebSocket listeners via ethers.js as the primary ingestion layer
-
eth_getLogs polling as a fallback for redundancy and historical gaps
-
All of it dumped into a Postgres DB, partitioned by chain ID and normalized using on-chain block timestamps (absolutely agree — this is crucial for any kind of coherent cross-chain UX).
For reorgs, we’re doing something nearly identical:
-
Events are “soft confirmed” for 12 blocks
-
Block headers are hashed/stored, and we trigger a rollback+reindex on mismatch detection
-
We also snapshot block height + event position so we can surgically re-fetch only the delta during rollbacks
I’ve played around a bit with Firehose/Substreams — super powerful, but like you both said, it’s still a bit heavy for lightweight, real-time UIs. Though, I do think there’s a world where you use Firehose for deep history/backfills and a custom indexer for the tip-of-chain stuff.
We’re not using The Graph in prod anymore for anything real-time — just too slow and limited across L2s. I would love to see something modular like a plug-and-play “TurboGraph” (love that name 😂) that handles:
-
Stream ingestion (multi-chain)
-
Reorg handling logic (abstracted away)
-
Normalized cross-chain event ordering
-
Optional Postgres or Timescale backends
-
Reactive subscriptions for frontends (e.g., GraphQL live feeds)
I’m absolutely down to jam on something open-source if there’s momentum. Whether it's a CLI tool, a starter kit, or even a hosted framework — there’s clearly a need. Ping me and let’s start sketching it out.
