Triton Preconfs: transactions before the block exists

Triton Preconfs streams the transactions a leader's scheduler has already accepted, before the block is built, executed, or cut into shreds. You get the raw transaction bytes, and the slot. All filtered to the accounts you care about, over gRPC to your own servers.

Sourced from Jito BAM

Jito Labs Logo

Earlier than shreds

Earlier than shreds

Shreds are the block after the leader has packed and executed it. They're the earliest thing most of the network will ever see, which is why the race for early data has always started there.

A preconf is the step before that. It's the leader saying, "This one is in," while the block is still being assembled. Triton Preconfs forwards that signal to you as it happens, one message per transaction, before any shred exists.

  • One message per accepted transaction: the raw transaction bytes, the slot, and its sequence within the slot
  • Slot start and slot end markers in the stream, so you know when a slot is done
  • Typically 10 to 50 ms ahead of a Geyser stream, up to ~75 ms at p95, measured continuously from our own infrastructure

Built for HFT desks, market makers, and anyone who needs to know what's landing before the shreds exist.

Jito BAM

Jito BAM

The BAM proxy sends each transaction to the validator, the validator executes it as part of building the block and acknowledges back, and only then does the proxy stream it out. A BAM preconf means the validator has already executed it. There's one execution and no result field; the acknowledgement is the guarantee. BAM also flags bundle intent, so you can see when a transaction is set to revert on error.

A preconf is the leader's commitment, not finality.

A preconf tells you the leader has committed to a transaction. It doesn't tell you the block will land: a slot can still be skipped or forked, and we measure how often rather than hide it. That's what the slot end markers are for, and it's why we publish landed and unlanded numbers instead of asking you to take the feed on faith.

Filtered, not a firehose

Filtered, not a firehose

Nobody gets the full feed. You tell us what matters and we forward the transactions that match, so your bandwidth goes on flow you can act on.

  • Filter by accounts (any of, or all of) or by signature
  • Up to 64 named filters per stream, and every update tells you which filters it matched
  • Fair share per account, and if we ever clip your stream, we say so on the stream itself

One address, any region

One address, any region

You reach us through one address, preconfs.rpcpool.com, announced from all 10 of our points of presence across Europe, the US, and Asia. Your connection lands on whichever one is closest to you on the network; you don't choose it, and you don't need to.

The region is a required field in every subscribe request, and it picks whose preconfs you get. One stream serves one region, and every point of presence ingests every region, so wherever anycast lands you, you can subscribe to any of them. Anycast decides where you talk to us; the region decides whose preconfs you get. Pick the region by where the leader is, not by where you are.

  • One endpoint, announced from 10 points of presence; your connection lands on the closest
  • Region is chosen per stream and any region is available from any point of presence
  • GetVersion tells you which point of presence you landed on
  • TLS from our server to your client, with no proxy in the path
  • Upstream reconnects and region failover are our problem, not yours

How much faster than Geyser

How much faster than Geyser

We measure this ourselves rather than quoting a benchmark from a good day. Monitors in every point of presence match each preconf against a Geyser stream by signature and record which arrived first, on the same machine, so there's no clock skew in the numbers.

  • Jito BAM: typically ~91% of preconfs arrive before Geyser; when ahead, typically ~8 ms at p50 and up to ~34 ms at p95
  • The remainder arrive a few milliseconds after Geyser, almost always when the point of presence is far from the leader, which is why you choose your region
  • Figures are blended across all locations over rolling windows; your lead depends on where the leader is, with European leaders giving bigger leads in Europe and Asian leaders in Asia

Anycast endpoints

  • One address, routed to the nearest of 10 points of presence
  • Locations across Europe, the US, and Asia

Server-side filtering

  • Accounts (any of, or all of), signatures
  • Up to 64 named filters per stream
  • Every update tells you which filters it matched

Slot boundaries in-stream

  • Slot start and slot end markers alongside transactions
  • Know when a slot is complete
  • Boundaries are explicit, not inferred from a timer

Level playing field

  • No backrunning, frontrunning, or sandwiching
  • A preconf reaches you after the leader has accepted the transaction, so nothing a subscriber does can get ahead of it in that block
  • Fair share per account, and any clipping is disclosed on the stream

Direct support channel

  • Access to the engineers who built and run the service
  • Configuration help, debugging, and urgent fixes
  • Reachable 24/7 across all regions

Metered on what you use

Preconfs are billed on usage and priced separately for each feed, so what you pay tracks the flow you actually subscribed to. Full rates are on the pricing page.

Enabled on request

Preconfs isn't self-serve. We turn it on per subscription after a conversation, the same way we handle Triton Shred Streaming. That's deliberate: capacity in the busiest few hundred milliseconds of a slot is finite, and we'd rather know who we're serving.

Build with engineers behind Solana's core infrastructure

Triton sponsors, builds, and open-sources the infrastructure used by the fastest DEXs, the largest wallets, and the biggest analytics teams. We give you the speed, reliability, and tooling to get and stay ahead.