ProvableHQ/snarkOS

snarkOS is a Rust-based blockchain node implementation that supports multiple operational roles, including Validators, Provers, Clients, and BootstrapClients. It provides a modular architecture for Byzantine Fault Tolerant consensus, peer-to-peer networking with hardened security, and efficient ledger synchronization via CDN and REST APIs. The system includes a comprehensive CLI for account management and program deployment, alongside a terminal UI for real-time node monitoring and observability.

33 changes.

This period focused on restructuring the snarkOS codebase into distinct, modular crates for networking, consensus, and node types (Validator, Prover, Client). It introduced a comprehensive CLI with subcommands, a terminal UI, and hardened TCP/Noise networking protocols. The work also established REST API support, CDN synchronization, and priority-based transaction handling to improve performance and maintainability.

18 changes.

This period focused on restructuring the Byzantine Fault Tolerance (BFT) consensus module into a modular architecture with dedicated services for ledger, storage, and events. Significant improvements were made to network security and reliability through the introduction of a versioned protocol, stricter message validation, and a Noise-based handshake. The work also established comprehensive observability via Prometheus metrics and robust end-to-end testing for the new synchronization and consensus logic.

8 changes.

This period focused on enhancing block synchronization reliability by restructuring the state machine, introducing a dedicated BootstrapClient for peer discovery, and implementing robust proposal handling with backoff logic. Significant effort was also directed toward operational maturity, establishing comprehensive CI benchmarks, chaos engineering scripts, and extensive test coverage for BFT, CLI, and REST components.

The consensus layer now implements a two-tier mempool architecture to prevent overloading the BFT workers. Incoming transactions are first placed in inbound queues (LRU caches with a capacity of 1024 for deployments and executions) where they are checked for duplicates. A new \TransactionsQueue\ component manages these transactions, introducing a priority queue that orders transactions by their priority fee (highest first) while maintaining FIFO ordering for equal fees. Transmissions are only moved to the BFT worker ready queues when capacity allows, ensuring the consensus layer acts as a rate limiter. Solutions are also tracked in a separate LRU cache. This change improves throughput by allowing high-fee transactions to be prioritized and prevents node overload during traffic spikes.

node/consensus · high confidence

This change introduces the \snarkos-node-rest\ crate, which provides a REST API for the snarkos node. The package includes the core implementation, a build script that embeds the build version from the repository's release metadata, and standard documentation and licensing files (Apache 2.0).

node/rest · high confidence

The repository is initialized with the core configuration files required to build and run snarkOS. This includes a Rust toolchain definition (rust-toolchain.toml) pinning the compiler to version 1.96, a formatting configuration (.rustfmt.toml) enabling Rust 2024 edition features, and a dependency security policy (deny.toml) replacing previous auditing tools. The entry also adds a build script (build.rs) that enforces license headers and checks for locktick usage, a helper script (build\_ubuntu.sh) for installing system dependencies, and updated documentation (README.md, AGENTS.md, CI.md) outlining node types, hardware requirements, and development workflows.

(repo-wide) · high confidence

A new \snarkos-node-bft-storage-service\ crate provides the storage layer for the BFT memory pool, offering two implementations: an in-memory service (\BFTMemoryService\) and a persistent service backed by RocksDB (\BFTPersistentStorage\). The persistent implementation includes an LRU cache to optimize read performance and handles aborted transmission IDs alongside retrievable ones. Both services implement the \StorageService\ trait, which manages transmission lifecycle (insert, remove, retrieve) and reference counting against certificate IDs, ensuring that transmissions are retained until all referencing certificates are removed.

node/bft/storage-service · high confidence

Added the \BlockLocators\ data structure to the node sync module, enabling validators to advertise their known block history to peers via \PrimaryPing\ messages. This structure maintains two maps—\recents\ for the last 100 blocks and \checkpoints\ for every 10,000th block—to help other validators efficiently synchronize their chain state. The implementation includes validation logic to ensure locators are well-formed and consistent with previously received locators, preventing sync issues caused by faulty or malicious peers.

node/sync/locators · high confidence

A new BootstrapClient node type has been added to handle peer discovery and validation committee synchronization. This component implements a dedicated TCP codec and handshake protocol (supporting both Noise and legacy modes) to manage connections, specifically filtering peer responses to exclude validators when appropriate and exchanging repository SHA information during handshakes. It also includes logic to resolve peer addresses, maintain a peer pool, and fetch the latest validator committee from the explorer API, ensuring that connected peers are correctly distinguished by their connection mode (Gateway vs. Router).

_node/src/bootstrap\client · high confidence

A new \CommunicationService\ trait has been added to the sync module, providing an abstraction for sending block request messages to peers. This trait defines the interface for preparing block requests and sending them asynchronously, allowing implementations like \Gateway\ and \Client\ to handle peer communication consistently.

node/sync/communication-service · high confidence

A new \Client\ node type has been added to the node implementation, enabling full-node capabilities for querying the network without participating in consensus. This change introduces specific client logic for block synchronization, including support for syncing via CDN before REST, and exposes REST endpoints for sync status and historical data. The client node manages its own router, ledger, and synchronization state, with configurable limits for parallel solution verifications and REST verification concurrency.

node/src/client · high confidence

A new \snarkos-node-bft-ledger-service\ crate has been added to the \node/bft/ledger-service\ location, providing a dedicated ledger service implementation for snarkOS's memroy pool. This crate introduces a \LedgerService\ trait and several implementations: \CoreLedgerService\ for standard node operations, \MockLedgerService\ for testing, \ProverLedgerService\ for prover-specific logic, and \TranslucentLedgerService\ as a wrapper. It also includes strict deserialization helpers for transactions and solutions, ensuring buffers contain exactly one serialized item and rejecting trailing bytes or oversized data. The crate supports optional features like \ledger-write\ for atomic updates, \metrics\ for BFT metrics, and \test\_network\ for dev committee hotswapping.

node/bft/ledger-service · high confidence

The TCP layer now exposes a set of opt-in traits—Handshake, OnConnect, Disconnect, Reading, and Writing—that allow nodes to define custom logic for specific stages of a peer connection. Handshake enables configurable, timed authentication or negotiation before data exchange begins. OnConnect and Disconnect provide hooks for post-connection initialization and cleanup actions, with automatic disconnection handling if these hooks panic or time out. Reading and Writing manage inbound and outbound message streams respectively, featuring configurable queue depths, idle timeouts, and write starvation guards. These traits replace rigid, hardcoded connection behaviors with flexible, user-defined protocols that integrate into the node's task lifecycle.

node/tcp/src/protocols · high confidence

The \node/tcp/src\ location now contains a new, standalone TCP implementation (\Tcp\) that replaces the previous inline networking logic. This module provides a customizable TCP stack with built-in support for per-IP connection limits, banned peer filtering, and bogon IP address detection. It introduces specific error types (\ConnectError\, \ApplicationError\) for better error handling and exposes a \P2P\ trait for protocol integration, effectively centralizing low-level connection management, uptime tracking, and connection lifecycle (connect/disconnect) within this new crate.

node/tcp/src · high confidence

A new Prover node type has been added to the network, implemented as a light node capable of producing proofs for consensus. This component initializes a dedicated router, sync module, and puzzle generation loop, while handling network interactions such as handshakes, peer connections, and message processing. The Prover bypasses transaction validation restrictions and manages its own puzzle instances based on available CPU cores, integrating with the existing routing and sync infrastructure to support proof generation workflows.

node/src/prover · high confidence

The account module now exposes a dedicated Account struct that encapsulates a private key, view key, and address. This provides a unified interface for generating new accounts, deriving keys, and performing cryptographic operations such as signing and verifying messages in field, byte, or bit formats. The implementation includes conversion methods to initialize accounts from private key strings and a display formatter for outputting account details.

account/src · high confidence

A new \Sync\ module has been introduced in the BFT node to manage block synchronization for validators. This component handles fetching blocks from peers, processing responses, and syncing the local storage with the ledger at startup. It introduces a \SyncCallback\ trait to notify the BFT layer of new certificates and commits, and manages pending blocks and certificates to ensure ordered processing. The module also includes logic for issuing block requests, handling timeouts, and advancing block synchronization, with specific handling for panics during block advancement.

node/bft/src/sync · high confidence

The \snarkos-node-bft-events\ crate introduces a new \EventCodec\ that serializes network events using length-delimited framing with a 256 MiB maximum frame size, writing frames in-place to avoid unnecessary memory copies. It also implements a new Noise-XX-based handshake for the gateway, replacing the legacy challenge-response mechanism with a four-message exchange that binds peer metadata to cryptographic signatures for improved security and early rejection of invalid peers.

node/bft/events/src/helpers · high confidence

The \node/bft/examples\ directory now includes a \simple\_node\ example that allows developers to run local BFT or Narwhal nodes for testing. This example supports running multiple nodes via a provided shell script (\start-nodes.sh\) or manually, with options to configure node IDs, network size, and transaction firing intervals. Additionally, a \monitor\ example has been added, which serves a web-based visualization dashboard (using D3.js) to display the Directed Acyclic Graph (DAG) of node communications in real-time.

node/bft/examples · high confidence

The \node/cdn\ crate introduces a new capability to fetch ledger state from a CDN, allowing nodes to sync blocks more efficiently. This module provides the \CdnBlockSync\ manager and \load\_blocks\ function to handle background synchronization, including concurrent requests, retry logic, and integrity checks. It also exposes metrics for sync progress and height, and integrates with the node's logging and signal handling for graceful operation.

node/cdn · high confidence

The CI pipeline now includes dedicated scripts to benchmark BFT, CDN, and P2P block synchronization speeds, as well as REST API throughput (using a new Python helper). It also introduces comprehensive tests for database backup/restore, devnet stability, full and partial network upgrades, and validator restart/reset scenarios, providing deeper visibility into network performance and upgrade safety.

.ci · high confidence

The node now includes a dedicated block sync module (\node/sync/src/block\_sync.rs\) that manages fetching blocks from peers, enforcing a 60-second request timeout, limiting outstanding requests to 50, and validating peer consensus versions to prevent syncing with mismatched nodes. A new \Ping\ service (\node/sync/src/ping.rs\) periodically checks peer liveness every 20 seconds and updates block locators to maintain an accurate view of the network's head. These components replace previous ad-hoc synchronization logic with a structured, state-managed approach that improves sync reliability and network health monitoring.

node/sync/src · high confidence

The \snarkos developer\ subcommand now provides a comprehensive suite of tools for Aleo developers. You can deploy programs (\deploy\), execute program functions (\execute\), and perform private credit transfers (\transfer-private\) with support for custom endpoints, priority fees, and transaction broadcasting or dry-runs. Additionally, you can scan the blockchain for owned records (\scan\), decrypt ciphertext records (\decrypt\), and sign messages (\sign\ via the account module). These commands support multiple networks (Mainnet, Testnet, Canary) and allow keys to be provided directly, via file, or using developer validator keys.

cli/src/commands/developer · high confidence

The \node/metrics\ crate is introduced to centralize node observability, providing a comprehensive set of Prometheus metrics and a pre-provisioned Grafana dashboard for local development. The crate exposes granular metrics for BFT consensus (e.g., subdag density, batch certification latency, validator participation), block processing (accepted/rejected/aborted transactions and solutions), and network status (TCP queue depth, router connections). It includes a build script to embed the release version as a \build\_info\ gauge and manages the lifecycle of the Prometheus HTTP exporter, ensuring it shuts down cleanly with the node. For users, this means immediate access to a standardized monitoring stack via \scripts/devnet.sh\, which spins up Prometheus and Grafana with a dashboard ported from the incident response team, allowing for real-time visibility into node health and consensus performance without manual configuration.

node/metrics · high confidence

The scripts directory now includes several new tools to aid in local development and testing. The chaotic-network-runner.sh and delay-network.sh scripts allow users to simulate network conditions (such as latency, jitter, and packet loss) and inject chaos into local networks to test resilience. A new devnet.sh script simplifies spinning up a local multi-validator network with configurable parameters and automatic Prometheus scrape configuration. Additionally, dedicated runner scripts (run-validator.sh, run-core-client.sh, run-outer-client.sh, run-prover.sh) streamline starting individual node types with required private keys and peer configurations. A backup.sh script has been added to automate ledger checkpoint backups, and a lint.sh script ensures shell scripts are checked for style and errors.

scripts · high confidence

The router now includes a new \Cache\ helper module that tracks inbound and outbound network activity to enforce rate limits and prevent duplicate processing. This cache monitors metrics such as unconfirmed solutions, block requests, puzzle requests, and peer connections using time-based intervals, allowing the network layer to throttle spam and manage resource usage more effectively.

node/router/src/helpers · high confidence

The display module now provides a terminal-based user interface for the node, replacing the previous implementation with the ratatui library. This new UI features a tabbed layout (including an Overview and Logs tab) with styled headers and content, allowing users to navigate between views using keyboard shortcuts (Left/Right arrows) and exit using the Escape key. The interface runs in an alternate screen with mouse capture enabled and respects a configurable tick rate for redraws.

display/src · high confidence

The display module now includes dedicated pages for viewing application logs and a network overview. The Logs page renders incoming log messages in a scrollable buffer, while the Overview page displays the latest block hash and height, synchronization status (including speed for non-bootstrap nodes), and a table of connected peers showing their IP, state, node type, and last-seen time. These pages are built using the ratatui library.

display/src/pages · high confidence

The utilities library now includes modules for handling node lifecycle and configuration storage. A new \CallbackHandle\ type allows safe, single-set callbacks that can be cleared to break circular dependencies during shutdown. The \signals\ module provides a \SignalHandler\ that listens for OS signals (SIGINT, SIGTERM, SIGQUIT, SIGHUP on Unix; Ctrl+C on Windows) and a \SimpleStoppable\ for simpler stop-checking, enabling the node to shut down gracefully. Additionally, \node\_data.rs\ defines the \NodeDataDir\ struct and constants for peer cache, proposal cache, and JWT secret file paths, standardizing where node-specific data is stored.

utilities/src · high confidence

The initial placeholder main.rs file containing a simple "Hello, world!" print statement has been removed from the source tree, indicating the project has moved past its initial scaffolding phase.

src · high confidence

The CLI now validates that the parent directory of sensitive files is accessible only by the owner (mode 0700) and restricts key files to read-only access for the user (mode 0400 on Unix). This ensures that private keys and other sensitive data created via the CLI are protected against unauthorized access by other users on the system.

cli/src · high confidence

The node/bft/src module has been reorganized into distinct source files (bft.rs, gateway.rs, primary.rs, worker.rs, lib.rs) to improve code modularity and maintainability. This change separates the core BFT logic, gateway networking, primary node responsibilities, and worker tasks into their own modules, making the codebase easier to navigate and modify. The restructure maintains all existing functionality while providing a cleaner architectural separation of concerns within the Byzantine Fault Tolerance consensus system.

node/bft/src · high confidence

The node/router/src module has been restructured to improve code organization and maintainability. The previous monolithic implementation has been split into distinct files: handshake.rs (connection initiation and authentication), heartbeat.rs (peer management and connection maintenance), inbound.rs (incoming message processing), outbound.rs (message propagation), routing.rs (protocol initialization and lifecycle), and writing.rs (outbound message sending and caching). This modularization makes the router's networking behavior easier to understand and modify, while preserving all existing functionality for peer connections, message handling, and network synchronization.

node/router/src · high confidence

The block synchronization logic has been restructured to explicitly track the node's synchronization status (Unsynced, Syncing, Synced) and BFT sync mode (Fast or DAG). A new metrics system monitors block synchronization speed using a 60-second sliding window, allowing users to observe how quickly the node is catching up. Additionally, a helper function for formatting height ranges has been added to improve log readability during synchronization.

_node/sync/src/block\sync · high confidence

The CLI command structure has been refactored from a monolithic implementation into distinct, modular subcommand files (\account\, \clean\, \developer\, \start\, \update\). This change introduces a new \snarkos account\ command group for managing accounts (including new \sign\ and \verify\ capabilities), adds a \snarkos clean\ command with a \--keep-node-data\ flag to selectively remove ledger or node data, and reorganizes the \start\ command's argument groups to enforce mutual exclusivity for node types and stricter validation for development flags. The top-level CLI now uses a unified \Command\ enum to dispatch these subcommands, improving maintainability and ergonomics.

cli/src/commands · high confidence

The CLI helper module has been reorganized into dedicated files to improve maintainability and introduce new capabilities. Argument parsing is now centralized in \args.rs\, providing utilities for endpoint URL normalization, private key retrieval (including a new \--dev-key\ flag for development mode), and node data directory resolution. A new \logger.rs\ module replaces the previous logging setup, offering granular verbosity control (levels 0–6) and automatically suppressing noisy third-party logs (such as \tower\, \axum\, and \h2\) by default, while a \DynamicFormatter\ dims log output during shutdown. System health is monitored via \fd\_check.rs\, which spawns a background task to track file descriptor usage and warn or panic if limits are exceeded, and \mod.rs\ now includes explicit checks for minimum open file limits and validator hardware requirements (CPU cores and RAM). Additionally, \bech32m.rs\ adds support for validating bech32m character sets and vanity strings, and \updater.rs\ remains the source for the built-in self-update mechanism.

cli/src/helpers · high confidence

The CLI tool now determines its version string by reading the \.cargo/release-version\ file from the repository root during the build process, rather than relying solely on the crate's package version. This ensures that the version reported by the CLI matches the project's unified release version, with a fallback to the crate version if the release file is not found.

cli · high confidence

The \node/network\ location now ships as the standalone \snarkos-node-network\ crate, providing peer discovery, connection management, and peer pool coordination. This update introduces an asymmetrical Noise-XX-based handshake (Noise\_XX\_25519\_ChaChaPoly\_BLAKE2s) that replaces the legacy challenge-response protocol, binding node identity via signed handshake hashes and exchanging the snarkOS repository SHA for version awareness. The new network layer hardens TCP sockets by disabling Nagle's algorithm, setting immediate disconnect on linger, and applying a 20-second user timeout on Linux to protect the kernel's retransmission queue. It also enforces stricter handshake message size limits (1024 bytes) and supports a \trusted\_peers\_only\ mode that prevents connections to untrusted peers. The crate includes pinned wire encodings for \NodeType\ (Client, Prover, Validator, BootstrapClient) and \ConnectionMode\ (Gateway, Router) to ensure backward compatibility.

node/network · high confidence

The BFT module now persists the current batch proposal, signed proposals, and pending certificates to disk via a new \ProposalCache\ (stored in the node's data directory), ensuring state recovery across restarts. Synchronization behavior has been refined to classify previously-aborted transmissions during sync, pause block advancement while syncing, and avoid fetching certificates that are already seen. Additionally, the module exports individual validator participation scores as telemetry gauges and updates the batch certificate format to V2.

node/bft/src/helpers · high confidence

The snarkos binary now uses the clap library for command-line argument parsing and replaces the previous logging implementation with the tracing ecosystem, enabling structured logging that adapts to interactive terminals versus background services. On Linux x86\_64 systems, the allocator is switched to jemalloc by default to improve memory performance. The application also includes a custom panic handler that captures and displays backtraces to aid in debugging, and ensures proper exit codes are returned for both successful execution and errors.

snarkos · high confidence

The TCP layer now enforces a configurable maximum number of connections per IP address (default 25) and maintains a dynamic ban list for peers that misbehave. The new \BannedPeers\ helper tracks banned IPs with expiration times, while the \Config\ struct exposes \max\_connections\_per\_ip\ and \connection\_timeout\_ms\ settings. This allows the node to limit resource usage from single peers and automatically disconnect or block peers that spam connections or fail to respond, improving network stability and security.

node/tcp/src/helpers · high confidence

The BFT events module introduces new event types for batch operations (BatchPropose, BatchCertified, BatchSignature) and updates the BlockResponse message to include the latest consensus version. This versioning allows nodes to detect if they or their peers missed a protocol upgrade, ensuring consistent state during synchronization.

node/bft/events/src · high confidence

The sync module now includes a new helpers module defining \PrepareSyncRequest\ and \SyncRequest\ type aliases to structure block hash and peer address data, along with a \PeerPair\ struct that normalizes and compares pairs of socket addresses for peer identification.

node/sync/src/helpers · high confidence

The node library has been restructured to support distinct node types—Validator, Prover, Client, and the new BootstrapClient—each with specific capabilities and storage modes. This change introduces automatic ledger checkpoints (with configurable frequency and retention) and RocksDB metrics polling for validators and clients. Shutdown behavior is improved to handle POSIX signals more gracefully, abort background tasks (like the metrics exporter and FD monitor) cleanly, and warn about any remaining straggler tasks. The node interface now requires a genesis block for safety and exposes helper methods for node identification and development mode checks.

node/src · high confidence

Release builds for Linux x86\_64 now automatically enable the Skylake CPU target flag, allowing the compiler to utilize modern vector instructions (SSE and AVX2) for better performance without requiring manual configuration. The project version has also been updated to v4.10.1.

.cargo · high confidence

The REST server now supports optional JWT-based authentication via a new middleware that validates Bearer tokens using HS256, allowing clients to access protected endpoints securely. Additionally, the API now returns structured JSON error responses (including specific codes like 400, 404, 422, 429, and 500) with detailed error chains, replacing previous generic error logs to provide clearer feedback to API consumers.

node/rest/src/helpers · high confidence

The REST API module has been reorganized into dedicated source files (lib.rs, routes.rs, history\_compat.rs, version.rs) and now supports API versioning with v1 and v2 prefixes. A new history compatibility mode has been added to proxy historical staking data from the Provable historical staking API, allowing operators to continue serving historical mapping and staking rewards endpoints that were previously removed due to data integrity issues. The version endpoint now exposes build information including git commit, branch, and consensus version details. The REST server also introduces verification concurrency limits for deployments, executions, and solutions, along with improved error handling for missing resources (returning 404 instead of 500).

node/rest/src · high confidence

The router messages module has been reorganized into a dedicated crate, introducing a versioned network protocol that maps specific consensus versions (V5 through V21) to distinct message versions (17 through 32). This change enforces strict size limits on network frames to prevent resource exhaustion: Ping messages are capped at 2 MiB, while most other message types are restricted to 8 KiB, with BlockResponse and UnconfirmedTransaction allowed larger sizes based on their specific overheads. The update also adds a compile-time check to ensure message versions remain synchronized with the active consensus version, and implements serialization for handshake and peer-discovery messages like ChallengeRequest, ChallengeResponse, and PeerResponse.

node/router/messages/src · high confidence

The router's message codec now enforces stricter security and stability measures: it rejects message types that are not permitted for a specific connection type (such as BlockResponse on validator connections) before deserialization, and it caps the maximum frame length for each connection based on the largest allowed message type rather than a global maximum. Additionally, the system now includes a comprehensive DisconnectReason enum that maps specific disconnection causes (like protocol violations, sync issues, or peer limits) to ConnectError types, providing clearer feedback on why connections are terminated.

node/router/messages/src/helpers · high confidence

The validator node implementation has been restructured into a modular \node/src/validator\ module, separating the core \Validator\ struct from its network routing logic in \router.rs\. This change introduces several behavioral improvements: TCP sockets are now hardened via \harden\_socket\ during the handshake, and the message codec explicitly excludes \BlockResponse\ messages on the general router to prevent untrusted peers from forcing large memory allocations. Synchronization behavior is updated to support CDN-based syncing, which can now start before REST services, and the node enforces stricter version checks during peer handshakes. Additionally, the validator now supports trusted validators and peers, persists the dev committee start round across restarts in test networks, and offloads heavy inbound message processing to blocking tasks to avoid queue congestion.

node/src/validator · high confidence

The primary node now uses a new \ProposalTask\ to manage batch proposals, replacing previous inline logic. This change introduces exponential backoff for proposal retries to avoid busy-waiting and ensures the node stops proposing if it detects it has fallen behind and started syncing again. The task also handles rebroadcasts correctly and wakes up on proposal tasks even when the maximum leader delay is reached, improving reliability during network synchronization.

node/bft/src/primary · high confidence

Add shared test helpers for router integration tests; Added CLI argument parsing tests; Added REST API handler benchmarks; Added common test infrastructure for node integration tests; Added end-to-end tests for BFT consensus, gateway handshake, and Noise protocol; Added integration tests for bootstrap handshake, node disconnections, and peer response validation; Added router connection lifecycle and peer management tests; Added tests for BFT worker pending queue and redundancy limits; New BFT test infrastructure for simulating validator networks.

A dependency / build maintenance change in (dependencies) — 2032 commits (127 fixs), 22 files.

(dependencies) · high confidence · unverified

A centralized license header file has been added to the project resources, defining the Apache 2.0 license terms and copyright notice for Provable Inc. (2019-2026). This change provides a consistent template for license headers across the codebase, ensuring legal compliance and uniformity in source files.

.resources · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 46 → 49 (+2.6)
• Rubric changed (rubric-2026.09.11 → rubric-2026.09.18) — scores are not directly comparable.

• Code Health 87 → 87 (+0.0)
• Architecture 97 → 96 (-1.0)
• Maturity 59 → 62 (+3.9)
• Readiness 39 → 39 (+0.3)
• Security 41 → 51 (+10.1)
• Event Sourcing 49 → 49 (+0.0)
• Performance 94 (new)

• Change coupling: prover.rs ↔ worker.rs (node/bft/ledger-service/src/prover.rs)
• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)
• Duplicated block (12 lines × 2) (node/src/client/mod.rs)
• Duplicated block (12–13 lines × 2) (node/src/client/mod.rs)
• Duplicated block (16 lines × 2) (node/src/client/mod.rs)
• Duplicated block (6 lines × 3) (node/bft/src/primary.rs)
• High: security finding (details withheld)
• Hotspot: node/bft/events/src/lib.rs (node/bft/events/src/lib.rs)
• Hotspot: node/bft/src/sync/mod.rs (node/bft/src/sync/mod.rs)
• Hotspot: node/router/messages/src/lib.rs (node/router/messages/src/lib.rs)
• Hotspot: node/sync/src/block_sync.rs (node/sync/src/block_sync.rs)
• Members sharing a duplicated core (4 members, 50+ identical tokens) (node/bft/src/gateway.rs)
• Members sharing a duplicated core (4 members, 50+ identical tokens) (node/rest/src/routes.rs)
• Off-boarding risk: anonymized user #1
• Off-boarding risk: anonymized user #2
• TodoComment (node/rest/src/lib.rs)
• TodoComment (node/rest/src/routes.rs)
• TodoComment (node/rest/src/routes.rs)
• calculateAverageBlockTime (cognitive 18) (.devnet/.analytics/analytics.js)

• Dependency hygiene PARTLY measured — Cargo dependencies read, dependency currency not (crates.io unreachable)
• Documentation: no installation or build instructions (node/sync/locators/README.md)
• Documentation: no usage examples (node/sync/locators/README.md)
• Duplicate function signatures with different parameter names (one named 'path', one '_path'). This suggests an overload or a copy-paste error in the API surface, which is confusing for consumers.
• Duplicated block (13 lines × 2) (cli/src/commands/developer/deploy.rs)
• Duplicated block (13 lines × 2) (node/src/client/mod.rs)
• Duplicated block (16–17 lines × 2) (node/consensus/src/lib.rs)
• Duplicated block (18 lines × 2) (node/src/client/mod.rs)
• Duplicated block (5 lines × 2) (node/bft/src/gateway.rs)
• End-of-life runtime: Rust 1.96
• High: security finding (details withheld)
• Hotspot: cli/src/commands/start.rs (cli/src/commands/start.rs)
• Inconsistent naming convention for data type variants. 'sign_bytes' uses the type name, while 'sign_bits' uses the pluralized type name. 'sign' is ambiguous as it takes a generic Field array but lacks a suffix.
• Inconsistent return types for 'contains' operations. 'Storage' returns a boolean, while 'LedgerService' returns a Result. This forces callers to handle errors differently for similar existence checks.
• Low cohesion: Client (LCOM4 4) (node/src/client/mod.rs)
• Low cohesion: Gateway (LCOM4 4) (node/bft/src/gateway.rs)
• Low cohesion: MockLedgerService (LCOM4 7) (node/bft/ledger-service/src/mock.rs)
• Low cohesion: Prover (LCOM4 4) (node/src/prover/mod.rs)
• Low cohesion: Storage (LCOM4 6) (node/bft/src/helpers/storage.rs)
• Medium CVE: RUSTSEC-2025-0055 (Cargo.lock)
• …and 15 more

• 86 commits — 70 feature/other, 16 fixes

• (repo) — 29 commits
• node/bft — 19 commits
• node/rest — 11 commits
• (root) — 9 commits
• node/metrics — 7 commits
• .circleci/config.yml — 4 commits
• cli/src — 2 commits
• .devnet/.analytics — 1 commit
• node/consensus — 1 commit
• node/router — 1 commit
• node/src — 1 commit
• node/sync — 1 commit

• fix: Converted several untracked tokio tasks to tracked ones. This is from a pre-existing issue. There were several tokio tasks and were spawned and never had any way of being shutdown. The current method of handling this is that we have some Vec<JoinHandle>s that we then use to shutdown all tasks when we shutdown the node. There's also a check that waits for 1s (arbitrary value) after the shutdown signal and then just checks for the number of live tasks, if it's more than 1 it errors. The problem is that these untracked tasks would stay alive (since they never got any shutdown signal) for a little longer than 1s and cause the error. Given that there exist JoinSets and CancellationTokens, this is a weird way of handling shutdowns, but it's way outside the scope of this PR to fix this.
• fix: Fix overzealous error logging. It would make the merge devnet workflow fail, even though all nodes were successful (test requires no error logs). This is a reasonable solution since what was happenning was not a real error, we have the exact same pattern a few lines below.
• fix: Merge pull request #4472 from ProvableHQ/fix/rest-forward-retry-after
• fix: Merge pull request #4478 from ProvableHQ/fix/cli-static-query
• fix: devnet.sh small fixes. It's running.
• fix: fix backoff
• fix: fix certificate storage race
• fix: fix gc round update race. Not an actual bug, but would cause unnecessary error logging.
• fix: fix out of date dependency
• fix: fix storage logging
• fix: fix storage round update race
• fix: fix wrong logging at bft.rs
• fix: fix(cli): accept static queries on developer endpoints
• fix: fix(rest): compat routes always ask the upstream; the node's own height plays no part
• fix: fix(rest): forward the rate limiter's retry-after header on a 429
• fix: fixed concurrent updates test. it was not sound.
• change: Allow operators to limit REST verification concurrency at startup.
• change: Check the full feature graph in cargo-deny.
• change: Clean stale JoinHandles when you spawn new tasks.
• change: Enable extended CI
• …and 66 more

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

ProvableHQ/snarkOS was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.