The BAM Verifier: Ensuring Verifiable Execution on Solana
BAM (Block Assembly Marketplace) is designed around a simple separation of responsibilities:
- BAM Nodes order transactions (inside Trusted Execution Environments) and send an ordered stream to the scheduled leader
- BAM Validators execute what they receive and remain responsible for consensus, block production, and state management
That separation only works if validators follow a clear, enforceable execution contract. This post dives into the BAM Verifier, the component that makes that contract credible by verifying compliance in real time and enabling enforcement when deviations occur.
The BAM Node - BAM Validator contract
The BAM Validator is responsible for doing the following:
- Execute all transactions from BAM Nodes, in the exact order received 1
- Only execute transactions received from BAM Nodes
- Provide correct execution feedback and state information
By default, validators running the BAM client unmodified comply with these requirements without any additional work.
1 Except when write locks are non-conflicting and can be parallelized
What is the BAM Verifier?
The BAM Verifier is the mechanism that lets BAM Nodes validate, in real time, that a BAM Validator is following the execution contract. It checks that the validator executed the exact ordered transaction stream it received and that the execution outcomes and state feedback it reports are correct and consistent.
If the verifier detects a mismatch in ordering or incorrect feedback, the BAM Node can take enforcement action, including temporarily or permanently disconnecting the validator.
Verifier’s role in ACE and Plugins
This verification layer is what makes Application-Controlled Execution (ACE) and a plugin ecosystem possible in practice. Apps can opt into specific execution rules (e.g., ordering, conflict handling, custom policies), but those rules only have real value if they’re verifiable and enforceable.
The BAM Verifier provides that credibility. By making execution verifiable in real time and enabling enforcement when deviations occur, BAM can offer ACE/plugin rules as dependable infrastructure that applications and users can actually rely on.
What the Verifier checks
1) Ordering integrity
The primary rule is simple:
If the BAM Node sent transactions [t1, t2, t3, …], the validator must execute [t1, t2, t3, …] in that order.
The BAM validator client software can still parallelize when account locks allow it, but operators cannot change the relative ordering they were given. If the validator executes out of order, skips items, or injects transactions not in the stream, the contract is violated.
2) Correct execution feedback and state information
BAM Nodes rely on validator feedback to stay in sync with what actually happened during execution. This includes whether each transaction succeeded or failed, any error conditions, and other state-relevant signals from block production.
If a validator returns incorrect or inconsistent results, the Node can no longer rely on its feedback. This is why accurate execution feedback and state information are explicitly part of the validator contract.
What to do if you get disconnected by the verifier
A verifier-triggered disconnect doesn’t always imply malicious behavior. In some cases, mismatches can be caused by issues outside a validator’s control (e.g., infrastructure instability, networking problems, or unexpected client/runtime behavior).
If you believe a disconnect was triggered by external conditions, the recommended next step is to reach out to the Jito team via the Jito Developers Discord, so the incident can be analyzed. Please include:
- Time window and slot
- Validator identity
- Any recent configuration or client changes
Jito will work with you to determine what happened and whether the disconnect reflects a network issue, a behavior that needs adjustment, or something else, and where appropriate evaluate a reconnection request.