mump2p's 7.88× Number Is Real. The Audit Trail Behind It Is Not.

Twelve node operators. One daemon. Zero published audits.

On a Tuesday that will not make anyone's year-end retrospective, ether.fi's operator set was told to run Optimum's mump2p sidecar. Not invited. Not offered a canary window. Told. The number attached to that instruction is the only part of this story that matters: roughly 1.4 million ETH of staked infrastructure — better than three percent of the network's total stake — sitting behind software whose source code has not been published, whose audit history has not been disclosed, and whose performance claims have never been measured by anyone who does not draw a salary from the company making them.

The pitch is clean. 2.42× faster block arrival. 7.88× lower variance. A sidecar that rides on top of libp2p, uses random linear network coding, never touches your consensus client. Client-agnostic. Drop-in. The kind of integration story that makes a protocol team's eyes go soft.

I have audited enough contracts to know what a clean pitch conceals. In 2020 I filed a reentrancy issue against a flash loan module for a small DAO, and the patch landed in forty-eight hours — not because I was brilliant, but because the code was public and the maintainers were embarrassed. That is the entire mechanism. Public code plus public embarrassment equals patched code. Remove either half and the machine stops.

mump2p has removed the first half.

This is not a hit piece. I think the underlying technology is the most credible thing in this entire story, and I will spend several thousand words defending that position. But credibility of mechanism and credibility of deployment are two different audits, and only one of them has been done here. What follows is the second one.

The Source Structure Problem, Stated Up Front

Before any technical claim, the evidentiary base has to be declared. Fifteen discrete information points underpin this story. Eleven come directly from Optimum's own official communications. One comes from an ether.fi executive. One comes from Optimum's founder speaking about his own product. Two are background context.

That is the whole file.

No third-party measurement firm. No competitor response. No auditor named. No Ethereum core developer commentary. No node operator quoted on the record about what the mandate felt like from the inside. No independent reproduction of the latency benchmark.

The entire performance narrative rests on a single source family, which means every number in it is an advertisement until proven otherwise — regardless of how plausible the underlying math is. This matters because the math is plausible. That is precisely the danger. Bad technology with a bad story is easy to dismiss. Good technology with an unaudited deployment is the thing that actually hurts you, because nobody demands the second audit. The mechanism is elegant, the founder is a legend, the integration is trivial, and the source code is a PDF of claims.

I am a Nansen-certified analyst. My job is to distinguish between "the data supports this" and "the data is consistent with this." Those are different sentences. Everyone in this story is using the second one and reading it as the first.

What Actually Got Deployed

Start with the architecture, because it is the strongest part of the case and it deserves to be stated precisely rather than dismissed.

mump2p is a network-layer sidecar. It sits on top of libp2p. It does not replace GossipSub. It does not fork your consensus client. It does not touch your validator keys. It runs as a parallel process, ingests block data, and rebroadcasts it using random linear network coding across an overlay of participating operators.

This is a materially different engineering posture from almost everything else in the block-propagation market, and the difference is not cosmetic.

Historically, if you wanted to speed up block propagation on Ethereum, you had three options. You could modify the client — fork Prysm, fork Lighthouse, ship a patch, and pray the diff review catches everything. You could pay a centralized relay network like bloXroute's BDN, which works well but requires trusting an operator with visibility into your traffic. Or you could wait for the core developers to improve GossipSub incrementally, which is the safest path and also the slowest, because consensus-layer changes move at the speed of an all-core-dev call with a six-month tail.

The sidecar approach escapes all three constraints. You do not fork anything, so you inherit zero consensus-divergence risk. You do not route through a single company's backbone, so the trust model is at least nominally distributed. And you do not need an EIP, because you are not changing the protocol — you are changing how packets find their way to the protocol.

That last point is doing an enormous amount of load-bearing work, and we will come back to it, because "we don't need an EIP" is simultaneously the architecture's greatest strength and the reason it can be pushed onto three percent of the network with no standards process whatsoever.

The client-agnostic property is what made twelve operators say yes in a single cycle. An operator running a mixed fleet — some Lighthouse, some Teku, some Nethermind behind it — does not want to maintain twelve different patched binaries. A sidecar is one binary, one config file, one process supervisor entry. The integration friction is close to zero. That is not a marketing claim; that is an accurate description of why adoption happened fast.

But zero integration friction is not the same as zero operational cost. Hold that thought.

Why the Network Layer Is Where the Money Hides

Ethereum's slot is twelve seconds. Inside that slot there is a schedule, and the schedule is brutal.

A block is proposed at t=0. Attestations are due at t=4 — one-third of the slot. Aggregates are due at t=8. If your node has not received and fully validated the block by t=4, your attestation is either late or wrong, and a late attestation is worth less than nothing because it burns your inclusion distance without paying full reward.

So block propagation latency is not an abstract networking metric. It is a direct input into validator revenue, expressed in missed attestations and degraded inclusion distance. Every hundred milliseconds of tail latency you shave off the p95 is a fraction of a basis point of APR recovered.

This is why the network layer is where the money hides, and why it is chronically under-scrutinized. The consensus layer gets audited to death because a bug there forks the chain. The execution layer gets audited because a bug there drains bridges. The propagation layer gets a blog post, because a bug there "only" costs you yield and, in the worst case, hands someone a latency advantage.

I learned this asymmetry the hard way in 2022. During the Terra collapse I was watching Binance liquidation data in real time, and what struck me was not the size of the cascades but their timing — the way liquidations clustered in windows that correlated suspiciously well with periods of degraded exchange connectivity. The price did not lead the infrastructure problem. The infrastructure problem led the price. Nobody was auditing the pipes because everybody was staring at the chart.

The same instinct is operating here. Twelve operators just adopted a propagation layer, and the discourse is about whether 2.42× is a real number. The discourse should be about what happens when the propagation layer itself is the thing that fails, and who finds out first.

The 7.88× Number Is the Only One That Survives Theory

Here is where I stop being a skeptic and start being an engineer, because the variance claim is the single most technically credible thing in this entire file, and it is credible for a reason that has nothing to do with Optimum's marketing department.

Random linear network coding works like this. Instead of forwarding original packets, intermediate nodes forward random linear combinations of the packets they hold, with coefficients drawn over a finite field. The receiver does not need specific packets. It needs any k linearly independent combinations, where k is the number of original pieces. Once it has them, it solves the system and reconstructs the block.

The mathematical consequence is that every forwarding node is effectively performing erasure coding. You convert the question "did I receive the specific packet that got dropped?" into the question "have I received enough packets of any kind?" The first question has a binary, high-variance answer. The second has a smooth, low-variance answer, because the probability of falling short of k independent combinations decays exponentially in the number of received packets.

Now follow the implication. Mean latency is already decent on GossipSub — the average path is not the problem. The problem is the tail. Long-tail arrival times are caused overwhelmingly by packet loss, retransmission, reordering, and asymmetric topology. RLNC is structurally robust to exactly those four things, because it never waits for a specific packet.

Therefore the theory predicts, with essentially no free parameters: modest improvement in the mean, dramatic improvement in the tail.

2.42× on arrival speed. 7.88× on variance. The variance improvement is more than three times the mean improvement, and that ratio is exactly what the mathematics demands. If Optimum had reported 7.88× faster arrival and 2.42× variance reduction, I would have assumed the numbers were fabricated by someone who had never read Médard's papers. They reported the shape that the theory predicts.

That is not proof. It is corroboration, and it is worth more than a press release. When a claim's internal geometry matches the geometry of a twenty-year-old body of academic literature, the prior probability that it is directionally true goes up substantially.

So: the mechanism is real. The direction of the effect is real. The magnitude is unverified.

The Bill Nobody Itemized

Now the part that did not make the announcement.

RLNC is not free. It trades compute, bandwidth, and memory for latency robustness, and the trade is not trivial at the edges.

Decoding requires solving a linear system — Gaussian elimination, or a structured incremental variant if you are clever about it. Complexity scales roughly with the square or cube of the shard count depending on implementation. On a modern CPU with a well-tuned decoder, that is microseconds per block, which sounds like nothing until you remember that operators are not running one validator. They are running thousands, across multiple clients, on machines that are already saturated during high-blob-load periods. You have just added a persistent linear-algebra workload to the most latency-sensitive machine in the building.

Bandwidth is the second line item. Every combination packet must carry its coefficient vector. For a shard count of thirty-two over a finite field, that is tens of bytes of overhead per packet — somewhere in the low single digits as a percentage, higher if you shard finely. Fine sharding improves decode granularity and worsens the ratio. There is no free setting.

Memory is the third. You must buffer enough shards to decode, which means holding block data longer than a pure forwarding path would. On a machine under memory pressure from state growth, that is a real constraint.

None of this was published. Not one number. Not a CPU profile, not a bandwidth multiplier, not a memory high-water mark. The announcement describes the benefit and omits the cost entirely, which is the oldest move in infrastructure marketing and also the most effective, because operators evaluating a sidecar cannot compare a published benefit against an unpublished cost.

Here is the framing that actually matters: "overlay, not replacement" is a brilliant engineering decision and a completely hidden cost transfer. The operator now runs GossipSub and mump2p simultaneously. Double the processes, double the surface area, double the monitoring burden, and the bandwidth bill goes up rather than sideways. That cost is real, it is borne by the operator, and it is invisible in a narrative about speed.

The Sidecar Can't Lie to Your Client. It Can Decide What Your Client Hears.

This is the section I would put in bold if the format allowed it, because it is the argument nobody in this story has made.

The standard defense of the sidecar architecture is that it does not change consensus trust assumptions. That is true, and it is a genuine engineering virtue. A compromised mump2p process cannot forge an attestation, cannot sign a block, cannot slash you. The consensus client remains the source of truth.

But propagation-layer trust is not consensus-layer trust, and the industry keeps conflating them.

A sidecar that sits between the network and your consensus client has one capability that matters enormously: it decides what your client hears first, and in what order. Even a purely non-consensus-critical process can selectively delay a block, deprioritize a peer, or drop a message it has already validated. It cannot make your client believe a false thing. It can absolutely make your client believe a true thing late.

Late is expensive. Late is the difference between an attestation at inclusion distance one and inclusion distance three. Late is the difference between having the block state available when the next proposer's slot opens and not. Late is the difference between submitting a bundle in the first hundred milliseconds and submitting it in the second hundred, which in a competitive block-building market is the difference between winning and losing.

So the honest security statement is not "trust model unchanged." It is: the sidecar cannot lie to your consensus client, but it can choose the order in which truth arrives, and order is a monetizable capability.

Does that mean Optimum is malicious? No. It means the architecture introduces a new class of actor — the overlay participant — whose failure modes include targeted propagation degradation, and whose existence is not covered by any of the auditing frameworks Ethereum currently applies to consensus clients. When a validator runs Prysm, there is a decade of adversarial analysis about what a malicious peer can do. When a validator runs a sidecar daemon from an eleven-million-dollar seed-stage company, there is a blog post.

I have written about AI-agent behavior on DEXes — the 2025 study where timestamp and gas-price fingerprints suggested roughly fifteen percent of Uniswap volume was machine-driven. The relevant lesson transfers directly. Automated actors do not need to break your system to extract from it. They need to be faster than the humans in the same queue. A propagation overlay is a queue-priority system wearing a networking costume.

The Audit Standard Nobody Applied

Let me be concrete about what is missing, because "no audit" is easy to say and hard to feel.

Prysm has been audited repeatedly by multiple firms, with reports published. Lighthouse has public audit reports. Teku, Nimbus, Lodestar — same pattern. They run bug bounty programs with meaningful maximum payouts. They have documented vulnerability disclosure policies. They publish reproducible builds. They have, in some cases, formal verification efforts running alongside the implementation.

That is the baseline for software that touches consensus. It exists because the ecosystem learned, expensively, that unaudited consensus code is a loaded gun pointed at the chain.

Now consider mump2p's position. It is not consensus software, so it does not inherit the full burden. Fair. But it is being deployed to infrastructure securing roughly 1.4 million ETH. The economic weight is consensus-adjacent even if the technical role is not. And against that weight, the disclosure set is: no audit report, no bug bounty mentioned, no vulnerability disclosure policy mentioned, no statement about open-source status, no reproducible build, no third-party measurement.

There is a specific question that I want answered and that nobody has asked. The sidecar parses network input. Parsing network input is the single most common source of remote code execution in the history of software. If the decoder is written in a memory-unsafe language, the attack surface is the decoder. If it is written in a memory-safe language, the attack surface is the FFI boundary and the config parser. Either way, the question "has anyone outside the company read this code" has one answer, and the answer is currently no, or at minimum not publicly.

I am not demanding that a seed-stage company match the Lighthouse audit budget on day one. I am pointing out that the deployment happened before the audit, not after, and that the ordering was chosen by an entity that had the leverage to choose differently. Twelve operators did not collectively decide to skip due diligence. They were instructed.

Topology Is the Product, and the Product Is Undisclosed

The structural weakness of a decentralized sidecar model — as opposed to a centralized relay — is that its benefit scales with the density of the overlay, and the overlay's density is not published.

bloXroute's BDN works because it owns the backbone. Every participant gets the same fast path because there is one fast path, centrally operated and centrally optimized. The scale effect is immediate and the latency is deterministic. You pay for it in trust and in fees.

mump2p inverts this. Each operator runs its own node in a peer overlay. The speedup you receive depends on how many well-connected peers you have, where they sit geographically, and how the overlay's topology happens to route your traffic. With twelve operators clustered in a handful of data centers, the overlay is dense enough to help. With twelve operators scattered across three continents and asymmetric peering, the benefit could be substantially smaller than the benchmark — and the benchmark's topology has not been disclosed.

This is not a gotcha. It is a structural property of the design, and it should be stated as such: decentralized sidecar acceleration is a network-effect product, and the network effect is currently twelve nodes deep. The moment ether.fi's mandate is joined by a second and third delegation layer, the overlay densifies and the numbers improve. Until then, the benchmark describes a topology that may or may not resemble production.

And the topology itself is a disclosure gap. If I cannot see the peer graph, I cannot evaluate the claim. If I cannot see the measurement methodology, I cannot reproduce it. If I cannot reproduce it, the number is a press release, however well-shaped it is.

The Competitive Map, Read Honestly

| Approach | Architecture | Trust Assumption | Structural Advantage | Structural Weakness | |---|---|---|---|---| | mump2p | Decentralized sidecar, operator-run, RLNC overlay | No trusted third-party operator | Client-agnostic, near-zero integration friction, no consensus divergence risk | Benefit scales with overlay density; weak scale effects at low adoption; new unaudited daemon | | bloXroute BDN | Centralized backbone, proprietary transport | Trust bloXroute as operator | Strong scale effects, deterministic latency | Centralized, paid gateway, visibility into traffic | | Native GossipSub improvement | Protocol-layer incremental optimization | No additional trust | No new dependencies, no new attack surface | Slow, incremental, consensus-process-bound | | DoubleZero (Solana ecosystem) | Dedicated physical fiber network | Trust network operator | Best possible physical-layer latency | Capital cost, non-Ethereum ecosystem | | Chainbound / Bolt (fiber) | Preconfirmation and propagation acceleration | Partially centralized | Strong for preconfirmation use cases | Overlaps mump2p's target scenario |

The correct read of this table is that mump2p's structural advantage is its trust model and its structural disadvantage is its scale model. It wins on "no one has to trust Optimum with their traffic" and loses on "twelve nodes is not a network." Everything else is a re-litigation of tradeoffs that the market already understands.

An Eleven-Million-Dollar Seed Against a Four-Hundred-Billion-Dollar Network

The team question cuts both ways and I want to be precise about it.

Muriel Médard is not a marketing hire. She is one of the founders of network coding as a field — MIT EECS professor, holder of core RLNC patents, co-founder of Code-On Technologies and Silvus Technologies. When she says the mechanism works, the correct epistemic response is to update substantially, because she has spent twenty years being right about this exact thing in domains where being wrong kills people. Silvus builds MIMO radios for environments where the link is contested. That is not a résumé built on vibes.

But academic-to-product conversion at protocol-infrastructure scale is a different discipline from academic-to-product conversion in defense hardware. The disclosure set here includes no shipped product history, no prior protocol deployment, and a seed round of eleven million dollars. For context, that is a small round for a company whose software is now positioned to touch three percent of Ethereum's stake. DoubleZero raised multiples of that for a physically simpler problem. bloXroute raised multiples of that with a centralized architecture that is much cheaper to operate.

Eleven million dollars buys a very good team and a very short runway. It does not buy a multi-firm audit program, a bug bounty with a meaningful maximum, and a sustained independent measurement effort, all simultaneously. That is not a criticism of the company. It is a criticism of the sequencing decision, which placed the deployment ahead of the disclosures.

There is one more question worth raising, gently. RLNC is a patented technology family. A "decentralized" overlay that depends on patented coding raises a licensing question that nobody has addressed publicly. What happens to twelve operators, and to any operator who joins later, if the patent posture changes? I do not know the answer. I am noting that the question is not in the file, and that the file has fifteen entries and eleven of them come from one source.

What 2.42× Actually Buys a Validator

Let me translate the headline into the only currency an operator cares about.

A validator's revenue is a function of attestation inclusion distance, sync committee participation, and proposal luck. Inclusion distance is where propagation latency lives. If your attestation lands at distance one instead of distance three, you earn the full reward instead of a fraction. Across a fleet, a few hundred milliseconds of consistent tail-latency improvement compounds into a genuinely measurable APR delta — not large, but not zero, and in a restaking market where yield differentials are the entire marketing pitch, "not zero" is the whole game.

That is the honest version of the value proposition, and it is more compelling than the press release, because it does not require the reader to believe 2.42× is a universal constant. It only requires them to believe that tail latency is expensive, which is true and well-documented.

The dishonest version is what the announcement implies: that every operator will immediately experience 2.42× faster blocks. They will not. They will experience a variance reduction that is larger in the tail, smaller in the mean, and entirely dependent on how many other operators are in the overlay and where they sit.

Follow the Exit Liquidity

Now the contrarian turn, and it is not the one you are expecting.

Everyone in this conversation is arguing about the numbers. Almost nobody is arguing about the precedent. That is backwards, and I think the reason is that the numbers are legible and the precedent is not.

Here is the precedent. A liquid restaking protocol — a delegation layer, not a client team, not a research collective, not a standards body — issued an operational mandate to its node operator set. Twelve operators adopted a third-party network daemon because the protocol that delegates to them said to. That is a software distribution channel with more reach and more speed than any EIP process in Ethereum's history. It moved three percent of stake in a single cycle, with no public comment period, no all-core-dev call, no security review from anyone outside the two organizations involved.

And it did so legally, because a sidecar is not protocol software. There is no EIP for it. There is no process to invoke. The governance surface that would normally catch this does not exist, because the thing being deployed deliberately sits outside the layer that governance covers.

That is the actual story. Not 2.42×. Not 7.88×. The story is that the restaking layer has quietly become Ethereum's fastest and least accountable software distribution mechanism, and the first thing it distributed was an unaudited latency overlay.

Why would ether.fi do it? Follow the exit liquidity. The restaking market is crowded — EigenLayer, Symbiotic, and a dozen aspirants all selling the same base yield with different points programs. Differentiation is scarce. "Our operators run the fastest propagation layer in the network" is a differentiable claim. It converts into a marginally better APR, which converts into a marginally better weETH narrative, which converts into marginally stickier deposits. The performance improvement is real but the strategic motive is not performance. It is positioning.

That is not sinister. It is rational. It is also exactly how infrastructure monocultures form: not through coercion, but through a sequence of individually rational differentiation moves that each add a dependency nobody is tracking at the system level.

Whales are circling. Not around the token — around the topology. Whoever densifies the overlay first owns the latency advantage, and the first mover here has a twelve-operator head start and a mandate mechanism to replicate it.

The Blind Spot Nobody Is Pricing

Here is the correlation-versus-causation trap, stated plainly.

If ether.fi's operators report better attestation effectiveness next month, the causal chain will be asserted immediately: mump2p improved propagation, propagation improved inclusion distance, inclusion distance improved rewards. The narrative writes itself.

But there are at least four alternative explanations that will produce the same measurement. First, operators who agree to a mandate are likely to be the better-run operators to begin with, so selection bias contaminates the comparison. Second, any operational change causes teams to pay closer attention to their fleets for a few weeks, and attention alone moves metrics. Third, the measurement window will overlap with normal network conditions varying in ways unrelated to the sidecar. Fourth, and most importantly, there is no control group — every operator in the set was mandated, so there is nobody left to compare against within the cohort.

That last point is the killer. A mandate applied uniformly to the entire cohort destroys the experiment. You cannot measure the effect of a treatment you gave to everyone. The only valid comparison is against operators outside ether.fi, and those operators differ in a hundred ways that have nothing to do with network coding.

So we will get a number, the number will be positive, and the number will be uninterpretable. This is the most predictable failure mode in the entire story and it is already locked in by the structure of the mandate itself.

I have seen this exact pattern before. When I analyzed Coinbase Custody flows against spot ETF premium and discount metrics in 2024, the temptation was to draw a clean causal arrow: institutional inflow causes premium. The data did not support that arrow. It supported a correlation with a much messier causal structure underneath it, where both variables were downstream of a third thing. The people who drew the clean arrow made money for a while and then got destroyed by the messiness. The people who held the correlation loosely made less and survived.

The same discipline applies here. The mechanism is sound. The deployment is unaudited. The measurement will be confounded. Hold all three at once.

Chain Doesn't Lie

Here is where I stop arguing and start waiting, because the beautiful thing about on-chain systems is that they generate their own audit trail whether or not anyone publishes one.

If the variance reduction is real at the claimed magnitude, it will show up in public beacon-chain data within one to two epochs of the mandate taking effect, and it will be visible without Optimum's cooperation. Attestation effectiveness across the ether.fi operator set is observable. Missed attestation counts are observable. Inclusion distance distributions are observable. Block arrival time percentiles, to the extent they are published by the observability providers, are observable.

If p99 block arrival across that operator set drops by anything close to 7.88× in variance, that is a signal so large it cannot hide behind a confounded cohort comparison. It will be visible in the tail, and the tail is where the claim lives.

If it does not appear — if the numbers move by noise-level amounts — then the honest conclusion will be that the benchmark topology did not resemble production, which is the most likely failure mode given that the topology was never disclosed.

Either way, we will know, and we will know without asking permission. Chain doesn't lie. It just takes its time.

There is a parallel worth drawing, and I will draw it because it has been on my mind for seven years. The Lightning Network had elegant engineering too. Hash time-locked contracts, onion routing, a genuinely novel approach to scaling payments without touching base-layer consensus. And it is half-dead, not because the cryptography failed but because routing failure rates and channel management complexity made the operational experience intolerable for anyone who was not running a routing node as a hobby. Elegance is not adoption. A mechanism can be mathematically beautiful and still lose, because the thing that determines survival is whether the operational cost is bearable for the median participant.

mump2p has an operational cost. It has not been published. That is the risk that the elegant math does not address.

The Blob Question Nobody Is Asking

One more thread, because it bears on whether any of this matters in eighteen months.

Every argument about block propagation assumes the block is the scarce resource. It is, today. It will not be, indefinitely. Blob space is being consumed at a rate that will saturate post-Dencun capacity within a couple of years at current growth, and when it does, the fee market re-rates and the economics of every rollup change at once.

When that happens, the network layer becomes more important, not less — more data, more propagation pressure, more value in tail latency. So mump2p is directionally early in a good way.

But there is an irony worth naming. The same instinct that says "the propagation layer is the bottleneck, let us optimize it" is the instinct that will say "blob space is fine, let us not worry about saturation." Both instincts come from the same place: a preference for solving the problem in front of you with an elegant mechanism rather than pricing the problem behind it. The propagation overlay is a good answer to a real question. It is not a substitute for asking what happens when the question changes.

What to Watch Next Week

Five signals, in descending order of information value.

One: source code publication. If the repository goes public with a reproducible build, the audit gap closes substantially and most of this article becomes a historical footnote. If it stays closed, the gap widens and the next mandate becomes a bigger problem than this one.

Two: an audit announcement with a named firm and a publication date. Not "we take security seriously." A firm, a scope, a timeline. The absence of this within thirty days of a production mandate to three percent of stake is the single loudest signal in the entire story.

Three: overlay topology disclosure. Peer count, geographic distribution, and the measurement methodology behind 2.42× and 7.88×. Without this, the numbers are unfalsifiable and should be treated as such.

Four: a second adopter. If another delegation layer mandates mump2p, the overlay densifies, the network effect kicks in, and the performance claims become self-fulfilling. If nobody follows within a quarter, the twelve-operator mandate was a differentiation stunt and the technology will sit at niche scale — which, per the Lightning precedent, is how elegant mechanisms die.

Five: operator attrition. Watch whether any of the twelve quietly exits the ether.fi set in the next two quarters. Operators do not publish reasons. They just stop showing up in the set, and the reason is almost always operational burden rather than ideology.

Leverage kills. Not just financial leverage — architectural leverage. The decision to place a dependency on three percent of the network before auditing it is a leveraged position, and the collateral is other people's stake.

The math is probably right. That is what makes the missing audit so expensive.