Constant MAX_SSA_BATCH_SIZE 

pub const MAX_SSA_BATCH_SIZE: usize = 9;

Hard ceiling on both SSA batch-size knobs, whatever the configuration says.

The current maximum value of 9 is based on the current available pool limitations.

Deliberately far below the wire limit (StartProtocol::MAX_SSAS_PER_REQUEST, 27), which only bounds what can be decoded. The real cost is paid on both sides of the exchange and neither is small at the profiled dimensions:

• Entry: every entry in the batch is a full new_ssa_commitment (hundreds of thousands of EC commitments), its own burst of thousands of SsaCommit packets, and its own ReadyToDeposit — i.e. its own on-chain deposit.
• Exit: every entry is a live reconstructor cycle, held until that cycle recovers — worst case ≈41 MiB at the deployed dimensions (hopr_protocol_pix::peak_cycle_bytes), so ≈820 MiB per Session at this ceiling, before the pipelining factor. That is what a Session reserves against IncomingSessionPixConfig::max_live_cycle_bytes, so raising the batch size directly divides how many PIX Sessions the node will accept.

It also bounds the supervisor’s deadline scaling: a batch multiplies both max_ssa_delivery_time and max_deposit_wait, and that product is what decides how long a Session may be served unincentivized.

Both SupervisorConfig::ssas_per_request and SessionManagerConfig::max_ssas_per_ssa_request are clamped to 1..=Self where they are read, so a programmatically built config that never calls validate() cannot exceed it.