Anycast endpoints
- One address, routed to the nearest of 10 points of presence
- Locations across Europe, the US, and Asia
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, the slot, and, on Harmonic, the execution result. All filtered to the accounts you care about, over gRPC to your own servers.
Sourced from Harmonic and Jito BAM
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
- On Harmonic, the execution result too: success, failure, or fees only, before the block lands
- 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.
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
- On Harmonic, the execution result too: success, failure, or fees only, before the block lands
- 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.
Two sources, two data paths
Preconfs come from whoever commits transactions to the block, and our two sources do that differently. You subscribe to both through the same request, the same message format, and the same token; what differs is where the commitment comes from and what it carries.
The Harmonic block builder sits in front of the validator's TPU. It executes each transaction in its own runtime, commits it to the block, and streams the result to us: success, execution failure, or fees only. The validator then executes the same transaction again when it produces the block. A Harmonic preconf means the builder ran it and is putting it in; the result you see is the builder's run, and the validator's run is the one that lands on chain, normally with the same outcome.
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.
- Harmonic: preconfs from validators running the Harmonic scheduler, across 7 regions (Amsterdam, New York, Frankfurt, London, Tokyo, Singapore, Salt Lake City)
- Jito BAM: preconfs from Jito's block assembly marketplace, across 15 regions
- Same request, same format, same token for both, so adding a feed is a parameter, not an integration
A preconf is the leader's commitment, not finality.
In both cases, 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 and Harmonic's execution results are for, and it's why we publish landed and unlanded numbers instead of asking you to take the feed on faith.
Two sources, two data paths
Preconfs come from whoever commits transactions to the block, and our two sources do that differently. You subscribe to both through the same request, the same message format, and the same token; what differs is where the commitment comes from and what it carries.
The Harmonic block builder sits in front of the validator's TPU. It executes each transaction in its own runtime, commits it to the block, and streams the result to us: success, execution failure, or fees only. The validator then executes the same transaction again when it produces the block. A Harmonic preconf means the builder ran it and is putting it in; the result you see is the builder's run, and the validator's run is the one that lands on chain, normally with the same outcome.
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.
- Harmonic: preconfs from validators running the Harmonic scheduler, across 7 regions (Amsterdam, New York, Frankfurt, London, Tokyo, Singapore, Salt Lake City)
- Jito BAM: preconfs from Jito's block assembly marketplace, across 15 regions
- Same request, same format, same token for both, so adding a feed is a parameter, not an integration
A preconf is the leader's commitment, not finality.
In both cases, 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 and Harmonic's execution results 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
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), by signature, or on Harmonic by execution result
- 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
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), by signature, or on Harmonic by execution result
- 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
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: Harmonic Amsterdam, BAM Frankfurt, and so on. 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
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: Harmonic Amsterdam, BAM Frankfurt, and so on. 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
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.
- Harmonic: typically ~99% of preconfs arrive before Geyser; when ahead, typically ~15 ms at p50 and up to ~75 ms at p95
- Jito BAM: typically ~91% 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
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.
- Harmonic: typically ~99% of preconfs arrive before Geyser; when ahead, typically ~15 ms at p50 and up to ~75 ms at p95
- Jito BAM: typically ~91% 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
Server-side filtering
- Accounts (any of, or all of), signatures, and on Harmonic execution results
- 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
Two feeds, one integration
- Harmonic and Jito BAM through the same request, format, and token
- Choose feed and region per stream
- Enabled and metered separately, so trialling one doesn't commit you to both
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, 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.