Engineering @monad @ponder_sh. EVM, TypeScript, open-source enjoyer

Brooklyn, NY
Based in United States
Replying to @what_the_func
I was curious about this question too - here's a subset of popular etherscan-style API endpoints & which ones could be replaced by these methods. These methods can also probably be composed with other standard methods to replace more endpoints.
1
9
263
Example: fetch every USDC transfer to an account, including the parent block timestamp. This returns the full transfer history (256 transfers spanning 68M blocks) in *one request* on an experimental Monad Mainnet endpoint.
2
1
26
1,395
Excited to propose five new JSON-RPC methods to fetch EVM blockchain history: blocks, transactions, logs, traces, and native transfers. These methods address longstanding Ethereum data problems at the protocol layer, through an open standard that any EVM chain can adopt.
46
45
390
55,930
Big news: the Ponder team has joined the Monad Foundation. We’re excited to contribute open-source tooling and standards that help applications take full advantage of Monad's performance and decentralization.
71
17
290
74,849
Today's Ponder release introduces a new indexing mode where each chain runs on a separate worker thread. The new design offers big benefits across indexing & query performance, and paves the way for better caching, reliability, and DX.
5
6
44
4,377
We also added support for custom database views, powered by Drizzle. This makes it easy to move data transformation logic from indexing-time to query-time, and expose the results in the GraphQL API. Docs: ponder.sh/docs/schema/views
1
126
We made big internal changes to Ponder in recent months. When the dust settled, we realized that our log output needed some love. The new logs have great signal-to-noise, consistent language, and eliminate issues where Ponder appeared to "hang".
1
2
154
Ponder 0.14 → * We redesigned every log line that Ponder emits * Custom database views * Offset pagination in GraphQL * Better performance & reliability across the board
2
6
23
1,018
By default, Ponder uses HTTP polling with a 1s interval. Reliable, but can become a latency bottleneck. This benchmark measures (block arrival timestamp - block header timestamp), averaged over 24 hours indexing WETH transfers on these chains.
1
6
576
Ponder now supports WebSockets (eth_subscribe) for new block notifications. Opt-in to improve realtime indexing latency by ~35% and consume fewer RPC credits. S/o @opaquefeldspar for the excellent work on this.
10
8
88
6,181
That’s why we created Marble — a cloud platform for custom offchain code, starting with Ponder indexers. Alongside Ponder’s excellent local dev experience, we now have fast, intuitive, and production-grade hosting infrastructure.
4
1
23
3,643
Introducing Marble. Marble is a platform for offchain software, built by the team behind Ponder. We're making it radically easier to build fast & reliable backend systems for crypto apps.
50
23
361
42,448
We updated the RPC configuration to simply accept a list of URLs for each chain. Ponder uses intelligent logic to load balance, fallback, and avoid rate limits across all endpoints. To improve throughput or reliability, just add another RPC URL.
1
5
185
Our new website is built with vocs, an excellent docs framework from the @wevm_dev team. We also rewrote dozens of pages with more clarity, redesigned the navigation, and added a version picker. ponder.sh/docs/get-started
1
5
215
Ponder 0.11 → We shipped a new docs website, made it easier to query Ponder tables directly in Postgres, and eliminated a bunch of RPC endpoint footguns.
4
7
64
4,325
Replying to @PaulRBerg
2
4
200
Thanks @Optimism for funding Ponder!
The results are in and Optimism has allocated 2M+ OP for this month's rewards for Dev tooling and Onchain Builders.
9
5
109
9,797
The new `event.­id` property is a globally unique ID for a log, transaction, block, or trace that works across all chains. For tables that don't have a logical unique constraint, `event.­id` is a good option for primary key values.
1
87
Ponder's factory pattern collects a list of addresses from decoded event logs, then plugs that list anywhere in your config. Before this release, the address list was built on-the-fly and filtering ran in SQL. This didn't scale well.
1
1
108
Ponder 0.10 This release speeds up large factories and contract reads, adds a new `event­.id` property, and fixes several reliability issues →
1
3
24
1,537
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.
2
166
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).
5
2
14
1,280
We also shipped @­ponder/react, a library that makes it easy to use the SQL client in any React app. It extends TanStack Query – a familiar experience for Wagmi users. The usePonderQuery hook uses a live query to re-render whenever the query result has changed.
1
1
16
482
The client library also supports live queries, powered by HTTP server-sent events, which update whenever a new block gets indexed. For latency-sensitive apps, live queries are a *huge* improvement over polling the GraphQL API.
1
11
346
This release introduces a new option – @­ponder/client, a SQL library for querying indexed data over HTTP. Write SQL queries directly from your frontend (or any JS code) using Drizzle with full-stack type inference.
1
1
9
399
Introducing Ponder 0.9 We built an SQL-based alternative to GraphQL, with live query support and a @Tan_Stack Query integration. Apps & websites that use Ponder for indexing are about to feel much faster →
13
14
130
8,291
iykyk
8
2
48
2,246
It finally happened
Are there any protocols that use a "nested" factory contract pattern? E.g. a factory contract that creates factory contracts that create child/implementation/logic contracts
3
32
1,558
Yes I have abandoned GraphQL despite supporting it in the past /s (but not really)
3
2
22
1,850
0.8 changes the pattern that Ponder uses for database schemas & table names. We removed most of the magic in favor of a simple + configurable design. Pass the schema name via env var or CLI option, and Ponder will use that schema - no table name tricks or views.
1
5
268
Ponder supports ad-hoc RPC requests during indexing, and caches the results to keep reindexing fast. It's an essential escape hatch when event logs fall short. This release adds 16 new Viem actions to `context.client`, including simulateContract and the ENS actions.
1
6
200
We received the `ponder` NPM package name! Huge thanks to the previous owner for donating it. We also took this opportunity to ship some long-overdue naming changes and QoL improvements.
1
1
12
224
Indexing native EVM transfers is famously difficult. Now, you can simply register an account (or account factory) and index all transfers to or from the address. Shout out @opaquefeldspar for an epic set of contributions on this.
1
8
253
Introducing Ponder 0.8 Native transfer indexing, `ponder` NPM package, support for 16 new Viem actions, and a simpler pattern for Direct SQL →
6
8
82
4,947
Built-in database drivers are more important for bun than nodejs compat & stability
Replying to @jarredsumner
Jarred, I’m really appreciate what you & your team are doing, I love Bun, that’s why I commented straightforward. But if you keep adding more features (especially builtin stuffs) like this, the time to make Bun replace Nodejs will be all taken, and Bun will never make it, because it would make the maintenance become super challenging. These stuffs are not hard with any developers, if they want to use it, they just need to install it, that’s it. Another thing is not everyone wants to use Postgres, so what’s next? MongoDB builtin? (Well, I can understand when you got sqlite builtin, it helps people to bootstrap faster) I can’t remember how many times I tried to convince my team to use Bun instead of Node, but it all ended up with switching back because of some random errors… Please understand that I’m not trying to criticize, I’m just saying out loud my wish. Hopefully it could help.
1
9
782
Just shipped Ponder 0.7.7 which adds a `totalCount` field to the GraphQL page type. This is actually pretty handy for some paginated UI patterns, and is also probably the fastest way to check how many rows there are in a table. github.com/ponder-sh/ponder/…
12
354
The new Drizzle-based schema API also makes Ponder much more portable. You can import the table objects and query them from any TS code, e.g. a React Server Component elsewhere in your monorepo.
1
10
407
Most writes in a Ponder app use a subset of SQL that runs in-memory and flushes to the database in large batches. It’s really fast. For more complex logic, you can now drop down to raw SQL without losing automatic reorg resistance. @kyscott18 absolutely cooked with this one.
2
14
568
We started experimenting with PGlite last month, and have been impressed by the performance, usability, and growing ecosystem around it. Huge thanks to @samwillis for creating PGlite (pglite.dev) and @ElectricSQL + @supabase for sponsoring its development.
1
1
17
521
Introducing Ponder 0.7 PGlite, Drizzle, raw SQL, portable table objects, and more. It’s our biggest release since 0.1 →
6
12
107
15,296
Replying to @FUCORY
Hard to say without more context, but - food for thought
1
1
155
Replying to @peter_szilagyi
Have never seen it used Also EIP-1767 is perhaps fraught with assumptions based on geth implementation details, which may not hold for other eth clients and other EVM chains
1
70
The Viem peer dependency requirement is now `>=2`, which improves compatibility in monorepos. Newer versions of Viem also include an address checksum cache, which will speed up some Ponder apps.
1
3
303
Ponder 0.6.0 improves observability, simplifies self hosting, and updates to the latest version of Viem. - New /ready endpoint - Terminal UI improvements (req/s, latest block) - Better ETA formula
6
5
66
3,639
Sick to see Ponder mentioned alongside these JS x Ethereum heavyweights - thanks @awkweb! So much more to build.
modern js for ethereum by @awkweb with the shout-out to @NoahZinsmeister
3
2
52
3,959
You won't see it on GitHub, but today is a huge day here at Ponder HQ.
5
1
48
1,929
The GraphQL client developer experience is cumbersome compared to TypeScript-native tools like tRPC. We have work planned that builds on API functions to improve the client/server experience further. More soon.
1
3
297
Why build API functions? The automatic GraphQL API is too rigid. With more flexibility at the API layer, users can simplify their data models and indexing logic. Example: Don't create a "volume" or "chart" table, just write a simple aggregation query.
1
4
301
Introducing API functions With today's 0.5.0 release, you can build custom API endpoints directly in your Ponder app. Use cases - Replace GraphQL with tRPC or REST - Build SQL queries with Drizzle - Merge onchain & offchain data
4
6
71
3,821
Ponder is now 10-50x faster during historical indexing 0.4.37 introduces batched database writes & an in-memory cache for frequently accessed records Apps that use a remote database will be much faster
4
4
57
5,663
Ponder 0.4.35 improves support for Foundry/Anvil With a few lines of code, you can integrate Ponder with any Foundry development workflow using `forge script` Build your indexer alongside your smart contracts, all on your local machine
1
3
25
1,501
Replying to @frolic
study fortnite
2
2
151