CMTATBaseCommon: DocumentEngine and ERC20Enforcement should be optional to stay under EIP-170

[sideris]

Problem

After upgrading from v3.1.0 to v3.2.0, our Token contract (extends CMTATBaseRuleEngine) exceeds the EIP-170 24,576 byte limit.

The v3.2.0 changelog states:

DocumentEngine and SnapshotEngine removed from constructors and initialization
(#343) to simplify deployment and reduce bytecode size.

However, DocumentEngineModule and the new ERC20EnforcementModule (ERC-7943) are still compiled into every token that inherits CMTATBaseCommon, even if never initialized or called. The init parameter removal saves a few bytes, but the new ERC-7943 module adds significantly more.

Root Cause

CMTATBaseCommon unconditionally inherits both modules:

abstract contract CMTATBaseCommon is
    VersionModule,
    ERC20MintModule,
    ERC20BurnModule,
    ERC20BaseModule,
    SnapshotEngineModule,
    ERC20EnforcementModule,  // ← always compiled in (new in v3.2.0)
    DocumentEngineModule,     // ← always compiled in
    ExtraInformationModule,
    IBurnMintERC20,
    IERC5679

Any token extending CMTATBaseRuleEngine → CMTATBaseAccessControl → CMTATBaseCommon pays the bytecode cost for both modules regardless of usage.

Proposal

Introduce a CMTATBaseCommonLight (or similar) that includes SnapshotEngineModule but excludes DocumentEngineModule and ERC20EnforcementModule:

CMTATBaseCore — minimal (no snapshot, no doc, no enforcement)
CMTATBaseCommonLight — Core + SnapshotEngine + ExtraInformation
CMTATBaseCommon — full (snapshot + doc + ERC-7943 enforcement)

Alternativess

Make DocumentEngineModule and ERC20EnforcementModule opt-in mixins that consumers add to their own inheritance

The corresponding CMTATBaseAccessControl and CMTATBaseRuleEngine would
need light variants too, or they could be parameterized.

[rya-sge]

Hello @sideris,

Thanks a lot for your feedback.

We will explore options to improve the separation of the different modules within the base contract.

I agree that a version which support RuleEngine, but not DocumentEngine could really make sense.

For ERC20Enforcement, we have a preference to keep it. But we will also explore options

We will try to do it for the next release

Best!
Ryan