# RX_DRAGONX Wire Protocol & Nonce Handling Spec (miner113 xmrig fork)

Source tree analyzed: `/home/dev/xmrig` (C++ xmrig fork, "miner113"/"Duke Leto" DragonX additions).
Scope: ONLY the `RX_DRAGONX` (DragonX / Hush Smart Chain) algorithm path.
All line references are to files under `/home/dev/xmrig/`.

> TL;DR for the pool implementer:
> - Stratum `algo` string is exactly **`rx/dragonx`**.
> - DragonX header (pre-nonce) is **108 bytes**; the full hashed blob is **140 bytes** (108 header + 32-byte nonce). Pool may send the blob either as a 140-byte hex `blob` (standard `job` notify) or as a Zcash-style `mining.notify` params array.
> - Nonce is a **32-byte field at offset 108** (`nonceOffset()=108`, `nonceSize()=32`).
> - In **pool/stratum** mode only the **uint32 at bytes [108:112]** of the nonce varies, starting from **0** with **no randomization**, driven by the global atomic counter. Bytes **[112:140] stay exactly as the pool sent them in the blob** (normally all zero). There is **no pool-assigned extra_nonce** applied to the DragonX nonce. => Two miners on the same job WILL scan identical nonce values unless the pool differentiates the blob per-connection. See §3 "BOTTOM LINE".
> - Submit JSON: `{id, job_id, nonce(64 hex = 32 bytes), result(64 hex = 32-byte RandomX hash), algo:"rx/dragonx"}`.
> - Share filter = `double_sha256(140-byte header || 0x20 || rx_hash)`; submit if the **last 8 bytes (little-endian uint64 at offset 24)** `< job.target()`. Same metric for shares and blocks (no separate block-target check).

---

## 1. ALGORITHM IDENTITY

### Enum / id
- `Algorithm::RX_DRAGONX = 0x72151264` — `src/base/crypto/Algorithm.h:83`.
- Family is computed as `id & 0xff000000` for non-CN algos: `0x72151264 & 0xff000000 = 0x72000000 = RANDOM_X` (`src/base/crypto/Algorithm.h:98` `RANDOM_X = 0x72000000`, `:180` `family()`). So `RX_DRAGONX.family() == Algorithm::RANDOM_X`. This matters: all the `family()==RANDOM_X` branches in the miner apply to DragonX.
- `l2()`/`l3()` derive from the id bytes like other RandomX algos (`Algorithm.h:178`); DragonX uses the standard RandomX scratchpad size (2 MiB) via its config (see below).

### Stratum algo string (the exact "algo" JSON value)
- Canonical name string: **`"rx/dragonx"`** — `src/base/crypto/Algorithm.cpp:87` (`kRX_DRAGONX = "rx/dragonx"`), registered in `kAlgorithmNames` at `:154` via `ALGO_NAME(RX_DRAGONX)`. `Algorithm::name()` returns this string, and it is what gets put into the submit `algo` field (§4).
- Accepted aliases (case-insensitive, `kAlgorithmAliases`, `src/base/crypto/Algorithm.cpp:270-272`):
  - `"rx/dragonx"` (auto, from name)
  - `"randomx/dragonx"`
  - `"randomdragonx"`
  - `"dragonx"`
- The pool may name the algo via the pool config `"algo": "rx/dragonx"` and/or `"coin": "dragonx"` (see `config-dragonx.json` lines 8-9). When a `job` carries an `"algo"` string it is parsed by `job.setAlgorithm(algo)` (`Client.cpp:382`); otherwise the coin's algorithm is inferred from the blob version byte (`Client.cpp:384-390`). Note: `RX_DRAGONX` is **not** present in `Coin.cpp`'s coin table, so coin-based inference does not map to DragonX; the `"algo"` string (or pool `algorithm()` default) is the reliable identity. The Zcash-style `mining.notify` path keys off `m_pool.algorithm() == RX_DRAGONX` (`Client.cpp:815`).

### RandomX parameters / seed handling (customized)
- Config selected in `RxAlgo::base()`: `case Algorithm::RX_DRAGONX: return &RandomX_DragonXConfig;` — `src/crypto/rx/RxAlgo.cpp:52-53`.
- DragonX RandomX configuration — `src/crypto/randomx/randomx.cpp:94-101`:
  ```
  ArgonIterations   = 5
  ArgonSalt         = "RandomXHUSH\x03"
  ProgramSize       = 512
  ProgramIterations = 4096
  ProgramCount      = 16
  ```
  (All other parameters inherit `RandomX_ConfigurationBase`: `ArgonLanes=1`, `SuperscalarLatency=170`, etc. — `randomx.cpp:123+`.)
- RandomX program version: `RxAlgo::version()` returns `104` for everything except RX_WOW (`RxAlgo.cpp:63-66`), so DragonX = 104.
- Seed: standard RandomX `seed_hash` (32 bytes). Delivered over stratum in the `seed_hash` field and stored via `Job::setSeedHash()` which requires exactly 64 hex chars (`Job.cpp:193-206`). In solo mode the seed comes from the daemon's `randomxseedhash` getblocktemplate field (`JunoRpcClient.cpp:539`). No DragonX-specific seed transformation — the seed bytes are used directly as the RandomX cache key.

---

## 2. JOB FORMAT (pool -> miner)

There are **two** delivery formats handled by `Client.cpp`:

### 2a. Standard JSON `job` notify (method `"job"` / login result) — `Client.cpp:365 parseJob`
JSON fields consumed (object `params`):
| field | required | code | how consumed |
|-------|----------|------|--------------|
| `job_id` | yes | 3 | `job.setId()` (`Client.cpp:374`) |
| `algo` | optional | — | `job.setAlgorithm(algo)` (`Client.cpp:379-382`); should be `"rx/dragonx"` |
| `blob` | yes | 4 | `job.setBlob(blobData)` (`Client.cpp:405`) — full 140-byte hex blob |
| `target` | yes | 5 | `job.setTarget()` (`Client.cpp:411`) |
| `height` | optional | — | `job.setHeight(Json::getUint64(...))` (`Client.cpp:416`) |
| `seed_hash` | yes (RANDOM_X) | 7 | `job.setSeedHash()` (`Client.cpp:423`) — DragonX is RANDOM_X family, so required |
| `sig_key` | optional | — | `job.setSigKey()` (`Client.cpp:428`) — 128 hex (64-byte) miner-signature key; normally absent for DragonX |
| `extra_nonce`, `pool_wallet` | only MODE_SELF_SELECT | 4 | `Client.cpp:393-401`; **not used in normal DragonX pool mode** |

In this format the pool supplies the entire blob (header + nonce placeholder) as hex.

### 2b. Zcash-style `mining.notify` (DragonX-specific) — `Client.cpp:814-873`
Only taken when `method == "mining.notify"` AND `m_pool.algorithm() == RX_DRAGONX`. `params` is an **array** with >= 9 elements (`Client.cpp:816`):
```
[ job_id, version, prevhash, merkleroot, blockcommitments, time, bits, clean_jobs, seed_hash ]
   [0]      [1]       [2]        [3]            [4]          [5]   [6]      [7]         [8]
```
- `version`,`time`,`bits` are hex strings parsed with `strtoul(...,16)` (`Client.cpp:838` for time; version/bits parsed inside `setZcashJob`).
- `clean_jobs` is a bool, currently **ignored** (`Client.cpp:836` `(void)cleanJobs`).
- Job built via `job.setZcashJob(version, prevHash, merkleRoot, blockCommitments, time, bits)` (`Client.cpp:846`).
- `seed_hash` via `job.setSeedHash()` (`Client.cpp:852`).
- Target: this path sets a **placeholder** target of all-`f`s (`Client.cpp:860`) or default diff 1 (`:861`). Real target is expected from `mining.set_difficulty`. NOTE: **there is currently NO handler for `mining.set_difficulty`** in `Client.cpp` (grep shows only the comment) — i.e. in pure Zcash-notify mode the effective target stays at the placeholder unless the pool also sends a standard `job`. The reliable, fully-wired path is **2a** (standard `job` with a real `target`).

### The blob: size and layout

**Pool sends 140 bytes** (108-byte header + 32-byte nonce placeholder). Evidence:
- `setBlob` minimum-size check: `minSize = nonceOffset() + nonceSize()` = `108 + 32 = 140` (`Job.cpp:74`), and it rejects `size < minSize` (`Job.cpp:75`). So a blob shorter than 140 bytes (e.g. a 108-byte header-only blob) is **rejected** in path 2a.
- `setZcashJob` builds the 108-byte header then sets `m_size = 140` reserving the 32-byte nonce slot (`Job.cpp:180`).
- `setJunoHeader` (solo) copies 108 bytes and sets `m_size = 140` (`Job.cpp:185-191`).

So: the on-wire `blob` for path 2a should be **140 bytes = 280 hex chars**, with bytes [108:140] (the nonce) normally zero.

`setBlob` details (`Job.cpp:61-94`):
- hex string length must be even (`:68`), `size = len/2`.
- `minSize = 140`, must satisfy `140 <= size < sizeof(m_blob)=408` (`:74-77`, `kMaxBlobSize=408` `Job.h:50`).
- `Cvt::fromHex` into `m_blob` (`:79`).
- If the existing nonce dword (`readUnaligned(nonce())`, i.e. uint32 at offset 108) is non-zero, `m_nicehash` is force-enabled (`:83-85`). For DragonX the placeholder is zero so this stays false.
- stores `m_size = size` (`:92`).

### Header layout (the 108-byte DragonX header) — `setZcashJob` `Job.cpp:96-183`
| offset | size | field | byte order in blob |
|-------:|-----:|-------|--------------------|
| 0 | 4 | version (nVersion) | little-endian (raw `strtoul` value memcpy'd) `Job.cpp:115-117` |
| 4 | 32 | prevHash | **byte-reversed** display->internal `Job.cpp:119-133` |
| 36 | 32 | merkleRoot | **byte-reversed** display->internal `Job.cpp:135-149` |
| 68 | 32 | blockCommitments | **byte-reversed** display->internal `Job.cpp:151-165` |
| 100 | 4 | time (nTime) | little-endian `Job.cpp:167-169` |
| 104 | 4 | bits (nBits compact) | little-endian `Job.cpp:171-174` |
| 108 | 32 | nonce | (mining field; see §3) |

Byte-order rule: the three 32-byte hashes arrive from getblocktemplate / pool in **display (big-endian) order** and are reversed to **internal (little-endian) order** for hashing (each `m_blob[pos+i] = temp[31-i]`). version/time/bits are stored little-endian directly. The solo `JunoRpcClient` builds the identical 108-byte layout manually (`JunoRpcClient.cpp:548-583`) — note it copies the already-internal-order hashes (`m_headerPrevHash` etc.) straight in without re-reversing, because those buffers were stored in internal order when parsed.

`setJunoHeader(const uint8_t* header108)` (`Job.cpp:185-191`): bypasses hex/reverse logic, memcpy's a ready-made 108-byte header, sets `m_size=140`. Used only by solo `JunoRpcClient` (`JunoRpcClient.cpp:587`).

> There is no function named `setDragonxHeader`. The DragonX header is built either by `setZcashJob` (stratum Zcash-notify) or `setJunoHeader` (solo), or delivered pre-built as the 140-byte `blob` (standard `job`).

### Target parsing & diff conversion — `Job::setTarget` `Job.cpp:209-250`
- For DragonX (not RX_YADA), `target` hex is decoded by `Cvt::fromHex` and interpreted by length:
  - **4 bytes**: `m_target = 0xFFFFFFFFFFFFFFFF / (0xFFFFFFFF / u32)` (`Job.cpp:219-220`) — "compact" 32-bit difficulty-style target.
  - **8 bytes**: `m_target = u64` read directly (little-endian) (`Job.cpp:222-223`).
  - other lengths => 0 => rejected.
- After parsing, `m_diff = toDiff(m_target)`.
- `toDiff(target) = target ? (0xFFFFFFFFFFFFFFFF / target) : 0` — `Job.h:121`.
- `setTarget64(u64)` is the direct setter used by solo: `m_target = u64; m_diff = toDiff(u64)` (`Job.h:107`). Solo computes `target64` from the compact `bits` field (`JunoRpcClient.cpp:604-635`), extracting the 64-bit window at byte offset 24 of the 256-bit target.
- The mining comparison is always `pow_value(uint64) < m_target` (see §5). Larger `m_target` = easier.

---

## 3. NONCE HANDLING  (most important)

### nonceOffset / nonceSize
- `nonceOffset()` for RX_DRAGONX = **108** — `Job.cpp:271-273`.
- `nonceSize()` for RX_DRAGONX = **32** — `Job.h:84-86` (`if (algorithm()==RX_DRAGONX) return 32;`).
- The DragonX nonce field therefore occupies blob bytes **[108:140]** (32 bytes).

### Two distinct nonce regimes

DragonX uses a different nonce strategy depending on mining mode (`Job::isSoloMining()` / `WorkerJob::isSoloMining()`):

#### (A) POOL / STRATUM mode (`isSoloMining()==false`)  — the standard incrementing 32-bit counter
- `WorkerJob::nonce()` for DragonX returns a `uint32_t*` pointing at blob offset 108 (`WorkerJob.h:46`, and the `N==1` specialization `:150-153`). It only ever treats the nonce as a **uint32**.
- Starting value & seeding: the global atomic counter `Nonce::m_nonces[index]` starts at **0** (`Nonce.cpp:27` `m_nonces[2] = {0,0}`) and is **reset to 0** on every job change (`Miner.cpp:124` `Nonce::reset(job.index())`, which sets `m_nonces[index]=0`, `Nonce.h:44`). There is **no randomization** of the starting nonce in pool mode.
- `Nonce::next()` (`Nonce.cpp:33-65`): `fetch_add(reserveCount)` on the shared counter, then writes `(*nonce & ~mask) | counter` into the **uint32 at offset 108** (`:57`). The `nonce+1` (offset 112) write at `:59-61` only happens when `mask > 0xFFFFFFFF`. For DragonX `nonceMask()` = `0xFFFFFFFF` (because `nonceSize()=32 != sizeof(uint64_t)=8` and not nicehash → the `0xFFFFFFFFULL` branch of `Job.h:93`), so **only bytes [108:112] are ever written**; bytes [112:139] are untouched by the nonce machinery.
- Per-round increment: `WorkerJob::nextRound` adds `roundSize` (=1) to the uint32 at 108 each hash, and every `kReserveCount`(=32768) hashes grabs a fresh range via `Nonce::next` (`WorkerJob.h:69-87`, specialization `:156-176`; `CpuWorker::nextRound` `CpuWorker.cpp:480-500`, `kReserveCount` `CpuWorker.cpp:82`).
- WHICH bytes vary: **only the 4 bytes [108:112]** (a little-endian uint32) increment. Bytes **[112:139] stay exactly as they were in the blob the pool sent** (all zero for a normal placeholder).
- The full 32-byte nonce that gets hashed and submitted is read from the blob at offset 108 each round and saved before increment: `CpuWorker.cpp:342-344` (`memcpy(current_solo_nonces + i*32, m_job.blob() + nonceOffset() + i*job.size(), 32)`). So the submitted nonce = `[ varying uint32 LE | 28 bytes copied verbatim from the blob (normally zero) ]`.

#### (B) SOLO mode (`isSoloMining()==true`) — random 256-bit nonce per thread
- Solo nonces are managed by `SoloNonce` and `WorkerJob`'s solo path, NOT by the global `Nonce` counter.
- `WorkerJob::initSoloNonces()` (`WorkerJob.h:99-105`) calls `SoloNonce::initialize()` per thread then copies the 32 bytes into the blob at offset 108.
- `SoloNonce::initialize` (`SoloNonce.cpp:39-61`): fills all 32 bytes with **cryptographically secure random** (`/dev/urandom`, or `BCryptGenRandom` on Windows; fallback `mt19937_64`), then **zeros bytes [0:2]** (low 16 bits, increment space) and **zeros bytes [30:32]** (top 16 bits, safety margin). Net: ~224 random bits per thread.
- `WorkerJob::nextRoundSolo` (`WorkerJob.h:107-114`) does a full little-endian 256-bit `SoloNonce::increment` (`SoloNonce.cpp:64-72`) each round and re-copies to the blob — never exhausts.
- So in solo every thread/instance gets a distinct random high-entropy nonce, and the whole 32-byte field is meaningful and submitted (`result.soloNonce()`).

### extra_nonce application
- DragonX standard stratum path does **NOT** apply any `extra_nonce` to the nonce field. `Job::setExtraNonce`/`extraNonce()` (`Job.h:103`,`:79`) are only set in `MODE_SELF_SELECT` (`Client.cpp:394`) and consumed only by `SelfSelectClient` (`SelfSelectClient.cpp:172`) — a different code path that does not run for DragonX pool mining. The DragonX worker code (`CpuWorker.cpp`) never reads `extraNonce()`.
- `nonceMask()` does reference `extraNonce().size()` but only for the `nonceSize()==sizeof(uint64_t)` (KawPow) case (`Job.h:93`); for DragonX (`nonceSize()==32`) the mask is the constant `0xFFFFFFFF`, independent of extra_nonce.

### BOTTOM LINE (miner-to-miner / thread-to-thread overlap)
- **Across threads of one miner instance:** no overlap. The shared atomic `Nonce::m_nonces[index]` hands out disjoint `reserveCount`(32768)-sized ranges to each thread via `Nonce::next` (`Nonce.cpp:40`). Threads scan different uint32 ranges of [108:112].
- **Across two separate miners (or one miner reconnecting) on the SAME job from a pool, in stratum/pool mode:** they **WILL scan the exact same nonce values**. Both start their counter at 0 (reset on job change, `Miner.cpp:124`; initial `m_nonces={0,0}`), there is **no per-connection randomization**, and bytes [112:139] are identical (the zero placeholder from the blob). Nothing in the miner prevents the overlap.
  - => To avoid duplicate-share work, the **pool MUST differentiate the job per connection**, e.g. by writing a unique value into the nonce placeholder bytes **[112:139]** of the per-miner `blob` (those bytes are preserved verbatim by the miner and included in the hash + submitted nonce), and/or into other header fields. There is no `extra_nonce` JSON mechanism wired for DragonX, so per-miner uniqueness has to be baked into the `blob` (path 2a) the pool sends.
- **Solo mode** is the only mode with built-in cross-instance collision avoidance, via the 224-bit random `SoloNonce` (§3B). This randomization does **not** apply to pool mode.

---

## 4. SUBMIT FORMAT (miner -> pool)

### Stratum submit (`Client::submit`, `Client.cpp:181-251`)
JSON-RPC `"submit"` with `params` object:
| field | value | reference |
|-------|-------|-----------|
| `id` | `m_rpcId` (login id string) | `Client.cpp:223` |
| `job_id` | `result.jobId` | `Client.cpp:224` |
| `nonce` | hex of `result.nonceBytes()`, length `nonceSize()` bytes | `Client.cpp:211`,`:225` |
| `result` | hex of the 32-byte hash `result.result()` | `Client.cpp:212`,`:226` |
| `sig` | hex of 64-byte miner signature, **only if present** | `Client.cpp:214-216`,`:229-231` (absent for normal DragonX) |
| `algo` | `result.algorithm.name()` = `"rx/dragonx"`, only if `EXT_ALGO` negotiated and algo valid | `Client.cpp:238-240` |

### `nonce` field for DragonX = 32 bytes => 64 hex chars. Confirmed.
- `nonceHexSize = result.nonceSize()*2 + 1` (`Client.cpp:203`); for DragonX `nonceSize()==32` → 64 hex chars (+NUL).
- `Cvt::toHex(nonce, nonceHexSize, result.nonceBytes(), result.nonceSize())` writes all 32 bytes (`Client.cpp:211`).
- Contents = the **full 32-byte nonce field** from the blob as hashed: in pool mode `[ uint32 LE counter | 28 zero bytes ]`; in solo `[ random 256-bit nonce ]`. (`result.nonceBytes()`/`m_nonceBytes`, populated per constructor — see below.)
- `m_tempBuf` was enlarged to 512 bytes specifically to hold the 64-char nonce + result + sig (`Client.cpp:86`, comment "Increased for RX_DRAGONX 32-byte nonce support").

### `result` field = the 32-byte RandomX hash (PoW solution) => 64 hex chars. Confirmed.
- `Cvt::toHex(data, 65, result.result(), 32)` (`Client.cpp:212`). `result.result()` = `m_result[32]`, the RandomX hash `m_hash` for that nonce (passed into the JobResult ctor in `CpuWorker.cpp:449`). It is **not** the double-SHA256 pow_hash; it is the raw RandomX output (so the pool can re-verify `randomx(blob,seed)==result` and recompute `double_sha256` itself).

### JobResult constructors used — `src/net/JobResult.h`
- DragonX uses the **32-byte-nonce / solo-style constructor**: `JobResult(const Job&, const uint8_t* nonce32, const uint8_t* result)` (`JobResult.h:94-107`). It copies `m_result=result`, `m_nonceBytes=nonce32` (full 32 bytes), sets `m_nonceSize=32`, and `m_isSoloResult=true`.
  - This is what `CpuWorker` calls for DragonX: `JobResults::submit(JobResult(job, current_solo_nonces + i*32, m_hash + i*32))` (`CpuWorker.cpp:449`). Same call shape is used for solo (`CpuWorker.cpp:457`).
- The uint64-nonce constructor `JobResult(job, uint64 nonce, result, ...)` (`JobResult.h:46-80`) is the **standard XMRig path** for non-DragonX algos (`CpuWorker.cpp:459`). NOTE: that constructor *does* contain a DragonX special-case (`JobResult.h:70-79`: for RX_DRAGONX set `m_nonceSize=32`, zero 32 bytes, write only first 8 from the uint64), but **the DragonX worker branch never uses it** — it always uses the 32-byte ctor. So the effective DragonX submit nonce always carries the true 32-byte field from the blob (low 4 bytes vary, rest as-sent), not a truncated 8-byte value.

### Solo submit (`JunoRpcClient`)
Solo does NOT use the stratum `submit` JSON. `JunoRpcClient::submit` → `submitBlock` (`JunoRpcClient.cpp:141-149`, `:358-443`) assembles a full raw block hex and calls daemon `submitblock` (JSON-RPC 1.0). The block = 108-byte header + `result.soloNonce()` (32 bytes, `:394-395`) + `0x20` solution-length varint + `result.result()` (32-byte rx hash, `:399-400`) + tx count + coinbase + txs. The nonce/result semantics match the stratum submit (32-byte nonce, 32-byte rx hash).

---

## 5. POW HASH / SHARE FILTER  (`src/backend/cpu/CpuWorker.cpp`)

### `dragonx_pow_hash` — `CpuWorker.cpp:106-117`
```c
static inline void dragonx_pow_hash(const uint8_t* blob, const uint8_t* rx_hash, uint8_t* out) {
    uint8_t full_header[173];
    memcpy(full_header,       blob,    140);  // header(108) + nonce(32)
    full_header[140] = 0x20;                  // compact_size = 32 (solution length)
    memcpy(full_header + 141, rx_hash, 32);   // RandomX hash = PoW solution
    uint8_t tmp[32];
    SHA256(full_header, 173, tmp);
    SHA256(tmp,          32, out);            // double SHA256
}
```
Exact 173-byte layout:
| offset | size | content |
|-------:|-----:|---------|
| 0 | 108 | header base (version, prevHash, merkleRoot, blockCommitments, time, bits) |
| 108 | 32 | 32-byte nonce (this round's nonce) |
| 140 | 1 | `0x20` (CompactSize = 32, the solution length) |
| 141 | 32 | RandomX hash result (`m_hash` for this nonce) |

Output = `SHA256(SHA256(full_header[173]))`. `SHA256` is OpenSSL when TLS is built, else sph_sha256 (Linux) / BCrypt (Windows) (`CpuWorker.cpp:41-67`). Confirmed byte layout matches the daemon's `CBlockHeader::GetHash()`.

The `blob_for_header[140]` fed to `dragonx_pow_hash` is reconstructed as `m_job.blob()[0:108]` (header, unchanged by nextRound) + `current_solo_nonces[i][0:32]` (the saved 32-byte nonce *before* increment) — `CpuWorker.cpp:435-441`. This guarantees the hashed nonce == the submitted nonce.

### Submit condition for RX_DRAGONX — `CpuWorker.cpp:425-450`
```c
alignas(8) uint8_t pow_hash[32];
dragonx_pow_hash(blob_for_header, m_hash + i*32, pow_hash);
const uint64_t pow_value = *reinterpret_cast<uint64_t*>(pow_hash + 24);  // last 8 bytes, LE
if (pow_value < job.target()) {
    JobResults::submit(JobResult(job, current_solo_nonces + i*32, m_hash + i*32));
}
```
- `pow_value` = little-endian uint64 read from `pow_hash[24..31]` (the last 8 bytes) — `CpuWorker.cpp:444`.
- Submit iff `pow_value < job.target()` — `CpuWorker.cpp:445`.
- This is **uniform**: there is exactly one comparison, identical in solo and pool mode. No `m_job.isSoloMining()` branch inside the DragonX block (contrast the standard path at `CpuWorker.cpp:454-460`, which does branch solo vs pool only to pick the JobResult constructor — DragonX skips that and always uses the 32-byte ctor).

### No separate block_target check. Confirmed.
- The only target compared anywhere on the DragonX path is `job.target()` against `pow_value`. There is **no** second comparison against a distinct network/block target in `CpuWorker.cpp` (grep: the DragonX block has a single `< job.target()` test at `:445`). Shares and blocks use the **same** double-SHA256 metric; whether a submitted share is also a block is determined by the pool/daemon comparing the same `double_sha256` against the real network target (the comments at `CpuWorker.cpp:446-448` state the pool does the block-vs-share distinction). The miner submits every share whose `double_sha256` beats the pool-set `job.target()`.

---

## 6. SOLO vs POOL behavior

| aspect | POOL / stratum (`Client`) | SOLO (`JunoRpcClient` / daemon) |
|--------|---------------------------|---------------------------------|
| job source | `parseJob` (140-byte `blob`) or Zcash `mining.notify` (`setZcashJob`) | getblocktemplate → `setJunoHeader` (`JunoRpcClient.cpp:587`) |
| `isSoloMining()` | false | true (`JunoRpcClient.cpp:640`) |
| nonce field | uint32 counter at [108:112], rest = blob bytes (zero); starts 0, no randomization | random 224-bit `SoloNonce`, per-thread, 256-bit increment |
| nonce bytes scanned | only [108:112] vary | full 32 bytes meaningful |
| RandomX hashing | `randomx_calculate_hash_first/next`, `family()==RANDOM_X` branch (`CpuWorker.cpp:366-384`) — **identical** | same |
| pow hash + filter | `dragonx_pow_hash`, `pow_value < job.target()` (`CpuWorker.cpp:425-450`) — **identical** | **identical** (same code, no branch) |
| JobResult ctor | 32-byte ctor `JobResult(job, nonce32, result)` (`CpuWorker.cpp:449`) | same 32-byte ctor (`CpuWorker.cpp:449`) |
| target derivation | from pool `target` hex (`Job::setTarget`) | from compact `bits` → `setTarget64` (`JunoRpcClient.cpp:604-635`) |
| submit transport | JSON-RPC `submit` {id,job_id,nonce,result,algo} (`Client::submit`) | daemon `submitblock` with full serialized block (`JunoRpcClient::submitBlock`) |

**Key point:** the **CpuWorker hashing and the share/PoW filter are byte-for-byte identical** in solo and pool for DragonX (same `randomx_calculate_hash_*`, same `dragonx_pow_hash`, same `pow_value < job.target()`, same 32-byte JobResult). The differences are entirely in (a) **nonce seeding** (random 256-bit solo vs zero-start uint32 pool) and (b) **submission transport** (raw `submitblock` vs stratum `submit`). The `m_isSoloMining` flag only switches nonce management (`CpuWorker.cpp:337-344`, `nextRound`→`nextRoundSolo` `:483-484`) and submit transport — not the hash math or the difficulty test.

---

## Quick reference — exact JSON shapes

### Pool -> miner (standard `job`)
```json
{
  "jsonrpc": "2.0",
  "method": "job",
  "params": {
    "job_id":   "<id>",
    "algo":     "rx/dragonx",
    "blob":     "<280 hex chars = 140 bytes: 108-byte header + 32-byte nonce placeholder>",
    "target":   "<8 or 16 hex chars (4 or 8 LE bytes)>",
    "height":   <int>,
    "seed_hash":"<64 hex chars = 32-byte RandomX seed>"
  }
}
```
(For per-miner nonce-space separation, set distinct values in blob bytes [112:140], i.e. hex chars 224..280.)

### Miner -> pool (`submit`)
```json
{
  "id": <seq>,
  "jsonrpc": "2.0",
  "method": "submit",
  "params": {
    "id":     "<rpcId from login>",
    "job_id": "<id>",
    "nonce":  "<64 hex chars = full 32-byte nonce field>",
    "result": "<64 hex chars = 32-byte RandomX hash>",
    "algo":   "rx/dragonx"
  }
}
```
Pool verification (per the miner's contract): recompute `rx = randomx(seed_hash, header[0:108] || nonce)` and require `rx == result`; then compute `double_sha256(header[0:108] || nonce || 0x20 || rx)` and compare its last 8 bytes (LE uint64 at offset 24) against the share target (and against the network target for block detection).