PRAC: Exact Per-Row Activation Counting in DDR5

• PRAC is a DDR5 architectural framework that adds an exact per-row activation counter to trigger refreshes via the ABO protocol before dangerous activation thresholds are reached.
• It replaces approximate tracking with precise, per-row counting, enabling more accurate and timely mitigation of RowHammer-induced disturbances.
• Implementations like MOAT, QPRAC, and PRACtical illustrate varied trade-offs in performance, energy overhead, and security based on counter update and mitigation scheduling choices.

Searching arXiv for recent PRAC and related RowHammer papers to ground the article in current literature. Per-Row Activation Counting (PRAC) is a DDR5 and future-DRAM architectural framework, defined by JEDEC JESD79-5C, that equips each DRAM row with an activation counter and couples those counters to the Alert Back-Off (ABO) protocol and RFM commands so that read-disturbance mitigation can be triggered before an aggressor reaches a dangerous activation count. In recent literature it is treated as the industry-standard, state-of-the-art RowHammer mitigation framework because it replaces small, easily thrashed tracker tables with exact per-row counting inside DRAM, but the same literature also stresses that PRAC is a framework rather than a complete defense: its security, performance, energy, and even side-channel behavior depend on how counters are updated, how rows are selected for mitigation, and how RFMs are scheduled (Woo et al., 31 Jan 2025, Yuksel et al., 15 Jun 2025).

1. Standardized role and architectural scope

PRAC is presented as a DDR5 architectural extension that adds a per-row activation counter to every DRAM row and an ABO signaling path from DRAM to the memory controller. Its purpose is to count the number of ACTIVATEs to each row during a vulnerable interval and to trigger protective refresh of potential victim rows before any aggressor row reaches a read-disturbance threshold. This makes PRAC fundamentally different from DDR4-style TRR mechanisms and other small-table in-DRAM trackers, which monitor only a limited set of suspect rows and can be thrashed by many-aggressor patterns (Woo et al., 31 Jan 2025, Qureshi et al., 2024).

The literature also distinguishes PRAC from earlier controller-driven RFM policies. In controller-driven periodic RFM schemes, the controller tracks bank-level activity and issues mitigation windows after aggregate thresholds are reached. PRAC instead places exact per-row counters in DRAM and lets the DRAM request mitigation when needed through ABO. This shift from approximate or aggregate tracking to exact per-row counting is the reason PRAC is described as a holistic mitigation framework for ultra-low RowHammer thresholds (Woo et al., 31 Jan 2025, Canpolat et al., 2024).

Architecturally, the framework specifies what must be counted and how mitigation is requested, but it does not fully specify how rows are prioritized for mitigation, how counters are organized internally, or how resets should interact with refresh and recovery. That omission is central in the later literature: MOAT, QPRAC, Chronus, PRACtical, CnC-PRAC, TPRAC, and AutoPRAC all study different realizations of the same standardized substrate rather than proposing entirely separate interfaces (Qureshi et al., 2024, Woo et al., 31 Jan 2025, Nazaraliyev et al., 24 Jul 2025, Lin et al., 13 Jun 2025, Woo et al., 15 May 2025, Qu et al., 22 Jun 2026).

2. Counting semantics, thresholds, and the ABO/RFM protocol

At the conceptual level, PRAC maintains a counter $C_r$ for each row $r$, incremented on each ACT to that row, and uses a threshold $N$ or RDT to decide when mitigation must begin. The basic safety intent is captured in the inequality

$$\mathrm{ACT\_count}(r) < \mathrm{RDT} \le HC_{\min},$$

where $HC_{\min}$ is the lowest measured hammer count that induces the first bitflip in the relevant technology (Yuksel et al., 15 Jun 2025). QPRAC expresses the same threshold as a Back-Off threshold $N$ constrained by

$N \leq T,$

where $T$ is the RowHammer threshold (Woo et al., 31 Jan 2025).

The protocol visible at the controller is ABO plus RFM. When a row counter reaches the threshold, DRAM raises Alert. JEDEC allows the controller to continue issuing up to 3 ACTs, corresponding to a max delay of 180 ns, before it must send RFMs. The standard configuration space then specifies 1, 2, or 4 RFMs per Alert, commonly written as PRAC-1, PRAC-2, and PRAC-4. JEDEC currently defines All-Bank RFM, so the controller cannot identify which bank raised the Alert and must issue RFM to all banks (Woo et al., 31 Jan 2025). The literature in these papers uses both “Refresh Management” and “Row Function Management” for RFM, but in both cases the command is the standardized mitigation window through which the DRAM refreshes potential victims (Woo et al., 31 Jan 2025, Yuksel et al., 15 Jun 2025).

Although the architectural description is ACT-centric, several implementation studies model the physical counter increment as a read-modify-write associated with PRE. In those analyses, PRAC lengthens $t_{RP}$ and $t_{RC}$: one study reports $r$0 increasing from 16 ns to 36 ns and $r$1 from 48 ns to 52 ns (Woo et al., 17 May 2026); another gives PRAC timings of $r$2 ns and $r$3 ns (Qureshi et al., 2024). This implementation choice is important because it turns exact counting into a persistent latency and energy cost even when no Alert fires.

3. Security guarantees, formal limits, and failure modes

PRAC is exact in the sense that every row is counted, but exact counting alone is not a proof of safety. The literature repeatedly emphasizes that PRAC is only a framework and that security depends on how the DRAM chooses rows for mitigation, how ABO slack is handled, and how counters are reset (Qureshi et al., 2024). Idealized analyses show that even a perfect PRAC implementation is fundamentally constrained by the non-blocking ABO protocol. For $r$4, the minimum secure threshold is $r$5 for PRAC-1, $r$6 for PRAC-2, and $r$7 for PRAC-4 (Woo et al., 31 Jan 2025). A separate system-level analysis concludes that PRAC can be configured for secure operation as long as no bitflip occurs before accessing a memory location 10 times (Canpolat et al., 2024).

The best-known secure realizations therefore add explicit selection logic on top of exact counters. QPRAC uses a priority-based service queue and analytically shows that, with $r$8, PRAC-1 is secure at $r$9 without proactive mitigation and at $N$0 with proactive mitigation (Woo et al., 31 Jan 2025). MOAT instead uses dual thresholds, ETH and ATH, and argues that $N$1 can safely tolerate a Rowhammer threshold of 99 once the allowed inter-Alert activations are incorporated into the analysis (Qureshi et al., 2024).

The same body of work also shows how naïve PRAC realizations fail. Panopticon-style FIFO service queues are vulnerable to Toggle+Forget, Fill+Escape, and Jailbreak patterns because non-blocking ABO lets an attacker exploit a full queue or a stale threshold transition to accumulate many unmitigated activations (Woo et al., 31 Jan 2025, Qureshi et al., 2024). UPRAC avoids the FIFO pathology by mitigating the top activated rows, but QPRAC argues that this requires impractical global scanning of all counters on every Alert unless additional selection structures are introduced (Woo et al., 31 Jan 2025). AutoPRAC later formalized this concern by modeling PRAC designs as bounded state machines and found a previously unreported flaw in MOAT’s counter-reset policy that allows up to 34 activations to go undetected above the Rowhammer threshold (Qu et al., 22 Jun 2026). The cumulative implication is that PRAC’s correctness burden lies less in counting than in mitigation scheduling and reset semantics.

4. Representative realizations of the PRAC framework

Concrete PRAC designs differ mainly in three places: how activation counts are updated, how candidate rows are chosen for mitigation, and how much controller-visible stall is introduced during recovery. Several designs have become reference points in the literature.

Mechanism	Defining idea	Selected reported outcome
MOAT (Qureshi et al., 2024)	Dual thresholds $N$2 and $N$3, with CTA/CMA tracking	$N$4 can safely tolerate a Rowhammer threshold of 99; 0.28% average slowdown; 7 bytes of SRAM per bank
QPRAC (Woo et al., 31 Jan 2025)	Priority-based Service Queue with opportunistic and proactive mitigation	secure at $N$5 without proactive mitigation and $N$6 with proactive mitigation; 0.8% slowdown, reduced to 0% with proactive mitigations
PRACtical (Nazaraliyev et al., 24 Jul 2025)	Subarray-level counter update overlap plus bank-level recovery isolation	improves performance by 8% on average, up to 20%; reduces energy by 19%
CnC-PRAC (Lin et al., 13 Jun 2025)	Buffered, reordered, and coalesced counter-row accesses	reduces counter-row activations by almost 75%-83%; dynamic energy overhead of 0.84%-1%

MOAT and QPRAC both keep the exact per-row semantics of PRAC but differ in mitigation policy. MOAT minimizes SRAM and uses dual thresholds, while QPRAC uses a small per-bank priority queue that continually tracks the highest-count rows and couples that queue to both ABO-driven and refresh-driven mitigations (Qureshi et al., 2024, Woo et al., 31 Jan 2025). PRACtical focuses on the implementation cost of the standardized mechanism itself: it overlaps counter updates with activity in other subarrays and changes recovery from channel-wide to bank-level granularity through a DRAM-resident bank register, while preserving the same security guarantees (Nazaraliyev et al., 24 Jul 2025). CnC-PRAC retains a dedicated counter subarray but argues that coalescing, rather than caching, counter updates is the more effective path to negligible slowdown and minimal dynamic energy (Lin et al., 13 Jun 2025).

Taken together, these designs show that the “PRAC framework” has become a family of microarchitectural policies layered on the same standard interface. This suggests that PRAC is best understood as a standard counting-and-signaling substrate whose practical properties are determined by queue discipline, update path, and recovery granularity rather than by per-row counters alone.

5. Overheads, timing channels, and observability

The strongest critique of PRAC in the recent literature is that exactness is expensive. One study models a QPRAC implementation of PRAC and reports that the required counter read-modify-write increases $N$7 from 16 ns to 36 ns and $N$8 from 48 ns to 52 ns, yielding roughly 14% average slowdown and 21.8% slowdown on high-memory-intensity workloads, largely independent of the RowHammer threshold (Woo et al., 17 May 2026). A broader analysis of emerging DDR5 read-disturbance solutions reports that PRAC incurs less than 13% performance overhead for today’s DRAM chips, but that the overhead can reach up to 94% for future chips, and that an availability-oriented adversarial pattern can hog up to 94% of DRAM throughput and degrade system throughput by up to 95% (Canpolat et al., 2024).

PRAC also introduces new observability. PRACLeak shows that the ABO protocol and RFM commands create a timing channel because activity-dependent RFMs stall the channel in a way that any co-located observer can measure. The paper demonstrates covert channels and an AES side-channel attack, then proposes Timing-Safe PRAC (TPRAC), which replaces activity-triggered recovery with Timing-Based RFMs, uses a single-entry in-DRAM mitigation queue per bank, and closes the timing channel while incurring 3.4% performance overhead at the RH threshold of 1024 (Woo et al., 15 May 2025). This establishes that the main confidentiality risk in PRAC is not the counter itself but the externally visible timing of mitigation.

A distinct line of work treats that observability as useful rather than harmful. HammerWatch uses PRAC-derived ABO events together with ECC Machine-Check Exceptions as attested evidence of RowHammer-like behavior. In its evaluation, a prover is classified as compromised if it shows more than 3 ABO alerts or more than 3 MCEs, and the system reports 0 false positives and 0 false negatives over 20000 simulated benign and malicious access patterns (Herrmann et al., 25 Mar 2026). A plausible implication is that PRAC’s event visibility is dual-use: the same back-off behavior that enables timing leakage can also serve as a trusted detection signal when protected by a TPM-anchored measurement chain.

6. Extensions, critiques, and position in the RowHammer design space

PRAC’s original design assumes single-row activation, but later work shows that this assumption does not survive all emerging DRAM usage modes. PuDHammer studies multiple-row activation in Processing-using-DRAM and adapts PRAC in two directions: PRAC-AO, which updates multiple counters sequentially and blocks a bank for $N$9, and PRAC-PO, which updates multiple counters in parallel. Because measured vulnerability differs sharply across RowHammer, CoMRA, and SiMRA, the paper introduces weighted counting in which RH contributes $$\mathrm{ACT\_count}(r) < \mathrm{RDT} \le HC_{\min},$$0, CoMRA $$\mathrm{ACT\_count}(r) < \mathrm{RDT} \le HC_{\min},$$1, and SiMRA $$\mathrm{ACT\_count}(r) < \mathrm{RDT} \le HC_{\min},$$2 per participating row, while keeping a single global threshold near 4000. Even with this optimization, PRAC-PO-Weighted Counting incurs 48.26% average performance loss and 98.83% worst-case slowdown across the evaluated PuD intensity range (Yuksel et al., 15 Jun 2025). This suggests that exact per-row counting remains principled under multiple-row activation, but its cost can become prohibitive when disturbance semantics change.

A more structural critique comes from PVAC, which argues that PRAC tracks the aggressor while the physical failure is victim-side. PVAC observes that PRAC increments counters on every activation, including REF and RFM-induced ACTs, and resets them only during RFM, so counters can saturate even in an idle bank and trigger cascading mitigations. PVAC replaces aggressor counting with per-victim-row hammered counting, resets the activated row’s counter, increments counters of victim rows, and uses a dedicated counter subarray to perform updates concurrently with normal accesses. The paper claims that, through victim-based counting, PVAC supports higher hammering tolerance than PRAC while maintaining the same worst-case safety guarantee and avoids spurious Alerts and PRAC timing penalties (Kim et al., 22 Apr 2026). Whether that model should be regarded as an extension of PRAC or a competing semantic replacement is a central current debate.

PRAC also now serves as the main point of comparison for approximate and probabilistic alternatives. CoMeT characterizes “classic PRAC” as exact per-row activation counting and replaces it with Count-Min-Sketch-based row tracking plus a small exact table for hot rows, reporting 4.01% average slowdown at a RowHammer threshold of 125 and 74.2x smaller area than the best-performing state-of-the-art mitigation it compares against (Bostanci et al., 2024). PrISM, by contrast, treats PRAC as the precise DDR5 baseline and argues that probabilistic intersection-based sampling can avoid per-row counters entirely: at threshold 500 it reports 0.2% average slowdown compared to 14% for PRAC (Woo et al., 17 May 2026). This suggests that PRAC has become the reference exact mechanism against which both low-area approximate counting and low-overhead probabilistic sampling are measured.

In that broader design space, PRAC occupies the deterministic, exact-counting end of the spectrum. Its strengths are exact per-row visibility, compatibility with JEDEC standardization, and the ability to support formal worst-case reasoning at low thresholds. Its recurring weaknesses are counter-update overhead, all-bank recovery cost, sensitivity to queue and reset design, and externally visible timing effects. The central research trajectory since DDR5 standardization has therefore been to keep PRAC’s exactness while reducing these costs or, where that proves too expensive, to preserve its security objective with victim-side semantics, approximate shared counters, or probabilistic mitigation policies (Nazaraliyev et al., 24 Jul 2025, Lin et al., 13 Jun 2025, Kim et al., 22 Apr 2026, Bostanci et al., 2024, Woo et al., 17 May 2026).