Add one-parent multi-aux future note

Pool-Merge-Mining-Notes.md

@@ -783,3 +783,52 @@ Taki fork może być natomiast:
 - łatwiejszy do dodania do schedulera parentów
 
 ale nadal jako osobny parent, nie jako drugi równoległy cel tego samego joba.
+
+### 20.7. Jeden parent, wiele aux chainów
+
+Osobnym i dużo bardziej realistycznym wariantem niż „wiele parentów jednym jobiem” jest:
+
+- jeden parent
+- wiele aux chainów
+
+Przykładowy przyszły układ:
+
+- `Monero` jako parent
+- `Tari` jako jedna aux chain
+- `Peya` jako druga aux chain
+
+To nie byłby model:
+
+- wiele parentów naraz
+
+tylko:
+
+- jeden parentowy job
+- kilka niezależnych aux ścieżek budowanych z tego samego parentowego wysiłku
+
+To jest architektonicznie bliższe klasycznemu merge miningowi niż jakiekolwiek próby wspólnego template dla `Monero`, `Zephyra` i `Salvium`.
+
+### 20.8. Kiedy taki wariant miałby sens dla Peyi
+
+Dziś najbardziej realistyczne parenty dla Peyi to:
+
+- `Salvium`
+- `Zephyr`
+
+Jeśli jednak w przyszłości Peya urosłaby na tyle, że:
+
+- `Salvium` byłby zbyt małym parentem
+- a nawet `Zephyr` przestałby być wystarczającą bazą bezpieczeństwa
+
+to wejście w bardziej dojrzały tor:
+
+- `Monero -> Peya`
+
+mogłoby mieć sens.
+
+W takim scenariuszu rozbudowa o:
+
+- `Monero -> Tari + Peya`
+
+stałaby się ciekawym wariantem strategicznym.  
+To nadal wymagałoby nowej warstwy integracyjnej, bo obecny `peya-merge-mining-proxy` obsługuje tylko jedną aux chain. Nie byłby to jednak problem wspólnego template dla wielu parentów, tylko problem obsługi wielu aux chainów nad jednym parentem.