fix(xmr): S06 - enforce signer and daemon identity contracts

ZlyDevMayarequested to merge
zly/s06-xmr-signer-contract into develop

Series context

S06 of the focused replacement MRs for the superseded XMR MR !4983 (closed).

  • Scope: fail-closed XMR signer startup compatibility, Monero daemon identity verification, scanner-rewind identity, and Compose profile wiring
  • Base: develop
  • THORNode dependencies: none
  • External dependency: Serai !70 provides the required /info identity contract and capabilities
  • Merge prerequisite: replace the temporary Serai !70 (merged) integration image with a reviewed published digest
  • Reuse: the first commit is intentionally self-contained so it can be cherry-picked into other XMR series branches that need working simulation profiles

Changes

Make XMR client construction fail closed unless both identities are configured and verified:

  • require chain_network for the Monero daemon identity,
  • require signer_expected_network for the THOR deployment identity,
  • accept only the canonical chain_network values mocknet, mainnet, stagenet, and testnet,
  • require the canonical observation, transaction-location, and Monero-network-identity capabilities,
  • compare the signer-reported Monero nettype and genesis hash against the configured daemon network,
  • use the signer deployment identity—not the Monero daemon identity—as the scanner-rewind compare-and-set token,
  • reject caller-supplied rewind identities that conflict with the configured signer identity,
  • remove the unused context-aware compatibility wrappers.

Update the mocknet, chainnet, and stagenet Compose profiles to:

  • pin the exact Serai !70 (merged) integration image,
  • provide the signer-specific bearer and insecure-HTTP settings expected by Bifrost,
  • keep the THOR deployment identity separate from the Monero daemon identity,
  • use the signer’s supported request-limit environment variables.

Document the complete /v1/monero/info contract, canonical network mappings, and restart-only compatibility policy.

Rollout

Compatibility and daemon identity are checked once during XMR client construction. Replacing the signer or changing its daemon requires a Bifrost restart. Runtime hot-swapping and background revalidation are not supported.

The currently pinned Serai !70 (merged) image is integration-only. It enables review and simulation, but it is not approval for production activation. Replace it with a reviewed published digest before merging or enabling economic XMR behavior.

This MR does not change consensus state, key-share persistence, or ceremony wire formats, and it does not activate production XMR keygen or scanning.

Merge request reports