FAQ & troubleshooting

50 SNOW per block at launch, halving every 210,240 blocks (about four years): 25 SNOW from May 2022, 12.5 SNOW from May 2026. The sum converges to just under 21,024,000 SNOW. Details.

Ten minutes on average; the target adjusts every block and also eases while no block is found, so the network recovers quickly from hash-rate swings. Difficulty adjustment.

No. Block 0 had to contain the hash of Bitcoin block #523,850, so mining could not start before that block existed (22 May 2018). History.

Both are accepted; snow: is recommended because the label is part of the checksum. Testnet addresses start with snowtest:. Duck32.

It is designed to be quantum resistant: keys are hidden behind hashes until spent, addresses can combine several algorithms, and since 2025 the post-quantum schemes SPHINCS+, Dilithium and Falcon are available (key_mode=pqc1 / pqc_lite). Old secp256k1 wallets are as safe as Bitcoin's. Quantum resistance.

The protocol supports sharding since 2022, but mainnet still runs one shard because blocks are far from full. If a split ever happens, existing wallets keep working: their coins follow the coordinator lineage automatically. Sharding.

No - wallets and miners can use any node, and the client falls back to public TLS seed nodes. Running your own is recommended for privacy (a node sees which addresses you ask about) and is required for indexes (addr_index, tx_index) that history and integrations need. Node.

About 100 GB for an indexed mainnet node (2026), growing; SSD recommended. 4 GB heap plus RocksDB memory - plan 6–8 GB.

Install a 64-bit Java. (db_type=lobstack works on 32-bit but is slow and has no TLS.)

Your system clock is wrong. Blocks may be at most 45 s in the future; run NTP.

Indexes are not built retroactively. Delete the database and resync with the options on.

The node refuses templates until its head is within 10 blocks of the best header it has seen. Wait, or on a private network set bypass_sync_check=true.

Harmless JVM warnings from older Java versions; ignore, or use Java 17+.

In the directory set by wallet_path (IceLeaf: ~/.snowblossom/wallets/<name>/db). Back up the whole directory - or, for HD seed wallets, the 12 words (show_seed tells you whether every key comes from the seed). Non-seed wallets need a fresh backup whenever new addresses are created. Wallet files.

Every change is written as a new fragment and merged on the next start; this makes the wallet crash-safe and sync-friendly. Just never rsync --delete.

No. Use disk encryption and file permissions.

Recovery needs a node with addr_index to find used addresses without balance; otherwise only addresses within the first 10 + 20 indexes are discovered. Run against an indexed node (or a public node that has the index) and let maintainKeys iterate.

The node is not reachable: check node_uri/node_host, the node's port and that it is running.

Yes, over any mix of algorithms. Single-wallet multisig comes from the key modes (qhard, pqc1); a shared M-of-N between people takes three commands: each co-signer runs pubkey, one person runs makemultisig <m> self <key>… --out share.json, everyone else runs import share.json. Spending passes a part-signed file through each wallet's signtx. Multi-party multisig.

On the command line: send --to snow:alice=1.5 --to snow:bob=0.25 --extra "invoice 7". Through JSON-RPC: send takes an outputs array and an extra (≤ 100 bytes) field. IceLeaf's Send tab also has a note field. send.

Yes - coin control is built into the CLI since 2.2: outputs lists every unspent output with a short id, and send/sweep/consolidate take --input txid:idx, --from address and value/shard filters. Coin control.

newaddress --key-mode pqc_lite mints a Falcon address inside any wallet. It is not derived from your seed words, so run backup <dir> afterwards. Key modes.

At least the activated one - currently field 9 (hippo) - or larger. The explorer's mining page shows the next field and how close the network is to it. Snow fields.

Torrents at snowblossom.org/snowfields, or generate it with auto_snow=true (very slow). Put it in snow/snowblossom.N/ with the deck files.

No. The proof of work is six dependent random reads per attempt; there is nothing for a GPU to compute. Storage IOPS or RAM decide the hash rate. Stoat.

Yes, with RAM larger than the field: memfield=true (needed on Windows) or simply enough RAM for the Linux page cache; partial caching via memfield_precache_gb; or split the field across machines with Arktika. Mining.

When the average difficulty reaches the next activation difficulty (two bits per field on mainnet). Never back: an activated field stays required even if difficulty drops.

No usable field ≥ N was found under snow_path. Check the directory name (snowblossom.N), the presence of all deck files, and the start-up self-test messages (“Unable to load …” means a corrupt file).

With ~160 blocks a day network-wide, solo mining pays rarely unless you have a large share of the hash rate. Pools pay every block they find, directly in the coinbase (PPLNS). Pools.

vote_yes=N / vote_no=N in the solo miner or pool config. Pool miners vote through their pool. Voting.

Wallet operations (addresses, sending, balances): the client's JSON-RPC. Chain data and push notifications: the node's gRPC. Quick reads without running anything: the explorer's HTTP API.

tx_hash = Skein-256-256(inner_data); address = Skein-256-160(required_signers ‖ count ‖ (type ‖ len ‖ key)…), rendered with Duck32. Transactions, Addresses.

Install Bazel (bazelisk) and a JDK 17+, then bazel build :all; deploy jars with bazel build :<Name>_deploy.jar. Quickstart.

network=regtest, tiny fields from tools/snowfall-spoon.sh, a node with bypass_sync_check=true and a solo miner; blocks take seconds. Networks.