If you're looking to tokenize assets on the blockchain, one of the most important factors is the smart contract that will manage and represent your token. You can either create a smart contract from scratch or opt for an existing implementation.
A technical partner can provide an existing implementation, and your main responsibility is to ensure the smart contract meets your specific needs and complies with your legal jurisdiction. At Taurus, we frequently use CMTAT, but our platform is agnostic and can deploy and manage all types of smart contracts.
But if you'd prefer to customize your smart contract or want more flexibility with the deployment process, this article will focus on that approach.
When choosing a smart contract standard or implementation, there are several key points to consider:
-
What standards are implemented, and for which jurisdictions?
-
Is the code up-to-date with the latest technology and libraries?
-
Under which license is the code published, and can it be used in commercial products?
-
How easy is it to modify the code?
-
Has the code been audited?
In this article, we will focus solely on implementations designed for Ethereum and EVM-compatible blockchains like Avalanche, Polygon, or Arbitrum.
For a comparison of different standards and their functionalities, feel free to check out our article: Security Token Standards Compared: CMTAT vs ERC-1400 vs ERC-3643.
TokenF (Distributed Lab)
TokenF is a recent framework which adds permissioned and regulatory features on top of ERC-20. It enables the configuration of regulatory rules for real-world asset (RWA) tokens using the ERC-2535 Diamond.
The standard ERC-2535 defines a specific type of proxy (upgradeable) contracts, known as diamond proxies. These are modular smart contract systems that can be upgraded/extended after deployment, and have virtually no size limits, unlike other proxy standards such as transparent or UUPS proxies.
-
More technically, a diamond is a proxy contract which calls other contracts, called facets, which are defined within the diamond.
-
Facets are separate, independent contracts that can share internal functions, libraries, and state variables.
The use of this standard is a very good choice since it allows us to add and configure new modules (facets) without the need to deploy a new smart contract implementation and modify the heart of the contracts.
Moreover, the implementation is provided under the license MIT, which is a permissive license. Since it is a recent implementation, the code contains the latest developments in the language used (Solidity).
As of the time of writing, no public audit is available for this implementation.
Currently, the main compliance feature is the KYC module, which restricts transfers to only KYC-verified addresses.
We don’t really find any major disadvantages with this implementation, apart from the fact that using and modifying ERC-2535 can be more challenging from a technical point of view.
Schema from TokenF documentation
ERC-3643 (Tokeny)
The ERC-3643 is an official Ethereum standard, unlike ERC-1400 and ERC-1404. This standard, also built on top of ERC-20, offers a way to manage and perform compliant transfers of security tokens.
ERC-3643 enforces identity management as a core component of the standards by using a decentralized identity system called onchainid. Trusted claim issuers (KYC providers) can upload KYC certificates on-chain. The issuers decide which providers are trusted for their tokens, and only addresses with a KYC certificate issued by a trusted provider can hold the token.
However, a standard alone is merely an interface with a list of requirements—you still need an implementation to actually use it.
As far as we know, there is only one available implementation, developed by Tokeny, which is not surprising since they are the creators of the ERC.
The implementation is regularly updated and audited by Hacken, supported by a strong development team.
Using this implementation for your projects does come with several constraints:
-
The implementation is available under the GPL-3.0 license, which is a copy-left license. This means if you use the implementation in your product, you must also release your product under the GPL-3.0 license or a compatible license and distribute the source code of your product.
-
Since version v4.2, all supplementary contracts for additional compliance features (e.g., setting a maximum balance by token holder, restricting token holders by country, etc.) are under the CC-BY-NC-4.0 non-commercial license which forbids the use of these contracts for commercial purposes without authorization from Tokeny.
-
The complex architecture makes it difficult to modify or update the code, especially its forced integration with the on-chain identity system. The implementation nevertheless offers a certain flexibility in terms of compliance modules. It is possible to add new compliance modules without changing the architecture, allowing you to add your own restrictions on transfers.
ERC-1400 (UniversalToken / Consensys)
The ERC-1400 standard also allows the creation of security tokens built on top of ERC-20. It is important to note that this standard never reached the final stage as an ERC, contrary to ERC-3643, and is still considered a proposal.
ERC-1400 contains four other ERC proposals: ERC-1410, ERC-1594, ERC-1643, and ERC-1644.
These proposals define how to transfer tokens and introduce additional features, such as the management of documents for ERC-1644. The main features include:
-
Standard interface to query if a transfer would be successful and return a reason for failure.
-
Perform forced transfers for legal action or fund recovery.
-
Attach metadata to a subset of a token holder's balance, such as special shareholder rights or data for transfer restrictions.
-
Manage documents on-chain (ERC-1643).
-
Represent partially-fungible tokens (ERC-1410).
One of the available implementations is UniversalToken written by Consensys, a reputable and well-known company in the blockchain industry. The implementation is also under Apache-2.0 license, a permissive license.
If you are interested in the standard ERC-1400, this implementation could be a good choice. The main disadvantage of ERC-1400 is that it includes many features you may not need. Removing certain features and adding custom ones can require significant work.
Another implementation is from Polymath, but we have decided not to include it in our analysis, as the code is more complex, and the project has not appeared to be publicly maintained since 2019.
CMTAT (CMTA)
The CMTA Token (CMTAT) is an open standard suitable for the tokenization of various financial instruments and adopted by multiple actors within the finance sector. Its implementation for Ethereum and EVM blockchain is written in Solidity and is also an extension of the ERC-20 standard.
Unlike ERC-3643 or ERC-1400, CMTAT has never been an Ethereum standard. Instead, interoperability with other systems is provided through ERC-20 and several other incorporated standards, such as ERC-2771.
But why is CMTAT a good choice?
-
CMTAT’s implementation follows a framework carefully designed and written by the association members, which includes notably lawyers and professionals from traditional finance.
-
The code, included in the RuleEngine (Compliance feature), is under the license MPL-2.0 authorizing commercial use and which only requires keeping the original file under the same license. If you include the smart contracts in your product, you don’t need to make other files under the MPL-2.0 license.
-
The architecture in modules allows you to easily remove or add features on these contracts. CMTAT solidity is only tied to the ERC-20 standard for interoperability and the standard proposition ERC-1404 which is very light since it defines only two supplementary functions.
-
CMTAT smart contracts have been used by several different companies (Obligate, UBS, amun and Daura) which have modified smart contracts to correspond to their needs.
-
CMTAT is also regularly audited with one audit on the version 1.0.0 and a second audit on the version 2.3.0. The audits are performed by ABDK consulting.
These are the reasons why CMTAT is used in our products for tokenization, and why we are happy to contribute to the code by proposing new features and submitting pull requests.
If you want to know more about this standard, we have written several articles on this:
-
Security Token Standards Compared: CMTAT vs ERC-1400 vs ERC-3643
-
Token Transfer Management: How to Apply Restrictions with CMTAT and ERC-1404
-
Equity Tokenization: How to Pay Dividend On-Chain Using CMTAT
Summary
For our analysis, we have taken the last available release or the last commits for project actively developed such as ERC-3643 and CMTAT.
|
TokenF |
ERC-3643 (Tokeny implementation) |
ERC-1400 |
CMTAT v2.5.0 |
---|---|---|---|---|
Last release / commit |
705de68 |
V4.2 Commit 8c5fa14 |
(2024) |
(2024) |
Company or association behind the implementation |
(Lenz & Staehelin, Mt Pelerin, Taurus, UBS, Daura, 21Shares, …) |
|||
Legal framework / functional specification) |
||||
ERC-20 |
✅ |
✅ |
✅ |
✅ |
ERC draft |
❌ |
ERC-1400 |
ERC-1404(Simple Restricted Token Standard) ERC-1643 (Document Management Standard) through DocumentEngine |
|
ERC final |
❌ |
(Gasless support) ERC-7201 |
||
License |
MIT |
ERC-3643 core: GPL 3.0 Compliance module: CC-BY-NC-4.0(forbid commercial use) |
Apache 2.0 |
MPL 2.0 |
Implementation still maintained |
✅ |
✅ |
Partial |
✅ |
Customizable modular design |
✅ (Diamonds proxy) |
Partial with compliance module*** |
❌ |
✅ |
Solidity version in solidity files (most recent 0.8.27) |
^0.8.20 |
0.8.27 |
^0.8.0 |
^0.8.20 |
Solidity version in configuration file (most recent 0.8.27) |
^0.8.20 |
0.8.27 |
0.8.7 |
0.8.27 |
OpenZeppelin version |
4.9.5 (12/2023) use also their own library solarity |
^4.8.3 |
^4.2.0 (2021) |
5.0.2 |
Development framework |
Hardhat |
Hardhat |
Truffle* |
Hardhat (CMTAT) Foundry (RuleEngine, DocumentEngine, DebtEngine) |
Public third-party security audit Version audited Company |
❌ |
✅ V4 |
✅ |
✅ |
*Consensys has announced the sunset of Truffle in December 2023. See Consensys Announces the Sunset of Truffle and Ganache and New HardHat Partnership for more details.
**In progress to become a final ERC.
***Partial because ERC-3643 enforces identity management as a core component of the standard.
Conclusion
If you are searching for a tokenization standard that offers flexibility for modification according to your needs, while implementing several standards for interoperability (ERC-1404, ERC-1643, ERC-2771) and comes with a permissive license (MPL-2.0), CMTAT is a solid option, and Taurus will be happy to assist you.
If you are interested in the promise of Diamond proxy pattern, the use of TokenF is a good choice, since this is the only available version which uses this architecture and provides the associated benefits. As a reminder, the main advantages of this architecture are as follows:
-
Upgraded/extended the functionalities of the token after deployment.
-
Virtually no size limit, unlike other proxy standards such as transparent or UUPS proxy.
For UniversalToken (ERC-1400) by Consensys and the ERC-3643 from Tokeny, these are more complex to modify and less adaptive. In this case, it is better to use them only if they completely meet your needs without requiring too many modifications. Typically, ERC-3643 offers a mature architecture for tokenization with on-chain identity management.