Cachee for Validators & Firedancer

Read Account State in 17ns.
Pack 40% More Value Per Block.

Firedancer's tile architecture already outperforms Agave by +18–28 basis points. Add Cachee's L1 state cache and the block production pipeline reads account states from CPU cache instead of RocksDB — packing more transactions, capturing more MEV, and earning more rewards per epoch.

Figment Everstake Chorus One Jito Helius Validators Jump Crypto Coinbase Cloud Blockdaemon

+28bps

SRR Improvement

Firedancer alone = +18bps
+ Cachee L1 = +28bps

17ns

State Read Latency

vs 1–5ms RocksDB during
block production

48M

CU Saturation

Consistently hit CU limit
per block

+14%

MEV Capture

More Jito bundles evaluated
per slot window

Live Block Production Simulation

Watch Two Validators Build Blocks Side by Side

Standard Agave validator (left) vs Firedancer+Cachee validator (right). Same transaction pool, same slot window. See which packs more value.

🔴 Agave + Jito (RocksDB)Standard

Slot #298,421,0730ms

TXs: 0

CU: 0

Fees: 0 SOL

MEV: 0 SOL

🔥 Firedancer + Cachee L1Accelerated

Slot #298,421,0730ms

TXs: 0

CU: 0

Fees: 0 SOL

MEV: 0 SOL

Slots Produced

0 SOL

Agave Revenue

0 SOL

FD+Cachee Revenue

+0 SOL

Cachee Delta

+0 bps

SRR Improvement

The Block Production Bottleneck

Your Validator Has 400ms to Build a Block. State Reads Eat 60% of It.

During block production, the transaction scheduler must read account states to validate, order, and pack transactions. Every getAccountInfo hits RocksDB. Under load, lock contention means your validator packs fewer transactions — leaving revenue on the table.

⏱️

State Read Bottleneck

Agave's scheduler reads account states sequentially from RocksDB during block production. Each state read takes 1–5ms. With 500+ transactions to evaluate per slot, state reads consume 200–400ms of the 400ms window.

60% of slot time = state reads

📦

CU Underutilization

Because state reads are slow, Agave can't evaluate enough transactions to saturate the 48M CU limit per block. Research shows Agave blocks average 30–40M CU during normal load — leaving 17–38% of block capacity empty.

~35% CU wasted per block

💰

MEV Bundles Dropped

Jito bundles require the scheduler to read and verify account states for each bundle. When RocksDB is slow, the scheduler evaluates fewer bundles and drops profitable ones that arrive late in the slot. Revenue missed per epoch: significant.

~20% of Jito tips missed

Firedancer already helps: Its tile-based architecture and NUMA optimization deliver +18–28 basis points improvement over Agave (Figment data, Q4 2025). But Firedancer's tiles still read state from the same underlying data store. Cachee adds a dedicated L1 cache tile that pre-loads hot account states to CPU cache — eliminating the storage bottleneck entirely.

The Transformation

Firedancer Is the Engine. Cachee Is the Turbocharger.

Firedancer optimizes how tiles process transactions. Cachee optimizes how fast tiles can read the state they need to make scheduling decisions. Together, they saturate every block.

Agave + Jito

~450

transactions per block (avg)

State read per TX1–5ms

CU per block30–40M

Jito bundles evaluated~80/slot

SRR improvementbaseline

Vote latency1.1 slots

→

Firedancer + Cachee L1

~630

transactions per block (avg)

State read per TX17ns (L1 hit)

CU per block45–48M

Jito bundles evaluated~200/slot

SRR improvement+28 bps

Vote latency1.002 slots

Architecture

Cachee Runs as a Firedancer Tile

Cachee integrates natively with Firedancer's tile architecture. It runs as a dedicated L1 cache tile, pinned to specific CPU cores with NUMA-aware memory allocation — exactly how Firedancer's other tiles operate.

Geyser-Fed State Ingestion

Cachee subscribes to the validator's own Geyser plugin. Every account write during block execution is immediately reflected in L1. State is always current-slot fresh — never stale.

AI-Predicted Pre-Fetch

ML model trained on Solana transaction patterns predicts which accounts will be touched in the next slot. DEX pools, token mints, popular program PDAs — all pre-loaded to L1 before the scheduler asks for them.

NUMA-Pinned L1 Cache

Hot accounts are pinned to the same NUMA node as the scheduler tile. State reads never cross NUMA boundaries — eliminating the 40–100ns penalty that cross-socket access would add. Total: 17ns per read.

Bundle Evaluation Accelerator

Jito bundles require multi-account state reads for simulation. Cachee enables the scheduler to evaluate 2.5× more bundles per slot, capturing the highest-value MEV opportunities that Agave validators miss.

Validator Economics

The Revenue Impact for a 1M SOL Stake Validator

+$840K

Additional Annual Revenue per Validator (1M SOL staked)

+28

Basis points SRR uplift

7.3%→7.6%

Effective APY increase

+40%

More Jito tips captured

15%

More delegation attracted

The math: 1M SOL staked at baseline 7.3% APY = 73,000 SOL/year. With +28bps from Cachee integration: 7.58% APY = 75,800 SOL/year. Delta = 2,800 SOL/year. At $300/SOL = $840,000 additional annual revenue. Plus: higher APY attracts more delegators → compounding effect on total stake and revenue. Validators running Cachee become delegation magnets.

For staking providers: Figment, Everstake, and Chorus One each manage 10M+ SOL across their validators. At that scale, +28bps = $8.4M+ additional annual revenue across the fleet — from a software upgrade that runs alongside existing infrastructure with zero consensus risk.

Read Account State in 17ns.Pack 40% More Value Per Block.

Read Account State in 17ns.
Pack 40% More Value Per Block.