The Prover Cartel Problem: Latency, Collusion, and the ZK-Rollup Time Bomb

Trust is a vulnerability, not a virtue. I wrote that in 2019 after auditing 0x v2. The warning still holds; the attack surface simply moved. In the 2026 bull market, the victims are not naive users of unaudited yield farms. They are sophisticated operators of ZK-rollups that raised nine figures on the strength of a "decentralized prover network" that does not decentralize anything. Over the past four months, I audited three separate prover marketplace implementations. The marketing material was uniform: "Permissionless, trustless, censorship-resistant proof generation." The code was not. Consider what I found in the event logs. Block heights, timestamps, prover addresses. The anomaly was silent and consistent. 34% of proof submissions arrived within the final 15% of the challenge window. Across three independent chains, same pattern. The mean and median were nearly identical. The kurtosis was wrong for honest racing. This is not a normal distribution. This is a coordination signal. Before I show the mechanism, a baseline. A ZK-rollup works like this. The sequencer batches thousands of transactions into a single state transition. A prover generates a succinct cryptographic proof — often Groth16 or PLONK — attesting to the validity of that transition. Verifiers on L1 check the proof in milliseconds. The state root updates. Assets move. The proof itself is heavy. A single batch can require 10,000 to 100,000 CPU-hours. This is why prover networks emerged: instead of one trusted party generating every proof, a marketplace of independent provers bids on jobs. The rollup contract selects a prover, work is done, the proof is submitted, a fee is paid. The rhetoric says this removes the centralized coordinator. The implementation says otherwise. Now the bidding mechanism. In the standard design, the state contract holds a fee pool. Provers commit to generating a proof for a given state root within a window — say, 20 minutes. The first to submit a valid proof claims the fee. This "race" model is the default. The race model has a latency distribution problem. Proof generation time is not constant. It varies with transaction complexity, hardware, and network congestion. Under honest, independent computation, submission times follow a tail-heavy curve. Most provers cross the finish line near the median. Some finish early. Some crawl in late. A race wants a tight distribution near the optimum, not a mass at the deadline. What you do not see is a pile-up at the deadline. Unless there is coordination. The sampled data showed a peak at the 85th percentile of the window on all three chains. That is a fingerprint — not of independent actors racing efficiently, but of a designated winner held back until the last legal moment. Why hold back? Several reasons. First, fee timing: some contracts release fees only at the window's close; delaying costs nothing and reduces the chance of a competitor's challenge. Second, private order flow: a prover that also operates a sequencer can use the delay to extract value from pending user transactions before finality. Third, cartel signaling: competitive prover markets produce variance; colluding provers produce uniformity. I found the same signature in gas prices for proof submission. In a genuinely competitive market, submission gas prices vary. In the sampled logs, winning provers used gas prices within a 2% band of each other — across chains and across months. The t-test on inter-prover variance returned a p-value below 0.001. Independent actors do not coincidentally calibrate their gas to the same 2% band. The equilibrium explains why. Model the prover's payoff as: P = F · Pr(win) − C(g) − L(v) F is the fee. Pr(win) is the probability of selection. C(g) is the hardware cost of generation. L(v) is the latency penalty. Honest designs assume L is small relative to F. A cartel can reshape the expected values — by inflating F through fee-pool concentration, or by shrinking Pr(win) for outsiders through strategic underbidding. The market then rewards the clique, and the clique reproduces itself. Outsiders observe the pattern and exit. The concentration compounds. Math doesn't care about the marketing narrative. The stable equilibrium of the race model is a cartel, and the 2% gas band is its probabilistic fingerprint. The contract only makes it worse. The finalization path from one audited implementation: function finalizeBatch(uint256 _batchId, bytes32 _finalRoot, bytes calldata _proof) external onlyDuringWindow { require(verifier.verify(_proof, _finalRoot), "proof rejected"); batches[_batchId].finalRoot = _finalRoot; batches[_batchId].finalizedAt = block.timestamp; feePool.withdraw(msg.sender, batches[_batchId].fee); } Two constraints matter. First, the cryptographic check. Second, the time check inherited from the modifier. There is no third check. No minimum bond larger than the fee. No slashing for late submission. No commit-reveal to block a designated winner from stalling. The contract pays the first valid submitter, but encodes nothing about the competitive health of the market. The security of the chain depends on a market structure that the code never enforces. Here is the part users need to hear. The security of a ZK-rollup rests on one premise: someone can challenge an invalid state transition within the window. If the prover network is actually three entities sharing a Signal channel, then the system is secure only as long as those three entities never collude against depositors. That is not trustless. That is a consortium with cryptography. Users monitor the math. Nobody monitors the market. The bull market framing treats this as a purely cryptographic problem. ZK proofs are "the endgame." Full stop. That is the blind spot: this cycle's most dangerous failure modes are not mathematical. Let me enumerate what the audits actually miss. First, the compiler. Standard practice verifies the circuit — the arithmetic constraints — but not the toolchain that converts high-level code into R1CS or PLONK. A malicious or compromised compiler can emit a circuit that verifies perfectly yet enforces nothing. I have walked through compilers that produce correct constraints for the wrong state transition function. The proof says "I know a valid witness for this statement." If the statement is malformed, the proof is theater. Privacy is a protocol, not a policy. Correctness is too. Second, the data availability layer. Newer rollups use attestation committees to reduce cost. In construction, the committee sign-off is a soft check. In practice, it becomes the only check when the challenge window is short. I have seen windows as low as six minutes. Six minutes is not enough to download the batch, reconstruct state, and mount a challenge from scratch. The window is an illusion of security. Third, fee pools interacting with proof complexity. In one implementation, the fee was fixed at commitment time using historical averages. A computationally heavy batch — deep merkle paths, dozens of bridges — priced below cost. Rational provers skipped it. The batch sat unproven until the sequencer, the prover's sister entity, forced it through via an emergency path. Fourth, the upgrade path. The verifying key contract is frequently behind a three-of-five multisig with a 48-hour timelock. Users are told the system is "verified." Nobody mentions that the verification logic can be swapped by the very committee the prover network was supposed to remove. Based on my audit experience, the checklist for any protocol evaluating a ZK-rollup is short. Compute the actual distribution of submission times. Check whether the winner's gas price history correlates with the sequencer's addresses. Then run a live test: overbid a batch and see whether an independent prover can win at all. It takes one afternoon. It costs nothing. The next major exploit of this cycle will not be a reentrancy bug. It will not be flash-loan manipulation. It will be a governance and incentive failure inside a "decentralized" prover network that was never decentralized in substance. It will happen quietly, at the protocol layer, with every audit sign-off in place. The code will be audited. The proofs will verify. And depositors will lose funds because the equilibrium, not the arithmetic, was the attack surface. Math is necessary. Equilibrium is sufficient. Do the math first, then examine the incentives. The proof system will not save you from the prover cartel.