How does Syncro Sender route and deliver transactions on the Solana network?
The core mechanism: parallel multi-path submission
When a transaction is submitted to Syncro Sender, it does not travel through a single route. Instead, the service broadcasts the transaction simultaneously through multiple parallel channels. Earlier delivery to a leader can improve the chance of earlier inclusion, but inclusion timing is not guaranteed and depends on network conditions.
The four routing channels
Syncro Sender uses these delivery paths in parallel:
Direct leader submission: the transaction is sent directly to the current block leader and the next upcoming leaders in the Solana leader schedule.
Staked TPU connection via SWQoS: the transaction is routed through P2P.org's validator TPU endpoint, which receives priority bandwidth under Solana's native Stake-Weighted Quality of Service mechanism.
Dedicated relayer via SWQoS: an additional SWQoS-enabled routing path operated by P2P.org for redundancy.
Standard RPC broadcast: the transaction is submitted through conventional Solana RPC infrastructure as a fallback.
Why parallel routing matters
Public RPC endpoints send transactions through a single path shared by many users. During network congestion, this single-path approach can introduce unpredictable delays. Multi-path routing can reduce reliance on a single route because the transaction only needs one of its several paths to succeed. The result can be an improved likelihood of early-slot inclusion, depending on network conditions.
What happens before submission
Before routing begins, Syncro Sender validates the incoming request. For the public endpoint, it checks that the request is a sendTransaction call and that the transaction includes the minimum required tip. For private endpoints, non-transaction requests (such as getBalance or getAccountInfo) are proxied to standard RPC nodes, allowing clients to use a single endpoint for both reads and writes.
No changes to signing logic required
Syncro Sender accepts pre-signed transactions. The client application signs the transaction exactly as it does today, then submits it to the Syncro Sender REST endpoint. No modifications to key management, signing workflows, or transaction construction are needed.
This article is for informational purposes only and does not constitute a service agreement. Use of Syncro Sender is governed by the Terms of Service: https://www.p2p.org/syncro-terms