A paired Frankfurt benchmark compares DoubleZero IBRL with the public Internet and shows where network distance changed Solana transaction placement.
TLDR
- RPCEdge raced DoubleZero IBRL against the public Internet for one hour from the same Frankfurt sender to the same eligible Solana leader transaction endpoints.
- Distance separated the result. Nearby European leaders usually landed in the same coarse PoH interval. Among leaders at least 5,000 kilometres away, IBRL was earlier on PoH ticks in 85 of 90 same-slot pairs.
- From Frankfurt, approximately 15% of active stake advertised transaction endpoints with a verified IBRL route. Many other leaders advertised shared BAM or Harmonic ingress, which was not reachable over IBRL from our sender.
DoubleZero's Increase Bandwidth, Reduce Latency service, or IBRL, gives a Solana sender an alternate network path to reachable leader Transaction Processing Unit (TPU) endpoints. The destination does not change. The sender still targets the validator's advertised IP and QUIC port, while the operating system uses the doublezero0 interface when a valid DoubleZero route exists.
On 13 July 2026, RPCEdge tested whether that route changed transaction placement. For every eligible leader window during a one-hour run, the sender submitted one matched transaction through IBRL and one through the public Internet.
Edge reads. IBRL sends.
DoubleZero's read service, DoubleZero Edge, distributes leader and regional retransmit shreds to subscribers over multicast. As of 15 July 2026, validators representing approximately 56% of active Solana stake were publishing their leader shreds through Edge.
IBRL provides bidirectional unicast routes between eligible network participants. This benchmark tested only its send direction. The adoption figures use different denominators: publisher stake describes leaders contributing shreds to Edge, while IBRL reachability describes destinations a particular sender can route over DoubleZero.
The paired benchmark
We tested one narrow question:
When a Frankfurt sender has both a verified IBRL route and a public route to the same Solana leader, does IBRL improve the transaction's position in the produced block?
The benchmark ran for one hour on 13 July 2026. At the beginning of each eligible leader window, it submitted two matched transactions. One used the public interface and the other doublezero0.
Both arms used the same host, relay binary, transaction shape, recent blockhash, slot trigger, compute-unit limit, and advertised leader TPU endpoint. Neither paid a priority fee, and payer assignment rotated between the paths.
Eligibility was verified from Frankfurt before every send. The current TPU endpoint, live DoubleZero session, and route evidence had to agree. Publisher status and validator location were not used as proxies.
The run covered 246 eligible leader windows across 29 validator identities. All 492 relay submissions were accepted. Both signatures appeared in the same slot in 201 windows, which form the placement comparison. Of the remaining windows, three placed the transactions in different slots, 34 exposed only the IBRL signature, two only the public signature, and six neither. These outcomes matter for landing coverage, but they cannot be compared as positions within one slot.
We used two placement metrics:
- Preceding PoH ticks show the coarse interval in which the leader recorded each transaction.
- Processed transaction index shows the finer ordering inside the produced block.
Observation time was secondary because it also contains the read path from the leader back to the receiver. Placement is not packet arrival: without instrumentation inside the leader, this benchmark cannot identify the exact moment each packet entered the TPU.
Distance separated the result
For leaders within 1,000 kilometres of Frankfurt, 101 of 109 same-slot pairs landed in the same PoH interval. IBRL was earlier in five and the public path in three. At the finer transaction index, the public path was earlier in 82 pairs and IBRL in 27.
For leaders at least 5,000 kilometres away, IBRL was earlier on PoH ticks in 85 of 90 pairs, with four ties and one public-path win. IBRL was also earlier at the processed transaction index in 86 pairs. The median difference was two PoH ticks and 22 transaction positions in IBRL's favour.
Negative deltas favour IBRL. One mid-distance pair and one pair without usable coordinates account for the other two same-slot comparisons.
The result is consistent with IBRL having more room to improve a long public route. Public connectivity is already competitive between Frankfurt and nearby European metros. Reaching Canada or Singapore can involve more carrier boundaries and less direct routing.
The data does not prove that distance alone caused the placement difference. Validator scheduling and packet processing also affect position inside a block. The distant sample was concentrated: 73 of its 90 pairs came from one validator in Beauharnois, Canada. Singapore contributed another 11. A multi-day, multi-region replication is needed before treating the result as a general distance curve.
Why only part of leader stake was eligible
In our Frankfurt test, verified doublezero0 routes reached advertised TPU endpoints representing approximately 15% of active stake. A key reason for the gap is how Solana transaction ingress now works.
Many validators using external block builders do not advertise a validator-owned TPU endpoint. They advertise shared ingress operated by systems such as Jito's BAM or Harmonic. The sender addresses that block-engine relay from the first packet; the later relay-to-validator leg is managed by the provider.
At the time of testing, those shared ingress endpoints were not reachable over IBRL from our Frankfurt sender. Transactions addressed to them therefore used the public Internet.
This also defines the benchmark's scope. It measured matched transactions sent to validator-address ingress where both public and IBRL routes were available. It did not measure transaction delivery into shared BAM or Harmonic ingress.
DoubleZero told RPCEdge that connecting block-engine ingress to its network is under discussion, but provided no implementation timeline. If added, it could make the long-haul placement advantage observed here available across more leader windows. Final inclusion would still depend on the block engine's own batching, auction, and scheduling decisions.
Consider a sender in Tokyo targeting block-builder ingress in Frankfurt. Across a fixed 24-hour window, DoubleZero's public metro telemetry reported approximately 134 ms RTT over DoubleZero and 231 ms over the public Internet. This is not a transaction-arrival measurement, but it shows why long-haul block-engine connectivity is worth testing.
IBRL cannot improve a route that is unavailable. Senders must check the route to each current or upcoming advertised endpoint instead of treating DoubleZero as a universal switch. Our results suggest that expanding IBRL to shared block-builder ingress is most worth testing across long public Internet paths.
Conclusion
The Frankfurt benchmark did not show IBRL winning everywhere. Nearby leaders mostly tied at PoH granularity, and the public path often won the finer ordering comparison. For the long-haul leaders in this sample, IBRL was usually placed earlier by both measures.
The practical value is leader-dependent. A sender needs to know whether the next advertised endpoint is reachable through IBRL and whether the public path is long enough for the alternate route to change placement. In this sample, the clearest separation appeared on intercontinental routes.
Find the full article HERE
Top comments (0)