Solana at
Wire Speed

01 — The 400-Millisecond Machine

Every Solana transaction passes through a piece of software called a validator. A validator is a state machine: it reads transactions off the network, verifies their signatures, executes the program calls, updates the affected accounts, and writes the result into a block. Then it does it again, starting from the new state, in the next 400-millisecond slot.

Think of an air traffic control center. Thousands of planes (transactions) arrive per second from every direction. Each one needs 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 a single mistake can crash a flight. That is 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 does not 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 of Firedancer that adds one capability the chain could not otherwise express; Delorean is the debugger for what the validators produce; pmm-sim is the laboratory bench for the private market-making programs that ride on top.

02 — 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 unifying design idea 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 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 every tile uses to talk to the next one. ballet/ is the math library where SHA-256, ed25519, and base58 are reimplemented 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/contains the FPGA modules — yes, Jump is building hardware-accelerated tiles for the truly throughput-bound stages.

03 — The Pipeline: A Transaction's Six Checkpoints

Imagine you click Swap on Jupiter. In the next 400 milliseconds, your transaction passes through six distinct checkpoints inside a Firedancer validator before it is committed to the chain. Every checkpoint either stamps it valid, continue or silently drops it. Nothing goes backward. Nothing is copied — the NIC tile writes your bytes once into a shared dcache region, and every downstream tile reads from the same pointer. This is the zero-copy insight 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 and the Pack tile is choosing other transactions ahead of yours).

04 — Samba: MEV at Wire Speed

MEV — Maximum Extractable Value — is money that exists purely in the ordering of transactions. If your arbitrage trade lands one slot after a large price-moving swap and one slot before anyone else reacts, you capture the spread. Application-layer solutions cannot guarantee this ordering; only the validator can. Harmonic Finance forked Firedancer to build that guarantee directly 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 submitted order, or all of them are rejected. The Samba pack tile holds a separate queue for bundles. When the validator is the upcoming leader for a slot, the 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 rather than build the same thing on Agave? The tile architecture makes it surgically modifiable: to add bundle support, Harmonic added a new tile (the bundle sender) and modified one existing tile (pack). The same change inside Agave's Rust monolith would mean threading MEV logic through a much more complex codebase. Firedancer's "one tile, one job" rule turned MEV from an architectural rewrite into a 6-tile diff.

05 — 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 cannot — 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 any 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, 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 itself worth understanding because it answers the question: what does the SVM 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 were active (a flag 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_accountsis the ground-truth result. With all of this in hand, you can replay the transaction in isolation, perfectly, three days or three years later.

06 — pmm-sim: The Private AMM Dissection Lab

You swap 15,000 USDC into WSOL on Jupiter. Your friend calls the exact same private AMM contract directly, same pool, same amount. She gets less WSOL. Same code, same liquidity, different result. Why?

The answer is that some Solana AMMs are not neutral. They are private AMMs (also called proprietary or prop AMMs) — programs whose pricing logic is closed-source and which look at the identity of the calling program to decide what quote to give. If your call originated 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 laboratory for measuring that gap.

pmm-sim uses LiteSVM — a lightweight, in-process Solana VM — 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 identify their caller by reading the upstream program ID in the CPI (Cross-Program Invocation) chain. pmm-sim substitutes the program ID of its own router with 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 it is being called by a whitelisted entity. You can now measure, in 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 cannot deploy a Solana program without publishing the ELF) even when their off-chain pricing service is closed-source. pmm-sim makes "what does this program actually do given input X?" an empirical question again, instead of a leak 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 are giving up by routing through one aggregator versus another.

07 — 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 was vulnerable to the same bug. The fix had to come from one team. The chain stopped.

With Firedancer running an increasing share of mainnet stake — already past 30% by 2025 — a future similar bug looks different. 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 is a protocol ambiguity that needs to be fixed in the spec, not in one team's codebase. This is consensus diversity, and it is the same reason ATMs and aircraft systems have 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.

08 — Who Uses What, When

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

09 — A Builder's Quickstart Path

If you are coming in cold and want a concrete sequence to follow, this is the shortest path that produces something 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.

10 — The Bigger Picture

Four teams. Four open-source repos. One observable thread: Solana is no longer one validator and one runtime and one debugger. It is 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 were replayable, perfectly, in under a second?
• pmm-sim — what if you could measure the exact pricing edge a private market maker is giving you, before sending the trade?

The interesting answer to all four questions is the same. Yes — open source, today, on a laptop. That fact is the underlying 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 who is willing to read C and Rust. That is 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