Jito Publishes BAM Attestations Design So Validators Can Verify Solana Transaction Ordering

Jito JTO$0.566-6.0% has published the design for BAM attestations, cryptographic proofs that will let Solana validators and traders verify that a BAM node runs the exact code it claims. The BAM Team's post, dated 28 September 2026, is a design and progress report, and most of what it describes has yet to ship. TLS encryption is live on every mainnet BAM node, the BAM Registry is being tested on BAM's testnet fleet, and the step that binds attestations to those encrypted connections has only entered internal testing. Public attestations remain on the roadmap.

Jito announced the post on X the same day, describing attestations as "the next step in BAM's road to transparency" and saying they "let validators and market participants independently verify that BAM's transaction ordering is fair, deterministic, and transparent."

What BAM attestations prove about Solana transaction ordering

BAM (Block Assembly Marketplace) nodes put incoming transactions into an order and pass that order to the validator producing the block. The nodes run inside trusted execution environments (TEEs), sealed-off areas of a processor that can issue signed reports about the software running inside them. Those signed reports are the attestations. According to the BAM Team, a validator checks each report against published measurements, fingerprints of the expected code and configuration, before it streams anything to the node.

The BAM Team frames the payoff for each side. Validators get "assurances that the orderflow they receive was scheduled according to known, pre-set rules," and market participants get "deterministic inclusion guarantees." The larger aim is decentralisation of the nodes themselves: "Once third parties operate BAM Nodes, attestations are what let the network trust a specific node without trusting its operator," the post says.

The ordering being attested has real money attached. Jito tips, which traders pay to have bundles of transactions included in a set order, totalled about 43,300 SOL over the 30 days to 28 September, roughly 18% of the ~235,000 SOL in Solana network fee revenue across base fees, priority fees and tips, according to Solana Compass data.

TLS, the Registry and the relay-attack gap in TEE attestations

The BAM Team splits the trust problem into three questions, each answered by a separate component at a different stage of rollout.

TLS answers "am I really connected to a BAM node?" It is the encryption standard behind HTTPS, and it is now live on all mainnet BAM nodes, with certificates issued and renewed automatically by Certio, a library for managing TLS inside TEEs. BAM binds each certificate to an IP address instead of a domain name, which the post describes as a deliberate choice so nodes can operate permissionlessly, and each certificate lasts only as long as the TEE instance holding it. The BAM Team says it verified the setup with its Dublin BAM node producing blocks over HTTPS with one of Jito's internal validators. Validator connections are still optional TLS today.

The BAM Registry answers "which BAM node should I connect to?" It tells validators which nodes are healthy, fails over to the next-best node when one drops, and is meant to let validators find nodes run by third parties without tracking endpoints by hand. The Registry is in internal testing on BAM's testnet fleet.

Attestations answer "is this node running what it says it is?", and on their own they leave a gap. A report proves only that some machine runs the correct code; it says nothing about the machine on the other end of the connection. A dishonest node could forward a validator's request to an honest node and pass the genuine report back as its own, which the BAM Team calls the relay-attack gap. The fix ties the report to the live connection:

1. The validator asks the BAM Registry for the IP address of a healthy BAM node.
2. The validator opens a TLS connection and checks the node's certificate.
3. Over that session, the validator requests an attestation report and includes a fresh random value, a nonce.
4. The BAM node generates the report inside its TEE, binding in the nonce and key material from that specific TLS session.
5. The validator checks the binding and compares the report with the published measurements before streaming transactions.

A relayed report would carry another session's details and fail step five. It works much like a one-time login code, which is only accepted in the session that asked for it.

What remains before attestations go public: TLS-only and an open-source scheduler

The post lists three remaining steps without dates: rolling the BAM Registry out to mainnet, moving validator connections from optional TLS to TLS-only, and opening attestations to the public alongside open-sourcing of the BAM scheduling code.

The last step matters most for outside observers. A measurement proves a node runs a known build; publishing the scheduling code is what lets anyone read what that build does with the transactions it orders. Until both are public, the checks are mainly available to validators connecting to BAM nodes. TEE-based proofs also shift trust away from the node operator and onto the enclave hardware that signs the reports.

Attestations cover one direction of what the post calls the BAM "arrangement." The other direction is already handled by two existing components: the BAM Verifier "checks the ordering of transactions sent to leaders against what lands on-chain, and Autobahn automatically bans validators the Verifier flags." Together, the BAM Team argues, they "cover both directions of the BAM 'arrangement' between BAM Nodes and BAM validators to provide trustless guarantees."

Jito's ordering transparency push and the SIMD-0649 debate

Jito's attestations design lands less than three weeks after BAM preconfirmations went live on Solana mainnet on 9 September. It also follows the closure on 27 September of SIMD-0649, a proposal to set a priority-ordering rule at the protocol level, without merging.

The two efforts attack the same concern from different layers. The protocol debate is about what ordering rules every Solana validator should follow; BAM's attestations are about proving that Jito's own ordering system follows the rules it publishes. For validators already running BAM, the practical change arrives with the Registry's mainnet rollout and the switch to TLS-only connections, the two pieces the attestation flow depends on.