fix: some old branding left (#125)

There were still some `buildernet-orderflow-proxy` references in place.
Now grepping for that returns nothing.

There are some formatter diffs but I hope they're not too annoying. I
think those are good defaults.

Author: thedevbirb

.github/workflows/release.yml

@@ -46,5 +46,5 @@ jobs:
       - name: Upload artifact
         uses: actions/upload-artifact@v4
         with:
-          name: buildernet-orderflow-proxy-${{ needs.extract-version.outputs.VERSION }}-x86_64-unknown-linux-gnu
-          path: target/x86_64-unknown-linux-gnu/reproducible/buildernet-orderflow-proxy
+          name: flowproxy-${{ needs.extract-version.outputs.VERSION }}-x86_64-unknown-linux-gnu
+          path: target/x86_64-unknown-linux-gnu/reproducible/flowproxy

.github/workflows/reproducible-build.yml

@@ -22,12 +22,12 @@ jobs:
       - name: Build reproducible binary
         run: |
           just build-reproducible
-          mv target/x86_64-unknown-linux-gnu/reproducible/buildernet-orderflow-proxy buildernet-orderflow-proxy-1
+          mv target/x86_64-unknown-linux-gnu/reproducible/flowproxy flowproxy-1
       - name: Clean cache
         run: cargo clean && cargo cache -a
       - name: Build reproducible binary again
         run: |
           just build-reproducible
-          mv target/x86_64-unknown-linux-gnu/reproducible/buildernet-orderflow-proxy buildernet-orderflow-proxy-2
+          mv target/x86_64-unknown-linux-gnu/reproducible/flowproxy flowproxy-2
       - name: Compare binaries
-        run: cmp buildernet-orderflow-proxy-1 buildernet-orderflow-proxy-2
+        run: cmp flowproxy-1 flowproxy-2

AGENTS.md

@@ -1,16 +1,19 @@
 # Repository Guidelines
 
-This guide helps contributors deliver changes to `buildernet-orderflow-proxy-v2` safely and predictably.
+This guide helps contributors deliver changes to the project safely and predictably.
 
 ## Project Structure & Module Organization
 
 ### Entry Points & Core Structure
+
 - The entrypoint binary lives in `src/main.rs` and delegates to the library crate in `src/lib.rs`.
 - CLI arguments are defined in `src/cli.rs` using the `clap` crate.
 - The `src/runner/` module handles application lifecycle and HTTP server setup.
 
 ### Domain Modules
+
 Core domain logic is organized under `src/`:
+
 - **`ingress/`**: HTTP handlers for three endpoints:
   - `user.rs`: Public API for bundle/transaction submission
   - `system.rs`: Internal API for system operations
@@ -34,44 +37,53 @@ Core domain logic is organized under `src/`:
 - **`tasks/`**: Task execution and graceful shutdown coordination
 
 ### Supporting Code
+
 - **`src/utils.rs`**: Shared helper functions
 - **`benches/`**: Criterion performance benchmarks
 - **`fixtures/`**: SQL schema files for ClickHouse tables
 - **`simulation/`**: Load testing harness with Docker Compose
 - **`tests/`**: Integration tests with reusable fixtures in `tests/common/`
 
 ### Guidelines for New Code
+
 - Place new code in the closest domain module and expose it through `lib.rs`.
 - For cross-cutting concerns, consider adding to `utils.rs` or creating a new focused module.
 - Keep modules focused and cohesive; split large modules into submodules when they exceed ~500 lines.
+
 ## Build, Test, and Development Commands
 
 ### Building
+
 - `cargo build` compiles the binary with the default dev profile.
 - `cargo build --release` produces an optimized build with LTO enabled.
 - `just build-reproducible` creates a verifiable production build (uses the `reproducible` profile).
 - `cargo run -- --help` prints the CLI flags defined in `src/cli.rs` and is the fastest smoke-test.
 
 ### Testing
+
 - `just test` runs the test suite using nextest (faster parallel test runner).
 - `cargo test` executes unit and integration tests; add `-- --nocapture` when debugging async failures.
 - `cargo bench` runs Criterion benchmarks (validation, signature verification, etc.).
 - Integration tests use `testcontainers` for ClickHouse and require Docker to be running.
 
 ### Code Quality
+
 - `just fmt` or `cargo +nightly fmt --all` applies formatting rules from `rustfmt.toml`.
 - `just clippy` or `cargo clippy --all-targets --all-features -- -D warnings` enforces lints.
 - All linting configuration lives in `Cargo.toml` under `[lints.clippy]`.
 
 ### Database Operations
+
 - `just provision-db` creates the ClickHouse database and tables from `fixtures/`.
 - `just reset-db` drops and recreates tables (destructive operation).
 - `just extract-data <FILE>` exports data to Parquet format.
 
 ### Justfile Commands
+
 Run `just --list` to see all available commands. The justfile automates common workflows and should be the preferred method for development tasks.
 
 ## Coding Style & Naming Conventions
+
 - Keep Rust code within 100 columns (enforced by rustfmt).
 - Use `rustfmt` for formatting; it is authoritative and will reorder imports at crate granularity.
 - Use `snake_case` for modules and functions, `UpperCamelCase` for types, and reserve `SCREAMING_SNAKE_CASE` for constants.
@@ -85,40 +97,49 @@ Run `just --list` to see all available commands. The justfile automates common w
 ## Testing Guidelines
 
 ### Test Organization
+
 - Unit tests live in the same file as the code they test, in a `#[cfg(test)]` module.
 - Integration tests are in the `tests/` directory, organized by feature area.
 - Shared test utilities and fixtures belong in `tests/common/`.
 - Async flows rely on `#[tokio::test]`, so ensure all async test helpers are properly propagated.
 
 ### Naming Conventions
+
 Name test functions with the behavior under test, following the pattern:
+
 - `<module>_<scenario>_<expected_outcome>`
 - Examples: `ingress_rejects_invalid_signature`, `forwarder_retries_on_timeout`, `entity_scores_spam_bundle_low`
 
 ### Test Coverage Requirements
+
 New behavior must include either:
+
 1. A targeted unit test in the owning module covering the happy path and key edge cases, OR
 2. An integration test scenario covering success and error paths
 
 ### Running Tests
+
 - `just test` uses nextest for parallel execution (recommended).
 - `cargo test` for standard test runner.
 - `cargo test -- --nocapture` when debugging async failures or inspecting tracing output.
 - Run `cargo test --features ...` if you introduce optional features.
 
 ### Integration Tests
+
 - Integration tests may use `testcontainers` to spin up ClickHouse for indexer tests.
 - Ensure Docker is running before executing integration tests.
 - Clean up resources in test teardown to avoid port conflicts and leaked containers.
 
 ### Performance Tests
+
 - Benchmark critical paths using Criterion in `benches/`.
 - Focus on hot paths: validation, signature verification, entity scoring, serialization.
 - Run `cargo bench` to execute all benchmarks and generate performance reports.
 
 ## Commit & Pull Request Guidelines
 
 ### Commit Message Style
+
 - Follow the short, imperative style seen in history (e.g., `fix package name`, `add builder metrics`).
 - Prefix with scope if it aids triage: `ingress:`, `forwarder:`, `entity:`, `validation:`, `chore:`, `fix:`, `feat:`.
 - Examples:
@@ -127,7 +148,9 @@ New behavior must include either:
   - `chore: bump version to 1.1.3`
 
 ### Pull Request Requirements
+
 Each PR should include:
+
 1. **Motivation**: Why is this change needed? What problem does it solve?
 2. **Approach**: High-level overview of the implementation strategy.
 3. **Risky Areas**: Call out potential edge cases, performance impacts, or breaking changes.
@@ -136,46 +159,56 @@ Each PR should include:
 6. **Evidence**: Attach logs, metrics screenshots, or before/after comparisons for user-facing changes.
 
 ### CI Readiness Checklist
+
 Before requesting review, ensure:
+
 - [ ] `cargo build` succeeds
 - [ ] `just fmt` produces no changes
 - [ ] `just clippy` passes with no warnings
 - [ ] `just test` passes all tests
 - [ ] Integration tests pass if touching ingress, indexer, or forwarder
 
 ### Review Process
+
 - Address reviewer feedback promptly.
 - Keep commits focused; avoid mixing refactoring with feature work.
 - Rebase on `main` before merging to maintain a clean history.
 
 ## Configuration & Runtime Notes
 
 ### CLI Configuration
+
 The proxy is configured through CLI flags defined in `src/cli.rs` (`OrderflowIngressArgs` struct):
+
 - **Required**: `--user-listen-url`, `--system-listen-url`, `--builder-name`
 - **Optional**: `--builder-url`, `--builder-hub-url`, `--orderflow-signer`, `--metrics`, etc.
 - All flags support environment variable overrides (e.g., `USER_LISTEN_ADDR`, `SYSTEM_LISTEN_ADDR`).
 
 ### Configuration Guidelines
+
 When adding new configuration:
+
 1. Document the flag in the struct's `#[arg(...)]` annotation with clear help text.
 2. Choose safe defaults for local testing (loopback listeners, disabled external services).
 3. Update `--help` text to reflect behavior changes.
 4. Add validation logic in `src/runner/` if the flag affects startup behavior.
 5. Update this document's Configuration section if the change is significant.
 
 ### Runtime Behavior
+
 - The proxy uses Tokio's multi-threaded runtime for async operations.
 - Jemalloc is the default allocator for better memory performance.
 - Graceful shutdown is coordinated through `src/tasks/` using `TaskExecutor` and `TaskManager`.
 - HTTP servers bind to configured addresses and serve JSON-RPC requests via Axum.
 
 ### Observability
+
 - **Logs**: Structured logging via `tracing` (text or JSON format with `--log.json`).
 - **Metrics**: Prometheus metrics exposed at `--metrics` endpoint (default: disabled).
 - **Tracing**: Use `RUST_LOG` environment variable for log level control (e.g., `RUST_LOG=info,flowproxy=debug`).
 
 ### Performance Considerations
+
 - Rate limiting is disabled by default; enable with `--enable-rate-limiting`.
 - Gzip compression is disabled by default; enable with `--http.enable-gzip`.
 - Indexing is optional; ClickHouse/Parquet indexers only run if configured.
@@ -185,6 +218,7 @@ When adding new configuration:
 ## Architecture & Design Patterns
 
 ### Data Flow Overview
+
 1. **Ingress** receives bundles/transactions via JSON-RPC over HTTP
 2. **Validation** checks transaction intrinsics, signatures, and bundle structure
 3. **Entity Scoring** computes priority based on sender reputation and bundle characteristics
@@ -195,24 +229,28 @@ When adding new configuration:
 ### Common Patterns
 
 #### Error Handling
+
 - Use `eyre::Result` for most fallible operations.
 - Use `thiserror` for domain-specific error types with context.
 - Log errors at appropriate levels: `error!` for unexpected failures, `warn!` for recoverable issues.
 - Return structured errors from public APIs; log internal errors with context.
 
 #### Async Patterns
+
 - Spawn long-running tasks using `TaskExecutor` and `TaskManager` for graceful shutdown.
 - Use `tokio::select!` for concurrent operations with cancellation support.
 - Prefer bounded channels (`tokio::sync::mpsc`) over unbounded to prevent memory growth.
 - Use `Arc<RwLock>` or `Arc<Mutex>` for shared mutable state; prefer immutable sharing when possible.
 
 #### Observability Patterns
+
 - Instrument public functions with `#[tracing::instrument]` for automatic span creation.
 - Use structured fields in log messages: `tracing::info!(entity = %addr, "processing bundle")`.
 - Emit metrics for critical operations: request counts, latencies, queue depths, error rates.
 - Add custom metrics in `src/metrics.rs` using the `metrics` crate.
 
 #### Testing Patterns
+
 - Mock external dependencies using trait abstractions (see `PeerStore` trait in `builderhub.rs`).
 - Use builder patterns for complex test fixtures.
 - Leverage `proptest` for property-based testing of validation logic.
@@ -229,6 +267,7 @@ When adding new configuration:
 ### Dependencies & Ecosystem
 
 Key dependencies and their roles:
+
 - **`alloy`**: Ethereum primitives (transactions, signatures, addresses)
 - **`rbuilder-primitives`**: BuilderNet-specific bundle types
 - **`axum`**: HTTP framework for JSON-RPC APIs
@@ -241,14 +280,17 @@ Key dependencies and their roles:
 - **`criterion`**: Performance benchmarking
 
 ### Performance Hotspots
+
 Monitor and optimize these areas:
+
 1. **Signature Verification**: Uses `alloy` for ECDSA recovery; consider batching.
 2. **Entity Scoring**: Computed per bundle; cache aggressively.
 3. **Validation**: Runs on every transaction; keep logic fast and allocate minimally.
 4. **Serialization**: JSON-RPC parsing and encoding; consider message size limits.
 5. **Queue Operations**: High contention on shared queues; use per-level locks.
 
 ### Security Considerations
+
 - Validate all user inputs before processing (see `validation.rs`).
 - Rate limit by entity to prevent spam and DoS attacks.
 - Reject bundles from entities with low scores (spam detection).

simulation/Dockerfile

@@ -40,17 +40,17 @@ FROM build-shadow AS build-proxy
 RUN apt-get install -y libssl-dev
 
 # Note: the docker context must be the root of the git project due to this COPY
-COPY . /root/buildernet-orderflow-proxy
+COPY . /root/flowproxy
 
 # Build the orderflow proxy
-WORKDIR /root/buildernet-orderflow-proxy
+WORKDIR /root/flowproxy
 RUN cargo build --profile profiling
 
 # Build the mock of the hub used in shadow
-WORKDIR /root/buildernet-orderflow-proxy/simulation/mockhub
+WORKDIR /root/flowproxy/simulation/mockhub
 RUN cargo build --release
 
-WORKDIR /root/buildernet-orderflow-proxy/simulation/submitter
+WORKDIR /root/flowproxy/simulation/submitter
 RUN cargo build --release
 
 RUN cargo install --locked flamegraph
@@ -69,9 +69,9 @@ COPY simulation/testdata/ /root/testdata/
 
 # Copy the compiled binaries and libraries to the fresh image
 COPY --from=build-proxy /root/.local/bin/shadow .
-COPY --from=build-proxy /root/buildernet-orderflow-proxy/target/profiling/buildernet-orderflow-proxy .
-COPY --from=build-proxy /root/buildernet-orderflow-proxy/simulation/mockhub/target/release/mockhub .
-COPY --from=build-proxy /root/buildernet-orderflow-proxy/simulation/submitter/target/release/submitter .
+COPY --from=build-proxy /root/flowproxy/target/profiling/flowproxy .
+COPY --from=build-proxy /root/flowproxy/simulation/mockhub/target/release/mockhub .
+COPY --from=build-proxy /root/flowproxy/simulation/submitter/target/release/submitter .
 # These shadow libraries have to be in /lib according to readelf
 COPY --from=build-proxy /root/.local/lib /lib
 

simulation/scenarios/buildernet.yaml

@@ -29,22 +29,22 @@ hosts:
     network_node_id: 0
     ip_addr: 10.0.0.1
     processes:
-    - path: /root/mockhub
-      start_time: 0s
-      expected_final_state: running
-      environment:
-        # System API ports of the proxies
-        SYSTEM_PORT: "5544"
+      - path: /root/mockhub
+        start_time: 0s
+        expected_final_state: running
+        environment:
+          # System API ports of the proxies
+          SYSTEM_PORT: "5544"
   submitter:
     # Run the submitter in zone 0
     network_node_id: 0
     ip_addr: 10.0.0.2
     processes:
-    - path: /root/submitter
-      args: --url http://proxy1:9754 --path ../../../testdata/testdata.parquet --scale 5
-      # Wait 35s for the proxies to connect to each other
-      start_time: 35s
-      expected_final_state: { exited: 0 }
+      - path: /root/submitter
+        args: --url http://proxy1:9754 --path ../../../testdata/testdata.parquet --scale 5
+        # Wait 35s for the proxies to connect to each other
+        start_time: 35s
+        expected_final_state: { exited: 0 }
   proxy1:
     network_node_id: 0
     ip_addr: 10.0.0.3
@@ -54,13 +54,13 @@ hosts:
       # we mainly care about metadata. 20 bytes represents minimum IPv4 header size.
       pcap_capture_size: 20
     processes:
-    - path: /root/buildernet-orderflow-proxy
-      args: --user-listen-url 0.0.0.0:9754 --system-listen-url 0.0.0.0:5544 --builder-listen-url 0.0.0.0:8756 --builder-hub-url http://hub:3000 --indexer.parquet.bundle-receipts-file-path bundle_receipts_proxy1.parquet --builder-name proxy1
-      start_time: 1s
-      shutdown_time: 4m
-      expected_final_state: { exited: 0 }
-      environment:
-        RUST_LOG: flowproxy=info,ingress=info,forwarder=info
+      - path: /root/flowproxy
+        args: --user-listen-url 0.0.0.0:9754 --system-listen-url 0.0.0.0:5544 --builder-listen-url 0.0.0.0:8756 --builder-hub-url http://hub:3000 --indexer.parquet.bundle-receipts-file-path bundle_receipts_proxy1.parquet --builder-name proxy1
+        start_time: 1s
+        shutdown_time: 4m
+        expected_final_state: { exited: 0 }
+        environment:
+          RUST_LOG: flowproxy=info,ingress=info,forwarder=info
   proxy2:
     network_node_id: 1
     ip_addr: 10.0.0.4
@@ -70,9 +70,9 @@ hosts:
       # we mainly care about metadata. 20 bytes represents minimum IPv4 header size.
       pcap_capture_size: 20
     processes:
-    - path: /root/buildernet-orderflow-proxy
-      args: --user-listen-url 0.0.0.0:9754 --system-listen-url 0.0.0.0:5544 --builder-listen-url 0.0.0.0:8756 --builder-hub-url http://hub:3000 --indexer.parquet.bundle-receipts-file-path bundle_receipts_proxy2.parquet --builder-name proxy2
-      shutdown_time: 4m
-      expected_final_state: { exited: 0 }
-      environment:
-        RUST_LOG: flowproxy=info,ingress=info,forwarder=info
+      - path: /root/flowproxy
+        args: --user-listen-url 0.0.0.0:9754 --system-listen-url 0.0.0.0:5544 --builder-listen-url 0.0.0.0:8756 --builder-hub-url http://hub:3000 --indexer.parquet.bundle-receipts-file-path bundle_receipts_proxy2.parquet --builder-name proxy2
+        shutdown_time: 4m
+        expected_final_state: { exited: 0 }
+        environment:
+          RUST_LOG: flowproxy=info,ingress=info,forwarder=info

simulation/sim.sh

@@ -86,7 +86,7 @@ run() {
         sleep 5
 
         echo 'Generating flamegraphs for running processes...'
-        for pid in \$(pgrep -f buildernet-orderflow-proxy); do
+        for pid in \$(pgrep -f flowproxy); do
           proxyName=\$(ps -p \$pid -o args= | grep -oP 'proxy[0-9]+' | head -n1 || true)
           if [[ -n \"\$proxyName\" ]]; then
             echo -n