The T-REX token is an institutional grade security token standard. This standard provides a library of interfaces for the management and compliant transfer of security tokens, using an automated onchain validator system leveraging onchain identities for eligibility checks.
The standard defines several interfaces that are described hereunder:
The advent of blockchain technology has brought about a new era of efficiency, accessibility, and liquidity in the world of asset transfer. This is particularly evident in the realm of cryptocurrencies, where users can transfer token ownership peer-to-peer without intermediaries. However, when it comes to tokenized securities or security tokens, the situation is more complex due to the need for compliance with securities laws. These tokens cannot be permissionless like utility tokens; they must be permissioned to track ownership and ensure that only eligible investors can hold tokens.
The existing Ethereum protocol, while powerful and versatile, does not fully address the unique challenges posed by security tokens. There is a need for a standard that supports compliant issuance and management of permissioned tokens, suitable for representing a wide range of asset classes, including small businesses and real estate.
The proposed ERC-3643 standard is motivated by this need. It aims to provide a comprehensive framework for managing the lifecycle of security tokens, from issuance to transfers between eligible investors, while enforcing compliance rules at every stage. The standard also supports additional features such as token pausing and freezing, which can be used to manage the token in response to regulatory requirements or changes in the status of the token or its holders.
Moreover, the standard is designed to work in conjunction with an on-chain Identity system, allowing for the validation of the identities and credentials of investors through signed attestations issued by trusted claim issuers. This ensures compliance with legal and regulatory requirements for the trading of security tokens.
In summary, the motivation behind the proposed standard is to bring the benefits of blockchain technology to the world of securities, while ensuring compliance with existing securities laws. It aims to provide a robust, flexible, and efficient framework for the issuance and management of security tokens, thereby accelerating the evolution of capital markets.
The proposed standard has the following requirements:
While this standard is backwards compatible with ERC-20 and all ERC-20 functions can be called on an ERC-3643 token, the implementation of these functions differs due to the permissioned nature of ERC-3643. Each token transfer under this standard involves a compliance check to validate the transfer and the eligibility of the stakeholder’s identities.
The standard defines an Agent role, which is crucial for managing access to various functions of the smart contracts. The interface for the Agent role is as follows:
The IAgentRole interface allows for the addition and removal of agents, as well as checking if an address is an agent. In this standard, it is the owner role, as defined by ERC-173, that has the responsibility of appointing and removing agents. Any contract that fulfills the role of a Token contract or an Identity Registry within the context of this standard must be compatible with the IAgentRole interface.
To be able to perform a transfer on T-REX you need to fulfill several conditions :
Here is an example of transfer function implementation :
The transferFrom function works the same way while the mint function and the forcedTransfer function only require the receiver to be whitelisted and verified on the Identity Registry (they bypass the compliance rules). The burn function bypasses all checks on eligibility.
The isVerified function is called from within the transfer functions transfer, transferFrom, mint and
forcedTransfer to instruct the Identity Registry to check if the receiver is a valid investor, i.e. if his
wallet address is in the Identity Registry of the token, and if the Identitycontract linked to his wallet
contains the claims (see Claim Holder) required in the Claim Topics Registry and
if these claims are signed by an authorized Claim Issuer as required in the Trusted Issuers Registry.
If all the requirements are fulfilled, the isVerified function returns TRUE, otherwise it returns FALSE. An
implementation of this function can be found on the T-REX repository of Tokeny.
The canTransfer function is also called from within transfer functions. This function checks if the transfer is compliant with global compliance rules applied to the token, in opposition with isVerified that only checks the eligibility of an investor to hold and receive tokens, the canTransfer function is looking at global compliance rules, e.g. check if the transfer is compliant in the case there is a fixed maximum number of token holders to respect (can be a limited number of holders per country as well), check if the transfer respects rules setting a maximum amount of tokens per investor, ...
If all the requirements are fulfilled, the canTransfer function will return TRUE otherwise it will return
FALSE and the transfer will not be allowed to happen. An implementation of this function can be found on the T-REX
repository of Tokeny.
Description of other functions of the ERC-3643 can be found in the interfaces folder. An implementation of the
ERC-3643 suite of smart contracts can be found on the T-REX repository of Tokeny.
ERC-3643 permissioned tokens build upon the standard ERC-20 structure, but with additional functions to ensure compliance in the transactions of the security tokens. The functions transfer and transferFrom are implemented in a conditional way, allowing them to proceed with a transfer only if the transaction is valid. The permissioned tokens are allowed to be transferred only to validated counterparties, in order to avoid tokens being held in wallets/Identity contracts of ineligible/unauthorized investors. The ERC-3643 standard also supports the recovery of security tokens in case an investor loses access to their wallet private key. A history of recovered tokens is maintained on the blockchain for transparency reasons.
ERC-3643 tokens implement a range of additional functions to enable the owner or their appointed agents to manage supply, transfer rules, lockups, and any other requirements in the management of a security. The standard relies on ERC-173 to define contract ownership, with the owner having the responsibility of appointing agents. Any contract that fulfills the role of a Token contract within the context of this standard must be compatible with the IAgentRole interface.
A detailed description of the functions can be found in the interfaces folder.
The Identity Registry is linked to storage that contains a dynamic whitelist of identities. It establishes the link between a wallet address, an Identity smart contract, and a country code corresponding to the investor's country of residence. This country code is set in accordance with the ISO-3166 standard. The Identity Registry also includes a function called isVerified(), which returns a status based on the validity of claims (as per the security token requirements) in the user’s Identity contract.
The standard relies on ERC-173 to define contract ownership, with the owner having the responsibility of appointing agents. Any contract that fulfills the role of an Identity Registry within the context of this standard must be compatible with the IAgentRole interface. The Identity Registry is managed by the agent wallet(s), meaning only the agent(s) can add or remove identities in the registry. Note that the agent role on the Identity Registry is set by the owner, therefore the owner could set themselves as the agent if they want to maintain full control. There is a specific identity registry for each security token.
A detailed description of the functions can be found in the interfaces folder.
Note that IClaimIssuer and IIdentity are needed in this interface as they are required for the Identity eligibility checks.
The Identity Registry Storage stores the identity addresses of all the authorized investors in the security token(s) linked to the storage contract. These are all identities of investors who have been authorized to hold the token(s) after having gone through the appropriate KYC and eligibility checks. The Identity Registry Storage can be bound to one or several Identity Registry contract(s). The goal of the Identity Registry storage is to separate the Identity Registry functions and specifications from its storage. This way, it is possible to keep one single Identity Registry contract per token, with its own Trusted Issuers Registry and Claim Topics Registry, but with a shared whitelist of investors used by the isVerifed() function implemented in the Identity Registries to check the eligibility of the receiver in a transfer transaction.
The standard relies on ERC-173 to define contract ownership, with the owner having the responsibility of appointing agents(in this case through the bindIdentityRegistry function). Any contract that fulfills the role of an Identity Registry Storage within the context of this standard must be compatible with the IAgentRole interface. The Identity Registry Storage is managed by the agent addresses (i.e. the bound Identity Registries), meaning only the agent(s) can add or remove identities in the registry. Note that the agent role on the Identity Registry Storage is set by the owner, therefore the owner could set themselves as the agent if they want to modify the storage manually. Otherwise it is the bound Identity Registries that are using the agent role to write in the Identity Registry Storage.
A detailed description of the functions can be found in the interfaces folder.
The Compliance contract is used to set the rules of the offering itself and ensures these rules are respected during the whole lifecycle of the token. For example, the Compliance contract will define the maximum amount of investors per country, the maximum amount of tokens per investor, and the accepted countries for the circulation of the token (using the country code corresponding to each investor in the Identity Registry). The Compliance smart contract can be either “tailor-made”, following the legal requirements of the token issuer, or can be deployed under a generic modular form, which can then add and remove external compliance Modules to fit the legal requirements of the token in the same way as a custom "tailor-made" contract would.
This contract is triggered at every transaction by the Token and returns TRUE if the transaction is compliant with the rules of the offering and FALSE otherwise.
The standard relies on ERC-173 to define contract ownership, with the owner having the responsibility of setting the Compliance parameters and binding the Compliance to a Token contract.
A detailed description of the functions can be found in the interfaces folder.
The Trusted Issuer's Registry stores the contract addresses (IClaimIssuer) of all the trusted claim issuers for a specific security token. The Identity contract (IIdentity) of token owners (the investors) must have claims signed by the claim issuers stored in this smart contract in order to be able to hold the token.
The standard relies on ERC-173 to define contract ownership, with the owner having the responsibility of managing this registry as per their requirements. This includes the ability to add, remove, and update the list of Trusted Issuers.
A detailed description of the functions can be found in the interfaces folder.
The Claim Topics Registry stores all the trusted claim topics for the security token. The Identity contract (IIdentity) of token owners must contain claims of the claim topics stored in this smart contract.
The standard relies on ERC-173 to define contract ownership, with the owner having the responsibility of managing this registry as per their requirements. This includes the ability to add and remove required Claim Topics.
A detailed description of the functions can be found in the interfaces folder.
Transfers of securities can fail for a variety of reasons. This is in direct contrast to utility tokens, which generally only require the sender to have a sufficient balance. These conditions can be related to the status of an investor’s wallet, the identity of the sender and receiver of the securities (i.e., whether they have been through a KYC process, whether they are accredited or an affiliate of the issuer) or for reasons unrelated to the specific transfer but instead set at the token level (i.e., the token contract enforces a maximum number of investors or a cap on the percentage held by any single investor). For ERC-20 tokens, the balanceOf and allowance functions provide a way to check that a transfer is likely to succeed before executing the transfer, which can be executed both on-chain and off-chain. For tokens representing securities, the T-REX standard introduces a function canTransfer which provides a more general-purpose way to achieve this. I.e., when the reasons for failure are related to the compliance rules of the token and a function isVerified which allows checking the eligibility status of the identity of the investor. Transfers can also fail if the address of the sender and/or receiver is frozen, or if the free balance of the sender (total balance - frozen tokens) is lower than the amount to transfer. Ultimately, the transfer could be blocked if the token is paused.
Security and compliance of transfers are enforced through the management of on-chain identities. These include:
The T-REX standard provides a comprehensive framework for managing the lifecycle of security tokens. This includes the issuance of tokens, transfers between eligible investors, and the enforcement of compliance rules at every stage of the token's lifecycle. The standard also supports additional features such as token pausing and freezing, which can be used to manage the token in response to regulatory requirements or changes in the status of the token or its holders.
The T-REX standard supports the implementation of additional compliance rules through modular compliance. These modules can be used to enforce a wide range of rules and restrictions, such as caps on the number of investors or the percentage of tokens held by a single investor, restrictions on transfers between certain types of investors, and more. This flexibility allows issuers to tailor the compliance rules of their tokens to their specific needs and regulatory environment.
The inclusion of Agent-scoped functions within the standard interfaces is deliberate. The intent is to accommodate secure and adaptable token management practices that surpass the capabilities of EOA management. We envision scenarios where the agent role is fulfilled by automated systems or smart contracts, capable of programmatically executing operational functions like minting, burning, and freezing in response to specified criteria or regulatory triggers. For example, a smart contract might automatically burn tokens to align with redemption requests in an open-ended fund, or freeze tokens associated with wallets engaged in fraudulent activities.
Consequently, these functions are standardized to provide a uniform interface for various automated systems interacting with different ERC-3643 tokens, allowing for standardized tooling and interfaces that work across the entire ecosystem. This approach ensures that ERC-3643 remains flexible, future-proof, and capable of supporting a wide array of operational models.
T-REX tokens should be backwards compatible with ERC-20 and ERC-173 and should be able to interact with a Claim Holder contract to validate the claims linked to an Identity contract.
This specification has been audited by Kapersky and Hacken, and no notable security considerations were found. While the audits were primarily focused on the specific implementation by Tokeny, they also challenged and validated the core principles of the T-REX standard. The auditing teams approval of these principles provides assurance that the standard itself is robust and does not present any significant security concerns.
Copyright and related rights waived via CC0.