[TOC]
The CMTA token (CMTAT) is a framework enabling the tokenization of securities in compliance with Swiss law.
The CMTAT is an open standard from the Capital Markets and Technology Association (CMTA), and the product of collaborative work by leading organizations in the Swiss finance and technology ecosystem.
The present repository provides CMTA's reference implementation of CMTAT for Ethereum, as an ERC-20 compatible token.
The CMTAT is developed by a working group of CMTA's Technical Committee that includes members from Atpar, Bitcoin Suisse, Blockchain Innovation Group, Hypothekarbank Lenzburg, Lenz & Staehelin, Metaco, Mt Pelerin, SEBA, Swissquote, Sygnum, Taurus and Tezos Foundation. The design and security of the CMTAT was supported by ABDK, a leading team in smart contract security.
The preferred way to receive comments is through the GitHub issue tracker. Private comments and questions can be sent to the CMTA secretariat at [email protected]. For security matters, please see SECURITY.md.
The CMTAT supports the following core features:
- Basic mint, burn, and transfer operations
- Pause of the contract and freeze of specific accounts
Furthermore, the present implementation uses standard mechanisms in order to support:
- Upgradeability, via deployment of the token with a proxy
- "Gasless" transactions
- Conditional transfers, via a rule engine
This reference implementation allows the issuance and management of tokens representing equity securities. It can however also be used for other forms of financial instruments such as debt securities.
To use the CMTAT, we recommend that you use the latest audited version, from the Releases page.
You may modify the token code by adding, removing, or modifying features. However, the mandatory modules must remain in place for compliance with Swiss law.
If you want to deploy without a proxy, in standalone mode, you need to use the contract version CMTAT_STANDALONE
The CMTAT supports deployment via a proxy contract. Furthermore, using a proxy permits to upgrade the contract, using a standard proxy upgrade pattern.
The contract version to use as an implementation is the CMTAT_PROXY.
Please see the OpenZeppelin upgradeable contracts documentation for more information about the proxy requirements applied to the contract.
Please see the OpenZeppelin Upgrades plugins for more information about upgrades plugins in general.
Note that deployment via a proxy is not mandatory, but recommended by CMTA.
The CMTAT supports client-side gasless transactions using the Gas Station Network (GSN) pattern, the main open standard for transfering fee payment to another account than that of the transaction issuer. The contract uses the OpenZeppelin contract ERC2771ContextUpgradeable, which allows a contract to get the original client with _msgSender() instead of the fee payer given by msg.sender while allowing upgrades on the main contract (see Deployment via a proxy above).
At deployment, the parameter forwarder inside the CMTAT contract constructor has to be set with the defined address of the forwarder. Please note that the forwarder can not be changed after deployment, and with a proxy architecture, its value is stored inside the implementation contract bytecode instead of the storage of the proxy.
Please see the OpenGSN documentation for more details on what is done to support GSN in the contract.
This functionality uses the opcode SELFDESTRUCT which the property of destroying the contract (= deletion of any storage keys or code) will be remove with the Cancun Upgrade, an upgrade of the Ethereum network.
Therefore, when the Ethereum Network will integrate this upgrade, this functionality will no longer be available.
See https://eips.ethereum.org/EIPS/eip-6780 & https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/cancun.md
A "kill switch" is a necessary function to allow the issuer to carry out certain corporate actions (e.g., share splits, reverse splits, and mergers), which involve cancelling all existing tokens and replacing them by new ones, and can also be used if the issuer decides that it no longer wishes to have its shares issued in the form of ledger securities. The "kill switch" function affects all tokens issued.
Such a functionality can be performed via that kill() function. A new token contract may then be deployed.
Alternatively, if interactions with the "contract" are still necessary, it may be paused (and never unpaused).
Here the list of the differents modules with the links towards the documentation and the main file.
| Name | Documentation | Main File |
|---|---|---|
| BaseModule | base.md | BaseModule.sol |
| BurnModule | burn.md | BurnModule.sol |
| EnforcementModule | enforcement.md | EnforcementModule.sol |
| ERC20BaseModule | erc20base.md | ERC20BaseModule.sol |
| MintModule | mint.md | MintModule.sol |
| PauseModule | pause.md | PauseModule.sol |
| Name | Documentation | Main File |
|---|---|---|
| MetaTxModule | metatx.md | MetaTxModule.sol |
| SnapshotModule* | snapshot.md | SnapshotModule.sol |
| ValidationModule | validation.md | ValidationModule.sol |
| creditEventModule | creditEvents.md | CreditEventsModule.sol |
| DebtBaseModule | debtBase.md | DebtBaseModule.sol |
*not imported by default
| Name | Documentation | Main File |
|---|---|---|
| AuthorizationModule | authorization.md | AuthorizationModule.sol |
| OnlyDelegateCallModule | onlyDelegateCallModule.md | OnlyDelegateCallModule.sol |
This module was not audited during the audit made by ABDK and it is no longer imported by default inside the CMTAT.
If you want to add this module, you have to uncomment the specific lines "SnapshotModule" inside the file CMTAT_BASE.sol.
Be warned that this module may possibly contain security flaws.
A CMTAT version inheriting from the SnapshotModule and used for testing purpose is available here: CMTATSnapshotStandaloneTest.sol & CMTATSnapshotProxyTest.sol
Please see SECURITY.md.
See the Section Modules/Security.
The Access Control is managed inside the module AuthorizationModule.
The module OnlyDelegateCallModule is a special module to insure that some functions (e.g. delegatecall and selfdestruct) can only be triggered through proxies when the contract is deployed with a Proxy.
The contracts have been audited by ABDKConsulting, a globally recognized firm specialized in smart contracts' security.
Fixes of security issues discovered by the initial audit were reviewed by ABDK and confirmed to be effective, as certified by the report released on September 10, 2021, covering version c3afd7b of the contracts. Version 1.0 includes additional fixes of minor issues, compared to the version retested.
A summary of all fixes and decisions taken is available in the file CMTAT-Audit-20210910-summary.pdf
The second audit was performed by ABDK on the version 2.2.
The release 2.3 contains the different fixes and improvements related to this audit.
The temporary report is available in the file Taurus. Audit 3.1. Collected Issues.ods.
You will find the report performed with Slither in the file slither-report.md
- You will find a summary of all automatic tests in the file test.pdf
- A code coverage is available in the file index.html
For information, we do not perform tests on the internal functions
initof the different modules.
As with any token contract, access to the owner key must be adequately restricted. Likewise, access to the proxy contract must be restricted and seggregated from the token contract.
Here a summary of the main documentation
| Document | Link/Files |
|---|---|
| Documentation of the modules API. | doc/modules |
| Documentation on the toolchain | doc/TOOLCHAIN.md |
| How to use the project | doc/USAGE.md |
| Project architecture | doc/general/architecture.md |
CMTA will release further documentation describing the CMTAT framework in a platform-agnostic way, and coveging legal aspects, see
- CMTA Token (CMTAT)
- Standard for the tokenization of shares of Swiss corporations using the distributed ledger technology
The code is copyright (c) Capital Market and Technology Association, 2018-2023, and is released under Mozilla Public License 2.0.