Builders' Defection and Incentive Compatibility

team@nuconstruct.xyz

TLDR

  • Under proposer-builder separation (PBS), a single builder observes every searcher’s bid and full payload before assembling the block, with no constraint on how it uses that information. It can therefore replicate a profitable bundle instead of honoring the auction it ran. This is an imperfect-commitment problem: the builder runs the auction but nothing binds it to the outcome it promised, summarized by a the share of opportunities on which it defects.

  • We ask whether reputation alone can sustain commitment under repetition, since searchers who detect a defection can reroute future orderflow, imposing a cost on the defector. Honesty is incentive-compatible only when the builder is sufficiently forward-looking, the one-time gain from defection is small relative to ongoing honest revenue, and detection is sufficiently likely, otherwise reputation fails to enforce commitment.

  • Estimating the one-time defection gain on the libmev panel, and given that replication-based frontrunning leaves no clean on-chain fingerprint, making detection unlikely, the incentive-compatibility condition fails for every major non-TEE builder: defection dominates honesty unless the builder is unusually forward-looking.

  • The scale is material: over the panel (Sep 2024 – Aug 2025) non-TEE builders could have captured approx. $26M/yr by defecting, or approx. $49M across all builders once BuilderNet’s TEE-neutralized exposure is counted.

  • Restoring commitment is therefore architectural, not reputational, as the builder must be structurally prevented from reusing observed bids and payloads. For example, this can be addressed by introducing trusted execution environments (TEEs), or cryptographic frameworks such as zero-knowledge proofs or commit-reveal schemes.

1. Introduction

In our previous paper we have modeled a builder that runs a sealed first-price MEV auction with an exogenous defection rate \varepsilon \in [0, 1] and characterized the resulting piecewise equilibrium under partial commitment. In particular, the result from Theorem 3.7, which states that \varepsilon^* \in [0,1] depends on whether \gamma(\tau) v exceeds or falls below the competitive first-price sealed bid \beta(v), leaves open the question of whether commitment can be sustained at all when the auction is repeated. In this paper extension we close that gap. Here we embed the static auction in a repeated game between the builder and the searcher pool, derive the incentive compatibility (later, IC) condition under standard reputational punishment and estimate the IC threshold per builder on the libmev panel.

2. Repeated Game Incentive Compatibility

The builder plays the sealed auction once per period. After the bids and payloads are observed, the builder chooses whether to honor the outcome or defect. Defection in period t yields the one-shot frontrun surplus:

\Delta_t = \sum_{i \in \ \text{round} \ t} \max \{\gamma(\tau_i) v_i - b_i, 0\}

where the \max operator captures selective defection: the builder defects only on bundles for which \gamma v_j > b_j. Suppose that with probability p the defection is detected and the searcher pool migrates away, so the builder loses his continuation revenue stream from period t+1 onward. Then, with probability 1-p defection fails and play continues as normal. We suppose that searchers know p and condition strategies on the builder’s history. In the simplest version of the punishment, a single detected defection triggers permanent exit. Next, we compare two paths at discount factor \delta per period:

\text{NPV}_h = \sum_{i=0}^\infty \delta^i \pi_h = \frac{\pi_h}{1-\delta}
\text{NPV}_d = \pi_h + \Delta + (1-p)\sum_{i=1}^\infty \delta^i \pi_d + p \cdot 0 = \pi_h + \Delta + (1-p) \frac{\delta}{1-\delta} \pi_h + p \cdot 0

where subscript h means honest behavior of the builder, while subscript d means immediate defection. The first term in \text{NPV}_d is current honest tips on bundles the builder does not frontrun, the second is the defection surplus, the third is the continuation value conditional on not being caught and the fourth is the zero continuation conditional on being caught and losing the business. Subtracting, one gets:

\text{NPV}_d - \text{NPV}_h = \Delta - p \frac{\delta}{1-\delta} \pi_h

Therefore, the IC constraint for honest behavior equals to:

\Delta \le p \frac{\delta}{1-\delta} \pi_h \tag{1}

If we define the ‘months-equivalent’ of per-period defection surplus as m \equiv \frac{\Delta}{\pi_h}, (1) becomes as follows:

\delta \ge \frac{m}{m+p}

The intuition here is quite simple: honesty is sustainable only when the builder is patient enough that the discounted future business stream exceeds the one-shot temptation. The mapping back to the static model is direct: as \delta \to 0, which is the case of myopic builder, the threshold \frac{m}{m+p} \to 0 and any positive \Delta produces defection, recovering the high-extractability branch of Theorem 3.7. Note that interior \delta \in (0, 1) produces interior \varepsilon^*.

3. Empirical Implementation

We use the same libmev panel as in the original paper. The four-type \hat{\gamma}(\tau) estimates carry over unchanged: sandwich: 0.95, naked arb: 0.74, backrun: 0.70, liquidation: 0.88. For each builder b we compute three quantities:

  1. One-shot defection gain, panel total: \Delta^b = \sum_i \max \{\hat{\gamma}(\tau_i) v_i - b_i, 0\} summed over the builder’s bundles. This is the panel-level analog of the Figure 3 decomposition, sliced by builder.

  2. Honest revenue rate: \pi^b_h as the mean tips per month, averaged only over months in which the builder was active. This corresponds to the forward continuation flow the builder would forgo under punishment.

  3. Months-equivalent: m^b = \frac{\Delta^b}{\pi^b_h}, the single summary statistic of how many months of honest revenue does the panel-level temptation equal.

The implied IC threshold, expressed at annual frequency

\delta^*_{yr} = \biggl(\frac{m}{m+p}\biggr)^{12}

is the annual discount factor below which defection beats honesty (i.e. minimal year discount factor for honesty). The detection probability p is treated as a sensitivity dial since direct identification is left for the future work.

4. Results

Top builders by tip volume:

Builder \pi_h ($M/mo) \Delta_b ($M) m \delta^*_{yr} (p=1) \delta^*_{yr} (p=0.1) \delta^*_{yr} (p=0.01)
beaverbuild 3.74 10.10 2.70 0.02 0.65 0.96
Titan 2.25 9.01 4.00 0.07 0.74 0.97
bobTheBuilder 0.47 4.14 8.88 0.28 0.87 0.99
rsync-builder 0.36 0.61 1.69 0.00 0.50 0.93
BuilderNet 0.42 23.00 54.71 0.80 0.98 1.00
BuildAI 0.15 2.06 14.00 0.44 0.92 0.99
Ty For The Block 0.49 0.07 0.15 0.00 0.00 0.47

Table 1: Per-builder IC thresholds.

One can see that at p = 1, which is a case of certain detection, only BuilderNet has a threshold above the range of plausible operator discount factors. As p decreases, the binding region expands: at p = 0.1 the threshold for beaverbuild and Titan is in the 0.65–0.74 range and at p = 0.01 every major builder has \delta^*_{yr} > 0.95, meaning IC fails for any operator with even modest impatience.

Since replication-based front-running has no clean on-chain fingerprint, as a revert looks identical from the searcher side to a lost action, plausible p is in the lower part of this range, probably 0.01–0.1. Within that range, the IC constraint binds for every major non-TEE builder in the panel.

5. Type-level Decomposition

The aggregate m decomposes into per-(builder, \tau) contributions m^{\text{tot}}_\tau = \frac{\Delta_\tau}{\pi_h} with total honest revenue, which is not type-specific, in the denominator, because if defection on type \tau is detected the builder loses all future business, not just business of that type.

Builder sandwich naked arb backrun liquidation
beaverbuild 0.27 1.22 0.57 0.65
Titan 0.78 0.53 1.19 1.50
bobTheBuilder 8.65 0.00 0.23 -
BuilderNet 0.35 38.42 0.76 15.17
rsync-builder 0.95 0.34 0.38 0.01

Table 2: Per-(builder, \tau) defection exposure m^{\text{tot}}_\tau = \frac{\Delta_\tau}{\pi_h}. Em-dash denotes no records for that type at that builder.

Note that cells with m^{\text{tot}}_\tau > 1 indicate that single-type defection alone exceeds one month of total honest revenue, meaning that even at moderate p, defection on that type alone is sufficient to break the IC inequality. The pattern is consistent with the type-heterogeneity result of the original paper but adds an important builder-level dimension: the first to defect on type varies systematically across builders. For instance, for beaverbuild it is naked arb, for Titan liquidation and backrun, for bobTheBuilder sandwich and for BuilderNet naked arb and liquidation account for 98% of total counterfactual exposure.

BuilderNet as an outlier

BuilderNet, rbuilder running in TEEs, enforces \varepsilon = 0 architecturally rather than reputationally: the operator literally cannot observe individual bundle payloads in a form usable for replication-based defection, which produces a clean cross-builder comparison. Hence, three observations arise here:

  1. BuilderNet has the lowest value-weighted bribe share, equal to 12.3%, of any major builder. In our framework, this reflects the absence of the deterrence-bid premium \gamma(\tau) v that high-value searchers post at non-TEE builders to deter frontrunning, which implies that bidding is closer to the pure competitive level.

  2. BuilderNet has by far the largest counterfactual defection exposure, stated in Tables 1 and 2, concentrated in naked arb and liquidation.

  3. The TEE architecture is doing precisely the work that the IC constraint would otherwise require of reputation. Searchers route the most replication-vulnerable opportunities to the operator that cannot defect, precisely because the same surplus would be exposed at non-TEE builders.

One timing point matters for reading the TEE/non-TEE split. The libmev panel runs September 2024 – August 2025, while BuilderNet launched only in late November 2024, and beaverbuild migrated its flow into it, running in TEEs, over the following months (the switch was essentially complete by mid-2025). The classification here is therefore as-of-panel: beaverbuild is counted as a non-TEE builder because it operated as a standalone builder for the earlier part of the window, even though today its flow runs inside BuilderNet’s TEE. Every defection-exposure number in this post is a historical, panel-period quantity, not a claim about the present builder market; where a builder straddles the migration, its exposure and BuilderNet’s partly describe the same flow at different points in the window.

Aggregating across builders puts a figure on the scale. Summing the counterfactual surplus \Delta_b of Table 1, the panel carries approx. $49M of defection surplus in total: approx. $26M at non-TEE builders that could act on it, and approx. $23M at BuilderNet, where the TEE neutralizes it. Since the split is as-of-panel and beaverbuild (approx. $10M) has since migrated into a TEE, the realizable non-TEE figure at today’s configuration is closer to approx. $16M.

6. Restoring Credible Commitment

The PBS architecture creates the imperfect commitment problem mechanically. The builder sees every bundle and payload, holds unilateral authority over block contents and is bound by no cryptographic constraint on how observed information is used ex post. Concentration further weakens whatever reputational discipline a competitive builder market might in principle supply. The standard auction-corruption channels operate at scale, with the additional feature that replication-based frontrunning leaves no clean on-chain fingerprint and is therefore hard to detect.

Any resolution must therefore act on the architecture rather than on incentives. In terms of the model, a fix must render honesty incentive-compatible for every discount factor, which requires driving \varepsilon \to 0 by construction rather than through reputation. The operational requirement is that the builder never obtains the searcher’s bid and payload in a form it can profitably reuse ex post; when this holds, the defection surplus \Delta in (1) is identically zero and the IC constraint is satisfied trivially, independently of the detection probability p. We refer to any architecture with this property as credibly committing, and stress that credible commitment, not a particular implementation, is the object of interest: several designs achieve it by distinct technical means.

  1. Trusted execution (TEE). The operator runs rbuilder inside a trusted execution environment, so individual payloads are never exposed in a form usable for replication and defection is precluded cryptographically. BuilderNet is the instance in our panel; its empirical signature, the lowest value-weighted bribe share combined with the largest counterfactual defection exposure, is precisely what the model predicts for a builder that has eliminated the deterrence-bid premium by eliminating the threat that motivates it.
  2. Commitment-based settlement. Orderflow is turned into commitments before any searcher or builder acts on it, and value is added by competing over those commitments rather than the raw payload. TOOL is the instance here: private transactions and bundles are processed inside attested TEE environments and exposed only as a commitment view, and block building is distributed across a peer-to-peer operator set rather than concentrated in one builder. Because the raw payload is never exposed to the parties that could replicate it, the defection surplus is removed at the source rather than merely deterred and p becomes irrelevant. This route thus pairs the trusted-execution primitive of (1) with a commitment abstraction, inheriting the confidentiality of TEEs without the single-operator concentration.
  3. Cryptographic order protection. The same guarantee can be obtained without specialized hardware or an external settlement layer, by keeping bids and payloads hidden until the ordering is fixed. The practical instances are threshold-encrypted mempools that decrypt transactions only after inclusion (deployed by Shutter and, combined with slashable commit-reveal preconfirmations, by Primev’s mev-commit), batched threshold decryption that closes the pending-transaction-privacy leak of per-epoch schemes, and timed-release or commit-reveal constructions such as VDFs and witness encryption. Each removes the builder’s ex-post information by construction, at the cost of added latency and a decryption-committee trust assumption.

The three routes differ in their trust and implementation assumptions, as routes (1) and (2) rest on trusted hardware, route (3) on cryptographic assumptions, but are equivalent for our purpose: each removes the builder’s ex-post informational advantage and therefore closes the IC gap that reputation alone cannot.

It is worth being explicit about what does not close this gap, because the two roadmap items most often invoked in this context do not.

ePBS (EIP-7732) enshrines proposer-builder separation in the protocol and replaces the trusted relay with a protocol-native commit-reveal between proposer and builder; it guarantees that the proposer is paid and that the builder can neither withhold nor alter the committed payload. That is a proposer-builder trust problem, not a searcher-builder confidentiality problem: under ePBS the builder still assembles the block and still sees every bundle and payload, so \varepsilon is exactly where we left it.

FOCIL (EIP-7805) enforces inclusion lists through the fork-choice rule, guaranteeing that eligible transactions are not silently excluded; it addresses censorship, i.e. the exclusion of orderflow, and says nothing about its replication once seen. Neither mechanism removes the builder’s ex-post informational advantage, and so neither moves the IC threshold of Section 4.

It’s worth mentioning directly because both are frequently presented as comprehensive solutions; on the specific channel modeled here they are simply orthogonal, and encrypted mempools are in fact usually proposed as a complement to FOCIL rather than a substitute.

7. Discussion

Our models show that under PBS, honesty is not an equilibrium. At a realistic detection probability, every major non-TEE builder has a strictly rational incentive to defect, even after the full discounted loss of future business is netted against this. Thus reputation, as the mechanism meant to establish a repeated relationship, is just too weak to bind.

While this research does not study or report any signs of malicious behavior of the actual PBS participants, it might expose architectural flaws: the builder sees every payload, is not bound by any cryptographic constraints, and has an incentive structure intrinsically skewed towards exploitation of user transaction information.

We hope that our research sparks the discussion of whether the community should address PBS as a supply chain risk that can affect the majority of Ethereum users. We think it’s appropriate to put more efforts into researching this direction as well as broaden the scope for addressing incentive incompatibility issues in other parts of the transaction processing pipeline.

2 Likes