ProfitClient: `MIN_RELAYER_FEE_PCT_*` JSDoc example has origin/destination chain IDs swapped

[Nexory]

Summary

The JSDoc comment for minRelayerFeePct in src/clients/ProfitClient.ts documents the environment variable key format with chain IDs in the wrong order. The code constructs route keys as tokenKey_originChainId_destinationChainId, but the example shows Arbitrum (42161) before Optimism (10) while describing a trade from Optimism to Arbitrum. Any operator who follows the documented example will set a key that is never matched, silently leaving their minimum-fee override inactive.

What I observed

src/clients/ProfitClient.ts, lines 403–424:

/**
 * Allow the minimum relayer fee to be overridden per token/route:
 * 0.1bps on USDC from Optimism to Arbitrum:
 *   - MIN_RELAYER_FEE_PCT_USDC_42161_10=0.00001          ← swapped
 * 0.1bps from USDC on Optimism to USDT on Arbitrum:
 *   - MIN_RELAYER_FEE_PCT_USDC_USDT_42161_10=0.00001     ← swapped
 * ...
 */
minRelayerFeePct(...): BigNumber {
  ...
  const routeKey = `${tokenKey}_${originChainId}_${destinationChainId}`;  // origin first
  ...
}

The code on line 424 builds the key as originChainId_destinationChainId (Optimism=10 first, Arbitrum=42161 second), but the JSDoc example lists 42161 before 10. The text description ("from Optimism to Arbitrum") matches neither ordering clearly, making it ambiguous without reading the source.

Impact

Operators who configure minimum relayer fee overrides by following the documented example will use a key like MIN_RELAYER_FEE_PCT_USDC_42161_10 when the runtime expects MIN_RELAYER_FEE_PCT_USDC_10_42161. The mismatch is silent: no error is raised, the env var is simply never read, and the relayer falls back to the global default minimum fee. This means intended per-route fee floors are never enforced, potentially causing the relayer to accept trades below the operator's configured minimum.

Suggested fix

Update the JSDoc examples to match the actual key construction order (originChainId_destinationChainId) and add an explicit label so the ordering is unambiguous:

- * 0.1bps on USDC from Optimism to Arbitrum:
- *   - MIN_RELAYER_FEE_PCT_USDC_42161_10=0.00001
- * 0.1bps from USDC on Optimism to USDT on Arbitrum:
- *   - MIN_RELAYER_FEE_PCT_USDC_USDT_42161_10=0.00001
+ * 0.1bps on USDC from Optimism (chainId=10) to Arbitrum (chainId=42161):
+ *   - MIN_RELAYER_FEE_PCT_USDC_10_42161=0.00001
+ * 0.1bps from USDC on Optimism to USDT on Arbitrum (originChainId_destinationChainId):
+ *   - MIN_RELAYER_FEE_PCT_USDC_USDT_10_42161=0.00001

No logic change is needed; only the comment requires correction.

Notes

The same transposed ordering appears in both the single-token and the cross-token (USDC→USDT) examples, suggesting the comment was written with destination chain first and never reconciled with the implementation. Adding an explicit (originChainId_destinationChainId) annotation to the format description would prevent a recurrence.