fix: resolve #879 #880 #881 #882 — tests, shared royalty logic, docs, benchmarks

[darkcode123456]

Summary

Closes #879,
Closes #880,
Closes #881,
Closes #882.

---

#881 — Encryption key rotation compatibility (security/bug)

New file: src/__tests__/encryptionKeyRotationCompatibility.test.js (16 tests, all pass)

• Documents and verifies the JS wire format: [ 12-byte IV | 16-byte auth-tag | ciphertext ]
• Asserts JS 32-byte AES key ↔ contract BytesN<32> secret are the same type/size
• Verifies commitment derivation SHA-256(secret ∥ blinding_factor) matches contract logic
• Full rotation flow test: old key encrypts, history records old commitment, new key decrypts new payload
• Confirms keys are not cross-compatible (ciphertext isolation enforced by GCM auth-tag)
• Docs: encryption byte format + key rotation compatibility section added to docs/atomic-swap.md

---

#879 — Royalty calculation consistency (bug)

New file: src/royalty/royaltyCalculation.js — canonical shared module
New file: src/__tests__/royaltyConsistency.test.js (31 tests, all pass)

• Extracts the royalty formula into a single shared module imported by both swapRoyaltyTracker.js and batchRoyaltyDistributor.js
• Asserts both modules produce identical totalRoyalty, sellerProceeds, per-beneficiary amounts, and dust assignment for the same inputs
• Canonical formula:

  totalRoyalty = floor(salePrice × rateBps / 10000)
  amount_i     = floor(totalRoyalty × shareBps_i / 10000)
  dust → first beneficiary
  

• Docs: full formula, invariants, and worked example added to docs/atomic-swap.md

---

#880 — Property-based tests for batchFeeCalculator (testing)

New file: src/__tests__/batchFeeCalculator.property.test.js (15 tests, all pass)
New dep: fast-check@3.22.0 (dev)

Properties tested with 200 random runs each:

1. Non-negativity — all fee fields ≥ 0
2. Bounded ceiling — netFee ≤ swap value + base fee
3. Monotonicity — higher volume → higher/equal fee; higher volume → lower/equal feeBps
4. Split invariant — protocolFee + lpFee === netFee within float tolerance
5. Discount bounds — discount ∈ [0, grossFee)
6. Totals consistency — batch totals equal sum of individual fees
7. Discount direction — discount can only reduce fees
8. Override feeBps — always honoured over tier selection

---

#882 — Compression benchmarks for batchCompressor (testing/performance)

New file: scripts/benchmark-batchCompressor.test.js (7 tests, all pass)
New file: src/__tests__/batchCompressor.fuzz.test.js (12 tests, all pass)
New file: docs/PERFORMANCE.md — baseline numbers

Benchmark results (Node v24.14.0, zlib deflate, 200 iterations):

Scenario	Ratio	Compress	Decompress
1 swap	1.81×	0.020 ms	0.007 ms
10 swaps	7.07×	0.029 ms	0.015 ms
50 swaps	10.24×	0.095 ms	0.050 ms
100 swaps	10.86×	0.185 ms	0.107 ms

Fuzz tests use fast-check to assert compress → decompress is a lossless identity for arbitrary swap structures (300 random runs).

---

What was tested

• All 5 new test files pass ✅
• No regressions introduced in existing passing tests ✅
• Pre-existing failures in batchRoyaltyDistributor.test.js (3 tests) are unrelated to this PR

[drips-wave]

@darkcode123456 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits