Crates

SOF is a small product family split by job:

  • observe and derive local runtime state
  • build and submit transactions
  • apply typed host tuning

That split is intentional because most services do not need the full surface at once.

Why The Split Exists

  • sof owns ingest, runtime composition, and downstream event surfaces
  • sof-tx owns transaction construction and submission policy
  • sof-gossip-tuning owns typed tuning profiles instead of stringly presets
  • sof-solana-gossip stays vendored and internal to preserve a tighter public API boundary

Typical Adoption Patterns

Observer-only or local market-data service

Start with sof.

Execution service that only needs a send pipeline

Start with sof-tx.

This is the right fit when:

  • you already have a blockhash source
  • you want transaction construction and submission first
  • you may use RPC, Jito, signed-byte submission, or your own external providers
  • direct or TPU-targeted routing is optional, not required

Execution service that wants locally observed control-plane state

Use sof together with sof-tx.

This is the right fit when:

  • sof is your local source of recent blockhash, leader schedule, and cluster topology state
  • sof-tx is your submit path
  • you want direct or hybrid sending based on locally observed traffic rather than only external RPC lookups

This does not mean sof-tx only makes sense with sof. It does not. sof-tx is still useful on its own for RPC, Jito, and signed-byte flows.

Embedded host with repeatable deployment presets

Add sof-gossip-tuning on top of sof.

SOF 2026