SLV v0.9.911 Adds Support for BAM Client Operations, Advancing Solana Toward a Transparent Execution Layer Suitable for Institutional Use

ELSOUL LABO B.V. (Headquarters: Amsterdam, Netherlands; CEO: Fumitake Kawasaki), together with Validators DAO, announces the release of SLV v0.9.911, an open-source operational framework for Solana validators. This release adds support for launching and operating the Block Assembly Marketplace (BAM) client developed by Jito Labs.

With this release, the introduction and switching of the BAM client can now be handled in a reproducible manner. Rather than relying on operator-specific procedures or individual operational expertise, SLV enables validators to start BAM client operations with a single command.

The Epics DAO validator has already migrated to BAM client operations using SLV and is currently running in production.

The Block Assembly Marketplace (BAM), developed by Jito Labs, is an initiative that builds on Solana’s already high-performance on-chain execution and seeks to make it possible to explain and verify, after the fact, the rules under which transactions were executed.

Compared to other blockchains, Solana has a clear advantage in transaction throughput and latency. However, as the network matures and its user base expands, the key question shifts from whether transactions can be processed quickly to whether the execution process itself can be explained in terms of the logic and rules by which it occurred.

In particular, institutions and enterprise users do not operate with proprietary capital alone. They manage client or custodial assets and are therefore accountable not only for outcomes, but for the execution process itself. They are required to explain to internal risk committees, external auditors, and in some cases regulators why a transaction was executed under a specific set of conditions and in a particular order.

This is not a theoretical concern. In traditional financial markets, such requirements are already standard practice. Best execution reporting and the submission of Transaction Cost Analysis are typical examples. It is not sufficient to state which exchange or venue was used; the execution logic itself must be explainable.

In today’s on-chain execution environments, it is difficult for third parties to verify why transactions were ordered in a particular way or which logic determined their placement. Regardless of intent, this lack of explainability alone is enough to discourage institutional participation.

BAM addresses this problem by making transaction ordering verifiable through cryptographic mechanisms. While it becomes possible to prove that transactions were ordered according to defined logic, BAM node operators themselves cannot inspect transaction contents or arbitrarily manipulate ordering.

What BAM ultimately aims to establish is not a model that relies on trusting specific operators, but one in which the execution logic itself is verifiable. This moves on-chain execution beyond being merely fast, toward an environment that is explainable, auditable, and suitable for formal reporting.

Today, Solana allows a high degree of freedom in how transaction ordering is handled. Multiple schedulers operate in parallel, each with different logic, timing characteristics, and prioritization strategies.

While this diversity enables experimentation and optimization, it also makes it difficult to consistently explain, from an external perspective, which rules determined transaction ordering. Depending on the client, routing path, or operational setup, it is not always possible to rule out ordering decisions that cannot be externally observed.

The issue here is not malicious intent. Even when all operators act in good faith, an execution environment that cannot be explained or verified is inherently incompatible with institutional and enterprise requirements.

Even if problems do not surface immediately, this opacity accumulates as execution risk and audit uncertainty. As a result, on-chain usage remains largely confined to individual users and experimental applications, while large-scale capital and enterprise adoption struggle to materialize.

Similar challenges have already emerged within the Ethereum ecosystem. With the introduction of proposer-builder separation, competition in block building increased, but this also led to a concentration of builders and the privatization of order flow.

As users and applications sought better execution, they increasingly relied on private relationships with specific builders, making transaction ordering harder to observe externally. While this structure sometimes improved short-term efficiency, it ultimately resulted in greater opacity and centralization.

Within the Ethereum community today, efforts are underway to restore transparency through approaches such as TEE-based block building. This reflects a post-hoc recognition of the importance of explainability at the execution layer.

BAM is designed with these precedents in mind, incorporating verifiability and transparency from the outset rather than attempting to retrofit them later.

BAM’s design principles only matter if they can be implemented and operated in practice. Even a well-designed system fails to improve transparency if it remains difficult to deploy or accessible only to a small number of operators.

SLV v0.9.911 integrates BAM client launch and operation into SLV’s standard workflow. This removes reliance on individual operator expertise and ad-hoc procedures when switching to BAM.

Being able to deploy in a reproducible manner is a prerequisite for widespread adoption of a verifiable execution layer. This release represents a concrete step toward embedding BAM into Solana’s operational infrastructure as an implementation, not merely as a concept.

Release details: https://github.com/ValidatorsDAO/slv/releases/tag/v0.9.911

The Epics DAO validator has already migrated to BAM client operations using SLV and continues to run in production. This demonstrates that BAM is not limited to conceptual design, but is actively functioning within real validator operations.

In addition, from a validator operations perspective, using the BAM client makes it possible to separate the logic for transaction ingestion and ordering from the validator’s core execution and voting processes.

Traditionally, the load associated with transaction intake and ordering has been tightly coupled with the validator’s execution path. With a BAM-based setup, however, the processing load related to transaction reception and scheduling can be handled as a distinct concern.

This allows validators to focus more directly on execution and voting, while enabling an operational design in which workloads with different characteristics are handled separately. This does not assert a direct performance improvement, but rather highlights that separating operational responsibilities and load domains expands the available design options for validator operations.

The verifiable transaction ordering and execution transparency that BAM aims to provide are a key element in advancing Solana toward an execution environment suitable for institutional and enterprise use.

SLV serves as the foundation for translating this direction into practical operations. Going forward, validators, RPC infrastructure, networking, and decentralized applications will be treated not as isolated optimization targets, but as interdependent components that collectively determine execution quality and trust. Through this approach, Solana’s operational infrastructure will continue to evolve.