Pool operator reference

How to fetch work from a KRNX node, hand it to kHeavyHash miners, take a share back and submit a solved block. Self-contained. This is about the KRNX main chain. Its proof of work is kHeavyHash, the same one Kaspa uses: identical pre-image, the same two cSHAKE256 passes, the same 64×64 matrix, the same little-endian comparison. Any kaspa miner (GMiner, lolMiner, BzMiner, IceRiver, Goldshell) mines KRNX with no firmware change — only the source of work differs. There are two differences from Kaspa, and both break an integration if you do not know them:

The timestamp is in seconds, not milliseconds. Section 4.
Share difficulty and consensus difficulty are different scales, exactly 2^32 apart. Section 5.

1. What the node must provide

Your own KRNX node with HTTP-RPC and template production enabled:

krnxd --http --http.api eth,krnx,net,web3 --http.addr 127.0.0.1 --http.port 8545 \
      --mine --miner.threads 0 --miner.etherbase 0xYOUR_ADDRESS --miner.recommit 3s

Flag	Why
`--mine`	without it the node builds no pending block and `getWork` errors
`--miner.threads 0`	disables the node’s own CPU mining while templates keep being built
`--miner.etherbase`	the address the block reward is credited to
`--miner.recommit`	how often the template is rebuilt (3s by default)
`--miner.notify URL`	optional: the node POSTs new work to the pool itself

The reward goes to the node’s etherbase, not to the stratum login. The login is only an accounting label; payouts are the pool’s own business. Three RPC methods, nothing else:

Method	Returns
`krnx_getWork`	an array of 11 strings — the work
`krnx_submitWork(nonce, powHash, mixDigest)`	`true` / `false`
`krnx_submitHashrate(rate, id)`	`true` (optional, for the node’s stats)

All three are mirrored in the eth_ namespace (eth_getWork, eth_submitWork) — the names match stock krnxd, so existing ethash pool code only needs its hashing swapped out.

2. `krnx_getWork`

curl -sS -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"krnx_getWork","params":[]}' \
  http://127.0.0.1:8545 | jq -r '.result[0,2,3]'

0x7bbec5a103d39fcd618e0233e6b872f8b1824f4e4d326ae5a4ef35f7736b3f9f
0x000005f67467c79dc2c3a72af48c650090096beaedfae8c63e25a35f67d59763
0xe193

Eleven strings. A pool needs four of them:

Index	What it is	Needed
`[0]`	the header’s seal hash — this is the `PRE_POW_HASH` of kHeavyHash	yes
`[1]`	DAG seed hash — always zero, kHeavyHash has no DAG	no
`[2]`	block target = 2^256/difficulty	yes
`[3]`	block number	yes (logs, staleness)
`[4]`	parent hash	no
`[5]`–`[8]`	gas limit, gas used, transaction count, uncle count	no
`[9]`	RLP of the header being mined	yes — for per-connection work (section 8) and to verify the timestamp
`[10]`	the header timestamp in seconds — the `TIME` of the pre-image	yes

Work is new when [0] changes. Everything else in the header is already folded into that hash. If the node is not mining or is still syncing, the method returns an error. That is normal: wait, and do not close the stratum port.

Push instead of polling

With --miner.notify http://pool:1234/work the node POSTs the work array as JSON whenever the template changes. With --miner.notify.full it posts the whole header as JSON instead. Polling krnx_getWork every 200–500 ms is an equally fine alternative; with --miner.recommit 3s the added latency does not matter.

3. The kHeavyHash pre-image

Byte for byte as in kaspad:

                 32 bytes              8 bytes       32 bytes        8 bytes
       ┌──────────────────────┬───────────────┬──────────────┬───────────────┐
       │   PRE_POW_HASH       │  TIME u64 LE  │  zero bytes  │ NONCE u64 LE  │
       └──────────────────────┴───────────────┴──────────────┴───────────────┘
        = krnx_getWork()[0]     = getWork()[10]  fixed 32       the miner's
                                  (SECONDS)      zero bytes     search space

Then:

first = cSHAKE256(data, customization="ProofOfWorkHash") → 32 bytes.
matrix = generate(PRE_POW_HASH) — a 64×64 matrix of 4-bit values from xoshiro256++ seeded with the seal hash, regenerated until its rank (float64 Gaussian elimination, eps = 1e-9) reaches 64.
mixed[i] = first[i] XOR (product[2i]<<4 | product[2i+1]), where product[i] = (Σ matrix[i][j] * vector[j]) >> 10 and vector holds the nibbles of first.
final = cSHAKE256(mixed, customization="HeavyHash") → 32 bytes.
The PoW value is final read little-endian. A block is solved when that value is <= the target.

The matrix depends on the seal hash alone: compute it once per work package, then roll only the nonce.

Golden vector

Every implementation must reproduce exactly this:

PRE_POW_HASH  0x37a01e19f6d0f7bd2b95bb45f4d1a5da5cbccdca4c1652deb3a4116ad4d0a4f1
TIME          1784505600
NONCE         0x123456789abcdef0
pow value     fb08e9df4e0cfa2e2f27a317413e7033856fd20a0e880cc4a936d92848e316c3

The node pins the same vector in TestKHeavyHashPowValueGolden (consensus/kheavyhash/kheavyhash_test.go). Every example in section 10 is checked against it.

4. The timestamp: seconds, not milliseconds

This is the one trap when porting code from Kaspa. Kaspa stores block time in milliseconds, and kaspa pools send something like 1787647789790 in mining.notify. KRNX is a krnxd fork: header.Time is in seconds, e.g. 1787647640. The node verifies the seal with that same field:

// consensus/kheavyhash/consensus.go
powValue := kHeavyHashPowValue(matrix, sealHash, header.Time, header.Nonce.Uint64())

A miner drops the number it is given straight into the pre-image. Multiply it by 1000 and the miner hashes a different pre-image, so the node rejects every solution it finds:

pow(seconds)       48a81dc862655be0467039c2f0b1b5f98c8a4a13f656676633aa4c587b3e4a18
pow(milliseconds)  83ecb0f6068f5c8e60093716fbbd7b0cddedb581ed01617672c539e9fffb910f

The same nonce that seals a block with seconds seals nothing with milliseconds. The rule is simple: send exactly the number the header carries.

Where to get it

From work[10] — hex, seconds, nothing to parse:

"0x6a8d5549"  ->  1787647305

The same number sits inside the RLP header in [9], which is how it gets verified (below) and which is also the field per-connection work needs in section 8. header.Time is at index 11 there:

ParentHash   3 Root        6 Bloom        9  GasLimit   12 Extra
UncleHash    4 TxHash      7 Difficulty   10 GasUsed    13 BaseFee (if present)
Coinbase     5 ReceiptHash 8 Number       11 Time

A full RLP library is unnecessary: skip eleven fields and read the twelfth. Implementations in four languages are in section 10. One more source is --miner.notify.full: the node POSTs the header as JSON with timestamp as its own field.

Proving the time is right

The seal hash covers Time, so the header from [9] can be re-hashed and compared with [0], and its header.Time compared with [10]. Both matching proves the number is the one the node will verify against. One subtlety: before RLP-encoding, the node appends four zero bytes to Extra (room for an ethash-style extra nonce that kHeavyHash never uses). To get the seal hash, strip those four bytes and take keccak256(rlp(fields)). A ready implementation is verifyWorkSealHash in cmd/krnx-kheavyhash-stratum-bridge/node.go. A mismatch is expected in exactly one case: the header carries a KRNX AuxPoW root, which [9] does not report.

Do not roll the time

Time is part of the seal hash. Change it and PRE_POW_HASH changes, and with it the matrix: the result is a different work package, one the node does not have. The kHeavyHash stratum dialect has no ntime rolling — miners never touch the timestamp.

5. Difficulty: two scales

Scale	Target	Used by
KRNX consensus	2^256 / difficulty	the node, `getWork()[2]`
Stratum (kaspa)	(2^224 − 1) / difficulty	miners, `mining.set_difficulty`

Stratum difficulty 1 is worth about 2^32 hashes. Hence:

difficulty_stratum = difficulty_consensus / 2^32
share_target       = (2^224 - 1) / share_difficulty
hashes_per_share   = share_difficulty * 2^32

Confusing the two is a factor of 2^32 in the books: either miner hashrate reads four billion times too low, or shares arrive in a flood the pool never sized for. For example, a network difficulty of 4.3·10^12 is 1000 on the miner scale, and a difficulty-125 share costs roughly 5.4·10^11 hashes. Rules that hold wherever the chain’s difficulty happens to sit:

Do not hard-code the starting difficulty — derive the band from the current network difficulty: start at netdiff/8, floor at netdiff/4096, ceiling at netdiff.
The ceiling is netdiff for a reason: above it every share is a block anyway, and the pool goes blind to a miner that produces nothing.
A share that solves a block is always accepted, even when it misses the current vardiff bound.

Miner hashrate is estimated as usual: Σ (share_difficulty * 2^32) / elapsed.

6. Stratum: the kaspa dialect

The full exchange (captured from a working bridge):

miner -> {"id":1,"method":"mining.subscribe","params":["GMiner/3.28"]}
pool  -> {"id":1,"result":[true,"EthereumStratum/1.0.0"],"error":null}
miner -> {"id":2,"method":"mining.authorize","params":["krnx.rig1","x"]}
pool  -> {"id":2,"result":true,"error":null}
pool  -> {"id":null,"jsonrpc":"2.0","method":"mining.set_extranonce","params":["0001",6]}
pool  -> {"id":null,"jsonrpc":"2.0","method":"mining.set_difficulty","params":[0.0000816]}
pool  -> {"id":1,"jsonrpc":"2.0","method":"mining.notify",
          "params":["1",[4581632339856567309,5783595065747121291,
                         6077351350858350511,17714875238603159769],1787647640]}
miner -> {"id":3,"method":"mining.submit","params":["krnx.rig1","1","0001000000000527"]}
pool  -> {"id":3,"result":true,"error":null}

Message	Rule
`mining.subscribe`	reply exactly `[true,"EthereumStratum/1.0.0"]`; `params[0]` is the user agent and decides the job format
`mining.authorize`	reply `true`; the `user.worker` login is an accounting label
`mining.set_extranonce`	`[hex prefix, how many nonce bytes the miner keeps]`
`mining.set_difficulty`	`[float]` on the scale from section 5
`mining.notify`	`[jobId, [4×uint64], timestamp]`
`mining.submit`	`[worker, jobId, nonce hex]`, answered with `true` or a stratum error

Two job formats

Ordinary: the seal hash read as four little-endian uint64s:

words[i] = LE_uint64(seal_hash[i*8 : i*8+8])

The miner reassembles the same 32 bytes from them. The third parameter is the timestamp (section 4). Big job (BzMiner, IceRiver, Goldshell and several ASIC stacks): instead of the array and the time, a single 80-character hex string — the first 40 bytes of the pre-image:

hex(seal_hash) + hex(timestamp as u64 LE)

For example 353bd663…7b003b + 9d578d6a00000000 (= 1787647901). Which format to use is decided by a regex on the mining.subscribe user agent.

Extra nonce

The prefix occupies the high bytes of the 64-bit nonce; the miner rolls the rest. Two prefix bytes give 65536 connections and 48 bits of search space each. Never hand out more than three: an ASIC exhausts what is left in a fraction of a second. On submit a miner sends either all eight bytes (0x0001000000000527) or only its own part (000000000527). When fewer than 16 - len(prefix) hex characters arrive, the pool prepends the prefix itself.

7. Submitting a block

curl -sS -H 'Content-Type: application/json' --data '{
  "jsonrpc":"2.0","id":2,"method":"krnx_submitWork","params":[
    "0x0001000000000527",
    "0x7bbec5a103d39fcd618e0233e6b872f8b1824f4e4d326ae5a4ef35f7736b3f9f",
    "0x0000000000000000000000000000000000000000000000000000000000000000"
  ]}' http://127.0.0.1:8545

Parameter	Rule
`nonce`	8 bytes, big-endian hex — precisely the 64-bit number the miner hashed
`powHash`	`getWork()[0]` of the work the nonce was found against, byte for byte
`mixDigest`	always 32 zero bytes. kHeavyHash has no mix; a non-zero one is rejected by consensus

The answer is true (block accepted) or false. false means one of:

the node no longer holds work with that powHash — a stale;
the PoW misses the target — the pool and the node disagree on the pre-image, most often the timestamp;
the block is too old relative to the current height.

The method takes an optional fourth parameter, the extra nonce. Pass it only if the pool built the work package itself following section 8; otherwise the node appends bytes to Extra, the seal hash changes and the PoW no longer matches. Do not tie the submission to the miner’s socket: a miner may drop the connection right after solving, and the block still has to go out. Ask for fresh work immediately after a submit — the template is spent either way.

8. Per-connection work and extradata

By default every miner is handed the same PRE_POW_HASH and separated only by its extra-nonce prefix inside the nonce. A pool can go further and give each connection a work package of its own, through the same mechanism ethash pools on krnxd use. work[9] reports the header with four zero bytes appended to Extra — the extra-nonce slot. The pool writes its own value there, hashes the header itself and serves that hash to miners:

pool_seal_hash = keccak256( work[9] with the four trailing bytes of the Extra
                             field replaced by the pool's value )

On submit the pool names the node’s seal hash (work[0] is the key the node looks work up by) and passes the same four bytes as the fourth parameter of krnx_submitWork. The node appends them to Extra, recomputes the seal hash and arrives at exactly the one the miner hashed:

{"method":"krnx_submitWork","params":[
  "0x0001000000000527",
  "0x7bbec5a103d39fcd618e0233e6b872f8b1824f4e4d326ae5a4ef35f7736b3f9f",
  "0x0000000000000000000000000000000000000000000000000000000000000000",
  "0x5030304c"
]}

What it buys:

work that is unique per connection or per worker — nonce spaces never overlap even without an extra nonce, and no two miners can find the same share;
the pool’s four bytes end up inside the KRNX block (header.Extra): a pool tag, a shift id, a server number.

The constraints are all hard:

Rule	Why
exactly four bytes	an in-place replacement keeps every RLP length prefix valid; another length means re-encoding the header
patch the `Extra` field (index 12), not the tail of the blob	`BaseFee` is encoded after `Extra`, so patching “the last four bytes” corrupts it
the node’s `--miner.extradata` must be ≤ 28 bytes	`Extra` plus four bytes has to stay inside `params.MaximumExtraDataSize` = 32
keep the value next to the work package	on submit it must match the bytes the seal hash was computed with
never substitute `work[0]` on submit	it is the node’s lookup key, not what the miner hashed

The code (Go; the other languages are in the examples, section 10):

// field 12 is Extra; end is the offset just past its payload
extra, end, err := field(headerRLP, 12)
patched := append([]byte(nil), headerRLP...)
copy(patched[end-len(extraNonce):end], extraNonce) // the pool's four bytes

hasher := sha3.NewLegacyKeccak256()
hasher.Write(patched)
poolSealHash := hasher.Sum(nil) // the PRE_POW_HASH for this connection

The scheme is pinned by TestKHeavyHashRemoteWorkWithPoolExtraNonce in consensus/kheavyhash: it patches the four bytes, mines kHeavyHash against the resulting seal hash, submits through krnx_submitWork and checks that the node accepted the block, that the sealed block’s Extra ends with the pool’s tag, and that the header hashes back to the pool’s seal hash. Any of the examples reproduces it:

go run . --extranonce P00L --scan 100000

All four implementations produce the same pool seal hash on the same template — e47d91b45cfbf3b878af24b59ad3376ac4f8b0b5bbda032dde8428fefa761bd6 for extraNonce = 5030304c.

9. What you may and may not change

Free:

What	Bounds
nonce	all 64 bits, minus the extra-nonce prefix bytes
share difficulty	your own vardiff, see section 5
job format	ordinary or big job, per user agent
the four extra-nonce bytes	per-connection work and a tag in the block, section 8

Not allowed:

What	Result
multiplying the timestamp by 1000	every solution rejected
rolling the timestamp	a different seal hash, i.e. work the node never issued
a non-zero `mixDigest`	`errInvalidMixDigest`
passing an extra nonce without hashing the header yourself (section 8)	the seal hash changes, the PoW stops matching
altering `powHash` on submit	”Work submitted but none pending”
share difficulty above the block difficulty	every share is a block, miner stats go blind

10. Code examples

Complete working clients (fetch work → decode the timestamp → compute difficulty → scan nonces → submit a block) live in docs/examples/kheavyhash-pool/. All of them are checked against the golden vector from section 3 and run against a live node.

Language	Directory	Scan rate (M1, single thread)
Go	`go/`	≈ 265 kH/s
Node.js	`node/`	≈ 52 kH/s
Rust	`rust/`	≈ 580 kH/s (release)
Rust on kaspa crates	`rust-kaspa-crates/`	—
Python	`python/`	≈ 4 kH/s

Python and Node.js are fast enough to validate an integration, not to hash for real. Below is the core of each implementation: building the pre-image and both cSHAKE256 passes.

10.1 Go

// PowValue hashes PRE_POW_HASH || TIME || 32 zero bytes || NONCE and reads the
// result little-endian, exactly like the node.
func PowValue(matrix *Matrix, prePowHash [32]byte, timestamp, nonce uint64) *big.Int {
	var pre [80]byte
	copy(pre[:32], prePowHash[:])
	binary.LittleEndian.PutUint64(pre[32:40], timestamp)
	binary.LittleEndian.PutUint64(pre[72:80], nonce)

	first := cshake256("ProofOfWorkHash", pre[:])
	final := matrix.heavyHash(first)
	for i, j := 0, len(final)-1; i < j; i, j = i+1, j-1 {
		final[i], final[j] = final[j], final[i]
	}
	return new(big.Int).SetBytes(final[:])
}

func cshake256(domain string, data []byte) [32]byte {
	hasher := sha3.NewCShake256(nil, []byte(domain)) // golang.org/x/crypto/sha3
	hasher.Write(data)
	var out [32]byte
	hasher.Read(out[:])
	return out
}

Targets and scales:

var stratumDiffOneTarget = new(big.Int).Sub(new(big.Int).Lsh(big.NewInt(1), 224), big.NewInt(1))

// the share target for a stratum difficulty
func difficultyToTarget(difficulty float64) *big.Int {
	target, _ := new(big.Float).Quo(new(big.Float).SetInt(stratumDiffOneTarget), big.NewFloat(difficulty)).Int(nil)
	return target
}

// network difficulty on the miner scale: 2^256/D against (2^224-1) is D/2^32
func stratumDifficulty(blockTarget *big.Int) float64 {
	value, _ := new(big.Float).Quo(new(big.Float).SetInt(stratumDiffOneTarget), new(big.Float).SetInt(blockTarget)).Float64()
	return value
}

Inside the node the algorithm is already exported, so a Go pool living in this repository does not reimplement it:

job := kheavyhash.NewKHeavyHashJob(sealHash)        // the matrix, computed once
value := job.PowValue(header.Time, nonce)       // pre-image plus both passes
target := kheavyhash.KHeavyHashTarget(difficulty)   // 2^256/difficulty

10.2 Node.js

const { cshake256 } = require('js-sha3');

// PRE_POW_HASH || TIME || 32 zero bytes || NONCE -> pow value as a BigInt
function powValue(matrix, prePowHash, timestamp, nonce) {
  const pre = new Uint8Array(80);
  pre.set(prePowHash, 0);
  new DataView(pre.buffer).setBigUint64(32, BigInt(timestamp), true); // LE
  new DataView(pre.buffer).setBigUint64(72, BigInt(nonce), true);     // LE

  const first = cshake('ProofOfWorkHash', pre);
  const final = heavyHash(matrix, first);

  let value = 0n; // little-endian reading
  for (let i = 31; i >= 0; i--) value = (value << 8n) | BigInt(final[i]);
  return value;
}

function cshake(domain, data) {
  return Uint8Array.from(Buffer.from(cshake256(data, 256, '', domain), 'hex'));
}

The verification path: the same timestamp out of work[9], without an RLP library:

function headerTimestamp(headerRlpHex) {
  const data = Buffer.from(headerRlpHex.replace(/^0x/, ''), 'hex');
  let offset = listPayloadOffset(data);
  for (let i = 0; i < 11; i++) offset = nextField(data, offset).next; // Time is field 11
  return BigInt('0x' + nextField(data, offset).payload.toString('hex'));
}

10.3 Rust

Own implementation on the sha3 crate:

use sha3::digest::{ExtendableOutput, Update, XofReader};
use sha3::{CShake256, CShake256Core};

/// PRE_POW_HASH || TIME || 32 zero bytes || NONCE, returned big-endian.
pub fn pow_value(matrix: &Matrix, pre_pow_hash: &[u8; 32], timestamp: u64, nonce: u64) -> [u8; 32] {
    let mut pre = [0u8; 80];
    pre[..32].copy_from_slice(pre_pow_hash);
    pre[32..40].copy_from_slice(&timestamp.to_le_bytes());
    pre[72..80].copy_from_slice(&nonce.to_le_bytes());

    let first = cshake256(b"ProofOfWorkHash", &pre);
    let mut value = matrix.heavy_hash(first);
    value.reverse(); // the node reads little-endian; reversed, it compares as a number
    value
}

fn cshake256(domain: &[u8], data: &[u8]) -> [u8; 32] {
    let mut hasher = CShake256::from_core(CShake256Core::new(domain));
    hasher.update(data);
    let mut out = [0u8; 32];
    hasher.finalize_xof().read(&mut out);
    out
}

10.4 Reusing the rusty-kaspa hasher

Yes — the hasher from Kaspa’s own node plugs in directly, because the pre-image and the domains are identical. Two crates from rusty-kaspa are enough: kaspa-hashes (both cSHAKE256 passes, implemented as pre-computed Keccak states and therefore faster than a generic cSHAKE) and kaspa-pow (the matrix).

[dependencies]
kaspa-hashes = { git = "https://github.com/kaspanet/rusty-kaspa", branch = "master", features = ["no-asm"] }
kaspa-pow    = { git = "https://github.com/kaspanet/rusty-kaspa", branch = "master" }

use kaspa_hashes::{Hash, PowHash};
use kaspa_pow::matrix::Matrix;

let seal = Hash::from_bytes(seal_hash_bytes);   // krnx_getWork()[0]
let matrix = Matrix::generate(seal);            // once per work package
let first = PowHash::new(seal, timestamp)       // timestamp is header.Time, SECONDS
    .finalize_with_nonce(nonce);
let mut value = matrix.heavy_hash(first).as_bytes();
value.reverse();                                // little-endian -> comparable number

Verified: this reproduces the golden vector from section 3 bit for bit. Three notes:

features = ["no-asm"] is required off x86_64 (Apple Silicon, for instance): by default kaspa-hashes expects the assembly KeccakF1600 built for x86_64.
Do not use kaspa_pow::State::new(header) — it takes a Kaspa header and derives pre_pow_hash and the target from bits itself. KRNX already has the seal hash, and the target comes from getWork()[2]. Use PowHash and Matrix directly.
PowHash::new(hash, timestamp) receives milliseconds in Kaspa and seconds in KRNX. The function only places the number into the pre-image; no conversion.

10.5 Python

from Crypto.Hash import cSHAKE256   # pip install pycryptodome

def cshake256(domain: bytes, data: bytes) -> bytes:
    return cSHAKE256.new(data=data, custom=domain).read(32)

def pow_value(mat, pre_pow_hash: bytes, timestamp: int, nonce: int) -> int:
    """PRE_POW_HASH || TIME || 32 zero bytes || NONCE, read little-endian."""
    pre = pre_pow_hash + timestamp.to_bytes(8, "little") + bytes(32) + nonce.to_bytes(8, "little")
    first = cshake256(b"ProofOfWorkHash", pre)
    final = heavy_hash(mat, first)
    return int.from_bytes(final, "little")

Checking a whole work package:

work = call(rpc, "krnx_getWork")
seal_hash = bytes.fromhex(work[0][2:])
block_target = int(work[2], 16)
timestamp = int(work[10], 16)                   # seconds; work[9] is the cross-check
network_diff = ((1 << 224) - 1) / block_target  # block difficulty on the miner scale
matrix = generate_matrix(seal_hash)
value = pow_value(matrix, seal_hash, timestamp, nonce)
solved = value <= block_target

11. The ready-made bridge

The repository ships a working implementation of everything above: cmd/krnx-kheavyhash-stratum-bridge. It polls krnx_getWork, serves both job formats, scores shares with the node’s own hasher, runs vardiff and pushes blocks through krnx_submitWork:

go run ./cmd/krnx-kheavyhash-stratum-bridge \
  --krnx.rpc http://127.0.0.1:8545 --stratum.listen 0.0.0.0:5555

The scheme from section 8 is one flag away — every connection gets work of its own and the pool’s tag ends up in the block:

go run ./cmd/krnx-kheavyhash-stratum-bridge --work.unique --work.tag KR

It works both as a finished solo-mining front end and as a reference while writing your own: the bridge README documents every flag.

12. Integration checklist

krnx_getWork answers, and [0] changes when the template does.
Your hasher reproduces the golden vector from section 3.
The timestamp comes from [10]; the header from [9], with the four zero Extra bytes stripped, re-hashes to [0] and reports the same header.Time.
mining.notify ships the seal hash such that a miner rebuilds exactly [0] from the four words.
Difficulty is set on the (2^224−1)/diff scale and below the block difficulty.
A share that solves a block is accepted even if it misses the vardiff bound.
krnx_submitWork returns true and the chain height moves.
The node’s rejection rate is near zero. If it is not, see section 13.

13. Diagnostics

Symptom	Cause
The node rejects every solution while shares keep coming	the pre-image diverged: timestamp in milliseconds, taken from the wrong work package, or an implementation that misses the golden vector
`krnx_getWork` returns an error	the node runs without `--mine`, without an etherbase, or is still syncing
A miner connects and stays silent	share difficulty above the block difficulty (section 5) — every find leaves as a block
Many `false` answers from `krnx_submitWork` on valid shares	the template moved on: slow polling, or the miner works on stale jobs
”Work submitted but none pending” in the node log	the `powHash` on submit is not the one from the work package
The node logs `errInvalidMixDigest`	a non-zero `mixDigest` was submitted
Reported hashrate is orders of magnitude off	shares counted on the consensus scale instead of the stratum one (the gap is exactly 2^32)

Node

Mining

Build

Pool operator reference

1. What the node must provide

2. `krnx_getWork`

Push instead of polling

3. The kHeavyHash pre-image

Golden vector

4. The timestamp: seconds, not milliseconds

Where to get it

Proving the time is right

Do not roll the time

5. Difficulty: two scales

6. Stratum: the kaspa dialect

Two job formats

Extra nonce

7. Submitting a block

8. Per-connection work and extradata

9. What you may and may not change

10. Code examples

10.1 Go

10.2 Node.js

10.3 Rust

10.4 Reusing the rusty-kaspa hasher

10.5 Python

11. The ready-made bridge

12. Integration checklist

13. Diagnostics

​1. What the node must provide

​2. krnx_getWork

​Push instead of polling

​3. The kHeavyHash pre-image

​Golden vector

​4. The timestamp: seconds, not milliseconds

​Where to get it

​Proving the time is right

​Do not roll the time

​5. Difficulty: two scales

​6. Stratum: the kaspa dialect

​Two job formats

​Extra nonce

​7. Submitting a block

​8. Per-connection work and extradata

​9. What you may and may not change

​10. Code examples

​10.1 Go

​10.2 Node.js

​10.3 Rust

​10.4 Reusing the rusty-kaspa hasher

​10.5 Python

​11. The ready-made bridge

​12. Integration checklist

​13. Diagnostics

1. What the node must provide

2. `krnx_getWork`

Push instead of polling

3. The kHeavyHash pre-image

Golden vector

4. The timestamp: seconds, not milliseconds

Where to get it

Proving the time is right

Do not roll the time

5. Difficulty: two scales

6. Stratum: the kaspa dialect

Two job formats

Extra nonce

7. Submitting a block

8. Per-connection work and extradata

9. What you may and may not change

10. Code examples

10.1 Go

10.2 Node.js

10.3 Rust

10.4 Reusing the rusty-kaspa hasher

10.5 Python

11. The ready-made bridge

12. Integration checklist

13. Diagnostics