Created a new Ponder chat including full history from the old one - come say hi! https://t.me/pondersh

7 replies

9 recasts

53 reactions

What gives?

1 reply

0 recast

0 reaction

Just finished the first page of Ponder's new docs website

7 replies

2 recasts

30 reactions

Are there any examples of developers building an SDK* with ponder for a specific project (eg set of contracts) that other developers can easily drop into their own ponder indexer? * I don’t know the right terminology here… module? plugin?

1 reply

0 recast

2 reactions

Ponder 0.10 This release speeds up large factories and contract reads, adds a new `event­.id` property, and fixes several reliability issues →

1 reply

2 recasts

11 reactions

Is Ponder a good starting point to build a Frame?

1 reply

0 recast

3 reactions

I've recently deployed a few Ponder installations on Railway, and thought that I could make a template so that it's easier for others: https://railway.com/template/ma-2Wo I'm keen to know about any requests. Some ideas I've had: - Another template with a monorepo that includes a vite frontend - Integrating contract indexing into this existing template, as a quickstart

0 reply

0 recast

3 reactions

Goal: By the end of 2025, even the largest Ponder app backfills will be fast enough to run in CI. Seconds or minutes, not hours or days. It should feel like a build or reload, not a "backfill".

4 replies

2 recasts

33 reactions

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).

2 replies

2 recasts

28 reactions

Introducing Ponder 0.9 We built a SQL-based alternative to GraphQL, with live query support and a TanStack Query integration. Apps & websites that use Ponder for indexing are about to feel much faster →

20 replies

37 recasts

217 reactions

iykyk

2 replies

0 recast

36 reactions

Fun debugging rabbit hole from this week. Last week, a few Ponder users opened issues for an "invalid byte sequence for encoding "UTF8": 0x00" error. Most software ignores or removes null characters (\0, \x00, or \u0000), but the Postgres TEXT data type rejects them with that error. We reproduced the issue with an ENS NameRegistered event log from 2022 (s/o @greg). Turns out, some EVM event logs contain null characters within decoded `string` parameter values. Now, the framework removes null characters from all decoded ABI parameters before passing them to userland. We could have instead fixed this on the PG driver/Drizzle side, but it seemed more fragile (are we wrong?). We're not certain why this only appeared recently - we haven't changed any relevant codepaths in recent releases. My best guess is that Viem used to remove them but stopped. Viem is a peer dep, so the version can change independently from Ponder's version. PR: https://github.com/ponder-sh/ponder/pull/1414

1 reply

1 recast

20 reactions

Two of the top 20 built with ponder, possibly more

2 replies

3 recasts

14 reactions

Yes I have abandoned GraphQL despite supporting it in the past /s (but not really)

5 replies

6 recasts

22 reactions

Introducing Ponder 0.8 Native transfer indexing, `ponder` NPM package, support for 16 new Viem actions, and a simpler pattern for Direct SQL →

2 replies

3 recasts

35 reactions