Solana at Wire Speed

The 400-Millisecond Machine

Every Solana transaction passes through a piece of software called a validator — the program that runs the network. A validator is a state machine: it reads transactions off the network, checks their signatures, runs the program calls, updates the affected accounts, and writes the result into a block. Then it does the whole thing again, starting from the new state, in the next 400-millisecond slot (Solana's basic time unit).

Think of an air traffic control center. Thousands of planes (transactions) arrive every second from every direction. Each one has to be cleared, sequenced, and routed onto exactly one runway (the block). The tower never sleeps. It never gets to say "come back later." Every second of delay costs someone money, and one mistake can crash a flight. That's the job description for a validator — except the volume is closer to 5,000 transactions per second and the deadline to produce a block is shorter than a human blink.

The pressure to make this machine faster has spawned three entirely different engineering projects, plus a fourth tool that doesn't sit inside the validator at all but lets you replay and dissect what one of them did. The four projects you should know by name:

The incumbent in this picture is Agave, the original Solana validator maintained by Anza (formerly Solana Labs). Most of mainnet still runs Agave. Firedancer is the challenger; Samba is a fork (a modified copy) of Firedancer that adds one capability the chain couldn't otherwise express; Delorean is the debugger for what the validators produce; pmm-sim is the lab bench for the private market-making programs that ride on top.

Firedancer: The C Engine

Firedancer is what happens when a high-frequency-trading firm writes a blockchain validator. Jump Crypto built it from scratch in C, with no garbage collection, no shared memory between threads, and one job per CPU core. The idea that ties it all together is the tile.

A tile is one thread on one CPU core that does exactly one thing — receive packets, or verify signatures, or deduplicate transactions, or pack a block. Tiles never call each other and never share memory directly. They pass work down the pipeline through a shared-memory ring buffer called Tango, which Jump borrowed from the HFT (high-frequency-trading) world. The result is a system that scales by adding more CPU cores: need more ingress bandwidth? Add more NIC tiles. Need more signature throughput? Add more SigVerify tiles. No lock contention, no coordination overhead.

from external NIC
     |
     v
  +-- core ----+
  | NIC / QUIC |     ← tile: raw packets
  | SIG VERIFY |     ← tile: ed25519 verification
  |  DEDUP TAG |     ← tile: fingerprint already-seen txs
  +------------+
     |
     v   (metadata via Tango mcache)
  +-- core ----+
  |    DEDUP   |     ← tile: drop duplicates
  |     MUX    |     ← tile: multiplex verified txs
  +------------+
     |
     v
  +-- core ----+
  | BLOCK PACK |     ← tile: choose what enters the block
  +------------+
     |
     v
  to Agave (Frankendancer) or flamenco (full Firedancer)

The source tree mirrors the pipeline. tango/ is the nervous system — the IPC layer (how separate processes pass messages) that every tile uses to talk to the next one.ballet/ is the math library, where SHA-256, ed25519, and base58 are rewritten in vector C for maximum speed. disco/ holds the common pipeline tiles;flamenco/ is where the Solana VM runtime actually executes program bytecode.funk/ is the in-memory, fork-aware accounts database.waltz/ is the networking layer; wiredancer/ holds the FPGA modules — yes, Jump is building hardware-accelerated tiles for the stages that are truly throughput-bound.

The Pipeline: A Transaction's Six Checkpoints

Say you click Swap on Jupiter. In the next 400 milliseconds, your transaction passes through six distinct checkpoints inside a Firedancer validator before it's committed to the chain. Each checkpoint either stamps it valid, continue or silently drops it. Nothing goes backward. Nothing is copied — the NIC tile (the one that handles the network card) writes your bytes once into a shareddcache region, and every downstream tile reads from the same pointer. This is the zero-copy trick that makes Firedancer fast.

1. 1

   QUIC ingest

   The NIC tile receives your transaction as raw UDP packets over QUIC and extracts the transaction payload.

2. 2

   Signature verify

   The SigVerify tile checks the ed25519 signature against your public key. Invalid? Dropped silently.

3. 3

   Dedup tag

   A 64-bit fingerprint is computed. If this validator has already seen the same fingerprint recently, the transaction is dropped — it is a resend.

4. 4

   Block pack

   Verified, unique transactions enter the Pack tile, which ranks them by priority fee and selects which ones go in the next block. There are 2,400 slots per block.

5. 5

   SVM execute

   The Solana VM runs each selected transaction against the current accounts state. Compute units are metered. If you exceed your budget, the SVM halts and rolls back all account changes.

6. 6

   Consensus commit

   The block is signed, gossiped to other validators, voted on, and confirmed.

When a transaction fails or stalls, knowing which checkpoint dropped it is the difference between debugging in five minutes and debugging for two days. "Transaction never confirmed" almost always means step 3 (deduped — you sent it twice and the validator silently dropped the second copy). "Transaction failed with simulation error" means step 5 (SVM execution rejected it). "Transaction is taking too long to land" usually means step 4 (your priority fee is too low, so the Pack tile keeps picking other transactions ahead of yours).

Samba: MEV at Wire Speed

MEV — Maximum Extractable Value — is money that exists purely in the order transactions land in. If your arbitrage trade lands one slot after a big price-moving swap and one slot before anyone else reacts, you capture the spread. Nothing at the application layer can guarantee that ordering; only the validator can. So Harmonic Finance forked Firedancer to bake the guarantee straight into the validator. The fork is called Samba.

A bundle in Samba is an ordered group of transactions that must land together, in the exact order you submitted them, or all of them are rejected. The Samba pack tile keeps a separate queue for bundles. When the validator is the upcoming leader for a slot, that bundle queue is drained first, with bundles locked into consecutive block positions before any regular fee-priority transactions are packed around them.

samba/src/discof/sender/   ← Harmonic-added: bundle sender tile
samba/src/discof/send/     ← Harmonic-added: streaming tx submission
samba/src/discof/resolv/   ← Modified: resolv tile with MEV routing

Why fork Firedancer instead of building the same thing on Agave? The tile architecture makes it surgically modifiable. To add bundle support, Harmonic added one new tile (the bundle sender) and changed one existing tile (pack). The same change inside Agave's Rust monolith would mean threading MEV logic through a much more tangled codebase. Firedancer's "one tile, one job" rule turned MEV from an architectural rewrite into a 6-tile diff.

Delorean: The Time Machine

A trading bot loses $40,000 on a transaction that should have succeeded. The transaction is buried in a block from three days ago. How do you debug it? Without Delorean, you can't — the on-chain state has moved on, the program may have been upgraded, the feature flags may have changed. The transaction is a fossil with no surrounding context.

Delorean is the time machine for Solana transactions. It pairs with a service called Penrose, built by Temporal XYZ, which captures a complete snapshot — a fixture — of every account, program bytecode, and Solana system variable that a transaction touched, at the exact slot it ran. Penrose serves these fixtures over a custom RPC method. The Delorean CLI fetches one, builds an in-memory mock bank (a fake copy of the chain state), runs the transaction through the real Solana VM on your laptop, and tells you whether the replay matches the original.

fetching fixture for WRM4dvtB32k261TTsn2nc4ini9VvWrB1NBLCQdtZk1FRycp54VTuaDikufLk1E2MANthZjQQS6skzeis2W3bvNA

--- fixture ---
  schema_version  : 0
  slot            : 420195494
  client_version  : 4.2.0-alpha.0
  enabled features: 221
  pre-accounts    : 25
  post-accounts   : 25
  loader-v3 progs : 3
  sysvars         : 9
  expected CUs    : 104291

--- replay outcome ---
  actual status   : Ok(())
  expected status : Ok(())
  status          : MATCH
  actual CUs      : 104291
  expected CUs    : 104291
  CUs             : MATCH
  post-state      : MATCH

The fixture format is worth understanding on its own, because it answers a basic question: what does the SVM actually need to execute a transaction? Look at the Rust struct:

pub struct TransactionFixture {
    pub schema_version: u32,
    pub slot: u64,
    pub recent_blockhash: Hash,
    pub signature: Signature,
    pub client_version: Vec<u8>,
    pub enabled_features: Vec<Pubkey>,
    pub lamports_per_signature: u64,
    pub transaction: Vec<u8>,
    pub alt_writable: Vec<Pubkey>,
    pub alt_readonly: Vec<Pubkey>,
    pub pre_accounts: Vec<FixtureAccount>,
    pub programs: Vec<FixtureProgramData>,
    pub sysvars: Arc<Vec<FixtureSysvar>>,
    pub result: ExecutionResult,
    pub post_accounts: Vec<FixtureAccount>,
}

Read it like a forensic kit. slot pins the moment in time; enabled_features captures which of Solana's 221 feature flags (on/off switches that change network behavior) were active at the time — a single flip can change how a transaction executes; pre_accounts is every wallet and contract state before the transaction; programs is the bytecode of every smart contract involved as it was deployed at that slot; post_accounts is the ground-truth result. With all of that in hand, you can replay the transaction in isolation, perfectly, three days or three years later.

pmm-sim: The Private AMM Dissection Lab

You swap 15,000 USDC into WSOL on Jupiter. Your friend calls the exact same private AMM (automated market maker — the on-chain program that quotes a price and does the swap) directly: same pool, same amount. She gets less WSOL. Same code, same liquidity, different result. Why?

Because some Solana AMMs aren't neutral. They're private AMMs (also called proprietary or prop AMMs) — programs whose pricing logic is closed-source, and which look atwho is calling to decide what quote to give. If your call came from an aggregator on their whitelist, you get the VIP price. If it came from a random wallet, you get the public price. pmm-sim, built by LimeChain, is the lab for measuring that gap.

pmm-sim uses LiteSVM — a lightweight Solana VM that runs inside your own process — to spin up a clean environment in milliseconds, inject only the accounts and programs you need, and run swaps over and over while measuring exchange rates and compute usage. No mainnet calls, no validator startup, no historical fossil. Where Delorean is an archaeologist replaying a real event, pmm-sim is a chemistry bench: fresh glassware every run.

The core trick is CPI impersonation. Private AMMs figure out who's calling them by reading the upstream program ID in the CPI (Cross-Program Invocation — one program calling another) chain. pmm-sim swaps the program ID of its own router for the ID of a real aggregator — Jupiter (route_v2), DFlow (swap2), Titan (swap_route_v2), OKX Labs (swap_v3_with_cpi_event) — making the private AMM believe a whitelisted entity is calling it. Now you can measure, in actual numbers, exactly how much better the VIP price is for each identity, for each pool, at each size.

let mut svm = LiteSVM::new()
    .with_default_programs()
    .with_sysvars()
    .with_sigverify(true)
    .with_compute_budget(budget);

// Inject token mints
mints.iter().for_each(|(mint, dec)| {
    svm.set_account(*mint, Misc::mk_mint_acc(*dec))
});

// Load the private AMM program from disk
svm.add_program_from_file(program_id, path_to_elf);

The fact that you can do this matters for the ecosystem. Private AMMs publish their on-chain bytecode (you can't deploy a Solana program without publishing the ELF) even when their off-chain pricing service stays closed-source. pmm-sim turns "what does this program actually do given input X?" back into a question you can answer by measurement, instead of a leap of faith. Aggregators that integrate prop AMMs use it to validate quotes; researchers use it to expose pricing asymmetries; market makers use it to estimate how much edge they're giving up by routing through one aggregator versus another.

Client Diversity: Why Three Engines Beat One

In March 2023, a bug in Agave caused a 4.5-hour mainnet outage. Every validator was running the same code, so every validator had the same bug. The fix had to come from one team. The chain stopped.

With Firedancer now running a growing share of mainnet stake — already past 30% by 2025 — a similar bug in the future plays out differently. The two implementations were written independently from the same protocol spec. When they agree, the network keeps moving. When they disagree, the disagreement itself is the signal: there's an ambiguity in the protocol that needs to be fixed in the spec, not in one team's codebase. This is consensus diversity, and it's the same reason ATMs and aircraft systems carry redundant computers from different vendors.

Client diversity is not fragmentation. It is resilience. A chain where every validator runs identical code is a single point of failure. Multiple independent implementations catch bugs that no single team can find alone.

Who Uses What, When

Every project in this stack solves a different problem for a different kind of user. Before you reach for one, ask yourself which seat you're sitting in. Below are the eight most common ones, the tool that fits each, and the concrete situation that makes you reach for it.

A Builder's Quickstart Path

If you're coming in cold and want a concrete sequence to follow, this is the shortest path to something actually running:

1. Pick any random mainnet signature. A swap, a transfer, an NFT mint — anything. Copy it from a block explorer.
2. Install Delorean. Clone temporal/delorean-client, cargo build --release. The binary is the only artifact you need.
3. Run a replay. delorean <signature> https://penrose.temporal.xyz — you have just executed a historical Solana transaction on your laptop. The output shows fixture metadata and replay outcome.
4. Modify a program locally. Pull the deployed ELF for any program the transaction touched. Patch it (or write a stub). Pass --replace-program to swap your ELF in. Watch what changes in the replay.
5. Stand up pmm-sim. Clone limechain/pmm-sim, point it at a private AMM ELF, configure a CPI identity. Run a swap. Vary the identity. Read the difference in your output WSOL.
6. Read one Firedancer tile. Open firedancer/src/disco/sig/fd_sig_tile.c. This is the SigVerify tile in 600 lines of C — the cleanest possible illustration of the tile pattern.
7. Read the Samba diff. git log against upstream Firedancer. Six commits tell the entire MEV-by-fork story.

The Bigger Picture

Four teams. Four open-source repos. One thread running through them: Solana is no longer one validator and one runtime and one debugger. It's becoming a stack where the validator layer competes on architecture, the MEV layer competes on guarantees, the tooling layer competes on fidelity, and the trading layer competes on measurement. Each project we covered started from a different question:

• Firedancer — what if validators were built like HFT systems?
• Samba — what if MEV guarantees lived in the validator, not the application layer?
• Delorean — what if every historical transaction could be replayed, perfectly, in under a second?
• pmm-sim — what if you could measure the exact pricing edge a private market maker is giving you, before you send the trade?

The interesting thing is that the answer to all four is the same. Yes — open source, today, on a laptop. And that's the deeper claim Solana is making about what it can be: not just a chain that runs fast, but an ecosystem where the inside of the machine is visible, modifiable, and reproducible by anyone willing to read C and Rust. That's the part worth showing up for.

The chain runs at wire speed because four different teams decided, separately, to write the machine they wished existed and then publish the source.

References