Ponder

Ponder 0.9.3 adds a new event ordering strategy designed for low-latency apps that index 10+ chains.

The current ordering strategy is “omnichain” - events across all chains share a single queue, with blocks ordered by (block timestamp, chain ID, block number).

Building ponder.sh. EVM, TypeScript, open-source enjoyer.

To maintain this ordering guarantee in realtime, we must wait for a new block from the slowest chain (by block time) before we can process events from the queue.

For a base + mainnet app, worst-case latency for base events can approach 12 seconds (not acceptable).

The new “multichain” strategy is simple: for a given chain, index blocks immediately without regard for progress on other chains.

This solves the realtime latency issue, but leads to a non-deterministic order of events across chains.

Docs:

For apps that just index the same contract(s) on many chains, this is usually fine.

But some use cases (eg a bridge indexer) might need to continue using "omnichain" ordering.

Over time I expect "multichain" will become the default.

The new “multichain” strategy is simple: for a given chain, index blocks immediately without regard for progress on other chains.

This solves the realtime latency issue, but leads to a non-deterministic order of events across chains.

Docs: https://ponder.sh/docs/api-reference/config#event-ordering