Cadence: Monad's Answer to MEV

Key Takeaways

• Category Labs, the developer behind Monad, has released Cadence, a Multiple Concurrent Proposers (MCP) consensus protocol. Unlike earlier multi-proposer designs, which paid two extra communication rounds per block for a separate aggregation stage, Cadence embeds multiple proposers into consensus itself and finalizes blocks with the same three-round optimal latency as single-leader consensus.
• Cadence shortens the block production cycle independent of network delays through Extreme Pipelining. Because each block is handled in an independent consensus instance that makes no reference to the previous block, the block interval is fully decoupled from network latency. In a simulation with Monad mainnet's 200 validators, under a 100ms block interval, transactions were included in a proposal within an average of 50ms, with finalization taking an average of 219ms and speculative finality 167ms.
• While Solana's Constellation layers a multi-proposer structure on top of the Alpenglow consensus protocol as a preprocessor, Monad's Cadence redesigns consensus from a blank slate. The difference between the two approaches ultimately comes down to whether to pay extra communication rounds.
• Combining a multi-proposer structure with an encrypted mempool is an attempt to remove, at the protocol level, the very preconditions of MEV: monopoly and information asymmetry. This departs from Ethereum's path of marketizing MEV through auctions. If Cadence is actually deployed, the outlook becomes uncertain for Monad's MEV-coupled liquid staking model, which has resold the leader's ordering rights through auctions and folded the proceeds into staking yields. The excess returns of liquid staking will be restructured from private auction revenue into open fee revenue, and the arena of competition over residual ordering policy will likely shift from the protocol level to the application level.

1. The Problem with the Single-Leader Structure

Nearly every blockchain in operation today grants full authority to a single party for each block. The validator designated as leader during block production single-handedly decides which transactions go into the block, which are left out, and in what order they are arranged. Most protocols do rotate this role from block to block, but rotation merely disperses power across time. It does not change the fact that, for that particular block, the leader holds a complete monopoly.

Why does this brief monopoly matter? The leader gets to see every pending transaction before anyone else. If the leader spots someone's large buy order, for example, it can insert its own buy order just ahead of it to push the price up, then sell right behind it and pocket the difference. The profits that can be extracted by using block-building authority to see first and place first are collectively known as maximal extractable value (MEV). The single-leader structure has been the structural root of this problem (or profit source), from sandwich attacks to timing games.

Source: Monad

On July 2, Category Labs, the core developer of Monad, released Cadence, a new consensus protocol offering its answer to this problem. An interactive tutorial was published alongside the paper, and this article draws on both.

Source: Category Labs

The gist of Cadence can be summarized as follows. It adopts a multiple concurrent proposer structure in which several validators propose block contents at the same time, while preserving the optimal latency of single-leader consensus. The block interval can be set arbitrarily short, independent of network latency. And when combined with BTX, its in-house encrypted mempool design, it makes meaningful progress toward addressing MEV at the protocol level.

The idea of multiple concurrent proposers itself is not entirely new. The Solana camp has declared it the endpoint of its roadmap for years, and in March of this year Anza released a concrete design called Constellation. What is interesting is that designs aiming for the same goal are making completely different structural choices. This article takes a close look at how Cadence solves the problem, based on the paper, and compares it with Constellation and other designs to discuss what this competition is really about.

2. A Look Inside Cadence

2.1 The Problem Cadence Sets Out to Solve

The Cadence whitepaper opens by laying out three requirements a consensus layer must meet to serve onchain financial markets well.

1. Elimination of proposer monopoly
2. Low latency
3. A short economic tick, meaning the minimum interval at which a transaction can be included in some proposal

The shorter the economic tick, the more frequently state updates like oracle price refreshes or market maker quote cancellations can occur, which in turn reduces arbitrage losses on decentralized exchanges.

Source: eprint

Regarding the first requirement, a multi-proposer design must guarantee two properties to be genuinely meaningful. These properties were proposed in the September 2025 paper "Multiple Concurrent Proposers: Why and How," which involved researchers from a16z crypto, and Cadence follows the same definitions.

1. Selective censorship resistance: a proposer must not be able to single out and delay specific transactions.
2. Hiding: each proposer's contents must remain concealed until the point at which other proposers can no longer see them and revise their own proposals. Without hiding, a malicious proposer could peek at an honest proposer's submission and react only when it is advantageous, an adverse selection that would defeat the whole purpose of the multi-proposer structure.

Cadence approached censorship resistance from a more trading-oriented perspective as “Short-term censorship resistance”. This is a slot-level guarantee that a transaction included by an honest proposer cannot be dropped from that block or pushed into a later one. The definition targets the fact that a proposer can profit simply by using its monopoly to delay a transaction's inclusion for a short time, and that the conventional notion of censorship resistance, "it will be included eventually," means nothing in a trading context.

Cadence also points to cost as a problem with existing multi-proposer designs. Most recently proposed designs place a separate "propose and aggregate" stage ahead of the main consensus. Each proposal is first confirmed by a quorum of witnesses, and the record of confirmations constrains the discretion of the leader who assembles the block. This structure has the advantage of reusing the existing consensus as is, but it must pay two extra communication rounds per block. Cadence's starting point is to avoid this extra cost by embedding multiple proposers into consensus itself rather than adding a separate aggregation stage.

2.2 Extreme Pipelining: Redefining the Bottleneck Through Independent Instances

Cadence assumes synchronized clocks across nodes, divides time into uniform slots, and has each slot contribute exactly one block to the ledger. So far this is familiar, but Cadence differs decisively in that a slot's block makes no reference whatsoever to the previous block. Every slot is handled in its own independent single consensus instance, and no slot waits for the completion and broadcasting of the one before it. The paper names this Extreme Pipelining.

To understand why this matters, it helps to look back at conventional pipelining. The traditional way to shrink block intervals was to overlap the consensus of consecutive blocks. But pipelined protocols like the HotStuff family or MonadBFT require the previous block's quorum certificate as input for the next block, so the next proposal cannot begin before the previous one has propagated. Even optimistic designs that let the next leader build a block without the previous proposal cannot pull the floor of the block interval below network latency. As long as blocks are chained to one another, the bottleneck for block intervals will always be the network's physical latency.

Cadence, by contrast, needs no output from the previous slot to open a new one, so slots open purely on a schedule set by the global clock. The block interval becomes a protocol parameter rather than a function of network latency, and it can be set arbitrarily short if desired. Category Labs' initial target is 100ms, in which case a transaction waits only 50ms on average before being included in some proposal. Even if a slot is slow or stalls, the others keep producing, and even if blocks finalize out of order, they are buffered and appended to the ledger in slot-number order. This, Category Labs argues, preserves the consistency of the ledger.

In a structure where multiple proposers start together, the slowest proposer sets the pace for everyone. Cadence instead fixes one deadline per slot shared by all validators, and a proposal only needs to arrive by that time. Each proposer chooses its own transmission timing to suit its network conditions. A well-connected proposer can wait until just before the deadline to include fresher transactions, while a distant proposer can simply send early.

2.3 Chorus: A Fast-Path Single-Slot Consensus Protocol

The actual consensus within each slot is carried out by Chorus, a single-slot consensus protocol. Chorus has the standard fault tolerance of BFT consensus, operating safely as long as fewer than one third of all validators are malicious. The paper describes it as taking the structure of conventional single-leader consensus and creating several leader seats at once.

Start with how proposals propagate. Each proposer first encrypts its proposal with slot-level threshold encryption. Threshold encryption splits a key into multiple shares held by participants, and decryption becomes possible only when a sufficient number of shares are gathered.

The ciphertext is then split using erasure coding, a technique that divides data into pieces such that the original can be reconstructed from only a subset of them. A single cryptographic fingerprint (a Merkle root) is created over all the pieces to seal them, and the pieces are distributed to validators. Validators vote on this fingerprint, not on the raw proposal. This lets data propagation and consensus proceed in parallel, so even a large proposal does not add to consensus latency. This propagation method directly reuses Deterministic RaptorCast, which is already being deployed on Monad.

Source: Category Labs

The fast path proceeds as follows. When the slot deadline arrives, each validator casts one vote per proposer, voting yes if it received that proposer's valid piece and no if it did not. Once matching votes from more than two thirds of validators accumulate for a proposer, that proposer's inclusion status is settled. When quorums form for all proposers, validators assemble a "meta block" containing one entry per proposer and cast a commit vote on it. When commit votes again exceed two thirds, the slot finalizes. One proposal propagation and two votes, three communication rounds in total: this is the theoretically proven optimum and the same figure as single-leader consensus.

Worth noting here is how nonparticipating proposers are handled. In a naive design, a single offline proposer out of five would block the fast path. But Chorus validators cast explicit no votes, so a completely silent proposer is excluded with a quorum of no votes and the slot stays on the fast path. The fast path breaks only when a proposer delivers its proposal to just some validators (partial propagation) or sends different proposals to different validators (equivocation). In those cases, a separate fallback path uses an off-the-shelf consensus protocol as a black box to close out the slot.

Chorus additionally provides speculative finality similar to MonadBFT. A validator can speculatively finalize a block one round early, at the moment it assembles the meta block, without waiting for the second voting round. This result can be reversed only if some validator is cryptographically proven to have double voted. In effect, it is finality that will not flip unless someone commits obvious and deliberate foul play.

Hiding is handled by threshold encryption. Proposals propagate in encrypted form, and at the deadline validators reveal their key shares (decryption shares) along with their first-round votes. A proposal can be decrypted only after shares exceeding one third of the total are collected, so no proposer can craft its own proposal after seeing another's contents. Because decryption shares and data pieces travel inside vote messages, reconstructing proposals consumes no extra round.

Finally, there is an accountability mechanism. A proposer that breaks the fast path through partial propagation can be identified and punished, under the assumption that malicious validators make up at most about one sixth of the total, because the signed votes split between yes and no themselves serve as transferable evidence. This works as a deterrent against timing games that delay transmission until just before the deadline.

2.4 Conductor: The Orchestrator That Schedules Slots

Source: Category Labs

Saying that slots are independent also means that open slots can pile up without bound when the network is unstable. If new slots keep opening every 100ms while finalization has stalled, validators' memory and computation burden would grow without limit. Conductor, the orchestrator that manages slot scheduling, handles this problem.

Conductor groups slots into windows of W, and opens the next window only when all previous windows are complete and the first p slots of the current window are complete. This caps the number of slots a validator handles simultaneously at 2W - p. The first deadline of the next window is set by gathering the times each validator proposes, agreeing on them through consensus, and taking the median. Because the median is used, Byzantine validators cannot drag the schedule outside the range of honest proposals. When the network is healthy, windows follow one another without gaps at exactly the block interval, and when it is unstable, the tempo automatically slows and then recovers once conditions stabilize. This is where the protocol gets its name: Cadence, meaning rhythm.

2.5 Translating Blocks, and Integration with the Encrypted Mempool

What Cadence reaches consensus on is only the pieces of encrypted proposals. Blocks carry no parent reference and no commitment to executed state. Devices that traditional blockchains have taken for granted are gone, so the paper also presents how to restore them.

First, Cadence presumes Monad's asynchronous execution mechanism, in which execution trails consensus. A meta block confirmed by consensus passes through a deterministic step called Translation to become an actual execution block. In this step, invalid transactions are filtered out, transactions included redundantly by multiple proposers are reduced to one, and the remaining transactions are sorted, for example by priority fee.

To prove which state it validated transactions against, a proposer must attach an execution certificate from some prior slot as a ticket, and this device keeps proposals from running too far ahead of certified execution. The chain connectivity severed by the absence of parent references is restored by certificates issued outside the critical path of consensus (a chain certificate over committed history and an execution certificate over executed state), which light clients and bridges can use.

Source: Category Labs

Finally, Cadence is built on the premise of the integration with BTX, a batched threshold encryption scheme designed by Category Labs. Chorus's hiding addresses the problem among proposers, that is, proposers peeking at each other's proposals. It does not stop a proposer from inspecting the transactions users have submitted. An encrypted mempool, where users submit transactions in encrypted form and decryption happens only after ordering is settled, fills this gap, and BTX is what powers it.

To sum up, Monad's response to MEV separates into three layers. 1) Cadence removes monopoly and inter-proposer information asymmetry at the consensus layer. 2) BTX removes the information asymmetry between users and proposers at the mempool layer. 3) The fee attribution remain areas the Cadence paper explicitly leaves out of scope, delegated to the separate design of the Translation step and the fee mechanism. The paper mentions priority-fee ordering only as an example, and completing Cadence's MEV story will have to wait for this third layer to be revealed.

3. Comparison with Other Multi-Proposer Designs

3.1 Where Everyone Is Headed

Multiple concurrent proposers did not suddenly appear in 2026. Solana has declared multiple leaders per slot a roadmap goal since 2023. Behind it was the vision of a global price discovery engine: information about an event in Singapore should already be reflected on chain through a block producer in Singapore before it even reaches an exchange in New York. In 2025, Anza's post "The Path to a Decentralized Nasdaq" diagnosed the quote-cancellation race among market makers as an inevitable consequence of the single-leader structure and reiterated the need for multiple leaders. In September of the same year, the paper by a16z crypto researchers formalized the problem academically in the form of short-term censorship resistance and hiding.

Then in 2026, designs started arriving in quick succession. March brought Anza's Constellation, and around the same time AMP for Circle's Layer 1 Arc and Prefix Consensus from Aptos researchers were released, followed in July by the second edition of Sei's Giga whitepaper. Dismantling the single-leader monopoly is effectively becoming an industry-wide design goal for onchain trading infrastructure.

3.2 Constellation

Source: Four Pillars

Cadence's most direct point of comparison is Solana's Constellation. Constellation is designed as a preprocessor sitting on top of Alpenglow, Solana's next-generation consensus. Multiple proposers propagate transaction bundles to a set of attesters, and the attesters' confirmation records constrain the discretion of the leader who does the final assembly of the block. Transactions confirmed by attesters above a certain stake threshold must be included by the leader, so even though a leader exists, the leader's monopoly is dismantled.

The differences between the two designs run along three axes.

1. Latency: Because Constellation is layered as a separate stage on top of Alpenglow consensus, finalization requires two additional communication rounds. Cadence avoids this cost by embedding proposers inside consensus.
2. The nature of the economic tick: Constellation introduces the concept of a cycle, creating a 50ms economic tick within a slot of roughly 400ms. Several rounds of "propose, confirm, assemble" repeat within each slot, and since consensus itself runs only once per slot, message costs are saved. But transaction finalization still happens only at slot granularity, so cycles narrow the interval of state updates without reducing the end-to-end latency users experience. Cadence's Extreme Pipelining, in contrast, lowers the block interval itself to 100ms, so the economic tick and block finalization move to the same beat. The Cadence paper notes that cycles could be adopted as an extension of its own design, while also stating that cycles cannot substitute for Extreme Pipelining.
3. Strength of censorship guarantees: What Constellation provides is selective censorship resistance for transactions confirmed by attesters, and by the Cadence paper's standard it is not a design with hiding built into the protocol. Cadence guarantees short-term censorship resistance for all slots after a grace period and builds hiding into the protocol through threshold encryption.

Solana is already carrying out a major consensus replacement with Alpenglow, and adding multiple proposers on top must pass through the SIMD governance process, a vast base of existing infrastructure, and community debate. Layering on top of a proven consensus without touching it may well be the best option under those constraints. Cadence, on the other hand, is a design drawn up by the developer of a chain that fully owns its consensus stack. Before any question of technical superiority, the difference between the two designs reflects the different conditions each side faces.

3.3 Sei Giga: The Throughput-Oriented Multi-Proposer Converging

Source: Sei

On July 1, the day before the Cadence announcement, Sei also released the second edition of the whitepaper for its new consensus protocol, Sei Giga. Sei has positioned itself as the first multi-proposer EVM Layer 1 since the first edition in May 2025 and has adopted Autobahn consensus, which makes the two an excellent case for comparison.

Source: Sei

Autobahn works as follows. Every validator continuously propagates batches of transactions in its own lane, and each batch receives an availability proof. Consensus happens not per individual block but per "tip cut," where a leader periodically gathers and cuts across the latest certified ends of all lanes. Once a tip cut commits, the entire history of each lane referenced within it is settled at once.

Even with the same multi-proposer structure, however, Autobahn serves the exact opposite purpose from Cadence. Autobahn's lanes carry different transactions, divided among them. Transactions are assigned to validators at intake without a mempool, and since propagation pipes multiply with the number of validators, the network's total bandwidth adds up. In other words, Autobahn's multiple proposers are a horizontal scaling device for throughput. Cadence's multiple proposers, by contrast, deliberately produce overlapping proposals within the same slot and pay that redundancy as the price of censorship resistance and hiding, making them a fairness device. The discourse on multi-proposer consensus effectively splits into these two branches, bandwidth aggregation and monopoly dismantling, and Sei's protocol descends from the former lineage, to which Narwhal and the DAG family belong.

What is interesting is that Sei is moving toward the latter. Autobahn does have fairness elements. Users can submit a transaction redundantly to multiple validators for censorship resistance, and if only one of the duplicates executes, part of the tip is refunded. There is also an inclusion guarantee requiring a correct leader to include quorum-confirmed proposals in a subsequent tip cut, and distributing block rewards evenly across all validators rather than to a specific producer structurally reduces proposer rents, all pointing in the same direction. The recently released second edition adds an element called Sedna, a pre-execution privacy device responding to the MEV risks peculiar to multi-proposer chains. It shards transactions across multiple lanes and reassembles them only after finality, aiming for an effect close to hiding without an encrypted mempool or threshold decryption.

For Sei, however, no matter how many lanes there are, cutting the tip cut remains the job of a single leader, and the leader retains discretion over which lane's endpoint to include and how far. So what Sei guarantees appears to fall short of Monad's short-term censorship resistance, which forbids both exclusion from the block and deferral outright.

3.4 AMP, Prefix Consensus, and DAGs

Beyond Solana and Sei, recent high-performance chains that have adopted multi-proposer consensus mechanisms include the following.

AMP is a multi-proposer layer on top of Tendermint consensus, the mechanism adopted by Circle's Arc. Proposers propagate transaction payloads, and validators carry their identifiers in vote extensions to bind the payloads the leader must include. Like Constellation, the separation of propagation and consensus costs two extra communication rounds. The core point is that payloads confirmed by all honest validators are force-included in the block at the next height, and hiding is mentioned only as an optional add-on.

Prefix Consensus is a leaderless multi-proposer consensus protocol that achieves low latency on par with Cadence's fast path. It differs somewhat on censorship resistance, however. With Prefix Consensus, even after the network stabilizes, censorship resistance may not be guaranteed in up to f slots, and crucially, arbitrary slots in time can be selectively censored. In a trading context, the ability of an attacker to censor at a moment of its choosing is no small difference.

Beyond these, DAG-based protocols have a multi-proposer structure in the broad sense, since every validator proposes each round, but they target different properties. In a DAG, it can actually be advantageous to stack one's own proposal conditionally on top of others, which conflicts with hiding. The paper adds that introducing short-term censorship resistance appears to require giving up optimistic responsiveness, the ability to commit at network speed under good conditions.

4. Impact on Monad's MEV Ecosystem

When Cadence will be integrated into Monad mainnet remains unknown, but the first to feel the pressure will be the MEV market already taking shape on Monad, above all the liquid staking protocols that have made MEV revenue the core of their product. This section first lays out the current structure, then discusses what could happen if Cadence and BTX are deployed as designed.

4.1 MEV-Based Liquid Staking Protocols

Monad's liquid staking market was designed from the start in a form coupled with MEV. Consider the two leading protocols.

Source: Fastlane

FastLane's shMON operates a sidecar auction that sells transaction ordering to searchers and folds the proceeds into shMON's yield. By its own count, 118 of Monad's 198 validators route through this auction. On top of that, it recovers a share of the oracle extractable value (OEV) generated in liquidations through Chainlink's Smart Value Recapture (SVR) and adds it to the yield, and it also offers Atlas, an app-specific sequencing framework that lets each application define its own ordering and MEV rules.

Source: aPriori

aPriori is a protocol that defines itself as MEV-based liquid staking. Users deposit MON and receive aprMON, and on top of base staking rewards, the MEV revenue aPriori collects through its own blockspace auction is distributed. Searchers bid over the inclusion and placement of bundles, validators sell blockspace, and the proceeds flow back to stakers.

These protocols take an asset the protocol grants the leader for free, the right to determine ordering, price it through auctions outside the protocol, resell it, and return the proceeds to stakers.

If Cadence and BTX are deployed as designed, the foundation of this business model is shaken. What the sidecar auction sells is the leader's monopolistic ordering right, and the multi-proposer structure dismantles that monopoly itself. Still, it is too early to declare sidecar auctions impossible. The final ordering rules for merged blocks and fee attribution are undecided areas delegated to the separate design of Translation and the rules governing fee distribution, and how much ordering discretion that design leaves will determine the residual value of ordering as a product. What is certain is the direction: the product changes character from a private auction over one leader's discretion to competition under open rules.

4.2 What Remains: A Return to Fees and App-Level Transaction Ordering

This does not mean the excess returns of liquid staking converge to zero. More precisely, the source of the returns is restructured.

The variable is who receives the fees once the ordering race turns into a fee auction. As noted in section 2.5, the Cadence paper explicitly leaves the fee mechanism out of scope. If ordering fees are burned or redistributed in proportion to stake, as Anza envisions, the MEV premium stakers have enjoyed effectively evaporates. If they accrue to proposers instead, the revenue of private auctions changes form into transparent fee revenue spread across the five proposers per slot. Competition among liquid staking protocols would then return to traditional criteria such as commissions, operational quality, and DeFi integrations.

App-specific sequencing, on the other hand, may become more relevant. Cadence's merge rules are only a global default, and application-specific ordering policies, such as prioritizing market makers' cancellation orders, must still be set by each app itself. FastLane's center of gravity may shift from sidecar auctions to execution abstraction of the Atlas kind.

5. Three Implications

5.1 On Top of Consensus, or Inside It

The surface issues in the multi-proposer design race are individual properties like latency, censorship resistance, and hiding, but the structural choice beneath them converges on one question. Do you layer multiple proposers on top of an existing consensus as a separate stage, or do you rewrite consensus itself? The former preserves a proven consensus and secures deployment realism, at the cost of paying a communication-round tax on every block. The latter gains optimal latency, at the cost of having to prove and implement an entirely new consensus.

This framing is not unfamiliar. In an earlier piece on LayerZero's Zero chain, I observed, watching Zero reassemble the Ethereum roadmap from the ground up, that sometimes rebuilding from scratch can be faster. The contrast between Cadence and Constellation is exactly the same question, transposed to the consensus layer.

The side that owns its consensus stack and carries little legacy can put a multi-proposer design directly inside consensus, while the side shouldering a huge existing ecosystem and governance will find layering on top of the consensus protocol the reasonable choice. The path each chain takes toward the same destination of multiple proposers reveals, I think, the weight of history that chain carries.

5.2 Block Intervals: From Physical Law to Policy

The significance of Extreme Pipelining deserves to be appreciated separately from multiple proposers. Until now, the block-time race has essentially been a fight against network propagation latency, so there was a floor set by physics. Cadence splits the block interval and finality latency into two separate numbers. Even if finalization takes 219ms, blocks can be produced every 100ms, or even faster if desired. By analogy with a display, it is like separating refresh rate from input lag. How often the screen updates and how long input takes to appear on screen are different questions, and in trading infrastructure the former corresponds to the economic tick, the latter to finalization latency.

This separation means two things.

One is that block time as a metric is nearing the end of its life. The moment the block interval becomes a protocol parameter, the number itself stops being a bragging point, and the real bottlenecks move to execution speed, state access, and bandwidth.

The other is that the design assumptions of onchain applications change. An environment where oracle prices, liquidations, and auctions refresh every 100ms will produce a qualitatively different market microstructure from one running at 400ms.

5.3 MEV: From Marketization to Neutralization

Finally, I want to step back and identify the philosophy behind the ecosystem-level reshuffle of Monad discussed in section 4.

Ethereum's dominant response to MEV has been marketization, represented by proposer-builder separation (PBS): acknowledge MEV's existence, delegate extraction to specialized parties through auctions, and redistribute the proceeds. The combination of multiple proposers and an encrypted mempool stands on the opposite philosophy. For MEV to exist, two preconditions are needed: a monopoly over block construction, and an information asymmetry that lets one see others' intentions first. Multiple proposers remove the former, while hiding and the encrypted mempool remove the latter, all at the protocol level.

Of course, this does not mean MEV disappears entirely. Value arising from market structure, like arbitrage across price differences between exchanges, cannot be removed by a protocol. The ordering inside merged blocks also remains subject to fee competition, whose rules will be set by the yet-unpublished fee market design. And since hiding and encryption block the branch of MEV that observes and acts on intentions, blind spam that sprays sandwich attacks statistically cannot be fundamentally prevented.

The single-leader monopoly was a debt that blockchains would have to settle someday, so long as they claim to be trading infrastructure. The answer sheets from each camp on how to settle it have now all been submitted, and Cadence stands among the most radical and, at the same time, the most concrete of them.