SettleMint
Compliance modules

Supply & Investor Limits

TokenSupplyLimit and InvestorCount modules for time-based and rolling supply caps with currency conversion, plus unique holder limits with per-country granularity.

Install TokenSupplyLimit when the asset terms set a ceiling on total issuance. Install InvestorCount when the policy limits the number of unique token holders, globally or per country. The two modules are independent and can run together on the same token.

Where these modules apply

Each module covers different on-chain operations.

ConcernTokenSupplyLimitInvestorCount
MintingEnforces cap (lifetime / fixed / rolling)Tracks new holders
TransfersNot checkedTracks new holders
BurnsNot checkedDecrements count
Forced transfersNot checkedTracks new holders after the transfer

TokenSupplyLimit

TokenSupplyLimit enforces the maximum token supply. Enable useBasePrice when the cap is denominated in EUR or USD rather than token units.

Interface (capabilities)

CapabilityWho can callInputsOn-chain effectEmitsNotes
setModuleParametersToken admin (via compliance)maxSupply, limitType, period, useBasePriceStores supply-limit config; validateParameters reverts if maxSupply = 0NoneCalling with maxSupply = 0 reverts; the cap must be a positive value
canTransfer (mint path)Compliance engineSender, recipient, amountChecks cumulative supply against limit (converts via price claim if useBasePrice)NoneOnly enforced on mints (from == address(0))

Supply limit types

TypeBehaviorUse case
LIFETIMETotal cap across the token's lifetimeMiCA EUR 8M asset-referenced token limit
FIXED_PERIODCap resets at the start of each periodQuarterly fundraising caps
ROLLING_PERIODSliding window of last N daysContinuous monitoring (rolling 12-month limits)

Base currency conversion

When an admin enables useBasePrice, the module converts token amounts using on-chain price claims before checking the supply limit. The conversion supports EUR- or USD-denominated caps on tokens priced in native units.

Key invariants

  • Supply limit applies to minting operations only. The module does not check transfers or burns.
  • ROLLING_PERIOD uses a sliding window; older mints fall off as time passes.
  • FIXED_PERIOD resets at the start of each new period, regardless of previous minting.
  • Calling setModuleParameters with maxSupply = 0 reverts; the cap must be a positive value.

Operational signals

The module emits no events. Monitor for ComplianceCheckFailed revert errors when minting exceeds the configured limit. You can detect a rejected mint by inspecting failed transactions for this revert.

Failure modes & edge cases

  • Missing or stale price feed when useBasePrice is active: minting reverts until a valid price claim exists.
  • ROLLING_PERIOD window boundary: mints near the window edge may succeed or fail depending on when older mints age out.

InvestorCount

InvestorCount restricts the number of unique token holders. The topicFilter determines which investors count toward the limit. Identity verification handles blocking; InvestorCount only tracks the headcount.

Interface (capabilities)

CapabilityWho can callInputsOn-chain effectEmitsNotes
setModuleParametersToken admin (via compliance)maxInvestors, countryCodes[], countryLimits[], topicFilter, global flagStores investor-count configNonetopicFilter uses the same RPN expression system as identity verification
canTransferCompliance engineSender, recipient, amountChecks if adding recipient would exceed global or country limitNoneSkips burns (to == address(0)); applies to mints and transfers

How it works

Investor stateIdentity module resultInvestorCount resultTransfer outcome
No KYC/AML claimsBlocked by identity moduleN/A (never reaches count check)Transfer blocked
Has qualifying claims, count < limitAllowedCountedTransfer allowed
Has qualifying claims, count = limitAllowedBlocked (over limit)Transfer blocked

topicFilter and limits

The topicFilter is a claim expression (same RPN system as SMARTIdentityVerification) that determines which investors count toward the limit. InvestorCount can enforce a global limit across all investors. It also supports per-country limits for jurisdiction-specific restrictions (e.g., max 50 Singapore residents).

Key invariants

  • canTransfer skips burns (to == address(0)) but applies to both mints and transfers.
  • The active tracker depends on the global flag. With global enabled, tokens using the same InvestorCount module instance share one investor tracker. Use separate module instances when your policies need isolated counts. Otherwise, counts are token-specific.
  • InvestorCount checks per-country limits independently of the global limit; both must pass when configured.
  • topicFilter determines who counts toward InvestorCount. Identity verification handles blocking.
  • InvestorCount does not count addresses without a registered identity. Use identity verification when your policy must block unverified recipients.

Operational signals

The module emits no events. Monitor for ComplianceCheckFailed revert errors when investor count exceeds the configured limit. If you see transfers failing unexpectedly, check whether the global or per-country limit has been reached.

Failure modes & edge cases

  • Forced transfers bypass the pre-transfer investor-limit check but still update holder tracking after the transfer. A forced transfer to a new holder can leave the current investor count above the configured limit. Later movements can bring the count back within policy.
  • Missing country code in the identity registry: InvestorCount counts the investor globally when a global limit is configured, but not toward a per-country limit.

See also

These pages cover related modules and complementary controls.

On this page