Introduction

Executive summary. This report studies the counting factor $q$ that appears in [1.0.0][Analysis] Total Stake Inference. We define $q$ as the conditional probability that an active slot is ultimately counted under a specified measurement rule. The main goal is to replace a purely empirical calibration view of $q$ in previous analysis with a mathematically interpretable one. This shifts the question from “which value of $q$ best fits simulation?” to “what mechanism determines whether an active slot is eventually counted?”. Something about q and network delays.

For chain-only counting, the starting point is a “local vulnerability-window” model. We use $Δ≥1$ as a deterministic slot-offset delay: a block produced in slot s first becomes usable for fork choice in slot $s+Δ$. Under this convention, the block is not yet usable during the intermediate future slots $s+1,...,s+Δ−1.$ Hence the induced local vulnerability window has length $L := Δ−1$. If future slots are independently active with probability $f$, then the local survival/counting probability is $q_{\text{local}} = (1−f)^L = (1−f)^{Δ−1}$.

This formula explains why delay lowers $q$: a larger vulnerability window makes it more likely that competing activity appears before the block is safely incorporated. However, although this formula is intuitive it is wrong. In this sense, $q_{\mathrm{local}}$ is the conceptual starting point of the analysis.

For the blockchain simulator, however, the main theoretical benchmark in the report is not the local formula above, but the long-run chain-only benchmark

$$ q_{\mathrm{chain}} \approx \frac{1}{1+f(\Delta-1)}. $$

This expression comes from a renewal-style spacing argument for blocks that remain on the longest chain. It is the main simulator-facing comparator in the deterministic-delay experiments, while $(1-f)^{\Delta-1}$ remains useful as the local counting-probability model and as the conceptual basis of the derivation. We note that $q_{\mathrm{local}} \approx q_{\mathrm{chain}}$ when $0<f\ll1$.

The report then studies how network delays affect the total stake inference. inferred-stake feedback loop. With known total-stake, increasing delay lowers the accepted/effective chain-growth rate because some candidate blocks are lost in forks, while the pre-fork candidate-block emission production rate is remains controlled by the target parameter $f\in(0,1)$. Here $f$ is consensus parameter. In an ideal scenario with the known total-satke, no network delays, no adversarial behavior, etc., in an epoch of $T$ time-slots the canonical chain grows by the number of blocks $fT$ on average. With inferred total-stake, increasing delay lowers the counted fraction q, reduces the inferred denominator total-stake, and can thereby raise the future pre-fork candidate-block emission rate through the feedback loop between counting, stake estimation, and leader election.

Rate definitions. The parameter $f$ is the target per-slot activity parameter in the ideal known-denominator, no-delay setting. In the ideal setting with no network delay, no adversarial behavior, and a fixed known denominator, an epoch of $T$ slots contains $fT$ blocks on average. In this ideal setting, the pre-fork and chain-visible notions coincide.

When network delay and fork competition are present, we distinguish two measured rates. The pre-fork candidate-block emission rate counts candidate blocks emitted by eligible leaders before fork choice and before fork-choice losses, divided by $T$. The accepted/effective chain-growth rate counts blocks that survive fork competition and remain visible to the chain-only counting rule, divided by $T$.

Under known total stake, the pre-fork candidate-block emission rate remains controlled by $f$, while the accepted/effective chain-growth rate decreases with delay because some candidate blocks are lost in forks. Under inferred total stake, delay-induced under-counting lowers the inferred denominator and can increase the future pre-fork candidate-block emission rate, partially compensating the accepted/effective chain-growth rate.

Reading guide and notation. This report has two main parts. The main text focuses on the quantities and comparisons that are directly used in the blockchain simulations. The appendix provides the technical derivations that motivate those benchmark formulas and the mean-field analysis used later for the inferred-stake loop. The intended reading order is as follows. Sections 1 and 2 explain why the counting factor $q$ is needed and how it should be defined. Section 3 introduces the chain-only counting model and the blockchain-facing benchmark formulas. Section 4 then studies the inferred-stake feedback loop through simulator-facing evidence. The appendix should be read as technical support for these main-text claims, rather than as a second, competing narrative.

Notation policy. We keep the (capital) $D$ notation for total-stake inference, following the standard TSI notation: $D_ℓ$ denotes the total-stake estimate at epoch $\ell$, and $D^0[\mathbf{w}]$ denotes the true total stake. We use $x_ℓ := D_ℓ / D^0[\mathbf{w}]$ only when a normalized variable is convenient in the fixed-point analysis. Delay variables are written separately: $L := \Delta-1$ denotes a local vulnerability window measured in future slots, also $Δ$ denotes a deterministic simulator-aligned network-delay or exclusion window. Thus the main text reserves the $D$-notation for stake estimation and does not reuse it for delay.

Role of the two counting formulas. The report uses two formulas for the counting factor, but they do not play the same role. The local expression $q_{\mathrm{local}} = (1-f)^{\Delta-1}$ is the conceptual starting point: it explains why delay lowers the probability that an active slot is ultimately counted. The blockchain-facing benchmark $q_{\rm chain} ≈ 1/(1+f(Δ−1))$ is the long-run chain-only expression used for the deterministic network-delay simulator comparison. The main text therefore treats these as two layers of the same story rather than as two competing curve fits.

1. Why this analysis is needed Motivation

The current total-stake inference analysis already makes one important qualitative point clear: the total-stake inference loop depends on a counting factor $q$, and this factor the latter deteriorates as the network delay and forkiness increase. What is still needed, however, is a cleaner theoretical interpretation of that factor analytical derivatrion from the first principles. If $q$ is treated only as an empirical calibration parameter, then the analysis explains what happens in simulation but not clearly why it happens. The purpose of this report is to replace that purely empirical viewpoint with a mathematically interpretable one.

The key conceptual shift is the following. Instead of asking which numerical value of $q$ best matches simulation, we ask what event $q$ is actually measuring. Once $q$ is defined as a counting probability, it becomes possible to relate it to propagation delay, fork competition, longest-chain selection, and eventually to the inferred-stake feedback loop itself. This produces a more coherent account of how delay affects the protocol: first through the probability that activity is counted, and then through the effect of that counted activity on stake estimation and leader selection.

This also explains why the report develops two complementary perspectives. The first is a local vulnerability-window picture, in which a newly produced block remains exposed for some number of future slots and may be displaced before it is counted. The second is a blockchain-facing chain-growth picture, in which one studies the long-run fraction of produced blocks that survive on the longest chain. The first viewpoint gives the conceptual starting point of the analysis; the second produces the benchmark formulas that are compared directly to the blockchain simulator. The report needs both, but they should not be confused with one another.