Skip to main content
Flamenco is Firedancer’s implementation of the Solana protocol, providing transaction execution, account management, consensus logic, and validator operations. It serves as the runtime layer that processes Solana transactions and maintains blockchain state.

Overview

Flamenco implements the complete Solana runtime environment, including:
  • Transaction execution and validation
  • Account state management
  • Program execution (eBPF VM)
  • Consensus and leader scheduling
  • Stake and reward calculations
  • Feature gate management
Flamenco aims for complete compatibility with the Solana Labs validator while providing significant performance improvements through optimized data structures and parallel execution.

Core Components

Runtime (runtime/)

The core execution engine for Solana transactions:Key structures:
Responsibilities:
  • Transaction execution orchestration
  • Cross-program invocation (CPI) handling
  • Compute unit metering
  • Account locking and conflict detection
  • Rent collection
  • Sysvar updates

Transaction Processing (txn/)

Processing pipeline:
  1. Parse and validate transaction format
  2. Verify signatures (via Ballet Ed25519)
  3. Load and lock accounts
  4. Execute instructions sequentially
  5. Update account states
  6. Calculate fees and rent
  7. Unlock accounts and commit
Transaction limits:
  • Max transaction size: 1232 bytes (FD_TPU_MTU)
  • Max signatures: Variable (typically 64)
  • Max accounts: 256 per transaction
  • Max instructions: 64 per transaction

Account Database (accdb/)

High-performance account storage and retrieval:Features:
  • Concurrent read access
  • Write coalescing
  • Account versioning
  • Snapshot support
  • Cache hierarchy (L1/L2)

Account Metadata

Borrowed Accounts

Lifecycle:
  • Borrowed at transaction start
  • Locked for write if writable
  • Modified during execution
  • Committed or rolled back at end

Account Manager (fd_acc_mgr_t)

  • Account lifecycle management
  • Memory pooling (fd_acc_pool_t)
  • Efficient allocation/deallocation

eBPF VM (vm/)

Solana’s eBPF (extended Berkeley Packet Filter) virtual machine:Capabilities:
  • sBPF instruction set execution
  • JIT compilation (optional)
  • Compute unit metering
  • Memory safety checks
  • Call depth limiting
Program execution:
  1. Load program from account
  2. Verify program (via Ballet sBPF)
  3. Compile to native code (JIT)
  4. Execute with instruction context
  5. Meter compute units
  6. Return result or error

Program Cache (progcache/)

Features:
  • Compiled program caching
  • LRU eviction policy
  • Concurrent access
  • Invalidation on program upgrades
Cache strategy:
  • Hot programs: JIT compiled, cached
  • Cold programs: Interpreted or compiled on-demand
  • Redeployment: Invalidate and recompile

Leader Schedule (leaders/)

Determines which validator is leader for each slot:Algorithm:
  1. Get stake distribution at epoch boundary
  2. Apply weighted sampling (Ballet wsample)
  3. Generate deterministic leader sequence
  4. Cache for current and next epoch
Key functions:
  • Leader rotation every 4 slots (typically)
  • Epoch-based recalculation
  • Stake-weighted selection

Stake Management (stakes/)

Stake tracking:
  • Active stake per validator
  • Delegated stake
  • Activation/deactivation epochs
  • Warm-up/cool-down periods

Rewards (rewards/)

Reward types:
  • Staking rewards (inflationary)
  • Transaction fees
  • Rent collection (deprecated)
Distribution:
  • Calculated at epoch boundary
  • Distributed to stake accounts
  • Commission split to vote accounts

Gossip Protocol (gossip/)

Distributed cluster information exchange:Gossiped data:
  • Cluster topology (validator IPs/ports)
  • Vote account information
  • Shred versions
  • Contact info updates
  • Node health metrics
Gossip messages:
  • Push messages: Broadcast new information
  • Pull messages: Request missing data
  • Prune messages: Stop forwarding
  • Ping/pong: Liveness checks
Properties:
  • Eventually consistent
  • Epidemic broadcast protocol
  • Fanout-based propagation
  • CRDT merge semantics

Feature Gates (features/)

Control activation of protocol changes:Feature lifecycle:
  1. Defined in code (pending)
  2. Activated by stake vote
  3. Effective at next epoch
  4. Remains active forever
Usage:
Common features:
  • Transaction version support
  • Account rent changes
  • Compute unit pricing
  • New syscalls
  • VM improvements

Genesis (genesis/)

Genesis block configuration:
  • Initial account states
  • System program accounts
  • Stake pools
  • Inflation parameters
  • Epoch schedule

Capture (capture/)

Features:
  • Transaction replay capture
  • Account state snapshots
  • Deterministic debugging
  • Conformance testing

Log Collector (log_collector/)

Program log message collection:
  • Syscall log output
  • Error messages
  • Return to RPC clients

Types (types/)

Solana protocol type definitions:
  • Serialization formats
  • Wire protocol structures
  • Custom type definitions (fd_types_custom.h)
  • Type casting utilities (fd_cast.h)

Address Utilities

Data Structures

Bank State

Banking stages:
  • Bank 0: Current leader slot
  • Bank 1: Next slot preparation
  • Bank N: Historical banks for forks

Synchronization

Lock ordering:
  1. Sort accounts by address
  2. Acquire locks in order
  3. Prevents deadlocks
  4. Enables parallel execution

Execution Flow

Instruction Execution

Execution:
  1. Verify program ownership
  2. Check account permissions
  3. Execute program (native or eBPF)
  4. Meter compute units
  5. Update account data
  6. Handle cross-program invocations

Performance Features

  • Parallel Execution: Banking stages execute transactions concurrently
  • Account Sharding: Partition accounts for parallel access
  • Program Caching: JIT-compiled programs cached in memory
  • Optimized Data Structures: Custom allocators and pools
  • SIMD Acceleration: Vectorized operations where applicable

Compatibility

Flamenco maintains compatibility with Solana Labs validator:
  • Identical transaction execution behavior
  • Same account state transitions
  • Compatible consensus rules
  • Matching feature gate activation
  • Equivalent RPC responses (via Agave integration)

Header Files

  • Ballet - Cryptographic primitives for signatures and hashing
  • Disco - Tile-based transaction processing pipeline
  • Tango - IPC for inter-stage communication