Direction is right — txPolicyRejectedCache short-circuits redundant policy work from peer-validated rejections. Three things worth resolving before merge:

• Integration test checkboxes in PR body remain unchecked despite the 5 fixup commits. Worth confirming they pass before re-requesting review.
• Cache uses random eviction. Under an adversarial peer sending high volumes of distinct policy-rejected tx hashes, the cache thrashes and provides no hit-rate guarantee — turning the optimization into pure overhead at exactly the load where it's supposed to help. Consider size-bounded FIFO or LRU, or document the eviction strategy + assumed attack model explicitly.
• policyRejectedTxMessageHandler validates the hash before insert (good) but has no rate-limit on the Kafka consumer. A flood of KAFKA_TX_POLICY_REJECTED messages can spike GC pressure and starve the cache anyway. Worth a sentence in the longdesc on expected message volume + a note if backpressure handling lives elsewhere.

Re-review against 75958f0de. The prior Critical (320 MB → broker) is genuinely fixed, consensus/validation equivalence checks out (cached txs are re-blessed from scratch — the cache can't launder an invalid tx or substitute a conflicting one), and cache-poisoning is soundly defended. Two load/DoS issues block.

P1 — the "64 MB" cache bound is entry-count, not bytes (policy_rejected_tx.go:34-47). maxSize = maxBytes/500 evicts on entry count, but each entry holds a *bt.Tx up to 1 MB. At default 64 MB that's ~131k entries → ~187–256 MB under normal traffic, and ~128 GB under an adversarial flood of distinct ~1 MB policy-rejected txs → pod OOM. The setting longdesc says "maximum memory in MB"; it isn't. Track cumulative tx.Size() and evict by bytes, or rename to …MaxEntries and fix the "max %d MB" log line. (This is the real form of the earlier eviction concern — wrong dimension, not wrong order; eviction order is fine.)

P1 — producer publish is unsafe under load (Validator.go:~503-544). (a) Publish(...) is a blocking channel send on the validator hot path — under Kafka backpressure it stalls validateTransaction; make it non-blocking drop-on-full (cache is best-effort, a drop just falls back to the HTTP fetch path). (b) No catchup/FSM gate — it floods Kafka on every policy rejection during CATCHINGBLOCKS/LEGACYSYNCING, where the sibling rejected-tx producer deliberately stays quiet; gate it behind the same FSM check.

Minor: the consumer's "single goroutine / natural backpressure" comment is inaccurate (goroutine-per-partition-per-fetch); integration-test checkboxes still unchecked (lookup-before-fetch has no test).

Re-review against aa77c5fb0. Both P1s from the prior pass are fixed and verified against current code (Go mechanics + load + offensive re-attack):

• B1 (cache OOM) — cache is now a true cumulative-byte bound (policy_rejected_tx.go: curBytes/maxBytes, evict by tx.Size()). The ~128 GB distinct-1MB-flood vector is gone; TestTxPolicyRejectedCache_BoundedByBytes pins the invariant and a concurrent-flood probe held under -race.
• B2 (publish unsafe) — publish is non-blocking TryPublish (drop-on-full, lossless → HTTP fetch) and FSM-gated during CATCHINGBLOCKS/LEGACYSYNCING via a cached atomic read. No hot-path stall, no catchup flood.

Not blocking, but worth addressing before merge:

• Memory-sizing honesty. curBytes counts serialized tx.Size(), not the retained *bt.Tx+map heap — measured ~2.75× for large txs, ~6–7× for small. At the 64 MB default that's ~440 MB actual RSS under typical traffic. The longdesc still says "maximum memory in MB"; tighten the default or state the multiplier so operators don't undersize pod limits.
• Validator.go:567 serializes + marshals (~2 MB) before the TryPublish drop check. Under sustained backpressure that's dead allocation per rejected tx. Defer the marshal until after confirming buffer space.
• Producer/consumer size caps mismatch: KafkaMaxMessageBytes = 1,048,576 vs maxCachedTxBytes = 1,000,000. A tx in the 1,000,001–1,048,576 B band passes the producer guard, publishes, then gets silently dropped consumer-side — wasted publish + guaranteed cache miss. Derive one from the other.
• The B2 fixes aren't unit-tested — TestPublishPolicyRejectedTx nils blockchainClient (skips the FSM gate) and the mock TryPublish always returns true (skips drop-on-full). Cache-poisoning hash-mismatch (PF6) still has no direct test; the defense itself is present and correct.