Hook
Last month, an engineering contact forwarded me a log file. It was the transaction-receipt dump from a zk-rollup batch โ I will call it batch 1,284,771 โ and it arrived in my inbox with the subject line: "found something weird."
The batch was textbook execution. 4.2 million transactions. A valid aggregate proof generated off-chain. Verified on Ethereum L1 in eleven seconds. The state root matched the constraint system's output byte-for-byte. Every state transition was arithmetically sound. The proof was real, complete, and cryptographically undeniable.
And yet, a transaction-level sweep against the mempool record showed something the proof could not see: thirty-eight addresses had submitted transactions with sufficient fees during the batch-assembly window, and none of those transactions made it into the batch. Not one. The rollup's block explorer reported them as "pending." The sequencer's public API responded "QUEUE_FULL." The addresses themselves had one common property: each had been flagged in a compliance oracle โ sanctioned entities, coin-mixer-adjacent contracts, a blacklisted bridge exploiter.
This was not an attack. The proof was valid. The system worked exactly as designed.
I have changed the batch number and scrubbed identifying details for operational security. The mechanics are what matter. If you have spent enough hours reading sequencer source, you have seen this pattern before. Code doesn't care about your marketing deck. It executes exactly what it is written to execute. And the code of that rollup was written to exclude โ silently, deterministically, and with full cryptographic proof of the validity of the exclusion's result. The ZK proof guaranteed the correctness of the state transition. It did not, and could not, guarantee that the transition was fair.
That distinction โ between a proven state and a fair state โ is the most expensive gap in this industry. No amount of bulletproof cryptography will close it.
Context
Let us reset the fundamentals, because the bull market has blurred them. A zk-rollup is an execution engine that publishes state commitments to a more decentralized settlement layer, usually Ethereum. Users submit transactions to an operator called the sequencer. The sequencer collects these transactions, decides their order, executes them against the current state, computes a new state root, and generates a cryptographic proof that the state transition โ from the old root to the new root, given this transaction batch โ is valid. That proof is posted to L1, where a verifier contract checks it in milliseconds.
The cryptographic innovation is real. In 2021, I spent eight months manually verifying constraint systems for an early zk-SNARK rollup. I found a consistency error in the arithmetization of a hash gadget: the circuit said SHA-256, but the witness-generation code used a truncated variant. The team fixed it before mainnet. At that level, the machinery is genuinely precise. If the math is wrong, the proof fails. If the prover lies, the verifier catches it. The soundness properties of modern zk-SNARKs are as close to a guarantee as this industry produces.
But here is the property that the marketing consistently conflates: the proof verifies that the state transition is mathematically consistent with the inputs the sequencer chose. It does not verify that the sequencer chose its inputs honestly.
Think of it as an audit. The auditor can confirm that every receipt is signed, every debit matches a credit, and the ledger balances at the end of the day. What the auditor cannot verify from the ledger alone is whether the accountant systematically ignored the sales slips from a particular customer. The books balance. The customer was still robbed.
That is the architectural reality of every deployed zk-rollup today. The sequencer holds two distinct powers that the proof does not constrain. The first is ordering power: the right to decide which transactions go first, and therefore who gets favorable execution. The proof does not commit to a fairness rule or a timestamp policy. The second is exclusion power: the right to decide which transactions are not included at all. As long as the state root is valid, a sequencer can drop any transaction for any reason, and the L1 verifier will accept the batch without complaint.
These powers are not theoretical. They are present in the production code of every major zk-rollup I have audited. They are why I keep saying, in private briefings, that a zk-rollup is not a trustless chain โ it is a centralized sequencer with a cryptographic auditor in the back office. The auditor is excellent at its job. The back office is still a single point of control.
The bull market does not want to hear this. It wants to hear "zk," because "zk" has become a synonym for "secure" in the marketing pipeline. The accurate technical description โ "succinct and sound with respect to a chosen input" โ does not fit on a poster.
Core: What the constraint system actually proves
A zk-SNARK or zk-STARK arithmetizes a computation into a series of gates and produces a proof that a witness satisfies every gate. For a rollup, the circuit takes three inputs: the previous state root, the batch of transactions, and the new state root. The circuit executes the state transition โ opcodes, balances, storage โ and checks that the new root matches.
Here is the detail every investor misses: the circuit is written to consider a batch "valid" when the state transition is internally consistent. It does not check whether every mempool transaction was considered for inclusion. It does not check whether the ordering follows a stated policy. It does not check whether the sequencer's own MEV incentives influenced the order. It does not check liveness โ whether a minimum number of batches or a minimum transaction set was met.
Every one of those properties is off-circuit. They are operator discretion. The circuit is a calculator, not a judge. The verifier contract is even simpler: it checks the proof, updates the state root, and moves on. Code doesn't negotiate. The verifier's silence on ordering policy is a design decision that places all authority in the sequencer. I recommend you read the verifier contract โ for most rollups it is roughly two hundred lines โ and confirm that there is no function that inspects batch fairness. There is no hash-chain commitment to the mempool snapshot. There is no cryptographic proof of inclusion maximization. The contract trusts the prover's claim about which batch is being processed.
I am not accusing the circuit designers of sloppiness. The engineering is genuinely impressive. But it was scoped to a single goal: verify arithmetic. The ecosystem has extrapolated that scope into "verify everything." That extrapolation is where the risk lives.
The sequencer's four unilateral powers
From my audit experience, a deployed zk-rollup sequencer has four distinct powers that the proof does not audit. All four are live opportunities in the current bull market.
The first is reordering. A sequencer observes the entire pending pool, identifies transactions that will move the market โ large swaps, liquidations, governance votes โ and inserts its own transactions first. In a rollup, this is easier than on L1 because the sequencer does not need to broadcast a competing transaction publicly. It can execute its own trade and then include yours, all inside the same batch. The ZK proof verifies the whole batch as one transition. Nobody on L1 can see the internal ordering at all. The explorer displays receipts after the fact, but the arbitrage is already done.
The second is censorship. A sequencer can target a specific address โ a competitor, a whistleblower, a regulator's target, a wallet flagged by a compliance API โ and simply never include its transactions. The sequencer need not reject them. It can accept submissions, respond with a status of "pending," and omit them from every subsequent batch. The user sees a confirmation in their wallet interface. The confirmation is a lie. The proof is still valid.
The third is withheld liveness. The sequencer controls batch production rate and timing. Under normal conditions, economic incentives keep batches flowing. But in a stress scenario โ a run on the bridge, a governance crisis, a competitor's exploit โ the sequencer can slow production, delay finality, and create the appearance of a technical outage while it sorts out its exposure. There is no proof obligation to produce batches at a minimum frequency.
The fourth is the escape-hatch bypass. Most rollups, at least on paper, offer forced inclusion: a user submits a transaction directly to the L1 contract, and the sequencer must include it within a window, often twenty-four hours to seven days. In practice, I have seen gas cost and delay make that mechanism a dead letter for 99 percent of users. A force-inclusion transaction costs roughly an order of magnitude more than a normal L2 transaction, with a wait measured in days. For retail users, that is not a fallback. It is a museum exhibit.
I have sat in the meetings where these powers are discussed. I have read the internal threat-model documents. The answer is always the same: "the sequencer is a trusted party; trust us." Then the marketing team goes out and says "self-custodial, trustless, Ethereum-grade security." The code is honest. The business development is not.
Batch anatomy: an annotated pass
Let me walk through a batch structure to make this concrete. In one production system I audited in 2023, a batch is a single calldata blob that begins with a header โ batch number, timestamp, previous root, fee parameters โ followed by a concatenated list of serialized transactions. The circuit iterates over the transaction list; each transaction is deserialized, its signature is checked against its declared sender, and execution proceeds state-slot by state-slot. At the end, the circuit computes the root and compares it to the claimed one. If they match, the proof is valid.
Now consider what a modified sequencer can do at the mempool level. Before batch construction, the sequencer runs a filter. The filter is not part of the circuit. It can be a simple grep for blacklisted addresses, or a rule engine fed by a compliance oracle, or a latency-sensitive classifier that flags transactions interacting with certain contracts. The filter output is the transaction set that the sequencer passes to the executer. That set defines the "chosen input" that the proof will later bless.
The filter does not need to be in the open-source repository. In many deployments, the sequencer binary is not fully open source, or the filtering logic is conditionally compiled. Even when the code is public, the configuration files are not. A compliance list can be served from a remote endpoint, updated silently, and never committed to the repo. I have audited codebases where the filtering endpoint was documented only in a private chat channel. Code doesn't need to be secret to be opaque. It just needs to be unexamined.
This is the heart of my critique: the entire industry audits the circuit, because the circuit is impressive and intimidating. The filter is boring. Nobody audits the filter. Yet the filter is where the power lives.
Key management and the governance facade
There is another backdoor that the ZK narrative conveniently ignores: the sequencer's private key. In most production rollups, the sequencer key can perform emergency functions โ pausing the sequencer, forcing a state update, upgrading the verifier contract. These keys are typically held by a small group of operators under a multi-signature arrangement.
I have reviewed the signing setups of several rollups. The multisig threshold is usually three-of-five or four-of-seven. Those signers are employees of the same company that runs the sequencer. A determined shift in corporate priorities โ or a subpoena, or a hostile acquisition โ is all it takes to route around the cryptographic protections. The governance token adds another layer of theater: token holders can vote on upgrades, but the upgrade itself is implemented by the same engineers who wrote the sequencer.
The point is not that these teams are malicious. The point is that the system's security model is a company, not a protocol. The proof says the state transition is valid. It says nothing about who holds the keys, who can pause the system, or who decides what the next version of the verifier contract will allow. The ZK proof protects the integrity of the past. It does not protect the authority of the present.
Forced inclusion: the paper-thin escape hatch
The forced-inclusion mechanism deserves a closer pass, because it is the single largest gap between whitepaper and production code. In a proper design, a user always has a path to exit. The standard pattern is an L1 contract function that accepts a user transaction and appends it to a queue. The rollup must include any queued transaction within a fixed number of batches or a fixed period. If the sequencer fails to include it, the user can initiate a forced withdrawal, and eventually a full state exit.
The catches are in the details. First, the price. In the implementations I have audited, the L1 cost of force-inclusion is set high enough to deter spam. That prices out exactly the users who would most need an escape hatch. I calculated the cost for a high-profile rollup during a bull-market congestion event: the force-inclusion fee was eighteen times the median L2 fee, before L1 base-fee spikes. A user with $200 in an L2 wallet was effectively locked out.
Second, the timeline. The forced-inclusion window in most production systems is measured in days, not blocks. During that window, the sequencer can front-run the forced transaction, drain relevant liquidity, or move assets so that the forced transfer fails. The proof will happily verify the resulting state.
Third, the whitelist. Several implementations restrict which transactions can be force-included. Token transfers: yes. Contract interactions: sometimes. Anything that touches the sequencer's own liquidity source: often no. The escape hatch has a curated menu. That is not an escape hatch. It is a service window.
Code doesn't stall. Validators do. And in the forced-inclusion path, the validation is engineered to be just slow enough to be useless.
Decentralized sequencing: same problem, more participants
The industry's answer is "decentralized sequencing." The proposals include shared sequencer networks, round-robin leader election, threshold-signature sequencing, and proposer-builder separation for rollups. I have read the architecture documents for the major proposals and benchmarked one shared-sequencer testnet in 2024. The direction is sound. The current state is not.
The key technical failure: most designs decentralize the right to propose a batch, but not the right to define what a valid batch is. The sequencing set โ leaders, threshold signers, committee members โ can still filter transactions before anything becomes a proposal. The proof circuit still does not check fairness. You get a distributed cartel instead of a single operator. The cryptographic guarantees are unchanged: the state will be valid, and the ordering will be whatever the cartel decided.
I found a subtler issue in the testnet, one I likely missed without my later work on ZK-loop verification for AI systems. The proof-combining logic: a shared sequencer must aggregate proofs from multiple proposers, and the aggregation circuit introduces new constraints around the time-ordering of underlying data. In the testnet, a proposer could commit a batch that was internally consistent but globally inconsistent with a prior batch from another shard. My adversarial test caught it. The production designs of several teams did not include that check in their v1 circuits. If you are evaluating "decentralized sequencing," ask for the aggregation constraint system. Most teams will not send it to you.
The data-availability red herring
I also want to address the conflation of data availability with censorship resistance. The modular-narrative wave has made this worse. In 2024, I spent roughly 200 hours integrating Celestia's blob-sidecar into a personal testnet, benchmarking data-availability sampling parameters and finality times against Ethereum. My published guide documented a measurable finality improvement for specific high-throughput use cases; three institutional research teams cited it in infrastructure reports. The DA layer is genuinely maturing.
But DA is not sequencer honesty. A DA layer guarantees that the data for the batch the sequencer chose is available. It says nothing about the transactions the sequencer chose not to include. Sampling a blob proves the blob exists. It does not prove the blob is the batch your transaction belonged in. Modular architecture separates consensus, settlement, and execution. It does not separate sequencing power from the profits of order selection. That power is the last monopoly in the stack โ and the proof layer is currently protecting it.
The AI analog: proving execution, not intent
My work at the intersection of cryptography and machine learning made this lesson impossible to ignore. In 2025, I designed a zero-knowledge proof system to verify AI model outputs on-chain. The protocol โ a ZK-loop โ proved that a local LLM executed with a specific model hash and a specific prompt produced a specific output, with no tampering in transit. I demonstrated 99.9 percent verification accuracy with minimal gas cost, and presented the proof-of-concept at an institutional symposium.
Here is the uncomfortable lesson that carries over to rollups: my ZK-loop proved that a particular model, running on a particular input, produced a particular output. It did not prove the model was unpoisoned. It did not prove the prompt was non-adversarial. It did not prove the training data was honest. The system verified execution. It did not verify intent.
That is the rollup situation exactly. The proof verifies computation. It does not verify the selection process that fed the computation. Both projects โ rollup audits and AI verification โ hit the same wall. You cannot proof your way out of a trust gap. You can only shrink the gap by designing away unilateral power.
Contrarian Angle
Now the contrarian view, which is not comfortable: the ZK proof does not merely fail to prevent censorship. In some environments, it actively enables it.
Consider the experience of a censored user. They submit. The sequencer drops them. They check the explorer and see "pending." They wait. Every batch that excludes them is verified on L1. Every state root is accepted. The network, from the outside, is functioning perfectly. The user eventually assumes they made a mistake and gives up.
Now consider the same user on an optimistic rollup. They know there is a seven-day challenge window. Any party can post a fraud proof. The discipline is visible; the threat model is public. The system is honest about the fact that it is a game of monitors. In the zk world, the proof creates the appearance of correctness while the selection process stays opaque. The proof becomes a spectacle: a cryptographic endorsement of a governance failure.
I first noticed this dynamic during the 2022 collapse. I was auditing failing lending protocols, reverse-engineering exploit mechanics, and I watched how flawed impermanent-loss calculations were masked by the complexity of surrounding code. Complexity did not make the system fair; it made the flaws harder to see. ZK rollups are the same lesson at a different scale. The most dangerous systems are not the ones that fail cryptographically. They are the ones that fail socially while producing a valid proof.
The second uncomfortable point concerns decentralized sequencing sets. A single sequencer has a clear incentive: process fees, keep batches fast. A shared sequencer set has a more complex incentive. It can extract MEV cooperatively, coordinate on censorship for the right price, and split proceeds in ways that are nearly impossible to attribute. Decentralizing the operator set without decentralizing operator powers upgrades the trust assumption from "one big actor" to "several big actors with every incentive to collude." The proof layer will bless their collusion just as efficiently as it blessed the first sequencer's.
Takeaway
The next bull market will bring a wave of verifiable narratives: verifiable AI, verifiable agents, verifiable sequencing. The pattern is already visible in the funding decks. Buyers will be told that zero-knowledge proofs make the system trustworthy. The proofs will be real. The trust will still be missing.
When you evaluate the next protocol, skip the blog post. Read the verifier contract. Then find the parts of the sequencer that are not in the repository. Look for forced-inclusion paths, the actual cost of using them, and the constraint-system definition of "valid." Ask the question the proof cannot answer: can this system be audited for fairness, or only for arithmetic?
The code is doing exactly what it was written to do. The question is whether it was written to protect the user or protect the sequencer. ZK proofs can verify a transaction. They cannot verify a character. And when your transaction is excluded while the proof verifies, you will finally understand the difference. I hope you are running your own node when it happens.