Deep Dive: Solana Onchain Activity - April 2026

Note: Below is the text-accessible version of this post for visually impaired readers.

Syndica Deep Dive: Solana Onchain Activity - April 2026

Part I Client & Scheduler Stakes

86% of stake run on Agave, 11% on Frankendancer, 3% on Firedancer.

Agave Jito was the single largest scheduler at 36%; JitoBAM (28%) and Harmonic (18%) followed, with Rakurai and Vanilla at 2% each.

Frankendancer was mostly Jito (FD Jito: BUN 5%, BAL 3%) with the rest on Harmonic (PRF 1.4%, BAL 0.4%).

Firedancer was almost fully Jito at 2.5% of network, with 0.15% on Firedancer Harmonic.

Part II Block-building behavior

How do schedulers fill a block?

Most schedulers fill general block work continuously through the slot. Three main components help us classify them:

• CU sets the main block-building shape.
• Votes are the most independent component, landing early, mid-slot, or late, depending on the scheduler.
• Jito bundles can be aligned with CU, late behind it, or forward of it.

The next slides prove why CU, votes, and Jito bundles are the right classification axes. We then use them to classify and group the different schedulers.

The underlying data comes from @0xGhostLogs and is available at sandwiched.me.

Part II.A Block Anatomy

Each block has moving parts which reveal schedulers' behaviour.

Ghost shred data captures every block in 10ms buckets. Ghost provides a rich set of per-bucket counters; we use the following subset:

• Votes
• Jito bundles
• Trades: DEX trade transactions.
• Other Non-Vote Transactions: all non-vote, non-bundle, non-trade transactions (eg program calls, oracle updates or NFT mints).
• Failed transactions.
• CU Success / CU Failed: compute units consumed by successful/failed transactions.

Each panel is one scheduler's average block in April, decomposed by transaction type.

The y-axis is the average number of transactions in each 10ms bucket; the x-axis is ms since the slot start. Some observations:

• Votes dominate the early slot for most Jito-family schedulers.
• Failed transactions tend to appear later, when the block is fuller.
• Some schedulers have visibly different shapes (eg. Harmonic and FD Jito BUN).

CU composition shows where schedulers execute work and where failures land.

Most Jito schedulers and Rakurai show a relatively steady CU shape: successful and failed compute are streamed through much of the slot.

FD Jito: BUN is the clearest delayed profile, with most CU held until later in the block.

Harmonic variants are less uniform, spanning fast-fill, delayed, and more continuous profiles.

Two limits of the area chart, and what we use instead.

Limits:

• TX counts and CU counts use different units. A TX panel can't be put next to a CU panel and read together.
• Stacked area hides shape. The chart shows where each component is dense per bucket, but not how the cumulative curve climbs through the slot; two schedulers can share a per-bucket distribution and still build very differently.

The fix:

• Plot every component as cumulative-fill % across the slot. Each component is rescaled to its own slot total. CU and TXs now share an axis. Steep early section = fast fill. Long flat section = idle.

Part II.B Classification Axes

CU is the cleanest read on a block: it captures non-vote transactions and tracks priority fee revenue.

The cumulative successful-CU curve shows how quickly each scheduler fills the block with executed compute.

Tracking compute is helpful for two reasons:

• It summarises the block. Every transaction consumes CU, so the curve ties votes, bundles, trades, and other non-vote work together.
• It tracks revenue. Priority fees (the largest share of block income) are a function of CUs consumed.

Only three components add real classification power.

To avoid over-classifying the block, we compare every Ghost component against successful CU. For each scheduler, we measure the gap between each component's cumulative-fill curve and the successful-CU curve.

Two components diverge meaningfully:

• Votes: 120ms median gap from CU, 200ms at most.
• Jito bundles: 30ms median, 150ms max.

CU failed, failed txs, other non-vote work, and trades all stay within 15ms of CU.

The final taxonomy uses CU fill, vote timing, and Jito bundle position with respect to CU.

Most schedulers hold one personality across April, but Agave Harmonic and FD Harmonic: PRF drift.

Daily p50 timing is stable for most scheduler families in April. The exceptions are Agave Harmonic and FD Harmonic: PRF.

Agave Harmonic shows a clear gradient across all three components. FD Harmonic: PRF shows a milder pre/post-Apr 23 split on votes and bundles.

This is why the report classifies schedulers and time-based regimes, not just client names. Collapsing Agave Harmonic or FD Harmonic into a single monthly average would mask two distinct shapes.

Part II.C Scheduler Profiles

CU fill gives the general shape of the block.

We can classify schedulers into four groups:

• Streaming fill: CU climbs steadily from the first bucket through the end of the slot. This is the default shape.
• Fast fill: CU is front-loaded and stays ahead of streaming fill through most of the slot, slowing at the end group.
• Delayed burst: CU is quiet early, then ramps sharply after ~200-250ms.
• Fast-start / long-tail: CU jumps early, then slows before reaching p50, then picks up again.

Schedulers differ in where Jito bundles sit relative to CU.

Bundle posture is measured relative to successful CU. We classify a scheduler as:

• Bundle-forward: bundles are included in the block before other transactions, so that the bundle curve leads CU. JitoBAM, Rakurai, with FD Jito: BUN being the most extreme case.
• Bundle-aligned: bundles and the rest of transactions fill at roughly the same pace, so that bundle and CU curves overlap. Most Harmonic variants run this, plus Firedancer Jito and FD: Jito BAL.
• Bundle-late: bundle curve trails CU, with p50 at 340ms. The last 100ms of the slot does the most bundle work. Only Agave Jito runs this.

Vote timing separate early, mid-slot, and late-vote schedulers.

The default vote shape is an early wave followed by a smaller tail. Some Harmonic regimes break it: votes either shift to the middle of the slot or are held back until after CU and bundles have mostly filled.

We use three vote-timing labels:

• Early vote fill: the default. Votes mostly clear before general CU.
• Mid-slot vote fill: votes start early but climb slowly, reaching half-fill near the middle of the slot.
• Late vote / vote-separated fill: CU and bundles fill first; votes arrive late.

Part II.D Scheduler Archetypes

Each scheduler regime is a combination of CU fill, vote timing, and bundle posture.

Scheduler/Regime CU Fill Vote Timing Bundle Posture
Agave Jito Streaming Early Bundle-Late
Agave JitoBAM Streaming Early Bundle-Forward
Agave Rakurai Streaming Early Bundle-Forward
FD Jito: BAL Streaming Early Bundle-Aligned
Firedancer Jito Streaming Early Bundle-Aligned
FD Jito: BUN Delayed Burst Early Bundle-Forward
Agave Harmonic (Apr 1-11) Delayed Burst Early Bundle-Aligned
Agave Harmonic (Apr 11-24) Fast-Start / Long-Tail Mid-Slot Bundle- Aligned
Agave Harmonic (Apr 24-30) Fast Fill Late Bundle-Aligned
FD Harmonic: BAL Fast Fill Late Bundle-Aligned
FD Harmonic: PRF Apr 1-23 Streaming Mid-Slot Bundle-Aligned
FD Harmonic: PRF Apr 23-30 Streaming Mid-Slot Bundle-Forward

Agave Jito: streaming, early votes, bundle-late.

General non-vote work streams through the slot, votes clear early, and Jito bundles land materially later than CU.

• CU success p50: ~250ms.
• Votes p50: ~140ms.
• Jito bundles p50: ~340ms, about +27% versus CU by the relative bundle rule.

Agave JitoBAM and Rakurai: streaming, early votes, bundle-forward

Both schedulers stream CU through the slot, run early votes, and pull Jito bundles forward of CU. The shapes are very similar; they differ in overall pace, with Rakurai running slightly slower.

• JitoBAM (p50): CU ≈ 230ms · Votes ≈ 130ms · Bundles ≈ 190ms (-21% vs CU).
• Rakurai (p50) : CU ≈ 270ms · Votes ≈ 130ms · Bundles ≈ 220ms (-23% vs CU).

Agave Harmonic is highly adaptive; three versions across the month.

The three regimes don't share a CU shape, vote shape, or vote position. The only constant is that bundles stay mostly aligned with CU.

• Apr 1-11 (p50) : CU ≈ 310ms · Votes ≈ 110ms · Bundles ≈ 310ms (0% vs CU) → delayed burst · early votes · bundle-aligned
• Apr 11-24 (p50): CU ≈ 220ms · Votes ≈ 250ms · Bundles ≈ 250ms (+12% vs CU) → fast-start, long-tail · mid-slot votes · bundle-aligned
• Apr 24-30 (p50): CU ≈ 160ms · Votes ≈ 350ms · Bundles ≈ 150ms (-7% vs CU) → fast fill · late votes · bundle-aligned

FD Jito: BUN: delayed burst, early votes, bundle-forward

Votes are early. CU is the unusual part: nearly flat through the first 200ms (only 13% filled), then ramping to 65% by 400ms. Bundles cross 50% by ~190ms This is the most extreme bundle-forward/late-CU split on the network.

• CU success p50: ≈ 340ms.
• Votes p50: ≈ 150ms.
• Jito bundles p50: ≈ 190ms, -79% relative to CU. bundle-forward.

FD Jito BAL and Firedancer Jito: streaming, early votes, bundle-aligned

Both schedulers stream CU continuously and keep Jito bundles within 15% of CU.

The difference is in pace: Firedancer Jito has the fastest votes in the panel (p50 100ms), and finishes the slot much earlier.

• FD Jito: BAL (p50): CU ≈ 270ms · Votes ≈ 170ms · Bundles ≈ 250ms (-8% vs CU).
• Firedancer Jito (p50): CU ≈ 230ms · Votes ≈ 100ms · Bundles ≈ 200ms (-15% vs CU).

FD Harmonic BAL: fast fill, late votes, bundle-aligned

CU and Jito bundles fill fast, bundles slightly ahead of CU. Votes are held back through the first 200ms and finish late.

• CU success (p50): ≈ 160ms.
• Votes (p50): ≈ 310ms.
• Jito bundles (p50): ≈ 140ms (-14% vs. CU).

FD Harmonic PRF: streaming, mid-slot votes, bundles shift from aligned to forward in late April

Both periods share the same CU shape (streaming, p50 220-240ms).

Jito bundles Apr 1-23 fill alongside CU; in late April, bundles lead CU through the whole slot.

Votes also change shape in Apr 23-30. They slow down twice within the slot, then sprint to catch up.

• Apr 1-23 (p50): CU ≈ 240ms · Votes ≈ 220ms · Bundles ≈ 240ms (0% vs CU).
• Apr 23-30 (p50): CU ≈ 220ms · Votes ≈ 250ms · Bundles ≈ 180ms (-22% vs CU).

Part III Scheduler Fundamentals

Part III.A Performance

Every Agave variant runs below average skip rate.

Agave JitoBAM has the lowest skip rate at 0.047% (-34% vs average), with the rest of the Agave family also below average: Agave Harmonic (-25%), Agave Rakurai (-21%), Agave Jito (-7%).

The Firedancer/Frankendancer side runs above average across the board, led by FD Harmonic: PRF at 0.527% (+632%).

FD Harmonic: PRF packs the most CUs and the most user transactions per block.

FD Harmonic: PRF leads compute units at 41.5M CU/block (+19% vs average), with Agave Rakurai and at +11%.

FD Harmonic: PRF leads again on user transactions at 599 txs/block (+34%), followed by Agave Rakurai (+10%) and FD Harmonic: BAL (+9%).

Most schedulers vote within 1.02 slots.

FD Jito: BUN runs the lowest vote latency at 1.012 slots (-2.7% vs average), with Agave Jito (-2.5%) and Agave Harmonic (-2.5%) close behind.

FD Jito: BAL is the slowest at 1.143 (+10%).

Jito schedulers run under target; Harmonic and Rakurai don't.

Jito and JitoBAM schedulers run fastest at 363-377 ms median (-9% to -6% vs the 400ms target), the Harmonic stack runs over target at 409-435 ms, and FD Harmonic: PRF sits alone at 642 ms (+61%).

Most schedulers run consistent blocks (IQR under 35 ms). FD Harmonic: PRF is the exception at 417 ms IQR (+813% vs panel).

Part III.B Economics

Harmonic schedulers pay validators the most; FD Harmonic: PRF and Rakurai pull ahead on the delegator side.

Three Harmonic schedulers lead validator non-inflation APY: FD Harmonic: PRF (0.92%), FD Harmonic: BAL (0.67%), and Agave Harmonic (0.64%).

The delegator side is led by FD Harmonic: PRF (0.19%) and Agave Rakurai (0.18%).

All Harmonic versions earn the most revenue per block.

FD Harmonic: PRF leads at 0.0555 SOL (+79% vs average), then FD Harmonic: BAL (+38%), and Agave Harmonic (+30%).

Agave Rakurai is the top non-Harmonic scheduler at 0.0343 SOL (+10%).

Rakurai tops Jito tips by a thread; FD Harmonic: PRF wins priority fees outright and lands second in tips.

Agave Rakurai earns 0.0107 SOL/block in Jito tips, +76% vs average. FD Jito: BUN nearly matches at +73%, with FD Harmonic: PRF third at +54%.

FD Harmonic: PRF dominates priority fees, capturing 0.046 SOL/block (+84% vs average). The rest of the Harmonic family follows: FD Harmonic: BAL at +47% and Agave Harmonic at +34%.

Harmonic versions earn the most revenue per CU and per transaction.

FD Harmonic: PRF earns the most revenue (Jito tips + priority fees) per CU at 1.34 lamports/CU (+50% vs average). Agave Harmonic (+42%) and FD Harmonic: BAL (+33%) are close behind.

Per transaction, FD Harmonic: PRF leads again at 41,000 lamports/tx (+58%), with FD Harmonic: BAL (+33%) and Agave Harmonic (+30%) close behind.

Appendix Background Theory

Clients live on mainnet

Base Clients Schedulers

• Agave: main Solana validator Client maintained by Anza, continuing the work of the Solana Labs client. Serves as the reference implementation for the network.
• Firedancer: validator client developed by Jump Crypto in C.
• Frankendancer: hybrid client as a transitional step towards the full Firedancer client. It combines the original consensus and runtime components from Agave with Firedancer's networking, signature verification, and block packing.
• Vanilla: default Agave/Firedancer/Frankendancer clients.
• Jito: modified version of the core client with built-in Maximum Extractable Value (MEV) auction and block engine to maximize revenue and potentially increase reliability and performance.
• JitoBAM: block building extension for jito-solana that offloads transaction sequencing to external schedulers running in trusted execution environments.
• Rakurai: performance-focused fork of Agave, incorporating optimized scheduling and transaction processing.
• Harmonic: marketplace for block construction where independent builders compete to produce blocks, and validators select based on revenue, fairness, or other preferences.

Validators and Block Production

A validator is a computer or node that verifies the accuracy of transactions, creates new blocks, and participates in consensus.

A slot represents an allotment of time for which a block may be produced. Validators are assigned to act as slot leaders for a set of 4 consecutive slots. During these 4 slots, the designated slot leader is responsible for creating blocks by bundling hundreds to thousands of transactions, which include both vote and non-vote transactions.

Validators submit vote transactions to reach consensus. One can understand it as validators casting votes to agree on what is happening within the Solana blockchain and what the correct order of events is.

Non-vote transactions are any other kind of transaction, like a swap, a token transfer, etc.

Measuring Network Performance

We will use four main metrics to measure Solana's network performance:

1. Block time: Measures how quickly blocks are created, with Solana aiming to produce one block every 400ms.
2. Blocks produced: Measures how many successful blocks Solana outputs, targeting 216,000 blocks per day.
3. Skip rate: When a slot leader fails to produce an acceptable block in their assigned slot, the block gets skipped. Skip rate tracks the ratio of skipped versus total slots.
4. Vote latency: Measures the time between when a block is produced and when a validator's vote for that block is included in a future slot. It is measured in slots, and the minimum possible latency is one slot.

Understanding Solana's fee structure

There are three types of transaction fees in Solana: base, vote, and priority.

• Transaction fees are fixed at 5,000 lamports per signature. 50% goes to the block leader, 50% is burnt. They apply to:
  • Non-vote transactions for user activity, like swaps and transfers, are commonly known as base fees
  • Vote transactions (validators participating in consensus), known as vote fees
• Priority fees are optional user payments to prioritize transaction inclusion. They are calculated by multiplying the transaction's compute unit limit by a user-defined price per compute unit.
• Tips are extra SOL payments users make to validators to speed up transaction inclusion.

What are compute units (CU)?

Onchain transactions consume computational resources, quantified in compute units (CU). Each CU generally corresponds to one Berkeley Packet Filter (BPF) instruction (e.g., basic arithmetic like addition or subtraction), with estimates for more complex ones.

BPF started as a kernel tool for efficient packet filtering in Linux, later extending to eBPF for broader, high-performance applications in networking and tracing. Solana uses sBPF, a modified version that creates a virtual machine for eBPF programs.

Block Compute Budget

• Each block: limit of 48M CU (raised to 50M CU on April 10 2025 and again to 60M CU on July 22 2025)
• Blocks consist of multiple transactions
• Each transaction deducts CU from the block budget

CU Limits

• Maximum: 1.4M CU per transaction
• Transactions are split into instructions
• Users specify a compute limit for the entire transaction, up to 1.4M CU. Without a specified limit, the default is 200k CU per instruction.