> ## Documentation Index > Fetch the complete documentation index at: https://docs.monad.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Execution Events The **Execution Events** system allows developers to build high-performance applications that receive lowest-latency event data from a Monad node via a shared memory queue. In addition to low-latency applications, this system is also needed by programs that process very large *volumes* of blockchain data. To consume this real-time data, you write some data processing software in C, C++, or Rust using the software development kit described on this page, and run it on a host running the [Monad node software](/node-ops) built by Category Labs. This would be overkill for simple data processing use cases; see the [alternatives section](#alternatives-to-execution-events) for more convenient ways to consume Monad blockchain data. For comparisons to other systems such as Reth's ExEx or Solana Geyser, see the [comparisons](#comparisons-with-other-data-systems) section. ## Do I need execution events? If you're coming to Monad from other EVM blockchains, you might find your data processing is "not able to keep up" with the rate of data generated on Monad. This is because Monad is a fast blockchain, in two different dimensions: * New blocks are proposed every 400 milliseconds, or equivalently about 150 blocks every minute. * A single block can contain many more transactions compared to other blockchains; at peak processing rates, Monad can execute blocks containing thousands of transactions, and it was designed to sustain execution rates approaching 10,000 transactions per second (TPS). The popular [JSON-RPC data access APIs](/reference) were designed for the original Ethereum blockchain, which rarely exceeds 50 TPS. If you need a lot of data, or you need the most recent data very quickly, JSON-RPC simply won't scale. Data streaming over [WebSockets](/reference/websockets) can sometimes help, but not all data is published over WebSockets. If you're not able to keep up, you have two options: 1. *Build more sophisticated processing yourself* - you can use the execution events SDK to build the lowest-latency, highest-throughput data consumer possible. 2. *Use a third-party data service* - if you are not comfortable with systems programming (low-level backend programming in the C, C++, or Rust programming langauges) or if you simply don't have the time or interest, there are many third-party providers which provide data services for Monad. Typically these services will use the execution events SDK themselves, and then somehow filter, digest, or enrich the data so that you can get what you need more efficiently than the traditional JSON-RPC. Check out the [Tooling and Infrastructure](/tooling-and-infra) page for links to popular providers, particularly the [indexers](/tooling-and-infra/indexers) section although other services like [block explorers](/tooling-and-infra/block-explorers) sometimes provide data access APIs that might offer you what you need. ## What are "execution events"? The Category Labs [execution daemon](https://github.com/category-labs/monad/blob/main/docs/overview.md) contains a shared-memory communication system that publishes data about most actions taken by the EVM during transaction execution. The raw binary records of these EVM actions are called "execution events". Third-party applications that need the highest performance can run on the same host as the node software, and directly consume the execution event records from shared memory. To read this data, your third-party application calls functions in the execution event SDK, our real-time data library. The Solidity programming language also has a feature called [events](https://docs.soliditylang.org/en/latest/contracts.html#events). These are not the same thing as execution events. Solidity events are a programming-language-level abstraction of the Ethereum Virtual Machine's [low-level logging opcodes](https://www.evm.codes/?fork=prague#a0). The execution events system *does* record all log events, but it also records information about other things that happen during transaction execution, such as calls to other contracts, a list of accounts that were accessed by a transaction, and more. ## Execution events documentation * [Release notes](/execution-events/release-notes) - see what's new in the latest release of the SDK * [Getting started](/execution-events/getting-started) - describes how to build and run a simple example program * [Events overview](/execution-events/overview) - explains the core concepts in the execution events system * [Event rings in detail](/execution-events/event-ring) - documents event ring files and protocol versioning * API documentation - overview of our programming libraries, which are provided for several programming languages * [C API](/execution-events/c-api) * [Rust API](/execution-events/rust-api) * [Consensus events](/execution-events/consensus-events) - execution publishes some information from consensus that is essential for understanding real-time data * [Advanced topics](/execution-events/advanced) - documentation for advanced users and for software developers who contribute to the execution source code ## Alternatives to execution events Category Labs' node software includes an RPC server component. The RPC server supports two easier ways to read blockchain data: 1. The typical [JSON RPC](/reference) endpoints supported by most EVM-compatible blockchain nodes (e.g., Geth) 2. The Geth [real-time events](https://geth.ethereum.org/docs/interacting-with-geth/rpc/pubsub) WebSocket protocol (i.e., `eth_subscribe`) is also supported, along with some Monad-specific extensions for better performance; see the [WebSocket guide](/reference/websockets) for more information Both of these access methods are standardized across EVM-compatible blockchains and are simpler to use than execution events. The execution events system is designed for specialized applications, such as running an indexer platform or applications that need the lowest latency possible (e.g., market making). It is also where the RPC server itself gets its real-time data. ## Comparisons with other data systems A brief comparison with low latency systems in other blockchain software: * **Geth Live Tracing** [(link)](https://geth.ethereum.org/docs/developers/evm-tracing/live-tracing) - "hook" based API: your code is loaded into the Geth node as a plugin, and is run synchronously (via callbacks) during execution * **Reth ExEx** [(link)](https://www.paradigm.xyz/2024/05/reth-exex) and [(link)](https://reth.rs/exex/overview) - async function based API: your code is loaded into a Reth node; execution sees events after the fact rather than synchronously * **Solana Geyser** [(link)](https://www.helius.dev/blog/solana-geyser-plugins-streaming-data-at-the-speed-of-light) - "hook" based API, a plugin that runs inside a Solana validator and invokes callbacks during execution All three of these are different from the Execution Events approach. In our approach: * You are seeing events "as-they-happen", as in the Geth Live Tracer and Solana Geyser. Unlike these approaches, your code is not running as a plugin inside the execution engine, but in parallel (about one microsecond later) in a separate process * Like the Geth Live Tracer (but unlike Reth's ExEx) you see each "piece" of the transaction -- each log, each balance change, etc. -- as a separate event * Unlike the Geth Live Tracer or Geyser, you do not install "hooks" and receive callbacks; instead you continuously poll for new event records, iterating through any new events that are returned to you (and ignoring events that you are not interested in) * Because the system is based on shared memory ring buffers, you can lose data if your consumer is too slow -- you must keep up!