SettleMint
ArchitectureSecurityCompliance Modules

Overview

How DALP compliance modules enforce per-asset rules for identity, geography, supply, approvals, collateral, and holding periods before regulated EVM token operations execute.

Overview

DALP compliance modules are reusable smart-contract controls that each asset configures for itself. Before a regulated EVM token mints or transfers, the token asks its compliance engine to run the selected modules with that token's parameters. One failed module blocks the operation.

Use this page to choose the right architecture page before you configure a module, review an asset policy, or explain why a mint or transfer was blocked.

How to read this section

Runtime model

The compliance engine sits in front of asset activity. The engine loads the controls selected for the token and passes token-specific parameters to each one. Evaluation stops as soon as one control rejects the request.

A control reads only the state that control needs: OnchainID claims, country codes, address lists, supply counters, approvals, collateral claims, or TimeLock batches.

Rendering diagram...

Several controls also record state after a successful mint or transfer. Investor-count modules update holder counts. Issuance-volume modules update issuance windows. Transfer-approval modules consume approvals. TimeLock modules record acquisition batches.

Configuration model

The shared module catalog contains reusable contracts, such as country lists, identity checks, transfer approval, collateral, and TimeLock.

The per-token asset policy stores the selected controls, their order, and their encoded parameters for one token.

Identity and issuer records tell claim-based modules which holder identities, trusted issuers, claim topics, and country codes count for the asset.

Operational records hold mutable state, such as investor counts, issuance windows, approvals, and TimeLock batches.

A deployed module can serve multiple tokens, but each token keeps its own policy. DALP validates module parameters before accepting the configuration, so reusable logic still produces token-specific enforcement.

Ownership boundary

DALP enforces the on-chain checks. Your organisation owns the policy choices and off-chain evidence that those checks depend on:

DALP runs selected modules before regulated mints and transfers. Your organisation chooses modules and parameters that match the asset policy.

DALP reads OnchainID claims and trusted issuers. Your organisation operates or integrates KYC/KYB, sanctions, accreditation, or other evidence providers.

DALP stores and consumes transfer approvals according to the selected module. Your organisation decides who may approve transfers and how approval fits the operating process.

DALP checks caps, issuance windows, and collateral claims at mint time. Your organisation maintains source evidence, trusted verifiers, asset terms, and off-chain reserve operations.

DALP records acquisition batches and checks whether tokens are unlocked. Your organisation decides the policy basis for the hold period and any exemptions.

DALP does not replace legal advice, regulatory permissioning, custody policy, banking ledger reconciliation, or off-chain reserve operations. DALP gives the asset selected EVM token controls that can block or allow on-chain transactions.

Module index

Control familyModulesUse it for
Jurisdiction rulesCountryAllowList, CountryBlockListAllowing or blocking recipients by country code on the identity record
Identity and wallet listsIdentityAllowList, IdentityBlockList, AddressBlockListAllowing or blocking named investor identities or EVM wallet addresses
Claim-based eligibilitySMARTIdentityVerificationRequiring recipient OnchainID claims from trusted issuers
Supply and investor limitsTokenSupplyLimit, InvestorCountLimiting minted supply or investor counts over the configured scope
Fundraising value capCapitalRaiseLimitCapping gross raised fiat value through minting in a fixed or rolling window
Issuance quotaIssuanceVolumeLimitCapping token units issued during a fixed or rolling window
Transfer pre-approvalTransferApprovalRequiring identity-bound approval before a transfer can proceed
Backing and supply capCappedComplianceModule, CollateralComplianceModuleBlocking mints above supply cap or without a valid collateral claim
Minimum holding periodTimeLockPreventing transfer until configured acquisition batches have matured

Where modules apply

Module familyTransferMintBurnState update after success
Country restrictionsChecks recipient countryChecks recipient countryNot applicableNo
Identity verificationChecks recipient claimsChecks recipient claimsNot applicableNo
Identity listsChecks recipient identityChecks recipient identityNot applicableNo
Address block listChecks sender and recipient walletChecks recipient walletNot applicableNo
Supply limitsChecks cap where configuredChecks cap where configuredNot applicableYes, for rolling supply tracking
Capital raise limitPasses throughChecks gross raised fiat capPasses throughYes
Issuance volume limitPasses throughChecks issuance quotaReleases capacity by burn attributionYes
Investor countTracks new holdersTracks new holdersNot applicableYes
Transfer approvalChecks active approvalNot applicableNot applicableYes, approval consumption
TimeLockChecks unlocked balanceNot applicableNot applicableYes, acquisition batches
Supply capPasses throughChecks post-mint supplyNot applicableNo
CollateralPasses throughChecks collateral claimNot applicableNo

For the transfer-level sequence, see Compliance transfer flow. For the broader security model, see Security overview.

On this page