The getTipAccounts method on Jito Labs' low-latency transaction send page returns eight public keys, and a live call to mainnet.block-engine.jito.wtf on 24 October 2026 returned that same set, including 96gYZGLnJYVFmbjzopPSU6QiEV5fGqZNyN9nmNhvrZU5 and HFqU5x63VTqvQss8hp11i4wVV8bD44PvwucfZ2bU7gRe. A Jito tip is a transfer of SOL into one of those keys.
The transfer is easy to misread as a cheque with a validator's name on it. The Jito Foundation tip-payment page says the leader rotates about every 1.6 seconds, and a searcher should keep one signed bundle in play across several leaders until it expires. The mechanism is a static address plus a config account that changes who the tip belongs to. Solana's fee-structure page, opened the same morning, takes the base fee and any priority fee before execution and keeps them when the transaction fails. The tip moves when the bundle commits and sits idle when the bundle expires in the engine.
CoinGecko marked JTO at $0.436728 at 07:37 UTC on 24 October 2026, with a circulating supply of 535,821,334.5 and a market cap of $234,028,463. The mint on that record is jtojtomepa8beP8AuQc6eXt5FriJwfFMwQx2v2f9mCL. JTO, the governance token, is separate from the SOL the steps below follow.
Updated 24 October 2026
Key facts
- Eight tip accounts accept the transfer, and the documented minimum for a bundle is 1,000 lamports. Source: Jito Labs docs, 24 October 2026.
- A bundle holds at most five transactions, in listed order, inside one slot, or it drops as a group. Source: Jito Labs docs, 24 October 2026.
- Auctions tick every 50 milliseconds and rank a bundle by tip per compute unit. Source: Jito Labs docs, 24 October 2026.
- A 6% fee comes off MEV rewards before validators and stakers are paid: half Block Engine commission, half TipRouter for the DAO and NCN participants. Source: Jito Foundation validator FAQ, 24 October 2026.
- The DAO treasury's tip line is 5.7% of all Jito tips, via TipRouter. Source: Jito Economic Hub, 24 October 2026.
- Solana's base fee is 5,000 lamports per signature, half burned and half to the validator, and the priority fee goes entirely to the validator. Source: Solana fee docs, 24 October 2026.
The path, in the order the lamports move
- A SOL transfer to one of the eight tip accounts, picked at random, sits inside the bundle.
- At most five signed transactions go to a regional block engine, over gRPC or JSON-RPC.
- The engine simulates the bundle and ranks it on a 50-millisecond auction by tip per compute unit.
- A winning bundle reaches the leader when that leader runs Jito-Solana and can take it inside the slot.
- The client folds the tip into an epoch account derived from its vote account, then runs the bundle as a whole.
- After the epoch, a merkle root is uploaded. Commission, in basis points, is the operator's share, and stake accounts claim the rest.
- A bundle id means the engine accepted the payload. Landing is a later status: Pending, Failed, Landed, or Invalid.
Write the tip into one of eight static accounts
Jito's sendBundle method states the entry condition directly. "A tip is necessary for the bundle to be considered. The tip can be any instruction, top-level or CPI, that transfers SOL to one of the 8 tip accounts." The client picks one of the eight keys at random so the writes spread across locks.
Eight keys exist because Solana write-locks an account a transaction writes, and one shared tip account would queue every paying bundle on a single lock. The tip-payment page says the eight static accounts let bundles pay and execute on parallel pipelines. On 24 October 2026 the addresses page still listed eight, the live getTipAccounts response matched it, and the program that owns them is T1pyyaTNZsKv2WcRAB8oVnk93mLJw2XzjtVYqCsaHqt.
A config PDA moves in place of a fresh signature every schedule turn, so the bundle pays whichever leader lands it and the searcher signs once. The tips section says to keep those accounts out of address lookup tables, and to place the transfer in the same transaction as the strategy. A tip that rides alone can clear in a state the strategy missed.
Hand the bundle to a block engine
Validators run a modified Agave client, Jito-Solana, and connect to the block engine. Searchers submit over gRPC or JSON-RPC. The overview states the bargain in one line: "Bundles have tips bids associated with them; these bids are then redistributed to the validators and their stakers."
A bundle is at most five transactions, in listed order, inside one slot, committed as a group. sendBundle relays that payload to the leader unchanged. When the bundle is set to expire after the next Jito-Solana leader, the method returns at once with a bundle id, the SHA-256 of the signatures. The page then says the quiet part out loud: "This does not guarantee the bundle will be processed or land on-chain."
The same page lists eight regional hosts, Amsterdam, Dublin, Frankfurt, London, New York, Salt Lake City, Singapore, and Tokyo, plus mainnet.block-engine.jito.wtf. The validator FAQ wants the round trip under 50 milliseconds, and farther out bundle inclusion thins while ordinary blocks still get built. One request per second per IP per region is the default, and past it the engine returns 429.
sendTransaction, the other door, can wrap a single transaction when bundleOnly is set, and the docs illustrate a 70/30 split, 0.7 SOL of priority fee beside 0.3 SOL of tip. For a real bundle the next line governs: "When using sendBundle, only the Jito tip matters."
Win a 50-millisecond auction
The engine auctions scarce blockspace on 50-millisecond ticks. Bundles whose locks intersect, write against write or read against write, share an auction, and bundles on different accounts run apart. The ordering key is "requested tip/cus-requested efficiency," and the engine offers the highest-paying combination up to a compute-unit limit.
Solana ranks a processed transaction by reward per cost, the priority fee plus the unburned half of the base fee, once it is already in the leader's buffer. The Jito auction runs earlier and chooses which bundles are offered. For sendBundle the bid is the tip scaled by requested compute, so a large tip on a bloated bundle can lose to a smaller tip on a tight one. The 1,000-lamport floor gets a bundle considered, and the docs call that floor too low in a crowded slot.
A pubkey beginning with jitodontfront has to lead the bundle, ahead of the strategy and the tip, and that account can be absent on chain and marked read-only. The page calls this a sandwich mitigation limited to the block engine. A bundle that fails simulateBundle leaves the tip with the searcher, because the leader commits the group when every transaction succeeds.
What the leader actually runs
"Only nodes on the Solana leader schedule can connect to the Jito Block Engine." The FAQ says Jito Labs operates the engines that simulate and forward, and an RPC may still run the open-source client for SimulateBundle.
A second latency budget appears for the Block Assembly Marketplace: inside 30 milliseconds to a BAM node, against the 50-millisecond block-engine figure. The command-line page documents optional --bam-url, from Jito-Solana v3.0.14 and v3.1.16, for pre-sequenced bundles from that node. On a BAM validator the block-engine stage exiting is expected, and the tip-payment program id stays T1pyyaTNZsKv2WcRAB8oVnk93mLJw2XzjtVYqCsaHqt.
The docs call a tip aimed at any leader outside Jito-Solana ineffective, and a stock Agave leader still clears Solana's own fee market.
From the static key to that epoch's piggy bank
Once the leader commits the bundle, the tip accounts hold the lamports and the config PDA attaches them to the leader of that slot.
The tip-distribution program, 4R3gSG8BpU4t19KYj8CfnbtRpnT8gtk4dvTHxVRwc2r7, turns a slot's tip into an epoch of tips. "Every epoch, the validator client creates a unique TipDistributionAccount derived by the epoch and vote account public key. The validator client then uses this TipDistributionAccount to aggregate MEV paid out to their account over the entire epoch." At the boundary a snapshot of the last slot feeds a merkle tree of pro-rata claims, and the root of that tree is what stakers claim against.
The upload flag, --merkle-root-upload-authority, points at 8F4jGUmxF36vQ6yabnsxX6AQVXdKBhs8kGSUuRKSg8Xt when Jito runs the airdrop and the claim. Any other key means the operator runs it. That same key is the merkle authority on the addresses page, and the program upgrade authority is the Jito DAO at 4ivLcnNLhe4cKdpV9b4jyEmxgbYWFgktHcTyyBvYavsD. Once the root is on chain, the claim is permissionless.
Those lamports arrive as an airdrop, unlike Lido's daily stETH rebase, which folds the reward into the balance the holder already has. Staking that airdrop is a step the owner takes. Until then the MEV stays out of the next epoch's stake weight.
Who keeps which slice
The validator FAQ prices the engines upstream of the operator's cut. "A total 6% fee is charged on all MEV rewards, so this amount is deducted from the amount available to validators and stakers. Half is taken by the Block Engine as block builder commission; the remaining half is taken by TipRouter at distribution time and routed to the Jito DAO and NCN participants."
Half of that 6% fee is 3% to each side, and the other 94% is what the FAQ leaves for the validator and its stakers, before the operator's own commission.
The Jito Economic Hub states a second figure the same day: "5.7% of all Jito tips, distributed via the TipRouter network." Adding that line on top of the 6% would double-count, because the pages leave the combined waterfall unstated. A separate hub line, a 4% fee on rewards distributed through JitoSOL, is liquid staking rather than the bundle tip, and the chart uses the FAQ alone.
After the fee, --commission-bps is the operator's share in basis points. The sample mainnet line passes 500, or 5%. On the 94% left after the fee, that sample is 4.7% of the original tip for the operator and 89.3% for stakers, and each validator sets its own rate.
TipRouter is the operator set that agrees the merkle root. On 4 December 2025 the Jito account said that set had distributed more than $1.1 million to restaking participants since launch.
No centralization on tips or priority fees!
Happy to report that the TipRouter NCN has distributed >$1.1m to restaking participants since launch! 🎉
ICYDK TipRouter is a network of node operators who come to consensus on the correct distribution of Jito tips & priority fees. pic.twitter.com/2ihZcN8O3yRelated5.0% Rise in Mantle (MNT) After the Reth Switch Notice
— Jito (@jito) December 4, 2025
Those operators are paid inside the TipRouter half, beside the DAO. How restaked stake compares with native stake is a different split, the one in EigenLayer against native staking, and the operator-and-delegator cousin is how Rocket Pool divides a minipool's ETH reward. Jito's version is the basis-point flag plus a merkle proof, in SOL, an epoch behind the slot.
| Jito tip | Solana priority fee | |
|---|---|---|
| What moves | SOL, by a transfer to one of eight tip accounts | Lamports from compute-unit price and limit on legacy and v0. On v1 the fee is an absolute lamport total. |
| Who receives it | Tip accounts, then the epoch distribution account | The leader receives the full priority fee. Half the base fee is burned. |
| What ranks it | For sendBundle, the bid is the tip | Reward per cost, among transactions already in the leader's buffer |
| If the attempt misses | A dropped bundle leaves the transfer unexecuted | A processed transaction that fails still pays the fee |
| Floor in the docs | 1,000 lamports for a bundle | Base fee of 5,000 lamports per signature, and a default priority fee of zero |
Sources, all retrieved 24 October 2026: Jito Labs, low-latency transaction send; Jito Foundation, tip-payment and tip-distribution pages; Solana, fee structure.
When the bundle misses
A bundle id means the bytes arrived. Landing is a later check, through getBundleStatuses or, for five minutes, getInflightBundleStatuses. Pending means the bundle is still in flight. Failed means every region that received it marked it failed and withheld the forward. Landed means an RPC check or the bundles_landed table saw it. Invalid means the id is absent from that five-minute window. getBundleStatuses looks through recent slots plus up to 300 rooted blockhashes, and a null is unknown or unlanded.
A low tip is the ordinary auction miss. The minimum is 1,000 lamports, and a crowded slot needs more. The docs publish a tip_floor endpoint for recent percentiles, and a request to that host failed on 24 October 2026, so the percentiles stay out. The SOL remains with the searcher.
The stranger miss is an uncled block, a block the supermajority skips. Jito's troubleshooting section says anyone who saw it may rebroadcast the transactions into ordinary banking, outside bundle atomicity. With the tip in the same transaction as the strategy, a rebroadcast that fails the strategy leaves the tip unmoved. An accepted block moves SOL into the eight accounts, and the merkle root moves it on to stakers.
What would make this account wrong
The description above would be wrong if the addresses page published a tip-payment program id other than T1pyyaTNZsKv2WcRAB8oVnk93mLJw2XzjtVYqCsaHqt, or a tip-distribution id other than 4R3gSG8BpU4t19KYj8CfnbtRpnT8gtk4dvTHxVRwc2r7. It would be wrong if getTipAccounts stopped returning those eight keys, if the validator FAQ replaced the 6% fee, or if the economic hub stopped stating 5.7% of tips via TipRouter. Documentation that a missed bundle still moved SOL, or that removed the merkle claim, would retire the last steps. A BAM-only payment path in place of the eight accounts would retire the static-address step.
Questions the path keeps attracting
What happens to the tip when a bundle misses the leader?
The tip is a transfer instruction inside the bundle. Jito's sendBundle page says a returned bundle id means the engine received the payload, and the same passage separates receipt from landing. A dropped bundle leaves the transfer unexecuted, so the tip accounts stay at their prior balances. Within five minutes, getInflightBundleStatuses reports Pending, Failed, Landed, or Invalid for that same receipt.
How is a Jito tip different from a Solana priority fee?
A Jito tip is a SOL transfer to one of eight tip accounts, and for sendBundle the docs say only that tip matters in the auction. A Solana priority fee is optional lamports from compute-unit price and limit, and the fee-structure page pays all of it to the leader. The base fee is 5,000 lamports per signature, deducted before execution and kept if the transaction fails. The tip moves only when the bundle commits.
What does the validator keep, and what does the protocol keep?
The validator FAQ deducts a 6% fee before validators and stakers are paid. Half is Block Engine commission and half goes through TipRouter to the DAO and NCN participants. The economic hub states a 5.7% treasury tip line via TipRouter, and the two figures stay side by side. After the fee, --commission-bps is the operator's share. The sample line uses 500 basis points, and each validator sets its own rate.
Why do eight accounts receive the tip?
Solana write-locks an account a transaction writes, so one shared tip account would queue every paying bundle on a single lock. The tip-payment page says eight static accounts let bundles pay and execute on parallel pipelines, and it tells searchers to pick one at random. A config PDA then points the tip at whichever leader lands the bundle. The rotation that page cites is about 1.6 seconds.
Does JTO itself move when a trader pays a tip?
JTO is the governance token, and CoinGecko on 24 October 2026 shows mint jtojtomepa8beP8AuQc6eXt5FriJwfFMwQx2v2f9mCL at $0.436728, a reference print beside the path. The tip instruction transfers SOL into a tip account, while the economic hub books a 4% fee on rewards paid through JitoSOL, a liquid-staking stream beside the bundle tip. One tip moves as SOL, then an epoch later as a claim.
This is a reading of public protocol documentation. It is not a recommendation to submit a bundle, tip a validator, or buy JTO.