[heemankv]

Summary

• pin Blockifier to the organization-owned madara-alliance/sequencer branch at 599710cebca0c6aa30f9888d26c291c02e9ee76a
• configure a max_snos_full_output_cells admission limit, defaulting to 49,000 cells
• close a non-empty block before admitting a transaction whose predicted full SNOS output would cross the limit, leaving that transaction for the next block
• terminally reject a transaction that exceeds the limit even in an otherwise empty block, preventing a permanent block-production loop
• preserve the terminal error through transaction submission and expose the setting in every chain preset/template

Sequencer implementation: madara-alliance/sequencer#1

Transaction rollover behavior

The devnet regression test submits five transactions with execution batches of two. Transactions 1–3 fit in block 1. Transaction 4 would take block 1 over its scaled test limit, so block 1 closes and transaction 4 is retried in block 2. Transaction 5 likewise moves to block 3. The persisted split is:

• block 1: T1, T2, T3
• block 2: T4
• block 3: T5

No transaction is lost, and the mempool drains.

Tests

• cargo test -p blockifier snos_output -- --nocapture — 5 passed
• cargo test -p mc-block-production snos -- --nocapture — 2 passed
• cargo fmt --all -- --check
• cargo metadata --locked --no-deps --format-version 1

[greptile-apps]

Confidence Score: 4/5

[High impact] Updates core block production constraints and dependencies.

The required regression tests should be added before merging.

_{Reviews (1) · Last reviewed commit: "feat(block-production): enforce SNOS out..." · Reviewed by Greptile}

[greptile-apps]

Key admission cases lack tests

Both new execution tests disable concurrency and only use transactions that eventually fit. The rejection tests construct TransactionTooLargeForProof directly, so they do not prove that a real oversized transaction is consumed once and lets healthy work continue.

The repository requires tests for critical block-production changes. Before merging, add an oversized transaction followed by healthy work, and cover the admission cases with concurrency enabled—the production default. Assert that the oversized transaction is not retried and the mempool drains.

Rule Used: # Madara PR Review Instructions ## Role You are reviewing a PR for Madara, a Starknet sequencer and its adjacent orchestrator stack. Prioritize correctness, protocol compliance, safety, operability, and long-term maintainability over style. Do not... (source)

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[heemankv]

Validated optimization update (PC Mainnet shadow replay, 2026-10-22):

• Pins madara-alliance/sequencer@1e9828e (incremental, rollback-safe SNOS accounting).
• Restores the required predictor seed after the block_n-10 write, preventing the previously observed 3/6-cell undercount.
• Controlled replay: identical blocks 2909844..2909847, 220 transactions, all four canonical hashes matched.
• With the existing Madara execution read cache allowlisted to 0x2 (64 MiB), warm SNOS admission fell from 27.251 ms/tx to 0.424 ms/tx (98.45%, 64.3x), or 0.72% of measured transaction time.
• Final prediction deltas were +3, +15, +6, +6 cells; zero undercounts.
• Optimized finalization averaged 34.509 ms/block.

Validated image: ghcr.io/madara-alliance/madara:manual-025b2c2@sha256:81dc3f5193b9f12a0a3999b40819d64f00bcfa781551eac9410a905a908e2ccb (manual run 39764449921, skip-cargo-check=true). Profiling/replay-only code is not included in this PR branch.