Document solo pool baseline for Salvium and Peya

Architecture.md

@@ -22,7 +22,7 @@
 - `/mnt/duzy/sal11v4/sal/salvium` — Salvium source tree
 - `/mnt/duzy/sal11v4/zeph/zephyr` — Zephyr source tree
 - `/mnt/duzy/sal11v4/cryptonote-nodejs-pool` — pool source tree for the next integration layer
-- `/mnt/duzy/sal11v4/node-cryptoforknote-util-salvium` — Salvium-oriented util backend for pool-side blob/template work
+- `/mnt/duzy/sal11v4/node-cryptoforknote-util-salvium` — shared Salvium/Peya util backend for pool-side blob/template work
 - `/mnt/duzy/sal11v4/xmrig` — local XMRig fork/source used for miner-side integration tests
 
 ### Additional Gitea Repositories
@@ -204,3 +204,42 @@ Hardfork heights are intentionally early because Peya does not need historical c
   - parent block serialization
   - parent coinbase interpretation
   - parent seed hash / PoW semantics
+
+## Pool Layer Status
+
+### Current Direction
+- the next integration layer is `cryptonote-nodejs-pool`
+- the pool is being adapted first for solo mining, not merge mining
+- the util backend is now being treated as an adapter host, not as a single-coin fork
+
+### Shared `Salvium/Peya` Util
+- `node-cryptoforknote-util-salvium` is now the active util for both:
+  - current Salvium
+  - current Peya
+- the intended shape is:
+  - shared `salvium-family` core
+  - small coin-specific adapter branches where needed
+- first concrete Peya-specific adapter need already confirmed:
+  - Peya block parsing after `HF_VERSION_MERGE_MINING`
+  - current Peya blocktemplate carries the `has_aux_header` tail even for solo blocks
+  - Salvium util had to learn that block suffix to parse current Peya templates
+
+### Solo Pool Validation
+- the pool layer has now been validated with `daemon + pool + xmrig` in three modes:
+  - local `Salvium -> pool -> xmrig`
+  - public Salvium testnet `-> pool -> xmrig`
+  - local `Peya -> pool -> xmrig`
+- concrete runtime result:
+  - local Salvium mined blocks successfully through the pool
+  - public Salvium testnet accepted shares cleanly through the pool on current Carrot-era templates
+  - local Peya accepted shares and mined blocks successfully through the pool after the util gained the Peya block adapter
+
+### Pool Compatibility Scope
+- for the current solo-mining milestone, the minimum compatibility set is:
+  - current carrot-only address validation for Salvium
+  - current carrot-only address validation for Peya
+  - current asset-aware transfer fields for Salvium/Peya payout code
+  - blocktemplate parsing for:
+    - current Salvium
+    - current Peya
+- legacy/carrot transition logic from earlier Salvium experiments is no longer considered part of the target architecture

Handover.md

@@ -20,6 +20,7 @@ Current work area:
 - merge mining implementation and hardening
 - parent-chain compatibility analysis
 - operating handoff for future agent instances
+- pool-layer bringup for current Salvium and current Peya
 
 Current `salvium` HEAD:
 - `f23c8e2fb` `Keep development MM signer enabled on testnet`
@@ -60,6 +61,67 @@ Current `salvium` HEAD:
 - The new multi-parent groundwork builds cleanly:
   - `peyad`
   - `peya-merge-mining-proxy`
+- Pool layer now works for solo mining on:
+  - current local Salvium
+  - current public Salvium testnet
+  - current local Peya
+
+### Latest Pool-Layer Findings
+- Active pool repo:
+  - `/mnt/duzy/sal11v4/cryptonote-nodejs-pool`
+- Active util repo:
+  - `/mnt/duzy/sal11v4/node-cryptoforknote-util-salvium`
+- Current goal was intentionally reduced to the minimum useful milestone:
+  - no merge mining yet at the pool layer
+  - just solo mining support for current Salvium and current Peya
+- Earlier Salvium transition logic for legacy/carrot crossover is no longer part of the target:
+  - current work assumes carrot-era only
+  - this matches both current Salvium use and Peya use
+
+- Pool-side code changes that were necessary before runtime testing:
+  - switched pool dependency from the old generic util to the local Salvium util
+  - replaced broken `bignum` share-difficulty path in `lib/pool.js` with native `BigInt`
+  - made `lib/notifications.js` lazy-load optional email/telegram modules so mining tests no longer depend on the telegram stack
+  - simplified address validation/runtime helpers in `lib/utils.js` toward current carrot-only `Salvium` and `Peya`
+  - updated pool daemon template-address selection in `lib/daemon.js`
+  - generalized payout-side asset fields in `lib/paymentProcessor.js` for asset-aware coins instead of only `SAL1`
+
+- Util-side direction:
+  - `node-cryptoforknote-util-salvium` is now being used as a shared `Salvium/Peya` util, not a single-coin utility fork
+  - this is being treated as the first real adapter layer for future multi-coin pool support
+
+- Critical concrete Peya parser finding:
+  - current Peya `blocktemplate_blob` does not fail because of addresses or token metadata
+  - the concrete blocker was block parsing:
+    - Salvium util did not know Peya's `HF13+` block suffix
+    - after `tx_hashes`, current Peya block serialization includes `has_aux_header` and optional `aux_header`
+  - even for solo blocks this trailing `has_aux_header` byte exists, so old util parsing failed with:
+    - `Failed to parse block 2`
+  - util was updated with a minimal Peya-aware block adapter so `convert_blob(..., 15)` now parses current Peya templates successfully
+
+- Runtime validation completed with `daemon + pool + xmrig`:
+  - local Salvium:
+    - accepted shares through the pool
+    - mined multiple blocks through the pool
+    - local parent height advanced from `1600` to `1605` during the validated run window
+  - public Salvium testnet:
+    - accepted shares cleanly through the pool against `explorer-testnet.salvium.io:29081`
+    - hard-fork context observed in pool logs: current templates parsed as `Hard fork version: 11`
+    - this was enough to confirm pool compatibility with live public testnet templates
+  - local Peya:
+    - accepted shares cleanly through the pool after the util parser fix
+    - hard-fork context observed in pool logs: `Hard fork version: 14`
+    - mined multiple local blocks successfully through the pool
+    - confirmed examples:
+      - block `9f19eb...` at height `149`
+      - block `25d900...` at height `150`
+      - block `77976c...` at height `152`
+
+- Current practical conclusion:
+  - the minimum solo-pool milestone is reached
+  - current Salvium and current Peya can be mined through the pool with XMRig
+  - the shared util approach for `Salvium + Peya` is viable
+  - next pool-layer work should happen on a separate branch and can build on this as the stable solo baseline before adding merge-mining support
 
 ### Verified Not Working
 - `Zephyr -> Peya` as parent/aux pair is not currently compatible without code changes.

Pool-Merge-Mining-Notes.md

@@ -251,6 +251,43 @@ To jest prostsze operacyjnie.
 
 Na start to wygląda rozsądniej niż runtime hot-switching.
 
+## 10.1. Updated Practical Direction
+
+Po pierwszym wejściu w kod poola kierunek został doprecyzowany:
+
+- nie robimy osobnego utila dla Peyi
+- aktywny cel to wspólny util `Salvium + Peya`
+- util ma być rozwijany już teraz jako warstwa adapterów, a nie jako zbiór doraźnych ifów
+
+Dlaczego:
+
+- `Peya` jest dużo bliżej `Salvium` niż `Zephyr` jest `Monero`
+- obecne rozjazdy między `SAL` i `PEY` okazały się punktowe
+- najważniejszy dotąd rozjazd był konkretny:
+  - aktualny `Peya blocktemplate_blob` po `HF13` zawiera ogon blokowy z `has_aux_header`
+  - stary util Salvium tego nie parsował
+- to jest typ różnicy, który dobrze pasuje do wspólnego utila z adapterami per coin family
+
+Wniosek roboczy:
+
+- `node-cryptoforknote-util-salvium` powinien ewoluować w util `salvium-family`
+- później można dołożyć kolejne adaptery, w tym ewentualnie `Zephyr`
+- nie należy zakładać, że `blobType 15` oznacza dokładnie jeden format bloku
+
+## 10.2. Solo Pool Baseline Is Done
+
+Warstwa poolowa ma już osiągnięte minimum bazowe bez merge miningu:
+
+- local `Salvium -> pool -> xmrig`
+- public Salvium testnet `-> pool -> xmrig`
+- local `Peya -> pool -> xmrig`
+
+To daje dobry punkt startowy przed osobnym branch-em pod:
+
+- integrację poola z `peya-merge-mining-proxy`
+- klasyfikację `parent-only / aux-only / dual`
+- politykę payoutów dla merge miningu
+
 ## 11. Czy Wiele Pooli Może Jednocześnie Kopać Różne Parenty Dla Peyi
 
 Tak.