Skip to main content

The seven stages

A transaction submitted through Sinker passes through seven distinct stages. Each stage transition is detected from the live Yellowstone gRPC stream and written to the lifecycle log.
[enqueued]
    ↓  TPU ingestion at leader (via Jito block engine)
[submitted]
    ↓  Leader includes tx in block; shreds propagate via Turbine
[landed / processed]
    ↓  ≥ 2/3 stake weight votes confirm the block
[confirmed]
    ↓  31+ subsequent blocks are finalized on top of this one
[finalized]
A bundle can receive HTTP 200 from the Jito block engine and still never land. This happens when no jito-solana validator is scheduled as leader in the next ~20 slots. Sinker’s background status tracker detects this by polling getInflightBundleStatuses and stamps the entry invalid.

Lifecycle entry

Every bundle submission produces a LifecycleEntry written to lifecycle.jsonl. You can read all entries with sinker.getLifecycle() or filter to a single transaction with tx.lifecycle().
const entries = await handle.lifecycle();

for (const entry of entries) {
  console.log(entry.bundle_id);
  console.log(entry.stage);            // 'finalized' | 'failed' | ...
  console.log(entry.tip_lamports);
  console.log(entry.confirmed_to_finalized_ms);  // latency delta
  console.log(entry.ai_decision_trace);           // agent's reasoning
}

LifecycleEntry fields

bundle_id
string
Unique identifier assigned by the Jito block engine (or a synthetic ID for faulted/errored submissions).
slot_submitted
number
The slot at which the bundle was submitted.
leader
string | null
The validator identity pubkey scheduled to lead slot_submitted.
tip_lamports
number
The tip amount included in this bundle attempt, in lamports.
submitted_at
string
ISO 8601 timestamp of submission.
stage
BundleStage
Current lifecycle stage: submitted | landed | processed | confirmed | finalized | failed | invalid | unknown
failure
FailureClass | null
Structured failure class when stage is failed. See Fault Injection for the full taxonomy.
confirmed_to_finalized_ms
number | null
Wall-clock milliseconds from confirmed to finalized. Observed values on mainnet: ~2,300–2,400ms (~5–6 slots).
ai_decision_trace
string | null
The AI agent’s chain-of-thought for this bundle: tip selection rationale, failure pattern analysis, and escalation decisions.
queued_tx_ids
string[]
The tx_id values from /tx/enqueue that were included in this bundle.

Commitment levels

LevelSlots from tipDescription
processed0Included in a block. Can reorg.
confirmed~2Supermajority vote. Reorg rate <0.1% on mainnet.
finalized~32Irreversible under BFT assumption.
Sinker uses confirmed commitment when fetching blockhashes, giving 148 valid slots (~59s) vs 118 slots (~47s) for finalized. This is meaningful when targeting a specific 4-slot Jito leader window.

Observed latencies (mainnet-beta)

From real bundle submissions during development:
Bundlesubmitted → confirmedconfirmed → finalized
160974fe11,875ms2,480ms
b9e8b29413,354ms2,355ms
4359b58d13,053ms
Variance in submitted → confirmed is primarily driven by leader window alignment at submission time.