---
title: "On-Chain Connectivity"
book: "Networks, Hardware and Trading Infrastructure"
subject: quant
language: en
chapter: 21
exercises: 8
source: https://one-course.com/books/quant/14/en/chapter/21-on-chain-connectivity
---

# Chapter 21 — On-Chain Connectivity

A transaction sent to a public node of a blockchain reaches the rest of the network by gossip, hop by hop, and is visible to everyone on the way; one sent to a [block engine](#def-nw-on-chain-connectivity-engine) in the region of the next block producer skips the gossip altogether. On a chain whose leaders change every few hundred milliseconds, and whose software gives each leader four consecutive slots, which region to send to is a scheduling question: the answer changes with the [leader schedule](#def-nw-on-chain-connectivity-leader), and the schedule is published in advance.

Book 3 described the actors of on-chain trading (nodes, validators, builders, relays, searchers). This chapter is about their network: how nodes peer and gossip, what propagation networks and private relays change, where the [block engines](#def-nw-on-chain-connectivity-engine) are, how a [leader schedule](#def-nw-on-chain-connectivity-leader) turns into a choice of endpoint, and what [hosted node providers](#def-nw-on-chain-connectivity-engine) sell. The documentation is cited and dated; the propagation is a labelled simulation on the book’s map.

## 21.1 Running and peering nodes

**Definition 21.1 (Gossip protocol).**

A *gossip protocol* spreads a message over a peer-to-peer network by having each node that receives it for the first time forward it (or announce it) to some or all of its peers, so that it reaches every node in a number of hops that grows with the logarithm of the network’s size.

A node joins a chain’s network by connecting to peers found through the chain’s discovery protocol; in this chapter’s model they are chosen at random, with no regard to geography. Each hop costs the link’s delay plus the node’s validation of the message before it forwards it. The consequence was measured early: Decker and Wattenhofer found in 2013 that a Bitcoin block reached the median node after 6.5 seconds and that after 40 seconds 5% of nodes still had not seen it. Smaller messages and faster validation shorten each hop, but not the structure: a transaction still reaches the far side of the world through a chain of hops between peers it did not choose.

**Proposition 21.2 (Gossip time).**

On a network whose nodes each forward to all their peers on first receipt, a message reaches every node at the length of its shortest path from the source, where a link’s length is its delay plus the receiving node’s processing; forwarding to a subset and announcing to the rest, who pull, lengthens the announced links by a round trip and can only delay arrival.

**Proof.** Flooding explores every path in parallel, so each node receives the message first along its shortest path (Dijkstra’s argument). Replacing some pushes by announcements adds a round trip to those links’ lengths, and shortest paths cannot become shorter when lengths grow. ∎

```python
def spread(graph, source, mode="flood"):
    """Earliest arrival at every node (Dijkstra). In 'sqrt' mode a node pushes to ceil(sqrt(d))
    peers; the others are announced to and pull, one extra round trip on that link."""
    best = [math.inf] * graph.n
    best[source] = 0.0
    heap = [(0.0, source)]
    while heap:
        t, i = heapq.heappop(heap)
        if t > best[i]:
            continue
        peers = sorted(graph.adj[i])
        push = set(peers[:math.ceil(math.sqrt(len(peers)))]) if mode == "sqrt" else set(peers)
        for j in peers:
            d = graph.edges[(i, j)] + (0.0 if j in push else 2 * graph.edges[(i, j)])
            if t + d < best[j]:
                best[j] = t + d
                heapq.heappush(heap, (t + d, j))
    return best
```

***Listing 21.1.** Gossip as shortest paths: flooding, and square-root fan-out with announcements and pulls. code/firm/chainnet/firm_chainnet.py*

The model places 600 nodes evenly in the eight cities of [Box 21.1](#dat-nw-on-chain-connectivity-engines), joins each to eight random peers, and charges each link its fibre floor times 1.5 plus $5\,\mathrm{m}\mathrm{s}$ of processing (assumptions). A transaction from a node in Tokyo reaches half the nodes after $85.0\,\mathrm{m}\mathrm{s}$ and nine-tenths after $99.5\,\mathrm{m}\mathrm{s}$ by flooding; with square-root fan-out, which saves bandwidth, after 113.9 and $149.0\,\mathrm{m}\mathrm{s}$. In the model the random graph offers paths close to the direct legs, so what gossip adds is its extra hops: three to eight of them, 15 to $40\,\mathrm{m}\mathrm{s}$ of processing, against the engine’s one millisecond (an assumption). The tails differ most: the last node has it after $158.5\,\mathrm{m}\mathrm{s}$ by flooding and $326.5\,\mathrm{m}\mathrm{s}$ with square-root fan-out.

![Simulation: the share of 600 nodes in eight cities, eight random peers each, that have a transaction sent from a node in Tokyo, against time. Flooding reaches half at 85.0\, m s and nine-tenths at 99.5\, m s; square-root fan-out at 113.9 and 149.0\, m s. Data: fig_chain.py, firm_chainnet.spread().](https://one-course.com/images/onecourse/chapters/quant-14/nw-on-chain-connectivity/fig-25534e939e86.svg)

***Figure 21.1.** Simulation: the share of 600 nodes in eight cities, eight random peers each, that have a transaction sent from a node in Tokyo, against time. Flooding reaches half at $85.0\,\mathrm{m}\mathrm{s}$ and nine-tenths at $99.5\,\mathrm{m}\mathrm{s}$; square-root fan-out at 113.9 and $149.0\,\mathrm{m}\mathrm{s}$. Data: `fig_chain.py`, `firm_chainnet.spread()`.*

![Simulation: when a transaction sent from Tokyo reaches the next leader, by the leader’s city: through the gossip graph from a public node in Tokyo (median over the city’s nodes), and directly through the published block engine nearest the leader. Gossip adds 14 to 39\, m s. Data: fig_chain.py, nw_chain.to_leader().](https://one-course.com/images/onecourse/chapters/quant-14/nw-on-chain-connectivity/fig-72a68aa55256.svg)

***Figure 21.2.** Simulation: when a transaction sent from Tokyo reaches the next leader, by the leader’s city: through the gossip graph from a public node in Tokyo (median over the city’s nodes), and directly through the published [block engine](#def-nw-on-chain-connectivity-engine) nearest the leader. Gossip adds 14 to $39\,\mathrm{m}\mathrm{s}$. Data: `fig_chain.py`, `nw_chain.to_leader()`.*

## 21.2 Transaction propagation networks and private relays

**Definition 21.3 (Transaction propagation network).**

A *transaction propagation network* is a privately operated network of relays, peered with many nodes and validators of a chain, that carries transactions and blocks between them faster and with less variance than the chain’s own gossip over the public internet.

Two services change the path of a transaction. A propagation network, such as bloXroute’s Blockchain Distribution Network, replaces random public hops with its own relays, which its documentation describes as reducing “latency and variance” in propagation. A private relay changes who sees the transaction: Flashbots Protect, on Ethereum, sends it to a private mempool where it is “hidden from frontrunning and sandwich bots” until a builder includes it. The first is a latency product; the second a visibility product; a searcher may need both (Book 3’s private order flow).

## 21.3 Block-builder and block-engine endpoints by region

**Definition 21.4 (Block engine, hosted node provider).**

A *block engine* is a service, run close to a chain’s validators, that accepts transactions and bundles from traders and forwards them directly to the current or next block producer, often through an auction for inclusion. A *hosted node provider* runs a chain’s nodes and sells access to their RPC endpoints, with request limits per plan, so that a firm need not run its own.

**As of September 2026 — Block engines and relays, from their documentation.**

- Jito (Solana): mainnet [block engines](#def-nw-on-chain-connectivity-engine) in Amsterdam, Dublin, Frankfurt, London, New York, Salt Lake City, Singapore and Tokyo, each with its own endpoint; its `sendTransaction` forwards a transaction directly to the validator; bundles need a tip of at least 1 000 lamports.
- Flashbots Protect (Ethereum): a private mempool hidden from frontrunning and sandwich bots, with refunds.
- bloXroute: a Blockchain Distribution Network of relays for Solana, BNB Chain, Base, Ethereum, Hyperliquid and other chains.

![Two ways to the next leader: hand the transaction to a public node and let gossip carry it hop by hop, visible to every node; or send it over the firm’s own route to the block engine nearest the leader, which forwards it directly. Schematic.](https://one-course.com/images/onecourse/chapters/quant-14/nw-on-chain-connectivity/fig-077417710765.svg)

***Figure 21.3.** Two ways to the next leader: hand the transaction to a public node and let gossip carry it hop by hop, visible to every node; or send it over the firm’s own route to the [block engine](#def-nw-on-chain-connectivity-engine) nearest the leader, which forwards it directly. Schematic.*

A [block engine](#def-nw-on-chain-connectivity-engine) is a [point of presence](https://one-course.com/books/quant/14/en/chapter/11-the-european-map#def-nw-the-european-map-pop) (chapter 11) for the chain’s producers. Sending to the engine nearest the producer puts the long-haul part of the path on the firm’s own route and the last hop on the engine’s short one, instead of on a dozen random public hops.

## 21.4 Validator proximity and the leader schedule

**Definition 21.5 (Leader schedule).**

A *leader schedule* is a chain’s published assignment of future block-production slots to validators, computed in advance for an epoch, which lets anyone know which validator will produce each coming block and, if its location is known, where to send transactions.

**As of September 2026 — Slots and leaders, from the chains’ specifications and code.**

Ethereum’s mainnet configuration sets 12-second slots. Solana computes its [leader schedule](#def-nw-on-chain-connectivity-leader) an epoch in advance; the Solana SDK’s default target slot time is $300\,\mathrm{m}\mathrm{s}$ (it defines 400 and shorter as well) and the effective target is changed dynamically, so clients must not assume the default; the Agave validator gives each leader four consecutive slots.

With 12-second slots, geography matters for Ethereum only at the edges of a slot. With slots of a few hundred milliseconds and four in a row per leader, it matters for every transaction on Solana: the next leader’s location is known in advance, and a transaction that reaches it after its four slots waits for the next leader, possibly on another continent.

```python
def to_leader(leader_city, mode="flood"):
    """Median over the leader city's nodes of the gossip arrival, and the direct path through the nearest engine."""
    a = cn.spread(GRAPH, SOURCE, mode)
    gossip = float(np.median([a[i] for i, c in enumerate(NODE_CITY) if c == leader_city]))
    e = cn.choose_engine(ENGINES, CITIES[leader_city])
    at = (e.lat, e.lon)
    leg = cn.one_way_ms
    direct = leg(CITIES["tokyo"], at) + ENGINE_MS + leg(at, CITIES[leader_city])
    return {"gossip": gossip, "direct": direct, "engine": e.region}
```

***Listing 21.2.** Arrival at the next leader: through the gossip graph, and directly through the published engine nearest the leader. code/networks/21-on-chain-connectivity/python/nw_chain.py*

![Simulation: the share of next leaders, placed in turn in each of the eight engine cities, reached in time from Tokyo, against the time left in the leader’s window. Sending to the engine nearest the leader shifts the curve left by 14 to 39\, m s. Data: fig_chain.py, nw_chain.timely_rates().](https://one-course.com/images/onecourse/chapters/quant-14/nw-on-chain-connectivity/fig-57fc230d5dd9.svg)

***Figure 21.4.** Simulation: the share of next leaders, placed in turn in each of the eight engine cities, reached in time from Tokyo, against the time left in the leader’s window. Sending to the engine nearest the leader shifts the curve left by 14 to $39\,\mathrm{m}\mathrm{s}$. Data: `fig_chain.py`, `nw_chain.timely_rates()`.*

Averaged over the eight leader cities and over a time left uniform between zero and $150\,\mathrm{m}\mathrm{s}$, the leader-aware chooser lands 61% of transactions in time against 48% through gossip; over $300\,\mathrm{m}\mathrm{s}$, 80.5% against 74.0%. For a leader in Frankfurt, the chapter’s problem, the direct path takes $69.5\,\mathrm{m}\mathrm{s}$ and gossip $83.5\,\mathrm{m}\mathrm{s}$.

## 21.5 Hosted node providers

Running a chain’s nodes well is work: storage, bandwidth, upgrades and peering. Hosted providers sell their nodes’ endpoints instead, by plan and request limit. For trading, the question is the one of chapters 16 to 18: where the provider’s nodes are, whether they are the ones the firm’s transactions should enter, and how their limits are governed (Book 3’s rate limits). A provider’s endpoint is a convenient place to read the chain and a poor place to race on it.

**Method 21.6 (Getting a transaction to the next block).**

1. Read the chain’s slot time and [leader schedule](#def-nw-on-chain-connectivity-leader) ; map the coming leaders to regions where their location is known or can be measured (chapter 17’s triangulation).
2. Keep connections open to the [block engines](#def-nw-on-chain-connectivity-engine) or builders in every region the leaders use; choose per transaction the one nearest the next leader with enough time left.
3. Use a propagation network or private relay where visibility or variance matters more than the last milliseconds.
4. Run your own nodes where you read state critical to trading; use hosted endpoints for the rest, within their limits.
5. Measure landing rates per region and per leader; the schedule and the engines’ locations change.

## 21.6 Tutorial: gossip and the next leader

**Goal.** Simulate gossip on a peer graph over the book’s map, and compare it with sending to the [block engine](#def-nw-on-chain-connectivity-engine) nearest the next leader. **End state:** Figures [21.1](#fig-nw-on-chain-connectivity-propagation), [21.2](#fig-nw-on-chain-connectivity-leaders) and [21.4](#fig-nw-on-chain-connectivity-timely).

1. **Engines.** `firm_chainnet.load_engines` reads the dated regional endpoints.
2. **Graph.** `Graph` places 600 nodes in the engines’ cities with eight peers each; `spread` ( [Listing 21.1](#lst-nw-on-chain-connectivity-spread) ) gives each node’s arrival time.
3. **Leaders.** `nw_chain.to_leader` ( [Listing 21.2](#lst-nw-on-chain-connectivity-leader) ) compares gossip with the nearest engine; `timely_rates` and `mean_timely` turn it into landing shares.

**What to change next.** Make the graph geography-aware (peers chosen among the nearest nodes) and see what gossip gains; add the engines’ own queueing and tips.

## 21.7 Build: the chain network model

**Purpose.** How transactions travel on a chain’s network and where to send them: the on-chain rows of chapter 29’s plan.

**Interface.** `firm_chainnet`: `Graph`, `spread`, `reach_time`, `Engine`, `load_engines`, `one_way_ms`, `choose_engine`, `timely`.

**Rules.** Endpoints are dated rows with sources; link delays are the fibre floor times a stated [route factor](https://one-course.com/books/quant/14/en/chapter/10-the-north-american-map#def-nw-the-north-american-map-factor) plus stated processing; every result is labelled a simulation.

**Acceptance tests.** `code/firm/chainnet/tests/`: the engines’ data, flooding on a line graph by hand, square-root fan-out never faster than flooding, and the chooser and deadline check.

**Stretch.** Read a live [leader schedule](#def-nw-on-chain-connectivity-leader) and validators’ measured locations; model the engines’ auctions.

Sources and further reading

- C. Decker and R. Wattenhofer, “Information propagation in the Bitcoin network”, IEEE P2P 2013.
- Ethereum consensus specifications (mainnet configuration); Anza documentation (leader rotation), Solana SDK and Agave source.
- Jito Labs, low-latency transaction send; Flashbots Protect; bloXroute documentation.

## 21.8 Exercises

**Exercise 21.1 ★.**

How many milliseconds does a Solana leader hold the chain if it has four consecutive slots at the SDK’s default target?

**Solution of Exercise 21.1.**

$4 \times 300 = 1\,200$ ms, 1.2 seconds; but the effective slot time is changed dynamically, so read it from the chain rather than assume the default.

**Exercise 21.2 ★.**

What is the difference between a [transaction propagation network](#def-nw-on-chain-connectivity-tpn) and a private relay?

**Solution of Exercise 21.2.**

A propagation network carries the transaction faster and with less variance than public gossip, and may still deliver it to the public; a private relay keeps it out of the public mempool until a builder includes it. The first sells latency, the second invisibility.

**Exercise 21.3 ★.**

Why does gossip reach a node in the sender’s own city later than a direct message would?

**Solution of Exercise 21.3.**

Its peers are random: a node in the same city is usually reached through other nodes, each adding its processing, and in the model the median node in Tokyo is reached after eight hops, $40\,\mathrm{m}\mathrm{s}$ against $1\,\mathrm{m}\mathrm{s}$ through the Tokyo engine.

**Exercise 21.4 ★★.**

Using [Proposition 21.2](#prop-nw-on-chain-connectivity-gossip), why is square-root fan-out never faster than flooding, and why use it?

**Solution of Exercise 21.4.**

Square-root fan-out replaces some pushes by an announcement and a pull, which lengthens those links by a round trip; by the proposition, longer links cannot shorten any shortest path. It is used because it sends each transaction in full to far fewer peers, saving bandwidth for a small cost in time.

**Exercise 21.5 ★★.**

The next leader is in Singapore and your machine in Tokyo. Which engine do you use, and what does the model say you gain?

**Solution of Exercise 21.5.**

The Singapore engine: $39.9\,\mathrm{m}\mathrm{s}$ against $58.9\,\mathrm{m}\mathrm{s}$ by gossip, $19\,\mathrm{m}\mathrm{s}$ sooner.

**Exercise 21.6 ★★.**

Why does the choice of region matter little on a chain with 12-second slots?

**Solution of Exercise 21.6.**

A tenth of a second of propagation is under one percent of a 12-second slot: nearly every transaction sent early in the slot arrives in time wherever the proposer is, and geography matters only for what is sent at the slot’s end.

**Exercise 21.7 ★★★.**

*Coding.* With `firm.chainnet`, how much faster does flooding reach nine-tenths of the nodes if each node has 16 peers instead of 8?

**Solution of Exercise 21.7.**

Half the nodes after $80.3\,\mathrm{m}\mathrm{s}$ and nine-tenths after $89.5\,\mathrm{m}\mathrm{s}$: 4.7 and $10.0\,\mathrm{m}\mathrm{s}$ faster, because more peers mean fewer hops.

**Exercise 21.8 ★★★.**

*Find the flaw.* “We send every transaction to the [block engine](#def-nw-on-chain-connectivity-engine) nearest our servers, so we always use the fastest path.”

**Solution of Exercise 21.8.**

The fastest path is to the next leader, not to the firm: an engine next to the firm’s servers helps only when the leader is also nearby. With leaders on several continents, the endpoint must be chosen per leader from the schedule.

## 21.9 Problem: The Leader Is in Frankfurt

**Problem 21.1.**

Weekend problem — gossip against the leader-aware engine

A firm in Tokyo sends transactions on a chain whose next leader is in Frankfurt. It can hand them to a public node in Tokyo and let gossip carry them, or send them to the [block engine](#def-nw-on-chain-connectivity-engine) nearest the leader. Use the chapter’s network model.

**Part I — Gossip.**

1. How long does flooding take to reach half and nine-tenths of the nodes from Tokyo?
2. And square-root fan-out?
3. When does the transaction reach a leader in Frankfurt through gossip?
4. Why is that longer than the direct path?

**Part II — The engine.**

5. Which engine is nearest the leader, and when does the transaction reach the leader through it?
6. What is the one-way fibre floor Tokyo–Frankfurt, and what [route factor](https://one-course.com/books/quant/14/en/chapter/10-the-north-american-map#def-nw-the-north-american-map-factor) does the model assume?
7. How much of the direct path is the engine’s own time?
8. What does the engine see that gossip would have shown to everyone?

**Part III — Landing rates.**

9. With the time left uniform between zero and $150\,\mathrm{m}\mathrm{s}$ , what share of leaders over the eight cities does each method reach?
10. And with up to $300\,\mathrm{m}\mathrm{s}$ ?
11. Why does the gain shrink as the window grows?
12. How would four consecutive slots per leader change the firm’s planning?

**Part IV — The verdict.**

13. State the *named result* : the propagation time to half and nine-tenths of the network, and the gain in timely arrival from sending to the [block engine](#def-nw-on-chain-connectivity-engine) nearest the next leader against a fixed region.
14. Which inputs are documentation and which assumptions?
15. What would a geography-aware peer graph change?
16. Where should the firm’s machines be for this chain?
17. What does a propagation network add on top of the engine?
18. How should the firm check that its model matches reality?
19. Where does this go in chapter 29’s plan?
20. In one sentence: why is the region a scheduling question?

**Solution of Problem 21.1.**

**Part I.**

1. $85.0\,\mathrm{m}\mathrm{s}$ and $99.5\,\mathrm{m}\mathrm{s}$ .
2. $113.9\,\mathrm{m}\mathrm{s}$ and $149.0\,\mathrm{m}\mathrm{s}$ .
3. After $83.5\,\mathrm{m}\mathrm{s}$ .
4. It takes three hops, each with $5\,\mathrm{m}\mathrm{s}$ of processing, where the direct path has one engine at $1\,\mathrm{m}\mathrm{s}$ .

**Part II.**

1. Frankfurt’s; $69.5\,\mathrm{m}\mathrm{s}$ .
2. $45.6\,\mathrm{m}\mathrm{s}$ one way; the model multiplies it by 1.5.
3. $1\,\mathrm{m}\mathrm{s}$ , an assumption; the rest is the route.
4. The transaction itself: gossip shows it to every node on the way, the engine only to itself and the leader.

**Part III.**

1. 61% with the engine, 48% by gossip.
2. 80.5% against 74.0%.
3. Once the time left exceeds the slowest arrival ( $99.5\,\mathrm{m}\mathrm{s}$ by gossip), both methods reach every leader; the fixed difference in milliseconds is then a smaller part of the window.
4. The same leader holds four slots, so the endpoint changes only at the handovers; transactions sent near the end of a leader’s run go to the next leader’s region, chosen from the schedule in advance.

**Part IV.**

1. *Named result* : in the model, a transaction from Tokyo reaches half the network in $85.0\,\mathrm{m}\mathrm{s}$ and nine-tenths in $99.5\,\mathrm{m}\mathrm{s}$ by flooding (113.9 and 149.0 with square-root fan-out); sending to the [block engine](#def-nw-on-chain-connectivity-engine) nearest the next leader rather than to a public node in Tokyo raises the share of leaders reached in time from 48% to 61% over a $150\,\mathrm{m}\mathrm{s}$ window, and reaches a Frankfurt leader in 69.5 instead of $83.5\,\mathrm{m}\mathrm{s}$ .
2. Documentation: the engines’ cities and endpoints, the slot and leader rules; assumptions: the peer graph, the [route factor](https://one-course.com/books/quant/14/en/chapter/10-the-north-american-map#def-nw-the-north-american-map-factor) , the processing times.
3. Peers chosen among near nodes would shorten each hop but add hops across oceans; gossip’s times would move, not its extra hops’ cost.
4. Near the engines of the regions where most leaders are, with a fast route to the others; for this chain, Europe and one site in Asia.
5. A second path, with less variance, for what the engine does not carry, and delivery to builders and validators outside the engine’s reach.
6. Send marked transactions through each path and measure the slot in which each lands, per leader region; compare with the model’s arrivals.
7. In the on-chain rows: the engines per region, the chooser, the private relays and propagation networks, and the nodes the firm runs.
8. Because the next leader’s location, known in advance, decides the fastest endpoint, and it changes every few slots.

## 21.10 Interview questions

**Interview question 21.1 ★ developer.**

How does a transaction propagate on a blockchain’s peer-to-peer network, and why is it slow?

**Solution of Interview question 21.1.**

By gossip: each node forwards it, or announces it, to its peers on first receipt, validating it first. It is slow because the peers are random, so the path zigzags, and every hop adds validation and queueing; the time grows with the number of hops and their worst links.

*What the interviewer is looking for: Peer-to-peer hops; processing per hop; announce and pull; measured tails.*

**Interview question 21.2 ★★ developer.**

What is a [block engine](#def-nw-on-chain-connectivity-engine), and why are there several around the world?

**Solution of Interview question 21.2.**

A service near the validators that takes transactions and bundles and forwards them directly to the block producer, often with an auction for inclusion. There are several because producers are spread around the world and the last hop should be short wherever the next one is.

*What the interviewer is looking for: Direct forwarding; tips or auction; regional endpoints.*

**Interview question 21.3 ★★ developer, researcher.**

How would you use a chain’s [leader schedule](#def-nw-on-chain-connectivity-leader) to route transactions?

**Solution of Interview question 21.3.**

Read the schedule for the coming slots, map each leader to a region (published or measured), and send each transaction to the endpoint nearest the leader that will still be producing when it arrives; keep connections warm in every region, and measure landing rates per leader.

*What the interviewer is looking for: Advance schedule; mapping validators to places; handovers; measurement.*

**Interview question 21.4 ★★ developer.**

When would you run your own node rather than use a hosted provider?

**Solution of Interview question 21.4.**

When the node is on the trading path: state that must be read with the lowest latency, transactions the firm does not want to share with a provider, or request rates beyond a provider’s plans; a hosted endpoint is fine for reading history and for everything that is not a race.

*What the interviewer is looking for: Latency; limits; privacy; cost of operation.*

**Interview question 21.5 ★★ trader.**

Why might a trader send a transaction privately rather than to the public mempool?

**Solution of Interview question 21.5.**

To keep it out of view of bots that would trade ahead of it or around it (frontrunning, sandwiching), and sometimes for a refund of the value it creates.

*What the interviewer is looking for: Visibility; MEV; private order flow.*

**Interview question 21.6 ★★★ developer, researcher.**

Design the transaction-sending layer of a trading firm active on a fast chain with leaders on three continents.

**Solution of Interview question 21.6.**

Connections to [block engines](#def-nw-on-chain-connectivity-engine) or builders in each leader region, a chooser driven by the [leader schedule](#def-nw-on-chain-connectivity-leader) with a margin at the handovers, private relays where visibility matters, the firm’s own nodes in the main regions for state, hosted nodes as back-up readers, per-region rate governors, and landing rates measured per leader region and per path.

*What the interviewer is looking for: Schedule-driven routing; regional presence; private paths; measurement and limits.*