Why stakefish is running mump2p on Ethereum mainnet

Optimum's mump2p is live on Ethereum mainnet across 16 operators and 1.4M ETH. What it changes, what we measured, and how to read the numbers.

Share
stakefish x Optimum: Why we run mump2p

Today Optimum announced that mump2p, its block propagation layer, is live on Ethereum mainnet. stakefish is one of 16 node operators running it. Together those operators secure about 1.4M staked ETH across roughly 22,000 validator keys, a little over 3% of all staked ETH.

Here's why we run it, how we monitor it on our own infrastructure, and what it means if you stake with us.

1. Validator performance is a timing problem

Most conversations about validator quality focus on uptime, client diversity, and hardware. Those matter. But a lot of outcomes are decided by something less visible: when your node first sees a block.

Ethereum runs on 12-second slots. Attesters are expected to vote about four seconds into each slot, on the block they've seen. A validator that sees the block late can vote for the wrong head or miss the window, and earns less for it. Proposers face the same clock: a block that reaches the network late risks being orphaned.

That data travels over GossipSub, Ethereum's default peer-to-peer protocol. Each node forwards full messages to its peers. It's resilient, but it's bandwidth hungry and slows down under load. Validators far from where a block originates feel it most.

2. What mump2p does differently

mump2p is built on random linear network coding (RLNC), which Optimum co-founder and CEO Muriel Médard co-invented through her research at MIT.

Instead of forwarding whole messages, nodes send coded fragments of a block. Each fragment is a random combination of the original pieces, so a receiver can rebuild the block from any sufficient set of fragments, no matter which peers sent them. Fewer duplicate transmissions means data gets through faster and holds up better when the network is busy.

GossipSub forwards full blocks. mump2p sends coded fragments.
GossipSub sends full blocks. mump2p sends coded fragments. Source: Optimum.

On our side, the Optimum Gateway runs as a sidecar next to each beacon node. It relays blocks and attestations between our consensus client and the mump2p mesh, in parallel with the standard libp2p network. Nothing about consensus changes. Our nodes simply gain a second, faster path for hearing about new blocks and votes.

3. What the numbers say, and how to read them

We don't adopt infrastructure on promises. We run mump2p and monitor results at our own gateways. The figures below come from Optimum.

MeasureResultSource
Block arrival vs GossipSub, all operators2.42x fasterOptimum, self-reported
Variance in arrival time7.88x lowerOptimum, early mainnet
mump2p nodes saw the block first9 of 10 measurementsOptimum, early mainnet

Two things are worth saying plainly. First, results depend on setup. An independent mainnet study of gateway v1.1.1 found earlier block arrival on some consensus clients and flat or slower results on others, with nothing statistically significant across its sample. That's why measurement at the operator level matters more than any headline number.

Second, faster propagation is not a promise of a higher headline APR. Short-term reward rates on Ethereum mostly reflect block proposal luck. What earlier block arrival does is cut avoidable losses: wrong-head votes, late attestations, proposals that land too late. Each one is small. Across every slot and every validator, they compound.

4. Where the saved time goes

Milliseconds saved on propagation are milliseconds available elsewhere in the slot. Optimum points out that operators can let their MEV sidecar wait longer for builder bids, because the finished block still reaches the network in time.

That's a real tradeoff, and one to handle with care. A faster network widens the safe window. It doesn't remove the clock.

5. What it means if you stake with stakefish

Nothing changes on your side. No migration, no re-delegation, nothing to update.

The gateway relays network messages only. It never touches validator keys or withdrawal credentials. It runs alongside the standard network rather than replacing it, so our nodes never depend on a single path.

If you're an institution evaluating operators, here's a fair question for any provider: what are you doing below the client layer, and can you show your own numbers?

6. Why it matters for Ethereum

Faster propagation isn't only a private edge. Slow gossip hits validators far from a block's origin hardest. When data reaches the edges of the network sooner, a validator's location matters less, and that's good for decentralization.

A propagation layer pays off most when most of the network uses it.

There's a longer arc too. Researchers have proposed cutting Ethereum's slot time to six seconds (EIP-7782). It isn't part of the next upgrade, but shorter slots would leave even less room for slow propagation. Work on the networking layer today is part of what makes that future possible.

We'll keep measuring and keep sharing what we see from inside our infrastructure.

Ready to stake with an operator that sweats the milliseconds? Start at stake.fish.

Stake. Earn. Relax.