Jito

• Name: Jito
• URL: https://docs.jito.wtf/
• Category: Solana transaction-delivery / low-latency data / MEV infrastructure
• Tags: solana-ecosystem
• Summary: Jito is the project-layer note for the combined Solana MEV and low-latency execution stack: Block Engine routing, tip-based bundle auctions, Shredstream, and the Jito-Solana validator-client path that ties searchers, apps, and validators into one market structure. That product cut is still useful, but the practical operator boundary now also lives in jito-labs, which is the cleaner place to reason about Block Engine availability, searcher access, regional endpoint topology, API-key issuance, and the company-run low-latency ingress many production users inherit.
• What it does:
  • Provides low-latency transaction submission endpoints for Solana users who care about fast landing, MEV protection, and revert protection
  • Supports atomic bundles of up to five transactions, with tip-based auctions and sequential all-or-nothing execution inside a slot
  • Operates Shredstream, a low-latency feed for Solana shreds intended to reduce data-delivery latency for RPCs, validators, and trading systems
  • Maintains Jito-Solana, a fork of the Solana / Agave validator client that connects validators into Jito’s Block Engine workflow
  • Publishes SDKs, protobufs, and searcher example repos that make the technical integration surface much more concrete than the marketing framing alone
• Key claims:
  • The docs home describes Jito as a Turbocharged Solana trading experience aimed at validators, Telegram bots, high-frequency traders / searchers, and dapps
  • The docs say Jito offers low-latency transaction sending, low-latency blockchain / shred data, and around-the-clock developer support
  • The low-latency transaction-send docs state that Jito provides superior Solana transaction execution through fast landing, MEV protection, and revert protection for both single transactions and bundles via gRPC and JSON-RPC services
  • The system overview explains that validators run Jito-Solana, connect to the Jito Block Engine, and receive profitable bundles, while searchers and apps connect to the Block Engine to submit transactions and bundles
  • The docs define bundles as up to five transactions executed sequentially and atomically, with tip bids competing in a priority auction that runs at 50ms ticks
  • The public GitHub org and repos show that Jito exposes real operator and developer surfaces, including searcher examples, protobuf definitions, a shredstream proxy, and validator-client materials split across Jito Labs and the Jito Foundation
• Whitepaper: No classic standalone whitepaper or litepaper was found during this pass. The strongest primary materials were Jito’s docs portal plus the Jito Labs and Jito Foundation repositories, which function as the real source of truth for the product and adjacent operator surface; see ../whitepapers/jito-primary-sources-2026-04-26.md.
• Sources:
  • https://docs.jito.wtf/
  • https://docs.jito.wtf/lowlatencytxnsend/
  • https://github.com/jito-labs
  • https://raw.githubusercontent.com/jito-labs/searcher-examples/master/README.md
  • https://raw.githubusercontent.com/jito-foundation/jito-solana/master/README.md
  • https://raw.githubusercontent.com/jito-labs/shredstream-proxy/master/README.md

Internal linkages

• Company boundary for the searcher-facing and low-latency ingress shell: jito-labs.
• Foundation boundary for validator-client stewardship and MEV-distribution guidance: jito-foundation.
• Strongest cross-chain comparison: flashbots-auction.
• Validator-side topology contrast: mev-boost.
• Best sold ordering advantage contrast: timeboost.

Protocol / company / foundation boundary

• This note keeps the product-layer cut: bundles, Block Engine routing, Shredstream, Jito-Solana, and the overall validator / searcher market structure.
• jito-labs is the operator note for the company-managed ingress and routing shell: API keys, regional endpoints, Block Engine availability, Shredstream packaging, and other searcher-facing workflow surfaces.
• jito-foundation is the adjacent validator-client and MEV-distribution boundary: Foundation-hosted Jito-Solana docs, validator workflow guidance, and tip-distribution framing.
• That split matters because some questions are about product behavior, some are about company-run latency and access control, and some are about the foundation-adjacent validator-client or payout layer.

Control surface

• At the project layer, the important mechanism is the combined path from searcher submission to bundle auction to validator execution to MEV redistribution.

• For concrete operator questions like who runs the Block Engine endpoints, how access is mediated, where low-latency traffic is routed, and which workflow defaults searchers inherit, read jito-labs.

• For validator-client stewardship and payout-path questions like where relayer behavior, tip-distribution workflow, and canonical validator guidance are documented, read jito-foundation.

• Read Jito as infrastructure for selling or packaging transaction-ordering advantage on Solana, not as just another RPC brand.

• Last reviewed: 2026-08-08 UTC