# An Analysis of Avalanche Consensus

arXiv: https://arxiv.org/abs/2401.02811 · HTML: https://mlsanity.com/paper/2401.02811/

## Key facts

- Cited by 2 papers in the map (data through 14 Oct 2026).
- First posted on arXiv 5 Jan 2024.

## Built on by (most cited first, 2 of 2)

- [Consensus learning: A novel decentralised ensemble learning paradigm](https://mlsanity.com/paper/2402.16157/) (2024)
- [Snowveil: A Framework for Decentralised Preference Discovery](https://mlsanity.com/paper/2512.18444/) (2025)

## Abstract (arXiv)

A family of leaderless, decentralized consensus protocols, called Snow consensus was introduced in a recent whitepaper by Yin et al. These protocols address limitations of existing consensus methods, such as those using proof-of-work or quorums, by utilizing randomization and maintaining some level of resilience against Byzantine participants. Crucially, Snow consensus underpins the Avalanche blockchain, which provides a popular cryptocurrency and a platform for running smart contracts. Snow consensus algorithms are built on a natural, randomized routine, whereby participants continuously sample subsets of others and adopt an observed majority value until consensus is achieved. Additionally, Snow consensus defines conditions based on participants' local views and security parameters. These conditions indicate when a party can confidently finalize its local value, knowing it will be adopted by honest participants. Although Snow consensus algorithms can be formulated concisely, there is a complex interaction between randomization, adversarial influence, and security parameters, which requires a formal analysis of their security and liveness. Snow protocols form the foundation for Avalanche-type blockchains, and this work aims to increase our understanding of such protocols by providing insights into their liveness and safety characteristics. First, we analyze these Snow protocols in terms of latency and security. Second, we expose a design issue where the trade-off between these two is unfavorable. Third, we propose a modification of the original protocol where this trade-off is much more favorable.