brontes: a Rust analytics pipeline that turns Ethereum traces into tables

The preprocessing chore is the problem being solved

Brontes is described as a general purpose blockchain analytics engine specialised in systematic MEV detection, and the README frames the problem in unusually blunt terms. Blockchain data analysis, especially at the trace level, produces an overwhelming flood of data and tedious preprocessing that often derail researchers from their core focus.

The audience for that pitch is listed explicitly: blockchain researchers and data scientists, MEV analysts and strategists, DeFi protocol developers, and anyone working with large-scale Ethereum data. Notice the emphasis on trace level, since that is where the volume problem lives and where most of the interesting MEV signals appear.

The three key features describe what the pipeline does with the raw stream. It transforms raw Ethereum data into a structured, analyzable format, it enhances that analysis with off-chain data including metadata, CEX prices and p2p data, and it provides a modular framework for user-defined inspectors so that custom analytics can be implemented without rebuilding the pipeline.

The value proposition is therefore not a new MEV detection method. It is the removal of the first three days of every project, the part where somebody writes decoders, normalises field names and sets up storage. Brontes calls itself Illuminate to Eliminate, which is a fair summary of the intent.

A Cargo workspace of twelve crates, with Reth pinned to one revision

The repository is a Cargo workspace, and the member list in the root Cargo.toml is the clearest description of the architecture:

[workspace]
members = [
  "crates/bin",
  "crates/brontes-core",
  "crates/reth-tracing-ext",
  "crates/brontes-inspect",
  "crates/brontes-types",
  "crates/brontes-classifier",
  "crates/brontes-metrics",
  "crates/brontes-tracing",
  "crates/brontes-database/brontes-db",
  "crates/brontes-macros",
  "crates/brontes-pricing",
  "crates/brontes-database/libmdbx-rs",
]

The names line up with the README's story. brontes-core holds the engine, brontes-types defines the data model, brontes-classifier is the part that decides what a transaction or trace is, brontes-inspect is the framework for user-defined inspectors, brontes-macros provides the derive helpers, brontes-metrics and brontes-tracing handle observability, brontes-pricing covers the off-chain price enrichment, and brontes-database holds the storage layer with a vendored libmdbx-rs.

The Reth coupling is tight and deliberately pinned. The workspace pulls reth-node-ethereum, reth-tasks, reth-rpc, reth-rpc-api and reth-rpc-types as git dependencies at the fixed revision ac29b4b, and Brontes is described as built on top of Reth. Pinning a revision rather than a branch means your build does not drift when upstream moves, which is the right call for a research tool, and also means merging an upstream Reth change is a deliberate manual step.

The database dependency is a fork as well: clickhouse is taken from SorellaLabs' own clickhouse.rs repository on the master branch with the tls feature enabled, rather than from the upstream client.

Inspectors are the extension point, not a plugin API

The Inspector Framework is what Brontes asks you to build on, and the README's argument for it is direct: the point is to let people develop and apply novel methodologies instead of drowning in preprocessing.

Concretely, an inspector is a unit of analysis that runs over the processed stream and produces a finding. The project publishes a methodology section for exactly this, linked from the README as the Methodology documentation under the mev_inspectors path in the user book, which tells you the framework is expected to be used for specific inspector types rather than as an open-ended extension mechanism.

The crates support that shape of extension. brontes-inspect holds the framework, brontes-classifier decides what the entities in the data are, and brontes-types defines the types an inspector works with, so a custom inspector is a new crate or a new module that consumes typed, already enriched data.

This is the same division of labour you would build by hand, except the parts you did not want to write are already done. The alternative is to write your own Rust program directly against the Reth crates that Brontes itself depends on, at the same pinned revision, and build the decoding, classification, enrichment and storage layers yourself. You would get full control and no framework, and you would still have to solve the hard part, which is not that you lack a query language, it is that trace level data has to be decoded and normalised before any query is meaningful.

Enrichment pulls in off-chain prices, metadata and peer to peer data

The second key feature is the enrichment layer, and brontes-pricing is where much of it lives. The README names the off-chain sources it enhances the analysis with: metadata, CEX prices and p2p data.

Centralised exchange prices matter for MEV work because a profitable arbitrage has to be judged against what the tokens were worth at the time, not against today's price. Pairing on-chain traces with CEX price data lets a researcher separate genuine value extraction from a token that simply moved. Whether the bundled pricing sources are sufficient for your question is a question the README leaves open, since the source list for prices is not enumerated in the visible documentation.

Metadata enrichment covers the other direction, decoding what a transaction actually did, whether that is a known protocol call, a token transfer or something custom. p2p data refers to information from the peer to peer network layer, which is where some of the MEV relevant information lives.

The cost of this layer is a dependency footprint and a configuration burden. The clickhouse dependency is a fork with TLS enabled, which means a TLS terminated ClickHouse endpoint, and the repository root carries a config/ directory and a sample.env file, so the pipeline expects environment configuration for at least some of its inputs. Treat the enrichment as the part most likely to need adapting to your environment, since a price source or a metadata endpoint is specific to your stack.

The Docker image builds on nightly and ships an Alpine binary on port 6923

The Dockerfile in the repository root documents the build and runtime shape of the tool. It is a multi-stage build on the rustlang/rust:nightly image, installs the native build dependencies, and uses cargo-chef to separate dependency compilation from the source build:

FROM rustlang/rust:nightly AS chef
RUN cargo install cargo-chef
WORKDIR /app
COPY . .
FROM chef AS planner
RUN cargo chef prepare --recipe-path recipe.json
FROM chef AS builder
ARG FEATURES=""
ENV FEATURES $FEATURES
RUN cargo +nightly build --release --features "$FEATURES"

The runtime stage is deliberately small. It starts from alpine, copies the release binary to /usr/local/bin/brontes, exposes port 6923 and sets it as the entrypoint:

FROM alpine AS runtime
COPY --from=builder /app/target/release/brontes /usr/local/bin/brontes
EXPOSE 6923
ENTRYPOINT ["/usr/local/bin/brontes"]

Two details follow from that file. The build needs a nightly toolchain, and the repository pins one through rust-toolchain.toml, so the toolchain version is not whatever happens to be installed. The FEATURES build argument exists so that optional crates can be compiled in or out, and the release binary is what the entrypoint runs.

The port number is the one exposed by the image, not necessarily the only port the process opens, since the ClickHouse and p2p connections are outbound. The README does not document the port list, so treat 6923 as the one figure you can rely on from the source.

No releases, two licences, and a book that documents the rest

Brontes has no GitHub releases. The install path is a documentation page, linked from the README as the Install link, and the rest of the guidance lives in a user book built with mdBook, since the repository contains book.toml and a book/ directory. The README links four destinations: the installation page, the user book, the crate documentation, and the methodology pages for MEV inspectors.

Licensing is dual. The repository root carries both LICENSE-APACHE and LICENSE-MIT, and the crate documentation link points at crate level docs, which is what you want if you depend on brontes-types or brontes-inspect rather than running the binary. Since the tree contains a crates/ directory with a public bin crate, read both licence files before you vendor a crate into a commercial codebase.

The rest of the repository is ordinary Rust infrastructure: Cargo.lock for reproducible dependency resolution, clippy.toml and rustfmt.toml for linting and formatting, a scripts/ directory, a config/ directory and sample.env, plus CODE_OF_CONDUCT.md, CONTRIBUTING.md and .github/ for the community side.

The maintenance picture is straightforward to state. The last push to the repository was on 2026-09-08, and with no tagged releases in the listing, a deployment pins a commit rather than a version. For a tool whose Reth dependencies are already pinned to a specific revision, that is a coherent choice, but it does mean your upgrade decision is a diff review rather than a version bump.

Editorial conclusion

brontes suits blockchain researchers, MEV analysts and DeFi teams who already work with trace level Ethereum data and want the normalisation, enrichment and storage layer written for them, and it suits anyone who needs to bolt a custom inspector onto a working pipeline. It does not suit a project that only needs a light query over public data, because the pipeline, the ClickHouse dependency and the Reth base are a heavy starting point, and it does not suit teams that require pinned, released artefacts, since the repository has no GitHub releases and the Reth crates are pinned to revision ac29b4b. Before adopting it, read the installation page linked from the README, decide whether your off-chain sources need the pricing and p2p enrichment, and confirm that your own inspectors can be written against the classifier and types crates. The last push to the repository was on 2026-09-08.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. SorellaLabs/brontes on GitHub