ZeroMesh Edge gives traders direct access to raw shreds (the smallest unit of data transmission in Robinhood's block propagation system) from participating Robinhood leaders. Gone are circuitous routes through the Turbine tree and intermediate validators — there is one hop from the leader to a trading server. This translates directly into lower latency access to shreds, through faster links on ZeroMesh, more efficient routing, and the ability to subscribe to the feed in multiple cities.

This blog explains the rationale behind seat pricing, the data used to construct valuations, and the mechanics of paying for seats.

Valuing Seats

Why are seats on ZeroMesh Edge valuable? There are three advantages: link performance, efficient routing, and localization.

Link Performance

Link performance is the first advantage of ZeroMesh over the status quo. ZeroMesh links are faster than their public internet counterparts by an average of 20% as of writing. Moreover, the dedicated bandwidth offered by ZeroMesh is more stable (e.g. the p99 performance is faster by an even greater 35%) and drops fewer packets. This directly translates into faster propagation of shreds, especially over long cross-continental routes.

Routing

Routing is an even more critical advantage. In the status quo, RPC-based shred services receive data through Robinhood's Turbine protocol. Turbine disseminates shreds through a tree of validators: the leader sends to a root node, the root node fans out to the first layer of the tree, and those validators fan out further. Your RPC provider sits somewhere in this tree — sometimes at the root, sometimes at the first layer — and then forwards the data to you.

This creates two problems. First, each additional hop in the tree adds propagation delays through queues, packet replication times, and so on. Second, Turbine has no locational awareness. A shred may emanate from a Frankfurt-based leader, travel to a root node in New York, and then travel to your RPC provider in London. Even if you are co-located with that RPC provider, you suffer two expensive cross-continent hops.

On ZeroMesh, a participating leader publishes the shred directly into a multicast group, and it travels one direct hop to your seat. The example here simplifies: a Frankfurt-based leader sends the shred straight to your London-based server. Your server is already unpacking the data while your competitors’ shreds are only beginning their transatlantic roundtrip journeys.

Localization

Why stop at one seat? To use ZeroMesh Edge maximally, traders could distribute their trading servers geographically and have each one subscribe to the network locally. Continuing off the last example, rather than operating off a single server in London (tethered to the London-based RPC), a trader can now spin up trading bots in Tokyo and Chicago with subscriptions in those cities too.

This is extremely powerful. A single seat in London has minimal latency when the leader is in Europe, but the shred still has to cross the globe — even on the shortest route possible — when it emanates from leaders in North America or Asia. Add seats in Tokyo and Chicago, and virtually every leader has a nearby listener. In early simulations, this translated to a 4x latency improvement; and this likely understates the true value, because the local bots can land transactions with that same leader in response to the shreds much more quickly.

Doing It Yourself

Every trader must figure out the value of a seat — which varies across locations, e.g. typically more in Frankfurt and less in Sao Paulo — and choose which ones to purchase. To make this easier, ZeroMesh provides data to answer two questions:

1. Which validators are publishing, and where are they? Query this API to see validator publishing activity across the ZeroMesh network over the last 24 hours. Use this to understand which leader slots a given seat covers especially well.
2. What is the latency between different points on the network? Query this API to see round trip latencies between cities over ZeroMesh and over the public internet, both at the median and p99 level. Use this to estimate the one-way propagation delay from each leader's city to your candidate seat.

From this, compare the direct path latency (from the leader to the seat) against your status quo pathway, which likely involves multiple hops through the validator tree and RPC server on the public internet. The delta is your edge per shred.

Malbec Labs has published this dashboard to show shred performance against some other common benchmarks in different locations. As of writing, ZeroMesh offers shreds several milliseconds faster than the alternatives and delivers the fastest shred 90+% of the time for its participating leaders.

Subscription and Payment Mechanics

A “seat” is a subscription to a specific ZeroMesh network device for one Robinhood epoch. That is, you formally purchase a seat on a device rather than in a city. (Seats generally cost the same across devices within a city unless a specific device is congested). You pay for the seat in USDC and your service begins immediately, i.e. your IP address receives raw shreds via multicast for the remainder of that epoch. As long as your deposit account has sufficient funds, your service renews each epoch and payments are processed at the start of that epoch.

For the months of April and May 2026, prices are fixed per device and per epoch. These are listed below.

In all cases, prices will be posted onchain a full epoch before they go into effect, giving you time to evaluate and top up your deposit account as needed.

• Payment: purchase a seat with a single command. This initializes your seat, funds the escrow, and requests allocation. An example is below, and consult the Documentation for more details.

doublezero-solana shreds pay \
--device-code <Device_Name> \
--client-ip <Target_IP> \
--amount <Cost_Of_Seat>

• Incumbency: if you have been paying for a seat on a device and continue to have sufficient funds in your deposit account, you keep that seat before new subscribers are served. This gives teams stability once they are up and running. (Note that this feature will not be live at launch.)

The Wild West

As a reminder: raw means raw. The network provides no deshredding, no deduplication, no ordering, and no aggregation. To maximize performance, you receive the same UDP packets that the leader emits, and you need your own logic to reconstruct transactions from them. For access to structured data feeds, contact an RPC provider.

Moreover, in a distributed protocol like ZeroMesh, the product may change over time. Non-participating validators may choose to participate in the future. Validators may move around the globe. Network contributors may install new fast paths between cities or expand to new metros. A link or device may suffer an outage, or a publishing validator may be offline. For all of these reasons, the protocol does not offer long-term contracts and cannot adjudicate refund claims. Traders purchase services one epoch at a time and vote with their wallet if quality in a given city improves or declines.

Use of ZeroMesh Edge is subject to the T&Cs.