Pith. sign in

REVIEW 5 major objections 5 minor 11 references

Pulsar Consensus

T0 review · 5 major / 5 minor · reviewed 2026-08-12 · deepseek-v4-flash

Pith's one-line read A single tuneable rule can reproduce both longest-chain and density-based proof-of-stake selection.

desk verdict A candid design white paper whose central 'superset' chain-selection claim fails at its own alpha=0 boundary; not a research result as written. read the letter →

arxiv 2411.14245 v2 pith:N7NC65BW submitted 2024-11-21 cs.CR

classification cs.CR
keywords proofofstakechainselectionruledensity-basedconsensussidechainverifiablerandomfunctionkey-evolvingsignaturesfinalitycheckpointing
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper proposes Pulsar, a proof-of-stake consensus protocol designed to run as a sidechain to a proof-of-work blockchain such as Bitcoin. Its central claim is that one composable, density-based chain-selection rule can replace the separate longest-chain and density rules used by earlier proof-of-stake protocols: with the tuning parameter $\alpha = 0$ it behaves like a longest-chain rule, and as $\alpha \to \infty$ it behaves like Ouroboros-style density selection. The rule is built from a per-slot trust function $f(t) = 1 - e^{-\alpha t}$ that assigns a filled slot a bounded positive score and subtracts one unit for an empty slot, so the canonical chain is the one with the highest cumulative trust. If the claim is right, a proof-of-stake chain can pick its security-liveness tradeoff by tuning one parameter while remaining compatible with a Bitcoin-style mainchain, including reorganizing alongside it up to a fixed depth.

What carries the argument

The central object is the composable chain-selection rule with trust function $f(t) = 1 - e^{-\alpha t}$, equivalently per-slot weight $W_b(t) = e^{-\alpha t}$; $\alpha$ is a free parameter controlling how fast a block's trust contribution saturates. The rule scores a chain by summing the bounded positive trust of filled slots and subtracting one unit per empty slot, so a chain's score is never negative. It is 'composable' in the sense that one rule selects the canonical chain over the entire post-checkpoint history, reproducing the longest-chain rule at $\alpha=0$ and Ouroboros-style density selection as $\alpha\to\infty$. This function is what carries the argument that a single mechanism spans the standard design space of proof-of-stake chain selection.

What would settle it

Attempt to produce a second valid signature with the same slot key before any key-evolution boundary in a standard key-evolving signature scheme, or on a Pulsar testnet have one pool broadcast two different blocks for the same slot; if both verify and are accepted by honest nodes, the protocol's no-equivocation premise fails.

Watch

Extended reading notes

Core claim

Pulsar's discovery is that a single rule, parameterized by $\alpha \in [0, \infty)$, can express both Peercoin-style longest-chain selection and Ouroboros-style density selection. Slot leaders are chosen by a verifiable random function with probability proportional to stake; blocks carry a VRF proof, a signature, and a timestamp, and epochs rotate keys and randomness. The chain-selection rule scores a candidate chain by adding $f(t) = 1 - e^{-\alpha t}$ for each filled slot and subtracting one unit of trust for each empty slot, with the exponential decay ensuring that no number of empty slots can outweigh a single filled slot's maximum score. The rule is applied only to the post-checkpoint history, and the protocol enforces a maximum reorganization depth of 1000 blocks, giving deterministic finality at that depth and probabilistic finality before it. The paper states the rule is a superset of existing longest-chain proof-of-stake rules and that a production implementation exists.

Load-bearing premise

The load-bearing premise is that a slot leader's signing key is destroyed immediately after signing, so a leader cannot produce two valid blocks for the same slot; if that single-use assumption fails, equivocation has no cost and the number of valid forks grows exponentially.

Editorial extensions

If this is right

  • A deployment can choose its desired behavior by setting $\alpha$: small values approximate a traditional longest-chain rule, large values approximate density-based selection, with intermediate values giving a continuous tradeoff.
  • The protocol can operate as a Bitcoin sidechain, with deterministic finality after 1000 blocks and probabilistic finality before that, so it can reorganize alongside the proof-of-work mainchain.
  • Because the trust function is bounded, long runs of empty slots cannot drive a chain's score negative, which the paper distinguishes from Ouroboros's $\pm 1$ mapping.
  • Checkpointing past block hashes blocks long-range reorganizations, and a chain that ignores a checkpoint cannot win even if it is denser.
  • Under the stated key-evolving signature assumption, a slot leader cannot equivocate, so the protocol does not currently need slashing.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A testable consequence the paper leaves implicit is that observed reorg depth and fork rate should vary monotonically with $\alpha$ in the deployed implementation; measuring that would directly test the claimed interpolation.
  • The no-equivocation guarantee rests on per-slot key destruction, but standard key-evolving signature schemes ratchet at period boundaries; if the implementation does not enforce single-signature keys, the protocol would need slashing or another equivocation penalty, which the paper itself identifies as future work.
  • The same rule could be applied to other networks by changing only the checkpoint and finality parameters, since the density scoring is independent of the mainchain's difficulty adjustment.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

5 major / 5 minor

Summary. The manuscript presents Pulsar, a proof-of-stake consensus protocol intended as a sidechain to a proof-of-work chain. Its claimed contribution is a single composable density-based chain-selection rule, f(t)=α∫0^t e^{-αx}dx, said to interpolate between a longest-chain rule at α=0 and Ouroboros-style density selection as α→∞. The paper describes block structure, staking, epochs, pools, VRF-based slot leader selection, difficulty adjustment, finality depth, checkpointing, a simple game-theoretic equilibrium analysis, and a set of informal lemmas arguing that equivocation must be punished. It states that formal proofs are future work and that Pulsar is implemented in Mintlayer.

Significance. The manuscript is honest about its scope: Section 1 says formal discussions of performance and security are out of scope, and Section 5.5 says a formal proof is to follow. These limitations are important because the headline claims—a composable superset chain-selection rule and resistance to equivocation—are exactly the claims that need precision. If established, the work would be practically significant: a tuneable rule that connects longest-chain and density selection, plus a deployed sidechain implementation, would be useful. The paper also provides a useful survey of related PoS work. However, the current draft does not provide a definition precise enough to compute the rule, the α=0 boundary claim is contradicted by the formula, and the lemmas in Section 6.1 contain substantive errors. I therefore cannot regard the central claims as supported.

major comments (5)
  1. [§5.5, chain-selection rule] The central chain-selection rule is not specified to the point of being computable. The text says the rule 'works on the basis of summing a chain trust value of valid blocks in slots and removing a unit of trust for empty slots,' but it never defines how f(t)=α∫0^t e^{-αx}dx combines with Wb(t)=e^{-αt} to produce a score for a slot string. Consequently the alleged behavior at the extremes cannot be verified. In addition, the α=0 case is false as stated: f(t)=1-e^{-αt} is identically 0, so a filled block contributes no positive trust and the rule does not 'essentially prefer the chain with the most blocks'; no renormalized limiting rule is given. The α→∞ claim is also only asserted, since the exact aggregation is missing. Because the abstract and Section 3 advertise this rule as a 'superset' of existing rules, these omissions undermine the paper's main contribution.
  2. [§5.5, game-theoretic model] The Nash-equilibrium analysis is not a well-defined model. The utility expressions U_m^2 = φ_m^2·2r and U_m^h = φ_m·r are asserted without specifying the probability model for a malicious pool producing two valid blocks, how rewards on a competing fork are realized, or why a partial-synchrony assumption Δ=0 plus a constant block time justifies these forms. The subsequent derivation 'if φ_m < 1/2' and the condition 0 ≤ (φ_h−1)(2φ_h−1) therefore do not establish a Nash equilibrium in any stated strategy space. This section should either be made precise or explicitly labeled as illustrative only.
  3. [§6.1, Lemma 6.2] Lemma 6.2 asserts that the maximum of k i.i.d. revenue draws grows as Θ(k). This is not generally true: for light-tailed or bounded distributions the maximum grows sublinearly (typically O(log k)), and for heavy-tailed distributions the growth rate is governed by the tail index, not by k. The claimed linear scaling of MEV revenue with the number of equivocated forks is therefore unsupported. Since this lemma feeds the motivation for the punishment mechanisms in Section 6.1, the security narrative is not established.
  4. [§6.1, Lemma 6.3] Lemma 6.3 assumes that a KES ratchets the signing key immediately after each signature, making a second signature in the same slot impossible. The cited Bellare–Miner scheme evolves keys per time period and permits multiple signatures within a period, so the assumption does not follow from the cited primitive. The manuscript itself states in §4.1.3 that KES is 'not essential' and that key ratcheting can happen after 'a defined period of time, be that a single use or a number of days,' which is inconsistent with the per-signature ratchet used in the lemma. The conclusion that equivocation is 'fully prevented' therefore does not follow.
  5. [§6.1, Lemma 6.4] Lemma 6.4 defines the slashing penalty as the leader's entire current stake plus all discounted future income, and then observes that any one-slot MEV gain is smaller than that quantity. Unprofitability is true by construction, so the lemma does not demonstrate that the protocol can enforce such a penalty, that slashing of this magnitude is implementable, or that a smaller penalty would suffice. The argument is circular with respect to the security property it claims to prove.
minor comments (5)
  1. [Title] The typeset title includes 'V ersion' with an extra space; please correct.
  2. [§5.5] The phrase 'he function Wb(t)' appears to be missing the initial 'T'; additionally, Wb(t) is defined only through its monotonicity and derivative, without stating its role relative to f(t).
  3. [§5.2.4] The pledge-incentive expression is not a well-formed equation as rendered ('σ + a·(...)/(a+1) → ...'); the intended formula should be restated cleanly with all variables defined on first use.
  4. [§5.3.1 and §5.5] The text alternates between calling the rule a 'longest chain rule' and a 'density' rule; this terminology should be unified, since the claimed novelty is a density-based rule.
  5. [§5.5 and §6.1] The notation r is used for the block reward and also, implicitly, for the reward in the game-theoretic utility expressions; distinct symbols would improve readability.

Circularity Check

2 steps flagged · score 6.0 of 10

Security lemmas 6.3 and 6.4 conclude exactly what their definitions assume; the main chain-selection superset claim is asserted rather than derived.

  1. self definitional [Section 6.1, Lemma 6.3]
    "If the slot- t key skt is destroyed immediately after signing, no pool can produce more than one valid signature in slot t, and any further blocks signed with the same key in that slot are rejected. Proof: By construction of a KES: upon signing message m, the key skt is ratcheted to a fresh key sk′t, rendering skt unusable thereafter."

    The lemma's conclusion—that a pool cannot produce more than one valid signature per slot—is exactly the KES behavior assumed in the proof. The proof does not derive this from the cited Bellare–Miner KES; instead it posits a per-signature ratchet 'by construction.' The paper's own Section 4.1.3 describes ratcheting as an implementation choice ('be that a single use or a number of days'), not as a property of the cited primitive. Thus the equivocation-prevention property is an input to the definition of the KES, and the lemma restates that input rather than proving it from standard assumptions.

  2. self definitional [Section 6.1, Lemma 6.4]
    "Under an on-chain slashing rule that forfeits a leader's entire stake and all future block-reward and MEV entitlements upon double-signing, any attempt to equivocate is strictly unprofitable. ... If a leader equivocates in slot t, they lose: Sslash = current stake + Ufuture, but can gain at most Rmax in that slot. Their net utility change is Ueq = Rmax − Sslash < 0, since Ufuture dominates any single-slot Rmax."

    The slashing rule is defined as forfeiting current stake plus all future block-reward and MEV entitlements. The proof then defines Sslash to include exactly that entire future income and concludes that a one-slot equivocation gain Rmax cannot exceed it. This is a tautology: the conclusion 'equivocation is strictly unprofitable' is already contained in the premise that the penalty includes all future income. No bound relating Rmax to Ufuture is derived; Ufuture is defined to dominate. The lemma therefore adds no information beyond its own assumption.

full rationale

The circularity is localized to the Section 6.1 security lemmas. Lemma 6.3 assumes a per-signature key-ratcheting KES and then proves single-signature-per-slot behavior; the proof is a restatement of the assumed KES behavior, not a derivation from the cited Bellare–Miner primitive. Lemma 6.4 defines the slashing penalty as forfeiture of current stake plus all discounted future income and then proves that a one-slot equivocation gain is smaller than that penalty; this is an algebraic tautology. Both lemmas are presented as proofs but add no information beyond their assumptions. The central chain-selection claim in Section 5.5 is not circular, but it is also not derived: the assertion that α=0 recovers a longest-chain rule is inconsistent with f(t)=1−e^(−αt), which is identically zero at α=0, and the α→∞ limit is only asserted without specifying the slot-string aggregation. These are correctness gaps rather than circular reductions, so they are not counted as circular steps. No load-bearing self-citations were found; the Mintlayer reference is only an implementation pointer. Overall, the security appendix contains two definitionally forced conclusions, giving a partial-circularity score of 6.

Assumptions & free parameters 7 free parameters · 8 assumptions · 0 invented entities

The central claims rest on the security of cryptographic primitives and on network assumptions that are standard, but the load-bearing assertions about the chain selection rule and about KES preventing equivocation are either unproven or incorrect. The protocol parameters α, a, z, and the finality depth are free choices that shape the protocol's behavior.

free parameters (7)
  • α = not specified
    Tunable convergence speed in the chain selection rule f(t) = 1 - e^{-αt}; the paper gives no default value and says it can be tuned for desired behavior.
  • a = 0.07537578
    Pledge incentive parameter in Section 5.2.4, chosen to give a 0.5% incentive increase for the first doubling of the pledge.
  • z = 1/1000
    Saturation threshold z = 1/k, with k=1000, limiting pool size to 1/1000 of total supply.
  • minimum pledge = 0.01% of total supply
    Set in Section 5.2.3 to incentivize pool operator financial interest.
  • finality depth = 1000 blocks
    Maximum reorganization depth chosen for Bitcoin compatibility; about 33 hours at 2 minute blocks.
  • block time target = 2 minutes
    Average block production interval chosen for the implementation.
  • difficulty adjustment cap = τ_prev / 1000
    Low-pass filter on threshold changes, Algorithm 1.
assumptions (8)
  • domain assumption Network latency is bounded by Δ such that all participants receive a block by time t + Δ
    Section 4.2.2 states this bound; used implicitly in the security model and in the probability of competing blocks.
  • domain assumption The network is dynamically available, with agents able to enter and exit at will
    Section 4.2.1 states this; it is a design goal and a premise for the chain selection and liveliness discussion.
  • standard math The hash function is collision resistant, preimage resistant, and has an avalanche effect
    Section 4.1.1 assumes BLAKE2 provides these properties; standard cryptographic assumption.
  • standard math The VRF output is pseudorandom and verifiable, preventing stake grinding and DoS on leaders
    Section 4.1.4 and 5.3 rely on VRF security for leader selection.
  • domain assumption The system operates in a partially-synchronous network model with PKI and a BFT adversary
    Section 1 says 'We assume a similar security model to a partially-synchronous Byzantine Fault Tolerant protocol with PKI.'
  • domain assumption KES provides forward secrecy and back-dating prevention
    Section 4.1.3 relies on KES properties, but Section 6.1 incorrectly extends this to one-time signing within a slot.
  • ad hoc to paper The density-based chain selection rule selects the honest chain under the stated assumptions
    Section 5.5 asserts this informally; the formal proof is deferred to future work.
  • domain assumption Checkpointing hardcoded block hashes prevents long-range attacks
    Section 5.4.2 states checkpointing is essential against long-range attacks; no analysis is provided.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Pulsar Consensus." pith.science (2026). https://pith.science/paper/N7NC65BW

@misc{pith2026241114245,
  author       = {Pith},
  title        = {Pith review of: Pulsar Consensus},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/N7NC65BW}},
  note         = {Machine review of arXiv:2411.14245}
}
read the original abstract

In this paper, we informally introduce the Pulsar proof of stake consensus paper and discuss the relevant design decisions and considerations. The Pulsar protocol we propose is designed to facilitate the creation of a proof of stake sidechain for a proof of work blockchain. We present an overview of a novel composable density-based chain selection rule for proof of stake systems which can be seen as a superset of some standard existing longest chain rules for proof of stake protocols. We discuss the Pulsar protocol in comparison to existing proof of stake protocols and define its benefits over existing designs while defining the limitations of the work. Pulsar is currently implemented in the Mintlayer proof of stake Bitcoin sidechain.

Figures

Figures reproduced from arXiv: 2411.14245 by the authors.

Figure 1
Figure 1. Two com￾peting chains without checkpoints In figure 1 two competing chains can be seen. Chain A will be selected by the longest chain rule in Pulsar given it is the denser chain [PITH_FULL_IMAGE:figures/full_fig_p012_1.png] view at source ↗
Figure 2
Figure 2. Two competing chains with checkpoints In figure 2 competing chains with a checkpoint can be seen. Both chains obey the checkpoint and only the later chain is considered. A will win again as it has the denser chain. But a block in an empty slot on B could mean B is now the longest chain [PITH_FULL_IMAGE:figures/full_fig_p012_2.png] view at source ↗
Figure 3
Figure 3. Two compet￾ing chains with an ignored checkpoint 12 [PITH_FULL_IMAGE:figures/full_fig_p012_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

11 extracted references · 5 canonical work pages

  1. [1]

    A Forward-Secure Digital Signature Scheme

    [BM99] Mihir Bellare and Sara K. Miner. “A Forward-Secure Digital Signature Scheme”. In: Advances in Cryptology — CRYPTO’ 99 . Ed. by Michael Wiener. Berlin, Heidelberg: Springer Berlin Heidelberg, 1999, pp. 431–

  2. [6]

    ALGORAND: The Efficient and Democratic Ledger

    [Mic16] Silvio Micali. “ALGORAND: The Efficient and Democratic Ledger”. In: CoRR abs/1607.01341 (2016). arXiv: 1607.01341. url: http://arxiv. org/abs/1607.01341. [Kia+17] Aggelos Kiayias et al. “Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol”. In: Advances in Cryptology – CRYPTO 2017 . Ed. by Jonathan Katz and Hovav Shacham. Vol. 10401. L...

  3. [8]

    Ethereum 2.0 Specs

    [Eth18] Ethereum Foundation. Ethereum 2.0 Specs. https://github.com/ethereum/ eth2.0-specs. Accessed: 2024-10-21

  4. [10]

    Proof-of-Stake Sidechains

    1145/3328526.3329567 . url: https://doi.org/10.1145/3328526. 3329567. 16 [GKZ19] Petros Gaˇ zi, Aggelos Kiayias, and Dimitrios Zindros. “Proof-of-Stake Sidechains”. In: IEEE Symposium on Security and Privacy (SP) . San Francisco, CA, USA, 2019, pp. 139–156. doi: 10.1109/SP.2019.00040. [Bur+20] Jeff Burdges et al. “Overview of Polkadot and its Design Consi...

  5. [120]

    Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services

    isbn: 0769504094. [GL02] Seth Gilbert and Nancy Lynch. “Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services”. In: ACM SIGACT News 33.2 (2002), pp. 51–59. doi: 10.1145/564585.564601. [Nak08] Satoshi Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. https: //bitcoin.org/bitcoin.pdf

  6. [448]

    Verifiable Random Func- tions

    isbn: 978-3-540-48405-9. 15 [MVR99] Silvio Micali, Salil Vadhan, and Michael Rabin. “Verifiable Random Func- tions”. In: Proceedings of the 40th Annual Symposium on Foundations of Computer Science. FOCS ’99. USA: IEEE Computer Society, 1999, p

  7. [2012]

    BLAKE2: Simpler, Smaller, Fast as MD5

    [Aum+13] Jean-Philippe Aumasson et al. “BLAKE2: Simpler, Smaller, Fast as MD5”. In: Applied Cryptography and Network Security . Ed. by Michael Jacobson et al. Berlin, Heidelberg: Springer Berlin Heidelberg, 2013, pp. 119–135. isbn: 978-3-642-38980-1. [Bac+14] Adam Back et al. Enabling Blockchain Innovations with Pegged Sidechains. https://blockstream.com/...

  8. [2014]

    Cryptocurrencies without Proof of Work

    [BGM14] Iddo Bentov, Ariel Gabizon, and Alex Mizrahi. “Cryptocurrencies without Proof of Work”. In: CoRR abs/1406.5694 (2014). arXiv: 1406.5694. url: http://arxiv.org/abs/1406.5694. [ML14] Andrew Miller and John LaVida. Anonymous Byzantine Consensus from Moderately-Hard Puzzles: A Model for Bitcoin . https://socrates1024. s3.amazonaws.com/consensus.pdf

Show all 11 references
  1. [2017]

    [V A17] Henry de Valence and Tom Arcieri

    doi: 10.1007/978-3-319-63688-7\_12 . [V A17] Henry de Valence and Tom Arcieri. [curves] Torsion-safe representatives (was: Ed25519 ”clamping” and its effect on hierarchical key derivation) . https : / / moderncrypto . org / mail - archive / curves / 2017 / 000866 . html

  2. [2018]

    Formal Barriers to Longest-Chain Proof-of- Stake Protocols

    [Bro+19] Jonah Brown-Cohen et al. “Formal Barriers to Longest-Chain Proof-of- Stake Protocols”. In: Proceedings of the 2019 ACM Conference on Eco- nomics and Computation . EC ’19. Phoenix, AZ, USA: Association for Computing Machinery, 2019, pp. 459–473. isbn: 9781450367929. doi:

  3. [2021]

    On PeerCoin Proof of Stake for Blockchain Consen- sus

    [Zha+21] Wenbing Zhao et al. “On PeerCoin Proof of Stake for Blockchain Consen- sus”. In: Proceedings of the 2021 3rd International Conference on Blockchain Technology. ICBCT ’21. Shanghai, China: Association for Computing Ma- chinery, 2021, pp. 129–134. isbn: 9781450389624. d...

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.