Korsh Core v0.0.1 — KSH

Korsh Core v0.0.1 — KSH

First public binary release of Korsh Core: full node daemon, RPC client, wallet tools and the Qt GUI wallet with the Masternode Setup Wizard — for Windows (x86_64), macOS (Apple Silicon) and Linux (x86_64).

Mainnet parameters

Parameter	Value
Genesis block	000017ec1f2f978429db70495ec7653aedca360e5f251bfe2a780ae5e731d7eb
Genesis date	20 September 2026 — "In honor of my uncle Satoshi Nakamoto"
Max supply	10,000,000 KSH
First block subsidy	2 KSH
Target block time	60 s (retarget every 20 blocks)
Halving interval	2,500,000 blocks
Reward split	70 % miner / 30 % masternodes (no treasury on mainnet)
Regular masternode collateral	1,500 KSH
Evo masternode collateral	7,500 KSH (Evo activation height is still in the future)
Proof of work	YesPower 1.0, N=256, r=8, no personalisation (256 KB working set)

Wallet data directory: ~/.korsh (macOS/Linux) or %APPDATA%\Korsh (Windows).

Contents of each archive

bin/korshd (node daemon), bin/korsh-cli (RPC client), bin/korsh-qt (GUI wallet + masternode wizard), bin/korsh-wallet, bin/korsh-tx, bin/korsh-util, the Sapling parameters in params/, and a short README-RELEASE.txt.

./korshd -daemon -server=1        # macOS / Linux
./korsh-cli getblockchaininfo
./korsh-qt                        # GUI wallet, includes the Masternode Setup Wizard

On Windows -daemon is not supported: run korshd.exe directly, install it as a service, or just use korsh-qt.exe.

Regtest for testing: ./korshd -regtest -daemon -server=1 -fallbackfee=0.0001

Verification performed for this release

• Unit tests: 693/693 test cases pass on the final build — subsidy, masternode payment split, LLMQ/quorum, Sapling, wallet, RPC and transaction-vector cases included.
• Mainnet smoke test on all three platforms: the node starts from an empty directory on main, reports blocks=0 and the genesis hash listed above. The published macOS tarball was additionally extracted to a clean directory and run from there, and the published Linux tarball was downloaded from this release page, hash-checked and run from an empty data directory.
• Regtest end-to-end: wallet creation (descriptor and legacy Berkeley DB), mining, RPC round-trips — verified on macOS and Windows with the packaged binaries.
• Functional regression tests (run on macOS against these binaries): wallet_basic.py (descriptors and legacy), mining_basic.py, feature_filelock.py, feature_governance.py (descriptors and legacy) and rpc_help.py all pass. feature_llmq_chainlocks.py and feature_dip3_deterministicmns.py fail for the two specific, expected reasons spelled out in the notes below.
• Masternode flow verified end-to-end on regtest: bls generate → protx register_fund with the 1,500 KSH collateral → mined → protx list shows the ProTx with ownsCollateral: true; restarting the node with masternodeblsprivkey makes masternode status report the operator service and masternode count report it as enabled.
• Masternode Setup Wizard (Qt) — exercised end-to-end in the GUI on regtest: opened from Masternodes → MN Setup Wizard (enable Settings → Options → Show Masternodes Tab), the type combo reads Regular (1,500 KSH) / Evo (7,500 KSH), Auto-fill from wallet fills the collateral/owner/voting/payout addresses and the fee source, Generate BLS key produces the operator key pair, and Finish sends the ProTx (6970486e… on the test chain). The resulting masternode appears in protx list with ownsCollateral: true, its service set to the entered ip:port, PoSeBanHeight: -1, and masternode count reports it enabled; the wizard also wrote masternodeblsprivkey into korsh.conf.
• Branding: every shipped icon is generated from the current Korsh mark — Qt window icon, macOS .icns, Windows .ico, Linux pixmaps, favicon, toolbar logo and the startup splash — replacing the inherited Smartiecoin artwork. The wallet's remaining legacy repository links and the macOS notification bundle identifier were pointed at this project.
• The GUI only offers what this network can run: with all LLMQ types set to LLMQ_NONE, the matching sporks off and no budget payments scheduled, the wallet hides the controls for the inactive services — no Governance tab or cycle clock, no InstantSend label in the send dialog, no InstantSend/ChainLock counters in the debug window and no Evo option in the masternode setup wizard — while PrivateSend, the masternode list and wizard, and the address/transaction pages stay available. The gates are capability checks, so these controls reappear by themselves once quorums and activation heights are configured.
• Consensus change before launch: the proof of work now runs from L2/L3. YesPower 1.0 was configured with r=32, which needs a 1 MB working set per hash (plus about 100 KB of S-boxes); it is now r=8, the smallest configuration the algorithm accepts (N >= 256, r >= 8), for a 256 KB region plus about 100 KB of S-boxes. Cache matters more than raw speed here: a 1 MB region does not fit in the 512 KB of L2 per core of, for example, an AMD EPYC 9554, so every hash had to be served from L3 there (measured at ~2.05 kH/s per thread, scaling linearly with thread count). At 256 KB the region is served from L2 instead, which is what makes the chain reachable for older CPUs, laptops and phones — the whole point of the change. GPUs and ASICs still gain nothing: the working set does not fit in their per-thread memory. Mainnet had no blocks, so no chain was orphaned — but the genesis nonces had to be re-mined for the new parameters (mainnet and regtest alike; the node re-checks a block's proof of work whenever it reads it back from disk) and the mainnet genesis hash changed (the timestamp, phrase, merkle root, nBits and reward are unchanged). Every binary from this release mines and validates the new rules, and any miner built for r=32 will no longer produce valid blocks.

Notes and known limitations

• The binaries carry the first public seed (195.26.244.209:8383, the VPS that also serves the explorer), so a fresh install finds the network by itself: about a minute after start the node logs Adding fixed seeds as 60 seconds have passed and addrman is empty for at least one reachable network and connects. No -addnode needed. There is still no DNS seed, so if that node is ever retired the seed list has to be updated in a release.

• Linux runtime dependencies: the tarball links Berkeley DB 5.3, miniupnpc, libnatpmp and libevent, which are not part of a minimal install. On Debian/Ubuntu:

  apt-get install -y libdb5.3t64 libdb5.3++t64 libminiupnpc17 libnatpmp1 libevent-2.1-7t64 libevent-pthreads-2.1-7t64

  (on releases before the t64 transition, drop the t64 suffix).

• A block explorer runs against this same node at https://explorer.195-26-244-209.sslip.io/ (eIquidus: blocks, transactions, addresses, masternodes, rich list, movement, network panels and public JSON APIs). The hostname is temporary until a domain is bought. The masternode table fills in as masternodes register.

• Two functional tests are expected to fail on this network, each for a specific reason. feature_llmq_chainlocks.py waits for LLMQ quorum rotation and ChainLocks, which Korsh ships disabled (LLMQ_NONE for every type, matching sporks off), so those code paths are unreachable by design. feature_dip3_deterministicmns.py asserts an early chain-height window (blocks < 135) that assumes Dash's regtest DIP3 activation parameters; Korsh activates DIP3 at block 432, so that window does not hold even though masternode registration itself works — the Qt wizard was exercised end-to-end on regtest and the resulting ProTx is listed and enabled. Everything else in the smoke set passes: wallet_basic, mining_basic, rpc_help, feature_filelock and feature_governance.

• A ready-to-run Windows CPU miner is attached to this release (korsh-miner-0.0.1-win64.zip, also in contrib/korsh-miner/ in the source): yespower 1.0 N=256 r=8, multi-threaded (with an optional two-way kernel that is ~35% faster and verified bit-identical by its own --selftest), solo mining straight against your own node.

  korsh-miner.exe Kxxxxxxxx --threads 8 --conf "%APPDATA%\Korsh\korsh.conf"

  It reads your wallet's address as the first argument (Qt wallet → Receive). Verified against this release: it mined 283 blocks in a local regtest node, all accepted. It stops when the template carries masternode payments, i.e. as soon as the first masternode registers — after that, mine with the wallet's generatetoaddress, which pays the masternode share.

• A hashrate monitor ships in the repository under contrib/ (korsh-hashrate-monitor.py): it samples getmininginfo/getnetworkhashps through korsh-cli, appends to a CSV and raises an alert (macOS notification and/or --webhook URL) when the network hashrate falls well below its recent median. A young chain with a cheap-to-mine history is most exposed when its honest hashrate drops, so this is the cheapest early warning available until masternodes make ChainLocks possible:

  ./contrib/korsh-hashrate-monitor.py --cli ./bin/korsh-cli --datadir ~/.korsh --interval 300

• macOS now embeds the Sapling zkSNARK parameters exactly like the Windows (Win32 resources) and Linux (.incbin object) builds do, so the node writes them into its own data directory on first start and no manual params/ handling is needed any more.

• Fixed: starting the macOS GUI with a masternode key (masternodeblsprivkey) and a wallet that has no CoinJoin client — a masternode wallet, for example — crashed before the window appeared (setNumBlocks() dereferenced a null CoinJoin client). Verified fixed against a reproduction that...