Issue: Operator/Spender Identity Lost in RuleEngine Hooks (burn/mint/cross-chain)

[rya-sge]

Severity: informational
Version concerned: CMTAT v3.0.0, v3.1.0, v3.2.0

Summary

In some operator-initiated flows, CMTAT previously dropped the effective operator identity before calling the RuleEngine transfer hook.
As a result, spender-aware RuleEngine policies were not consistently enforced in those paths.

This corresponds to Sequent report Finding 3 (crosschainMint, crosschainBurn, burnFrom), and also affects equivalent operator-routed burn/mint paths.

Impact

• Policy-consistency issue for deployments using RuleEngine rules that target spender/operator semantics.
• No direct role bypass for unprivileged users (entry points remain role-protected).
• Could allow operations to pass when an issuer expected operator-specific RuleEngine restrictions to block them.

Root Cause

Some mint/burn write paths reached _checkTransferred(...) with spender = address(0), which routes to spender-less RuleEngine logic.

Implemented Fix

Operator-as-spender propagation was implemented so the effective operator (_msgSender()) is preserved in RuleEngine write hooks for:

1. burn
2. batchBurn
3. burnFrom
4. mint
5. batchMint
6. crosschainBurn
7. crosschainMint

Test Coverage Added/Updated

• test/common/ERC20BurnModuleCommon.js
  • testBurnPropagatesSpenderToRuleEngine
  • testBurnWithRuleEngineAuthorizedSpenderCanBurn
  • testBatchBurnPropagatesSpenderToRuleEngine
  • testBatchBurnWithRuleEngineAuthorizedSpenderCanBurn
• test/common/ERC20MintModuleCommon.js
  • testMintPropagatesSpenderToRuleEngine
  • testMintWithRuleEngineAuthorizedSpenderCanMint
  • testBatchMintPropagatesSpenderToRuleEngine
  • testBatchMintWithRuleEngineAuthorizedSpenderCanMint
• test/common/ERC20CrossChainModuleCommon.js
  • testBurnFromPropagatesSpenderToRuleEngine
  • testBurnFromWithRuleEngineAuthorizedSpenderCanBurn
  • testCrosschainMintPropagatesSpenderToRuleEngine
  • testCrosschainMintWithRuleEngineAuthorizedSpenderCanMint
  • testCrosschainBurnPropagatesSpenderToRuleEngine

Scope Note

This issue is relevant only for CMTAT deployments where:

• RuleEngine is configured, and
• active rules explicitly enforce spender/operator-specific policy.