CMTAT and T-REX have often been discussed as separate approaches to regulated asset tokenization.

CMTAT was initially designed around Swiss legal and financial-market requirements. It has since evolved into a more internationally adaptable framework for tokenized equities, debt instruments, structured products, funds, stablecoins, and other controlled financial assets.

T-REX, meaning Token for Regulated EXchanges, is an open-source protocol for issuing and managing permissioned tokens. It was initially created and developed by Tokeny and was subsequently formalized as the ERC-3643 Ethereum standard. Its development, security, standardization, and adoption are now supported by the nonprofit ERC3643 Association. In this article, T-REX refers to the permissioned-token protocol formally standardized as ERC-3643.

The distinction between CMTAT and T-REX is becoming less rigid. CMTAT v3.0.0 introduced T-REX-compatible functions and interfaces, while the CMTA RuleEngine can be used with both CMTAT and T-REX-compatible tokens. A CMTAT deployment can also consult a T-REX Identity Registry through the RuleIdentityRegistry rule.

This is not a merger of the two frameworks, nor does it mean they are legally interchangeable. It is a form of technical convergence that allows components from each architecture to be combined.

What T-REX Actually Is

T-REX means Token for Regulated EXchanges.

T-REX is an open-source suite of smart contracts for issuing, managing, and transferring permissioned tokens. Unlike a conventional ERC-20 token, a T-REX token can restrict ownership and transfers to participants who satisfy predefined identity and compliance requirements.

The protocol was originally developed under the T-REX name and was later formalized through the Ethereum standardization process as ERC-3643. The official implementation is now maintained in the ERC-3643 open-source organization, while the former Tokeny repository directs developers to the current ERC-3643 repository.

A typical T-REX deployment contains:

  • A permissioned token contract
  • An Identity Registry
  • Identity Registry Storage
  • A Claim Topics Registry
  • A Trusted Issuers Registry
  • A Compliance contract
  • ONCHAINID contracts representing participant identities

The Identity Registry links wallet addresses to verified identities. The Claim Topics Registry defines which claims are required, while the Trusted Issuers Registry identifies the organizations authorized to issue those claims.

For example, an issuer could require every tokenholder to possess a valid KYC claim issued by an approved verification provider. Before permitting a transfer, the Identity Registry can verify that the recipient has an ONCHAINID containing the required claim and that the claim came from an authorized issuer.

The Compliance contract applies additional transfer rules. These may concern:

  • Investor classification
  • Jurisdiction
  • Holding limits
  • Lock-up periods
  • Sanctions restrictions
  • Maximum ownership percentages
  • Transfer frequency
  • Other issuer-defined conditions

T-REX therefore provides more than a token contract. It provides a standardized identity, eligibility, and compliance architecture for regulated digital assets.

However, the protocol does not determine which laws apply to a particular token. The issuer and its advisers must still identify the applicable legal requirements and configure the identity claims, trusted issuers, transfer restrictions, administrative powers, and operating procedures accordingly.

What CMTAT Actually Is

CMTAT is an open security-token framework developed by the Capital Markets and Technology Association, or CMTA. Its reference implementation is written in Solidity for EVM-compatible blockchains and is distributed under the Mozilla Public License 2.0.

CMTAT was initially optimized for Swiss law, but its modular architecture is intended to make it adaptable to other jurisdictions and financial instruments.

A CMTAT token can include functionality for:

  • Minting and burning
  • Pausing the token
  • Freezing accounts or balances
  • Forced transfers
  • Transfer restrictions
  • Legal-document references
  • Balance snapshots
  • Debt information
  • Cross-chain transfers
  • Gasless transactions
  • Role-based administration

The framework does not require every deployment to contain every feature. Instead, issuers select an appropriate deployment variant and connect optional modules or external engines where required.

This modularity matters because regulated token contracts can become extremely large. A single contract that attempts to manage identity, compliance, debt terms, corporate actions, documents, cross-chain transfers, snapshots, and administrative enforcement may approach the EVM contract-size limit. It may also become expensive to deploy and difficult to audit or upgrade.

CMTAT addresses this by separating responsibilities between the token, optional modules, and external engines.

The Importance of CMTAT v3.0.0

The convergence with T-REX became explicit in CMTAT v3.0.0, released on August 28, 2025 and audited by Halborn.

That release added support for several T-REX interfaces and conventions, including:

  • batchMint
  • batchBurn
  • batchTransfer
  • forcedTransfer
  • version

It also renamed certain functions to align more closely with T-REX terminology and introduced support for the T-REX standard without incorporating the complete on-chain identity architecture directly into CMTAT.

This distinction is important. CMTAT can expose compatible token and compliance interfaces without becoming a complete replacement for the T-REX Identity Registry, ONCHAINID, Claim Topics Registry, or Trusted Issuers Registry.

Although later CMTAT releases exist, CMTA's repository continues to identify v3.0.0 as the latest audited version. Operators should therefore distinguish between the latest available release and the latest release with the stated audit coverage.

Asset Classes and Deployment Patterns

CMTAT can be configured for several kinds of regulated financial assets. The required architecture depends on the legal and operational lifecycle of the underlying instrument.

Equity Shares and Fund Units

Equity shares and fund units often require balance snapshots.

A snapshot records token balances and total supply at a particular point in time. This can be used to establish entitlements for:

  • Dividends
  • Fund distributions
  • Voting rights
  • Corporate actions
  • Record-date reporting
  • Redemptions

An external distribution contract can use the recorded balances to calculate payments proportionally.

For example, if a dividend is declared with a particular record date, the issuer can use a snapshot taken on that date rather than relying on each investor's balance when the payment is eventually made.

Fund units may also require subscription, redemption, net asset value, and batch-processing systems. These functions can be implemented around the token rather than placing every operational workflow inside the token contract itself.

Debt Instruments

Debt instruments have lifecycle requirements that ordinary equity tokens do not have.

A tokenized bond may need to represent:

  • Principal amount
  • Interest rate
  • Issuance date
  • Maturity date
  • Payment schedule
  • Day-count convention
  • Credit events
  • Defaults
  • Restructuring events
  • Redemption status

CMTAT provides debt-oriented functionality and supports separating debt information from the core token through a dedicated debt deployment and external engine architecture.

This separation allows different organizations to control different parts of the instrument. The issuer may administer token transfers, while a trustee, calculation agent, or other authorized operator may be responsible for recording credit events or repayment information.

Structured Products

Structured products frequently depend on detailed term sheets and legal documentation.

CMTAT supports document-management functionality that can associate a token with information such as:

  • Document hashes
  • Document locations
  • Modification dates
  • Product terms
  • Offering documents
  • Prospectuses
  • Version information

Storing a cryptographic hash allows users to verify that an off-chain document has not been modified. The token does not need to store the entire document on-chain.

This is especially relevant for warrants, certificates, structured notes, and customized investment products whose rights cannot be understood merely by looking at the token balance.

Stablecoins and Other Controlled Fungible Assets

CMTAT also provides lighter deployment patterns for stablecoins and other controlled fungible assets.

These deployments can focus on essential functionality such as:

  • Minting
  • Burning
  • Pausing
  • Address freezing
  • Blacklisting
  • Role-based administration

They may omit more specialized features such as debt information, snapshots, partial balance freezing, or extensive document management.

CMTAT's reference documentation identifies equities, debt products, structured products, stablecoins, and tokenized funds among its supported or demonstrated use cases.

The RuleEngine Architecture

One of CMTAT's most important design choices is the externalization of transfer restrictions into a separate RuleEngine.

Instead of placing every compliance check directly inside the token contract, a CMTAT token can call an external RuleEngine before and during a transfer.

The RuleEngine contains one or more rule contracts. These rules can evaluate:

  • The sender
  • The recipient
  • The spender in a delegated transfer
  • The transfer amount
  • The token's total supply
  • Whitelists and blacklists
  • External identity registries
  • Sanctions oracles
  • Preapproved transfers

The RuleEngine can return a restriction code indicating whether the transfer is permitted. It can also invoke state-changing rules after an approved operation has been executed.

The architecture separates rules into two broad categories.

Validation Rules

Validation rules are read-only. They inspect the relevant state and determine whether a transaction is permitted, but they do not update storage during the transfer.

Examples include:

  • Whitelist checks
  • Blacklist checks
  • Identity verification
  • Sanctions screening
  • Maximum-supply checks

Operation Rules

Operation rules can modify their state when a transaction occurs.

For example, a conditional-transfer rule may record that an approval has been consumed after the approved transfer is executed.

The distinction is important when rules or RuleEngines are shared between multiple tokens. Read-only rules are generally easier to reuse. Stateful rules may maintain token-specific information and should not automatically be shared between unrelated or mutually untrusted tokens.

The RuleEngine documentation warns that T-REX compliance callbacks do not always identify which token invoked a stateful rule. A shared RuleEngine should therefore only be used where the bound tokens are appropriately trusted and governed together.

Why Externalize Compliance?

Externalizing compliance offers three main advantages.

Smaller Token Contracts

Both CMTAT and T-REX tokens can contain substantial functionality.

Adding every possible restriction directly to the token increases bytecode size and can make the contract harder to review. External rules allow issuers to add compliance functionality without placing all of that code inside the token.

Adaptable Compliance

Regulatory requirements and operational policies can change.

An issuer may need to:

  • Replace a sanctions provider
  • Add a new transfer restriction
  • Change an identity provider
  • Introduce a holding limit
  • Add support for another jurisdiction
  • Respond to a regulatory or judicial order

A modular RuleEngine allows rules to be added, removed, replaced, or reconfigured without necessarily replacing the token contract itself. Any such change must still follow the deployment's governance, access-control, testing, and upgrade procedures.

Reusability

A RuleEngine may be reused by multiple tokens where they genuinely share the same governance and compliance requirements.

This may be appropriate for:

  • Multiple bond series from one issuer
  • Several share classes of the same fund
  • Related structured products
  • Assets using the same sanctions policy
  • Issuances managed by the same transfer agent

Reusability can reduce duplicate infrastructure, but it also creates shared dependencies. An incorrect rule update could affect every token connected to the engine.

The Rules in Detail

The CMTA Rules repository contains several modular transfer-restriction rules for CMTAT and T-REX-compatible tokens.

RuleWhitelist and RuleWhitelistWrapper

RuleWhitelist requires the relevant sender and recipient addresses to appear on an approved list.

It can be used for:

  • Private placements
  • Restricted securities
  • Professional-investor offerings
  • Permissioned funds
  • KYC-controlled assets

RuleWhitelistWrapper allows multiple independently managed whitelist rules to be combined. A transfer can be permitted when both participants appear together in at least one qualifying whitelist.

This may be useful where different custodians, distributors, transfer agents, or compliance providers maintain separate investor populations.

RuleBlacklist

RuleBlacklist blocks transfers involving specified addresses.

It can be used to respond to:

  • Fraud
  • Compromised accounts
  • Court orders
  • Regulatory instructions
  • Disqualified investors
  • Internal risk controls

Unlike a whitelist, a blacklist does not require every permitted participant to be registered. It only identifies addresses that must be blocked.

RuleSanctionList

RuleSanctionList can connect to a Chainalysis sanctions oracle and reject transfers involving addresses identified under supported sanctions designations.

The rule can screen the sender and recipient against sanctions information associated with United States, European Union, and United Nations designations.

However, using an oracle does not establish that an issuer has satisfied every applicable sanctions obligation. The issuer must determine:

  • Which sanctions regimes apply
  • Whether the oracle has appropriate coverage
  • How false positives will be handled
  • Whether additional off-chain screening is required
  • Who may override or update the rule

RuleMaxTotalSupply

RuleMaxTotalSupply prevents minting that would cause the token supply to exceed a configured maximum.

This may be appropriate for:

  • Fixed-size bond issuances
  • Limited share offerings
  • Structured products with an issuance cap
  • Funds with a maximum authorized supply

The rule applies to minting. Ordinary transfers and burns do not increase total supply and are therefore unaffected by the cap.

RuleIdentityRegistry

RuleIdentityRegistry provides the principal connection between CMTAT and T-REX identity infrastructure.

When a T-REX Identity Registry is configured, the rule calls its isVerified function to determine whether transfer participants are eligible. It can check the sender, recipient, and, in delegated transfers, the spender.

A CMTAT issuer can therefore use an existing T-REX Identity Registry instead of building a separate CMTAT-specific identity list.

This can reduce:

  • Duplicate identity records
  • Repeated KYC processes
  • Inconsistent investor classifications
  • Integration work
  • Operational fragmentation

The rule only consumes the result provided by the registry. It does not itself issue claims, create ONCHAINIDs, select trusted claim issuers, or manage the entire identity lifecycle.

RuleERC2980

RuleERC2980 implements a Swiss-oriented transfer-restriction pattern combining a recipient whitelist with a frozen-address list.

Under the rule:

  • Only whitelisted addresses may receive tokens
  • Senders do not necessarily have to be whitelisted
  • Frozen addresses cannot send or receive
  • A frozen delegated spender can also be blocked
  • The frozen list takes priority over the whitelist

This allows an issuer to prevent a frozen address from interacting with the token even where that address was previously approved.

RuleConditionalTransferLight

RuleConditionalTransferLight requires a transfer to be approved by an authorized operator before it is executed.

Approvals are associated with the sender, recipient, and amount. When an approved transfer is completed, one approval is consumed.

This can support assets for which transfers require:

  • Issuer consent
  • Board approval
  • Transfer-agent approval
  • Legal review
  • Pre-transaction verification

A more extensive RuleConditionalTransfer implementation exists separately and is described by CMTA as experimental. It includes additional functionality associated with the Swiss concept of Vinkulierung, such as conditional approval and address-pair exemptions.

RuleSpenderWhitelist

RuleSpenderWhitelist controls delegated transfers made through transferFrom.

Direct transfers are not blocked by this rule. However, an account attempting to transfer tokens on behalf of another holder must appear on the spender whitelist.

This can limit delegated transfer powers to approved:

  • Custodians
  • Brokers
  • Transfer agents
  • Settlement systems
  • Smart-contract applications

The T-REX Integration

The convergence between CMTAT and T-REX occurs at two levels: token interfaces and compliance infrastructure.

Compatible Token Functions

CMTAT v3.0.0 introduced functions and naming conventions associated with T-REX, including batch operations, forced transfers, and version reporting.

This makes it easier for infrastructure designed around T-REX interfaces to interact with a CMTAT token.

Interface compatibility does not mean that the internal implementation is identical. It means that external systems can invoke familiar functions and receive data through standardized interfaces.

A Shared Compliance Interface

The CMTA RuleEngine implements the T-REX compliance interface.

A T-REX token expects its compliance contract to respond to operations such as:

  • canTransfer
  • transferred
  • created
  • destroyed
  • bindToken
  • unbindToken

The RuleEngine implements these compliance hooks and can therefore serve as the compliance contract for a compatible T-REX token.

Individual CMTA rule contracts generally do not implement the complete interface required for direct use as a T-REX compliance contract. For example, some implement transfer validation but not all minting and burning callbacks. The RuleEngine provides the full orchestration layer required to connect those rules to a T-REX token.

The binding process also includes governance protections. A token can be required to receive explicit approval before binding itself to a RuleEngine, reducing the risk of an unauthorized contract attaching itself to shared compliance infrastructure.

Shared Identity Infrastructure

The second form of integration is identity reuse.

A CMTAT token can be connected to:

  • A CMTA RuleEngine
  • A RuleIdentityRegistry rule
  • A T-REX Identity Registry

When a transfer is requested, the CMTAT token calls the RuleEngine. The RuleEngine calls RuleIdentityRegistry, which then asks the T-REX Identity Registry whether the relevant participants are verified.

The Identity Registry remains responsible for determining verification status. The RuleEngine is responsible for enforcing that result during token operations.

This separation allows the same identity infrastructure to support different token implementations.

The Important Limitation

CMTAT's T-REX compatibility should not be interpreted as complete implementation equivalence.

CMTAT v3.0.0 explicitly describes its T-REX support as operating without on-chain identity. CMTAT exposes compatible token and compliance interfaces, but it does not automatically include the complete T-REX identity suite.

An operator that requires the complete T-REX identity model may still need:

  • ONCHAINID
  • Identity Registry Storage
  • Claim Topics Registry
  • Trusted Issuers Registry
  • Claim issuers
  • Claim issuance and revocation procedures
  • Identity recovery and update procedures

The RuleIdentityRegistry connects CMTAT to that infrastructure. It does not replace it.

A combined deployment could therefore use:

  • CMTAT for the financial instrument and lifecycle functionality
  • A CMTAT DebtEngine, SnapshotEngine, or DocumentEngine
  • A CMTA RuleEngine for transfer enforcement
  • T-REX infrastructure for identity and claims
  • RuleIdentityRegistry as the bridge between them

Audit Coverage Must Be Evaluated Per Component

Audit claims should not be applied to the entire combined architecture without checking each component separately.

CMTAT v3.0.0 was audited by Halborn. However, the current CMTA RuleEngine and Rules repositories expressly state that those projects have not undergone an audit and are provided without warranties.

Therefore, the fact that the core CMTAT release was audited does not automatically mean that:

  • Every rule has been audited
  • The RuleEngine has been audited
  • A custom integration has been audited
  • An external identity registry has been audited
  • The combined deployment is secure
  • Governance and operational procedures are safe

A production deployment should review the exact versions, configurations, access-control assignments, proxy arrangements, external dependencies, and integration code being used.

Why the Convergence Matters

Previously, an operator might have viewed CMTAT and T-REX as mutually exclusive choices.

CMTAT offered flexible financial-instrument modules, while T-REX offered a standardized permissioned-token and identity architecture.

The increasing compatibility between them allows operators to assemble a more specialized stack.

For example, a tokenized bond could use:

  • A CMTAT debt-token deployment
  • A DebtEngine for bond information
  • A RuleEngine for compliance
  • RuleIdentityRegistry for investor eligibility
  • RuleSanctionList for sanctions screening
  • RuleConditionalTransferLight for approval-based transfers
  • A T-REX Identity Registry for identity verification

This arrangement allows the issuer to retain CMTAT's financial-instrument functionality while reusing identity infrastructure compatible with other T-REX issuances.

It may also improve interoperability with custodians, transfer agents, exchanges, wallets, and tokenization platforms that already understand T-REX interfaces.

The relevant architectural question is therefore no longer simply: "Should we use CMTAT or T-REX?"

The more useful questions are:

  • Which token functions does the asset require?
  • Which identity system will determine investor eligibility?
  • Which compliance rules must be applied?
  • Who may change those rules?
  • Which parties will administer the token?
  • Which system will manage corporate actions?
  • Which components can safely be shared?
  • Which components have been independently audited?
  • Which jurisdictional requirements must be reflected in the deployment?

Technical Compatibility Is Not Universal Legal Compatibility

CMTAT and T-REX can be technically interoperable without being legally suitable for every asset or jurisdiction.

A smart-contract interface can standardize functions such as transfer validation, minting, burning, freezing, forced transfers, identity checks, and compliance callbacks.

It cannot standardize every legal consequence of using those functions.

Different jurisdictions may impose different rules concerning:

  • The legal recognition of tokenized ownership
  • Securities registration
  • Investor eligibility
  • Transfer restrictions
  • KYC and anti-money-laundering obligations
  • Privacy and data protection
  • Custody
  • Settlement finality
  • Corporate registers
  • Disclosure
  • Tax reporting
  • Redemption
  • Insolvency
  • Enforcement
  • Governing law

Different asset classes also require different lifecycle processes.

A tokenized share may require legally recognized shareholder-register updates and voting procedures. A bond may require interest calculations, trustee powers, credit-event processing, and redemption. A fund unit may require net asset value calculations, subscriptions, redemptions, and investor-class restrictions. A structured product may depend on complex payoff terms and external market data.

Using the same token interfaces does not eliminate these differences.

Open Question

Are CMTAT and T-REX sufficiently interoperable to support every asset class across different jurisdictions, or must each implementation still be adapted to the asset's legal classification and the local requirements governing identity, transfers, custody, disclosure, settlement, investor protection, and lifecycle management?