ENSEngine
Vision
Section titled “Vision”Make ENS state changes subscribable.
Today, building an app that reacts to ENS - when an avatar changes, when a name is transferred, when a renewal happens - means either polling endlessly or running your own indexer. Both are heavy. ENSEngine exists to remove that work and turn ENS into a push-based protocol from the consumer’s point of view: subscribe, get notified, build.
What it is
Section titled “What it is”ENSEngine is the part of ENSNode that watches your ENSDb for changes in real time and delivers ENS-aware events - including webhooks - to any sink you configure.
It sits alongside ENSIndexer, ENSDb, ENSRainbow, ENSApi, and ENSAdmin as the home for reactive / event-based functionality across the ENSNode stack.
How it works
Section titled “How it works”flowchart TD Indexer["ENSIndexer
(keeps ENSDb up to date)"] Db["ENSDb
(live onchain state of ENS)"] subgraph engine [ENSEngine] Watch["Watches ENSDb for changes"] Process["Enriches, filters, transforms, routes ENS events"] Watch --> Process end Sinks["Your sinks: webhooks, cache invalidation, notifications, db sync, ..."] Indexer --> Db Db --> engine engine --> Sinks
In one sentence: ENSIndexer keeps ENSDb fresh, ENSEngine watches ENSDb for changes and turns them into ENS-aware events for any sink you configure.
The internal pipeline is intentionally simple to describe:
- Watch - observe ENSDb in real time as ENSIndexer updates it.
- Enrich - attach ENS-level context to raw changes so consumers don’t have to.
- Filter - apply subscription rules so each sink only sees events it cares about.
- Transform - shape events into the right payload for each sink type.
- Route - deliver to webhooks, cache-invalidation hooks, database sync targets, notification systems, and more.
Implementation details behind the watch layer are intentionally not part of this teaser. Those will land in dedicated docs when the service ships.
What it unlocks
Section titled “What it unlocks”The top priority for ENSEngine is cache invalidation. The goal is an ENS-native invalidation signal that lets apps and CDNs cache ENS data much more aggressively, then react when relevant onchain state changes. That’s the foundation for web2-grade latency on a web3 protocol, especially for high-traffic ENS profile views.
Additional key use cases:
- Notification services - name-expiry reminders, transfer alerts, activity bots in Discord/Telegram/Twitter.
- Sync to alternative databases - want to store alternative representations of ENSDb in databases that provide specialized benefits that Postgres doesn’t offer, such as Elasticsearch, Typesense, Meilisearch, Redis, Kafka, Google BigQuery, and more? ENSEngine will ensure 100% delivery of database changes to sinks with strict ordering and exactly-once processing.
- Realtime dashboards - surface ENS analytics and activity data as it happens.
For a longer use-case-focused overview from the integrate perspective, see the ENSEngine teaser.
Position in the ENSNode stack
Section titled “Position in the ENSNode stack”ENSEngine is one of several planned and existing services that build on top of ENSDb. ENSDb is the open standard that holds the live, onchain state of ENS in a plain PostgreSQL database. From there, different services consume that state in different ways:
- ENSApi - pull model: GraphQL / REST APIs for clients.
- ensdb-cli & ENSDb snapshots - operational model: portable snapshots and CLI tooling.
- ENSEngine - push model: real-time, ENS-aware events delivered to your sinks.