System Overview

This is the shortest architecture view of SOF.

Architecture At A Glance

flowchart LR subgraph Sources["Ingress"] UDP["Direct UDP"] GOSSIP["Gossip bootstrap"] KB["Kernel-bypass / private raw feed"] PROVIDER["Processed provider stream"] end subgraph Runtime["sof runtime"] INGEST["Ingest / provider adaptation"] PARSE["Parse / optional verify"] FEC["Recovery / reconstruction"] STATE["Local state"] HOOKS["Plugins / derived state / extensions"] end UDP --> INGEST GOSSIP --> INGEST KB --> INGEST PROVIDER --> STATE INGEST --> PARSE --> FEC --> STATE --> HOOKS

Read It From Left To Right

SOF is easiest to reason about as three layers:

  • ingress
  • runtime
  • consumption

Traffic enters from one of the supported ingress families. sof turns that ingress into runtime-owned state and events. Plugins, derived-state consumers, and sof-tx adapters sit on top of that runtime layer.

Built-in processed provider modes start later in the pipeline than raw-shred modes. That is part of the design, not a bug.

Why This Matters

The important boundaries are:

  • sof is the live observer/runtime
  • sof-tx is the transaction SDK that can consume control-plane outputs from sof
  • your own services sit on top of those outputs, not inside the packet path

The other important boundary is honesty about ingress:

  • raw-shred modes own more of the substrate
  • processed providers start later in the pipeline
  • public gossip is the independent baseline, not the universal fast path

The detailed optimization history and measurement method live in Performance and Measurement. This page stays focused on the architecture boundaries instead of repeating that material here.

SOF 2026