Cardano Transactions as Enterprise Blockchain Events
I have been building an open source engine that turns raw Cardano chain data into structured events that applications can consume directly.
The core issue is simple. Most systems do not need blocks. They need signals. Address activity, asset movements, metadata, governance actions. Today every team rebuilds parsing, indexing, and filtering from first principles. The result is duplicated effort and inconsistent outputs across the ecosystem.
This engine connects to Ogmios and works at the transaction level. You define what matters through rules. Address match, policy and asset filters, metadata, governance activity, or even every transaction. The system evaluates each transaction once and emits CloudEvents 1.0 in real time.
Events are pushed into a queue that can run on any service provider. From there, any number of consumers can subscribe over HTTP or through gRPC streams. Consumers do not need Cardano specific tooling. They receive clean, structured events and process them in their own environment.
I tested this against Cardano mainnet starting a full year behind the chain tip with four rules running in parallel, including a full transaction match. The behaviour is measurable:
• 5 days of chain history processed in 14 minutes, around 500 times real time
• 22,000 blocks scanned and 192,000 transactions evaluated
• 270,000 events emitted across rules, sustaining around 320 events per second
• 90 percent of events published in under 1 ms
• 139 MB memory footprint
• Zero failed events and zero data loss
• Checkpoint recovery built in, restart continues from the exact position
The design choice is deliberate. Process once at the edge of the chain, then distribute clean data downstream. It removes repeated work, reduces failure points, and makes behaviour predictable across systems.
Other ecosystems often push this complexity into every application or rely on centralised indexers. This approach keeps the pipeline transparent and composable while still scaling to real workloads.
In practice this means faster integration, fewer moving parts, and consistent data across services, along with cost savings.
It is still in progress, but this demo shows four consumers run in separate docker containers, each subscribing to a single queue, each receiving only the events they care about and surfacing it's details, all fed by one chain sync process.
All of this is open sourced and will continue to be
github.com/ItsDaveB/OgmiosDo…