MonadBFT Deep Dive - A Mechanism-Design Foundation for High-Performance Consensus - Part 1

Overview

Consensus protocols live inside economies. Validators carry stake, pay operating costs, chase or defend against MEV, and sometimes collude. If we describe MonadBFT as only a message-passing algorithm, we miss the forces that drive real outcomes. In this series we treat MonadBFT as a mechanism: a rule system played by strategic agents. Our questions are mechanism-design questions: does the protocol make “follow the spec” a best response for rational validators, while staying safe against Byzantine behavior?

MonadBFT’s paper¹² and implementation aim for fast confirmations, accountable safety, and resistance to tail-forking, while keeping the happy path essentially linear. In this opener we (i) place MonadBFT on a clean game-theoretic footing, (ii) explain its artifacts as mechanism components, (iii) pin those components to the repo, and (iv) lay out six research problems whose solutions strengthen the mechanism without bloating the protocol. Later posts will take them one at a time.

1) MonadBFT as a repeated game

We model an infinite-horizon game over views $v=1,2,\ldots$. In each view a leader $\ell(v)$ proposes a block $B_v$; validators either vote (happy path) or send timeouts (unhappy path). The network is partially synchronous: after an unknown GST, honest↔honest messages arrive within $\Delta$; pre-GST delays are unbounded. Safety doesn’t assume GST; liveness and latency do.

Each validator (i) has a type $\theta_i$ (stake $s_i$, latency, MEV capacity, coalition intent) and a per-view utility

We reason in sequential (perfect Bayesian) equilibrium, and whenever possible we aim for ex-post incentive statements that don’t depend on priors.

2) Protocol artifacts as mechanism components

Consensus systems read like distributed plays: clients announce intentions, nodes interpret them, a messenger chorus carries lines across the stage, and the pacemaker keeps time. MonadBFT renders this play in Rust. Each artifact below is simultaneously a software component and a mechanism element, a point where incentives, information, and control meet code.

Economically, preserving the linear happy path doesn’t just lower latency; it lowers the marginal cost of participation so smaller validators remain competitive, directly pushing against centralization pressure.

2.1 From client intent to on-chain commitment

A typical round begins outside the validator set. Clients speak JSON-RPC; the node translates intent into candidate state transitions; consensus determines the order in which those transitions become law³.

Figure: ingress → tx admission → propose/vote (QC/TC) → commit → RPC externalization.

Ingress (RPC as the intent boundary). monad-rpc exposes Ethereum-compatible HTTP/WebSocket endpoints, validates request shape, and forwards transactions/state queries via IPC to the node executors (monad-rpc/src/main.rs L65–125, 130–155). Mechanism view: RPC is the reporting channel where users reveal bids (tips per gas) that later drive allocation.

Admission & pre-adjudication (TxPool + policy). EthTxPoolExecutor checks signatures and policy, stores transactions, and, on demand from consensus, produces a proposal subject to EthBlockPolicy limits. Ordering is the priority rule implemented in the tracked-pool sequencer (monad-eth-txpool/src/pool/tracked/sequencer.rs). Mechanism view: this is the allocation rule over a batch; currently a first-price priority auction on effective_tip_per_gas.

Consensus loop (propose → vote → QC/TC). monad-consensus-state runs HotStuff-family rounds: the leader emits Proposal, validators verify and cast Votes, and the system aggregates a QC; on stalls it accumulates a TC (monad-consensus-state/src/lib.rs ~L435–752). Mechanism view: QCs/TCs are public signals aligning beliefs and advancing the game under partial synchrony.

Persistence & externalization. Committed blocks flush through MonadBlockFileLedger; state deltas land in TrieDB (monad-triedb). RPC surfaces final/optimistic views back to clients. Mechanism view: the ledger is the allocation outcome; optimistic confirmations are commitment devices contingent on non-equivocation.

2.2 Executors, events, and the control plane (how messages become moves)

Monad follows a clean executor pattern: monad-node orchestrates typed events and commands; each subsystem is a worker with a narrow contract.

monad-node boots keys/config (NodeState), wires executors, and drives the event loop (monad-node/src/main.rs L109–153, 299–418, 458–548). ParentExecutor fans out commands to MultiRouter (network), TokioTimer (timeouts), EthTxPoolExecutor (proposals), StateSync, Ledger, and more (monad-executor-glue/src/lib.rs L57–76, 441–489, 563–585). Mechanism view: the event bus delimits the strategy space, who can do what, when, and with what evidence. Typed commands make incentive boundaries explicit.

2.3 The network as courier, not arbiter (RaptorCast, routing, identity)

Broadcast must be fast, loss-resilient, and credibly neutral. That’s RaptorCast’s job: UDP + fountain codes + stake-scoped groups, shepherded by a routing/identity layer.

MultiRouter abstracts transports; PeerDiscoveryDriver maintains topology via signed MonadNameRecords and liveness pruning (monad-node/src/main.rs ~L643–663, docs/peer_discovery.md). RaptorCast encodes/broadcasts messages with redundancy; receivers verify authorship/group membership and drop spoofed/undersized chunks (monad-raptorcast/src/udp.rs L192–247). Mechanism view: the messenger should be incentive-neutral; where it isn’t (free-riding on relay), we get a measurable design surface (Problem 4).

2.4 The consensus core as a set of levers

This is where most mechanism knobs live.

Leader election (allocation ex-ante). WeightedRoundRobin samples a leader from stake via deterministic ChaCha20 seeded by the round (monad-validator/src/weighted_round_robin.rs L44–83, 144–151). Lever: unpredictability vs. verifiability; DSIC vs. schedulability.

Pacemaker (timing & escalation). Δ_timer = 3Δ + vote_pace + local_proc; two-phase timeout handling produces TCs when thresholds hit (monad-consensus/src/pacemaker.rs L166–177, 294–381). Lever: timing-strategy-proofness; adaptive vs. manipulable Δ.

Vote aggregation & safety (public signals + constraints). VoteState aggregates signatures and forms QCs; Safety enforces locking/double-vote rules (vote_state.rs L82–180). Lever: evidence that drives beliefs and slashing.

No-endorsement path (negative evidence). NoEndorsementState and NEC messages drive safe fallback when payloads don’t gather honest support (handlers in monad-consensus-state L442–1004). Lever: “proving absence” to unblock progress.

2.5 Transaction pool & proposal policy (where MEV meets allocation)

OrderedTx implements

fn cmp(&self, other: &Self) -> Ordering {
    (self.effective_tip_per_gas, self.tx.gas_limit())
        .cmp(&(other.effective_tip_per_gas, other.tx.gas_limit()))
}

, a first-price priority auction over slots (sequencer.rs Ord::cmp). EthBlockPolicy sets per-block resource ceilings (module monad-eth-block-policy). Mechanism view: the ordering rule defines bidders’ best responses; policy bounds define the feasible set.

2.6 Storage, state sync, and the external view

TrieDB + caches form the authoritative state with tuned read concurrency; StateSync hydrates lagging nodes. Mechanism view: confirmation surfaces (optimistic vs. finalized) serve as commitment devices in our equilibrium analysis.

2.7 The message taxonomy that drives the game

ProposalMessage (leader move), VoteMessage (endorsement), TimeoutMessage (escalation), RoundRecovery/NoEndorsement (negative evidence). Router publishes/broadcasts. These are not just packets; they are mechanism primitives carrying commitments, costs, and beliefs. When we tweak them, add a VRF to election, pay for relay, we change the equilibrium set.

3) Three core properties (paper theorems with intuition)

3.1 No-Tail-Forking (NTF)

This is Theorem 1 (“No-Tail-Forking”) in the MonadBFT paper¹. Informally: after GST, if a block $B_v$ has a QC with a strict majority of honest endorsements, then no conflicting proposal can ever commit at the same sequence $v$. Any valid successor at height $v{+}1$ must either extend $B_v$ or carry a No-Endorsement Certificate (NEC) that proves the parent was not reconstructible by a majority (e.g., data unavailability).

How the mechanism enforces it. MonadBFT’s recovery rules force extend-or-explain: a new leader must repropose the high tip (the most recent fresh proposal voted by $\ge 2f{+}1$) unless it presents an NEC. An NEC aggregates $f{+}1$ signatures attesting that the high-tip block could not be reconstructed from the advertised QC. This makes “skip the widely endorsed parent” impossible without public negative evidence, which is precisely the move tail-forking needs. The paper’s Lemma 2, Lemma 3, Lemma 4 establish the voting/form-validity properties used inside the proof of Theorem 1.

Intuition. In pipelined BFT, a malicious successor might try to abandon the predecessor to steal its value. MonadBFT closes that path: successors either extend the endorsed parent or provide costly, verifiable evidence (NEC) that extension is impossible. That is NTF. This is guaranteed by Lemma 4¹, which shows that once $≥2f+1$ validators vote for an honest block, all subsequent proposals must extend it.

Mechanism-design note. The NEC acts as a verifiable certificate of non-endorsement, which forces an extend-or-explain choice. As a result, the induced social choice rule $f:\Theta\to\text{Blocks}$ satisfies an ex-post incentive compatibility property (i.e., truth-telling remains optimal after all private information is revealed): for any type profile $\theta$, once an honest block collects $\ge 2f+1$ votes, no deviation can alter the outcome at that height without producing costly, public evidence (the NEC).

3.2 Accountable speculation (early confirmations revert only on equivocation)

The safety of the “early confirmation” fast path is captured by Theorem 2 (“Safety of Early-Confirmation”) together with Theorem 3 (“Safety”). The paper’s Corollary 1 states the operational headline: a speculative confirmation reverts only if there is accountable cryptographic evidence, e.g., leader equivocation (two conflicting signed proposals for the same view/sequence).

How the mechanism enforces it. Two ingredients:

1. Locking via QC. When a validator sees a QC for the predecessor, a strict majority of honest validators are already locked; there is no valid “override” in the same view. Acting speculatively is therefore safe.

2. Client threshold & rollback condition. Clients finalize only after receiving $2f{+}1$ same-view early confirmations. If a Byzantine leader equivocates and no branch reaches that threshold, nodes that speculated will revert only upon seeing cryptographic proof (the conflicting signed proposal). That evidence is slashable, so the revert is accountable.

Intuition. We trade latency for tightly scoped risk: “go fast” when a QC certifies the predecessor; if a revert happens, it must carry receipts (equivocation evidence). This couples any rollback to penalties, which we calibrate in the staking/slashing economics.

3.3 Optimistic responsiveness (progress at network speed after GST)

Theorem 4 (“Strong Liveness”) formalizes that, post-GST, progress happens at event speed: as soon as $2f{+}1$ responses arrive, the protocol advances, without waiting for a conservative wall-clock. Supporting timing lemmas include Lemma 7 (no QC+TC conflict post-GST), Lemma 9 (bounded-delay construction/propagation of NEC under unavailability), and Lemmas 10–11 (once TC/NEC conditions are met, all correct nodes converge and advance).

How the mechanism enforces it. Timeouts are aggregated into TCs when $2f{+}1$ arrive; TCs carry each validator’s tip, enabling a next-leader reproposal immediately from evidence rather than from fixed timers. NECs likewise provide succinct, verifiable signals to move forward under data-availability failure. The pacemaker is thus event-driven: it keys off quorum evidence, not long wall-clock cushions.

Intuition. Fixed “nearly $\Delta$” timers either leave performance on the table or incentivize edge-surfing. MonadBFT’s event-driven pacemaker moves at the network’s speed when healthy and falls back only on qualified, public evidence. That’s exactly what Theorem 4 asserts.

Where these three fit our mechanism agenda.

• Theorem 1 (NTF) is the backbone for our extend-or-explain policy in ordering (§5.1): it turns “reorg-for-MEV” into a dominated strategy once NECs are costly to fake.
• Theorem 2 / Theorem 3 + Corollary 1 (Accountable speculation) justify faster confirmation rules while ensuring that any rollback is accompanied by slashable receipts.
• Theorem 4 + Lemmas 7, 9, 10, 11 (Strong liveness / responsiveness) motivate the small pacemaker controller in §5.6: we can damp timing games without adding messages or weakening liveness.

We’ve now framed the mechanism and identified its security properties. Next, we attach those abstractions to specific files and lines in the MonadBFT codebase⁴. Each anchor below shows the exact implementation today, why it creates an incentive seam, and the smallest change that improves the game without changing MonadBFT’s message pattern.

4) Code → theory: precise touch points

Before we propose changes, we want to pin the abstract mechanism to exact lines in the repo. Each subsection below does three things in a few lines: (i) shows the specific code path that implements a protocol artifact, (ii) explains the mechanism-design pressure that arises there (incentives, predictability, public-goods leakage), and (iii) sketches the smallest design nudge that improves incentives without changing MonadBFT’s beautiful message pattern. Think of these as “surgical anchors”: we’re not rewriting consensus; we’re tightening seams that matter economically.

With that frame, the snippets below follow are not random examples, they’re the minimal places where a one-line seed, a price rule, or a small controller parameter changes the game the protocol is actually playing.

4.1 Leader selection (replayable and predictable → add VRF seed)

Deterministic PRNG helper (seeded by round):

// monad-validator/src/weighted_round_robin.rs
fn randomize(x: u64, m: u64) -> u64 {
    let mut gen = ChaCha20Rng::seed_from_u64(x);
    gen.gen_range(0..m)
}

Cumulative-stake sampling (u64 path):

// monad-validator/src/weighted_round_robin.rs (excerpt)
fn generate_random_validator_u64<PT: PubKey>(
    round: Round,
    validators: Vec<(&NodeId<PT>, &Stake)>,
) -> NodeId<PT> {
    let mut total_stakes = 0_u64;
    let stake_bounds = validators
        .iter()
        .filter_map(|&(node_id, stake)| {
            let stake_u64 = stake.0.to::<u64>();
            if stake_u64 > 0 {
                total_stakes = total_stakes
                    .checked_add(stake_u64)
                    .expect("total stake <= u64::MAX");
                Some((node_id, total_stakes))
            } else { None }
        })
        .collect_vec();
    // ... choose stake_index via randomize(round.0, total_stakes), then binary search ...
    // returns *stake_bounds[upper_bound].0
}

Interface + per-epoch branch (deterministic seeding by round.0):

// monad-validator/src/weighted_round_robin.rs
impl<PT: PubKey> LeaderElection for WeightedRoundRobin<PT> {
    type NodeIdPubKey = PT;

    fn get_leader(
        &self,
        round: Round,
        epoch: Epoch,
        validators: &BTreeMap<NodeId<PT>, Stake>,
    ) -> NodeId<PT> {
        if epoch < self.staking_activation {
            generate_random_validator_u64(round, validators.iter().collect_vec())
        } else {
            let mut gen = ChaCha20Rng::seed_from_u64(round.0); // deterministic, computable schedule
            let randomizer = |total_stake| randomize_256_with_rng(&mut gen, total_stake);
            generate_random_validator_with_randomizer(validators.iter().collect_vec(), randomizer)
        }
    }
}

Why this matters economically. The allocation rule is stake-proportional (cumulative bounds). The information structure is the seed. Seeding ChaCha20 with a public $\texttt{round.0}$ makes the entire leader schedule computable ex-ante. Replayability is good; predictability invites pre-positioned MEV and targeted DoS against upcoming leaders.

Minimal mechanism nudge. Keep the sampling code; swap the seed. Derive a per-epoch VRF seed from the prior epoch’s QC/TC transcript (verifiable ex-post), and feed that into ChaCha20 for per-round draws. You retain replay/debug determinism after the fact, but raise ex-ante min-entropy.

Lemma (next-leader min-entropy, informal). With adversarial stake share $\alpha$ and $k$ independent honest contributions to the epoch seed, \(H_\infty\!\big(\ell(v)\mid \mathcal{I}_A\big) \ge \log \frac{1}{\alpha+\varepsilon(k)}\) for negligible $\varepsilon(k)$. Effect: schedule remains reconstructible; future leadership becomes hard to front-run.

Evaluation: see §5.2 (Leader Selection).

4.2 Transaction ordering (first-price priority → batch auction + order-commit)

Current priority rule (first-price by tip-per-gas, then gas limit):

// monad-eth-txpool/src/pool/tracked/sequencer.rs
impl<'a> Ord for OrderedTx<'a> {
    fn cmp(&self, other: &Self) -> Ordering {
        (self.effective_tip_per_gas, self.tx.gas_limit())
            .cmp(&(other.effective_tip_per_gas, other.tx.gas_limit()))
    }
}

Why this matters economically. This is a clean first-price priority mechanism. It is not DSIC: users shade bids; leaders can capture reordering rents; searchers can frontrun. Safety is fine, but welfare and perceived fairness suffer.

Minimal mechanism nudge. Treat a block as a batch: (i) bind an ordering permutation before plaintext (commit-and-reveal or per-tx blinding); (ii) clear a single price for included txs (uniform clearing tip or VCG-like payments); (iii) add a modest audit penalty for gratuitous divergence from committed arrival.

Lemma (truthfulness under IPV, informal). Under independent private values, batch allocation with a uniform clearing price is DSIC/BNE (depending on details), and the expected reorder profit is upper-bounded by the calibrated audit penalty. Effect: less MEV variance, steadier fees, validator revenue preserved via the clearing price.

Evaluation: see §5.1 (Ordering & MEV).

4.3 Pacemaker timing (static edge → strategy-proof controller)

Current timeout calculation:

// monad-consensus/src/pacemaker.rs
fn get_round_timer(&self, round: Round) -> Duration {
    self.delta * 3 + vote_delay + self.local_processing
}

Why this matters economically. Fixed edges invite “almost-too-late” coalition timing: vote just shy of the timer to bias who proposes next, fattening latency tails without crossing slashing lines.

Minimal mechanism nudge. Add a tiny feedback controller per node to estimate local conditions and penalize systematic clustering of late votes in TC formation: \(\theta_{v+1} = (1-\alpha)\,\theta_v + \alpha\,\widehat{\Delta}_v + \beta\,\widehat{v}_v\) and lightly down-weight clustered near-deadline votes when aggregating timeouts (no new threshold, just statistical discounting).

Lemma (delay-to-bias dominated, informal). With suitable $(\alpha,\beta)$ and TC weighting, systematic almost-late voting is strictly dominated (higher TC risk / lower expected payoff), while $P99$ commit latency improves. Effect: better tails, unchanged message pattern.

Evaluation: see §5.6 (Pacemaker).

4.4 Staking flows (where we calibrate strict honesty)

There are two distinct “stake” touch points, serving different purposes:

1. Leader allocation weights (probability): implemented by the cumulative-stake sampling in weighted_round_robin.rs (see §4.1). This decides who gets to lead.

2. Payouts/penalties plumbing (payoff): implemented via system transactions that mint rewards (and are the natural home for eligibility gates/penalties).

Rewards plumbing (the enforcement hook):

// monad-system-calls/src/lib.rs
system_calls.push(SystemCall::StakingContractCall(
    StakingContractCall::Reward { block_author_address, block_reward },
));

Why this matters economically. Allocation (4.1) sets leadership probabilities; enforcement sets incentives. We co-tune equivocation slash $\phi$ and a reward-ineligibility window $\omega$ so that, even with liquid staking or external credit, deviation is strictly unprofitable in discounted utility for a long-lived validator:

where $\delta\in(0,1)$ is the per-view discount factor and the $\omega$ -length ineligibility window reduces post-slash utility $\mathbb{E}[u_i^{\text{post-slash}}]$ via foregone rewards. This converts “follow the spec” from a weak best response to a strict one, without touching message complexity.

Evaluation: see §5.3 (Staking).

4.5 RaptorCast (robust path, public-goods economics)

The receive path already drops malformed/undersized chunks and enforces group membership in the UDP pipeline (good security posture). The economics of forwarding, however, are a public-goods problem: rational nodes may under-relay under load.

Minimal mechanism nudge. Add witnessed-work receipts plus sparse audits: each forward emits a tiny receipt; a verifier audits with probability $q$. Honest forwarding earns a micro-reward $\rho$ on audited-true; audited-false/missing burns a small relay bond $b$.

Design inequality (dominance condition). \(q\rho > c \quad\text{and}\quad q b \ge \text{max spoof gain},\) where $c$ is per-chunk relay cost. Choose $q$ so $q\rho$ is negligible overhead but still deters shirking.

Lemma (relay strictly dominates shirking, informal). If $q\rho>c$ and $qb$ covers spoofable gains, honest forwarding maximizes expected payoff; overhead $q\rho$ remains tiny. Effect: higher decode success under stress with minimal new plumbing (receipts can be batched or recorded in block metadata).

Evaluation: see §5.4 (RaptorCast).

5) Six research problems we’ll tackle (expanded mechanism targets)

5.1 Ordering & MEV: from first-price priority to batch truthfulness

Monad’s txpool currently implements a clean “tip-per-gas then gas-limit” priority order. It’s simple and fast, but economically it’s a first-price auction: users shade bids, frontrunning is profitable, and leaders can earn reordering rents. None of that breaks safety, but it degrades welfare and perceived fairness.

// monad-eth-txpool/src/pool/tracked/sequencer.rs
impl<'a> Ord for OrderedTx<'a> {
    fn cmp(&self, other: &Self) -> Ordering {
        (self.effective_tip_per_gas, self.tx.gas_limit())
            .cmp(&(other.effective_tip_per_gas, other.tx.gas_limit()))
    }
}

Mechanism target. Treat each block as a batch: bind an order before plaintext or with per-tx blinding; clear a single price $p^*$ for all included transactions; penalize gratuitous divergence from committed arrival. Let $\pi$ be the final ordering, $\text{arrival}$ the committed permutation, $d(\cdot,\cdot)$ a permutation distance (e.g., Kendall-$\tau)$. The proposer maximizes \(\sum_{i\in \pi} (v_i - p^*)\,\text{gas}_i \;-\; \Lambda\, d(\pi,\text{arrival}) \quad \text{s.t.}\quad \sum_{i\in \pi}\text{gas}_i \le G,\) with $\Lambda$ calibrated to swamp reordering rent.

Why it exists. First-price is not DSIC; it invites strategic bidding and opportunistic reordering. Batch + single clearing price (or VCG-like payments) restores truthful revelation under IPV assumptions and reduces MEV externalities while preserving validator revenue via the clearing price.

What we’ll prove/measure. Existence of DSIC (or BNE) allocation under IPV; a bound $\mathbb{E}[\text{reorder profit}] \le C/\Lambda$; on-chain metrics: MEV per block, Kendall-$\tau$, inclusion-delay Gini, user surplus. Engineering risk is complexity (commitments, audits); we’ll start with minimal commit-and-reveal that doesn’t touch consensus messages.

5.2 Leader selection: keep replayability, add min-entropy

Leader selection today is replayable by design: ChaCha20 seeded from round.0 ensures anyone can reconstruct who should have led a given view. Replayability is a feature. The cost is predictability: coalitions can forecast leadership windows and stage order-flow or denial-of-service tactics around them.

// monad-validator/src/weighted_round_robin.rs
let mut gen = ChaCha20Rng::seed_from_u64(round.0);
let randomizer = |total_stake| randomize_256_with_rng(&mut gen, total_stake);

Mechanism target. Replace the round seed with an epoch-seeded VRF derived from the prior epoch’s QC/TC transcript; keep stake-weighted selection. Everyone verifies ex-post; ex-ante min-entropy rises.

Formal goal (informal). With adversarial stake share $\alpha$ and $k$ independent honest contributions to the epoch seed, \(H_\infty(\ell(v)\mid \mathcal{I}_A) \ge \log\frac{1}{\alpha+\varepsilon(k)}, \quad \varepsilon(k)\to 0.\) This caps a coalition’s ability to “call the next leader,” while preserving the debug/replay story.

What we’ll measure. Predictability score versus round-seed baseline; self-lead run-lengths; reward variance. Trade-off: a small amount of seed plumbing (still no extra consensus messages).

5.3 Staking & slashing: make honesty a strict best response

The system already mints rewards via system transactions; that’s our lever for making misbehavior uneconomic.

// monad-system-calls/src/lib.rs
system_calls.push(SystemCall::StakingContractCall(
    StakingContractCall::Reward { block_author_address, block_reward },
));

Mechanism target. Co-tune an equivocation slash $\phi$ and a reward-ineligibility window $\omega$ (optionally stake aging $\eta(t)$) so that for any validator $i$, \(\mathbb{E}[\text{MEV}_i(\text{equivocation/timing})] < \phi s_i + \mathbb{E}[\text{lost rewards under }\omega].\) We treat liquid staking and cheap external credit explicitly in the model; the inequality must hold even with such overlays.

Why it exists. Without strict dominance, a well-capitalized coalition can rationalize short-lived faults when MEV is spiky. Tightening $\phi$ and $\omega$ makes the expected value negative, converting “honest” from weakly optimal to strictly optimal.

What we’ll measure. Observed equivocation frequency (should be zero, but we track); time-at-risk windows; cost of capital sensitivity. Trade-off: slashes must be severe enough to deter, but not so severe they cause cascading bankruptcies; we’ll explore insurance-style caps.

5.4 RaptorCast relays: pay for witnessed work, punish spoofing lightly

RaptorCast’s receive path is robust (early drops for malformed/spoofed chunks, group checks), but forwarding is a public good. Under stress, rational nodes may under-relay.

Mechanism target. Add witnessed-work receipts and sparse audits: a forwarding node emits a signed receipt; a verifier randomly audits a tiny fraction $q$. Honest forwarding earns a small reward $\rho$ upon audited-true; audited-false/missing burns a small relay bond $b$.

Design inequality. Honest forwarding strictly dominates if \(q\rho > c \quad \text{and} \quad qb \ge \text{max spoof gain},\) where $c$ is per-chunk cost. Choose $q$ so $q\rho$ is negligible overhead and liveness still improves under load.

What we’ll measure. Chunk receipt rates; reconstruction latency $P95/P99$; audit failure rate; overhead. Trade-offs: tiny accounting channel and bond management, kept off the hot path; receipts can be batched or folded into block metadata.

5.5 Peer Discovery: small answers, big consequences (design for expansion)

Peer discovery’s responses are intentionally small (≤16 peers) and prune unresponsive nodes, good operational hygiene. Economically, a small answer budget makes every neighbor slot precious; naïve selection can entangle honest nodes in adversarial neighborhoods.

Mechanism target. Choose neighbors to maximize diversity/expansion, across stake pools, ASNs, geography, paired with a costly identity (stake/work) so large Sybil surfaces are expensive. The goal is an overlay that behaves like an expander from the honest region’s view.

Formal goal (informal). With answer budget $d$ and diversity score $\lambda$,

where $\sigma$ is adversarial identity weight and $w_H$ the honest diversity weight. The exponential term reflects expansion from diversity-aware selection.

What we’ll measure. Neighbor diversity indices; simulated eclipse probability; convergence time after churn. Trade-off: slightly more logic in the peer picker; same wire footprint.

5.6 Pacemaker: a small controller that makes delay-games not pay

The current timer combines a multiple of $\Delta$ with vote pacing and local processing, sensible and clear.

// monad-consensus/src/pacemaker.rs
fn get_round_timer(&self, round: Round) -> Duration {
    self.delta * 3 + vote_delay + self.local_processing
}

But static edges invite “almost-too-late” voting patterns that fatten tails without crossing obvious slashing lines.

Mechanism target. Fit a local feedback controller for the timeout, \(\theta_{v+1}=(1-\alpha)\theta_v+\alpha,\widehat{\Delta}_v+\beta,\widehat{v}_v,\) with clipping/hysteresis, and discount clustered late votes when assembling TCs (light, statistical weighting, not a new threshold).

Formal goal (informal). There exist $(\alpha,\beta)$ such that (i) the strategy “systematically vote at $>0.9\theta$” is strictly dominated in expected payoff (higher TC probability + penalty risk), and (ii) $P99$ commit latency improves without oscillations.

What we’ll measure. View-reset rate; $P95/P99$ commit latency; a “late-vote clustering” index pre/post. Trade-off: parameter tuning; we’ll provide safe defaults and guardrails.

Every mechanism above is local: it doesn’t introduce all-to-all communication or heavier certificates. The happy path remains linear. Each mechanism tightens one incentive seam (ordering, timing, schedule predictability, public-goods forwarding, neighbor quality, slashing economics) while preserving MonadBFT’s core promise: reverts come with accountable receipts. And each proposes precise, falsifiable metrics so the series earns its claims empirically, not just rhetorically.

6) Next up

Part 2 — Ordering & MEV. We’ll specify the batch auction + order-commit mechanism, give a truthfulness sketch, calibrate the audit penalty, and include a small agent-based sim spec you can run locally. The goal isn’t to “solve MEV” but to make a measurable dent in its worst pathologies without breaking validator economics, or MonadBFT’s beautiful message pattern.

References

Appendix: direct repo anchors

• Leader selection (replayable PRNG): monad-validator/src/weighted_round_robin.rs (seed_from_u64(round.0); randomize_256_with_rng).
• Txpool ordering: monad-eth-txpool/src/pool/tracked/sequencer.rs (Ord by effective_tip_per_gas then gas limit).
• Pacemaker timer: monad-consensus/src/pacemaker.rs (get_round_timer: 3*Δ + vote_pace + local_processing).
• Staking system calls: monad-system-calls/src/lib.rs (epoch change, snapshot, reward issuance).
• RaptorCast checks: monad-raptorcast/src/udp.rs (undersized/oversized drops, spoof checks, group membership).
• Peer discovery: docs/peer_discovery.md (bounded answers; liveness-based pruning).