Snowblossom Docs
Docs › Start here › Overview

Overview

Snowblossom is a proof-of-work cryptocurrency launched in May 2018 with a small set of deliberate design choices: an IO-bound proof of work that resists specialised hardware, a UTXO commitment in every block header so light clients can verify what nodes tell them, multi-algorithm multisignature addresses that already include post-quantum signature schemes, and a sharded chain (the “Braid”) that can split under load. This site documents all of it - from the bytes in a block header to running a pool.

What makes Snowblossom different

Quick facts

Ticker / unitSNOW; 1 SNOW = 1,000,000 flakes (all protocol amounts are integer flakes)
Launch22 May 2018, no premine, no ICO. Block 0 had to contain the hash of Bitcoin block #523,850 so nobody could mine early.
Block time target10 minutes (600,000 ms), adjusted every block with an exponential moving average
Block reward50 SNOW at launch, halving every 210,240 blocks (≈ 4 years) → supply converges to ≈ 21,024,000 SNOW
Hash functionsSkein-256-256 for block/transaction hashes, Skein-256-128 for snow-field merkle trees, Skein-256-160 for addresses, SHA-256 inside the UTXO trie
Address formatsnow: + 40 base-32 characters (Duck32, a bech32-like encoding with a 5-byte checksum)
Wire protocolProtocol Buffers over gRPC, for both peer-to-peer and wallet/miner traffic. Optional TLS with node identities derived from Snowblossom keys.
ImplementationJava, built with Bazel. One repository contains node, wallet, miners, pool and explorer. github.com/snowblossomcoin/snowblossom
Current software version2.2.0 (master: 2.2.0-dev). Consensus-relevant changes: header v2 since block 211,600 (sharding), post-quantum signatures since block 358,700.

How this documentation is organised

Everything here was written from the source code of the reference implementation; where the code and older documentation disagree, the code wins and the discrepancy is noted. File paths such as lib/src/PowUtil.java refer to the snowblossom repository. Live numbers on this page come from the explorer API.

A block in one picture

Block BlockHeader version · height · timestamp · shard_id prev_block_hash (32 B) merkle_root_hash (32 B) ← transactions utxo_root_hash (32 B) ← UTXO trie after this block target (32 B) · snow_field · nonce (12 B) pow_proof ×6 (word + merkle path) snow_hash (32 B) = block hash v2: shard_export_root_hash{shard→root} v2: shard_import{shard→height→hash} v2: tx_data_size_sum · tx_count transactions[] [0] coinbase: reward + fees, height, shard_id, votes [1..n] Transaction{tx_hash, inner_data, signatures[]} inner_data = inputs, outputs, claims, fee, extra imported_blocks[] (v2, sharding) header of a block from another shard import_outputs{shard → [raw_output, tx_id, out_idx]} outputs exported to this shard, verified against the source header's shard_export_root_hash
A block is a header, a list of transactions (the first is the coinbase) and, since sharding, the foreign blocks it imports. The header commits to everything; its hash is the result of the proof of work.