# Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation This site has an agentic ask interface you may use to query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.erc3643.org/erc-3643/index.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. --- # ERC-3643 Permissioned Tokens The Token standard for RWA Tokenization > The ERC3643 protocol is an **open-source suite of smart contracts that enables the issuance, management, and transfer of permissioned tokens**. Its built-in decentralized identity framework ensures only users meeting pre-defined conditions can become token holders, even on permissionless blockchains. ERC-3643 is a token standard designed to bring regulatory compliance and control to the world of blockchain-based securities and tokenized assets. This standard, formalized in the Ethereum Improvement Proposal (EIP) [ERC-3643](https://eips.ethereum.org/EIPS/eip-3643), introduces the concept of **permissioned tokens**, ensuring that only eligible investors can hold and transfer these tokens. ## What Are ERC-3643 Permissioned Tokens? ERC-3643 tokens are a special type of token that incorporates compliance measures directly into their design. Unlike traditional ERC-20 tokens, which can be transferred freely between any two addresses, ERC-3643 tokens include mechanisms to verify the identity and eligibility of participants before allowing transactions. This ensures that all transfers adhere to predefined compliance rules, such as Know Your Customer (KYC) and Anti-Money Laundering (AML) regulations. By identifying all relevant parties such as issuers, agents, investors, and others, it also **enables the tracking of legal ownership for digital assets**, thereby safeguarding token holders. ### Key Features of ERC-3643 1. **Identity Management**: ERC-3643 tokens are linked to on-chain identities managed by an open-source system known as ONCHAINID. Each participant’s identity is verified by authorized parties and stored on the blockchain, allowing for seamless and secure identity management. 2. **Permissioned Transfers**: Transfers of ERC-3643 tokens are governed by a set of compliance rules. Each transaction is checked against these rules, and only those that meet all the criteria are executed. 3. **Compliance by Design**: The standard ensures that all regulatory requirements are met before any transaction is completed. This includes verifying the investor's identity and ensuring they have the necessary credentials to hold the token. It is also possible to add Compliance Modules and to enrich the AssetID of the token. 4. **Interoperability**: Despite their enhanced security and compliance features, ERC-3643 tokens maintain compatibility with existing ERC-20 platforms and tools. This means they can be integrated into existing blockchain ecosystems with minimal modifications. ## ERC-3643 is a suite of smart contracts
## Why ERC-3643 Matters The introduction of ERC-3643 tokens addresses a significant gap in the blockchain ecosystem. While cryptocurrencies and utility tokens have demonstrated the potential of blockchain technology for efficient and decentralized asset transfer, they often fall short when it comes to regulatory compliance. Security tokens, representing real-world assets such as equity or debt, require strict adherence to financial regulations. ERC-3643 provides a robust framework to meet these requirements, opening the door for broader adoption of blockchain technology in regulated financial markets.

ERC-3643 main use cases

### The need for a common tokenization framework
# Built-in Compliance Framework On-chain identities and Compliance modules **ERC-3643 brings compliance and control on top of the blockchain network**. It is therefore not necessary to permission the whole blockchain as you can permission the tokens and the smart contracts you are using on this blockchain network. Securities regulations are intricate and vary across different countries, but they do share certain commonalities: * One such similarity is the need to **accurately identify the various stakeholders** involved in the issuance of financial products, in order to determine their respective responsibilities and liabilities. * Another important aspect of securities regulations pertains to the **investment offering and associated transactions**, such as the distribution, booking, redemption, and transfer of securities between investors in the secondary market, which are often subject to limitations, restrictions, or guidelines. **The ERC-3643 protocol addresses both of these dimensions.** * It represents stakeholders with on-chain **identities**, allowing for the definition of permissions and the assignment of rights and duties to each stakeholder. * Additionally, investment offering rules can be easily added through **compliance modules**, and the protocol can be enriched with other smart contracts to accommodate any specific rules desired for the tokens. However, the fundamental principle is that stakeholders must be properly identified, recognizing that a **blockchain wallet does not constitute an identity**. To achieve this, a better system is required, one that employs account abstraction, which is why the on-chain identity system is crucial in ensuring the legal ownership of tokenized assets.

Overview of the compliance smart contracts

# Onchain identities management An open-source identity system compatible with any KYC agents In the realm of blockchain-based securities, managing compliance and regulatory requirements is paramount. Traditional methods of enforcing these rules at the wallet level fall short, primarily because individuals can control multiple wallets. To address this challenge, the T-REX protocol implements onchain identities, ensuring compliance at an individual level and providing flexibility and reusability of verifiable credentials. ## The Need for Onchain Identities ### **Limitations of Wallet-Based Compliance** * **Multiple Wallets per Individual**: Individuals can hold multiple wallets, making it difficult to enforce compliance rules based solely on wallet addresses. * **Complex Whitelisting**: A simple whitelist of wallets is insufficient for ensuring that regulatory requirements are met for each individual. ### **Advantages of Onchain Identities** * **Individual-Level Compliance**: By managing identities on the blockchain, it becomes possible to apply compliance rules directly to individuals, regardless of the number of wallets they control. * **Centralized Identity Management**: ONCHAINID allows for the creation of globally accessible identities, which can be managed and verified on the blockchain. ## How Onchain Identities Work ### **ONCHAINID System** ONCHAINID is a blockchain-based identity management system that assigns a unique identity to each participant. This identity is linked to all their associated wallets, enabling comprehensive compliance management. * **Identity Creation**: Participants create an ONCHAINID that is stored on the blockchain. * **Claim Management**: Trusted entities issue claims (verifiable credentials) to these identities, which are also stored on the blockchain. These claims verify various aspects such as KYC and AML compliance. * **Verification**: During a transaction, the identity and its associated claims are verified to ensure compliance with regulatory requirements. ### **Verifiable Credentials** Verifiable credentials are digital certificates issued by trusted entities that attest to the identity and compliance status of an individual. * **Flexibility**: Claims can be reused across different tokens and platforms, simplifying the verification process for participants. * **Security**: Storing claims on the blockchain ensures their integrity and availability for verification. ## Benefits of Onchain Identities * **Enhanced Compliance**: Ensures that all regulatory requirements are met before any transaction is completed. * **Improved Security**: By linking transactions to verified identities, the risk of fraud and non-compliance is significantly reduced. * **Streamlined Processes**: Simplifies the identity verification process, reducing the need for repeated KYC checks across different platforms. * **Interoperability**: ONCHAINIDs and their claims can be used across various blockchain platforms and applications, enhancing their utility and reducing redundancy. # Modular Compliance add-ons Enrich your tokens with any compliance rule you like ## Examples of Compliance Modules {% hint style="info" %} These modules were developed by tokenization platforms and are not part of the open-source protocol {% endhint %} **CountryAllowModule**: It facilitates granular control over token transfers based on the geographic location of participants, allowing compliance entities to manage transaction permissions for specific countries on-chain. Investors are associated with a single country and saved within the ID registry. **CountryRestrictModule**: In contrast to the 'CountryAllowModule' mentioned above, the owner can restrict token transactions to users in specific countries with this module. **ExchangeMonthlyLimitsModule**: This module is designed to set the limit of tokens allowed to be transferred monthly. **MaxBalanceModule**: Sometimes, it is undesirable for a large number of tokens to be held at a single address because this situation can lead to price manipulation, unfairness in voting systems, and other issues. The MaxBalanceModule assists the platform owner in limiting the maximum amount of tokens a user can possess. **SupplyLimitModule**: The SupplyLimitModule implements the supply cap commonly seen in popular libraries. With this module, the platform owner can restrict the total supply to a certain amount, preventing the unlimited minting of tokens. **TimeExchangeLimitsModule**: The TimeExchangeLimitsModule allows platform owners to restrict token transactions to specific exchanges within set timeframes. A user, identified by the compliance address, can possess multiple exchange IDs and utilize them for transactions as needed. **TimeTransfersLimitsModule**: This module allows platform owner to set the limits of tokens allowed to be transferred in a given time frame. **TransferFeesModule**: Protocol fees can be vital for the sustainability of a platform. Mentioned module allows system administrators to effortlessly set fees and designate a collector address. Consequently, the module ensures that fees are collected during token transfers according to the specified rates and collectors. **TransferRestrictModule**: The TransferRestrictModule contract essentially creates a permit list functionality within the system, allowing system administrators to manage user access to transfers seamlessly. Furthermore, it provides flexibility through batch operations for efficiently managing multiple user addresses at once. # Interoperability & Standards The T-REX protocol leverages established blockchain standards to ensure compatibility, security, and ease of integration within the broader blockchain ecosystem. By building on these standards, T-REX provides a robust framework for the issuance and management of security tokens. ## ERC-20: The Foundation ERC-20 is the most widely recognized token standard in the Ethereum ecosystem. It defines a set of rules that all Ethereum tokens must follow, ensuring compatibility with various platforms and services. * **Fungibility**: ERC-20 tokens are fungible, meaning each token is identical in type and value to another token. * **Interoperability**: The standard allows ERC-20 tokens to be used seamlessly across different Ethereum-based applications, exchanges, and wallets. * **Basic Functions**: ERC-20 defines basic functions such as transferring tokens, checking balances, and approving tokens as spendable by another on-chain third party. ## Enhancements in ERC-3643 T-REX Protocol While ERC-20 provides a solid foundation, the T-REX protocol extends its capabilities to meet the specific needs of security tokens. ### **Identity Standards** T-REX incorporates robust identity management standards to enforce compliance with regulatory requirements: * **ERC-734 and ERC-735**: These standards are used for identity creation and claim management. They enable the integration of verifiable credentials, ensuring that only eligible participants can hold and transfer tokens. * **ERC-734**: Focuses on managing key holders and identity-related operations. * **ERC-735**: Deals with claims, allowing third parties to issue claims about a specific identity. ### **Proxy Standards** To enhance flexibility and upgradability, T-REX uses established proxy standards: * **ERC-1822**: The Universal Upgradeable Proxy Standard (UUPS) is adapted in T-REX to manage contract upgrades. This ensures that tokens can evolve and incorporate new features without disrupting existing functionality. * **Beacon Proxy**: This standard is used to manage contract implementations efficiently. The T-REX protocol leverages the Beacon Proxy to maintain a centralized version management system, simplifying the process of contract upgrades. ## Compatibility with Existing Standards The T-REX protocol ensures full compatibility with existing token standards, allowing seamless integration into the current blockchain ecosystem: * **Interoperability with ERC-20**: Despite its additional features, T-REX tokens maintain full compatibility with ERC-20 exchanges and tools. This means that T-REX tokens can be traded and managed using existing ERC-20 infrastructure with minor modifications. * **Integration of Identity and Compliance**: The protocol's identity and compliance features are designed to work in tandem with existing standards, enhancing security and regulatory adherence without sacrificing usability. # Enhanced by the T-REX token A strong Ecosystem building the future of Onchain Finance {% content-ref url="/pages/v7M9NKB4Y9m3NgqFNJzt" %} [T-REX Token Overview](/erc-3643/t-rex-utility-token/t-rex-token-overview) {% endcontent-ref %} # Permissioned Tokens The T-REX Token Smart Contract is facilitating the compliant issuance, management, and transfer of security tokens. By integrating with Identity Registry and Compliance contracts, the token contract ensures that all token operations adhere to regulatory requirements. ## Core Functions of the Token Smart Contract 1. **Compliance and Identity Verification**: * The token contract interacts with the Identity Registry to verify the identity of token holders. This ensures that only compliant and verified participants can hold and transfer tokens. * The Compliance contract is called to enforce transfer rules, restrictions, and other regulatory requirements, ensuring that all transactions meet the necessary legal standards. 2. **Token Information Management**: * The contract allows the owner to set and update essential token information, such as the token's name, symbol, and ONCHAINID. These updates are crucial for maintaining accurate and current metadata for the token. 3. **Pause and Freeze Mechanisms**: * The contract includes functions to pause all token transfers, providing a safeguard in emergency situations or during regulatory investigations. * Specific addresses can be frozen, either completely or partially, preventing them from transferring tokens. This feature is vital for compliance and security, allowing for swift action in case of suspicious activities. 4. **Recovery and Forced Transfers**: * Investors can recover tokens from a lost wallet to a new one, ensuring that access to tokens is not permanently lost due to wallet issues. * Forced transfers between compliant addresses can be executed to ensure regulatory and operational requirements are met, even if an address has frozen tokens. 5. **Batch Operations**: * The token contract supports batch operations for minting, burning, transferring, and freezing tokens. These batch functions are efficient and reduce transaction costs when dealing with multiple addresses. ## Interaction with Other Contracts While the token contract itself does not contain the logic for identity verification and compliance enforcement, it relies heavily on other contracts within the T-REX protocol to ensure these functionalities: * **Identity Registry Contract**: This contract maintains a registry of verified identities, ensuring that only authorized participants can interact with the token. * **Compliance Contract**: This contract enforces transfer rules and restrictions based on the regulatory requirements, ensuring that all token transactions comply with the law. ## Key Events The token contract emits several events to log significant actions and changes: * **UpdatedTokenInformation**: Emitted when token information is updated, ensuring transparency and traceability of changes. * **IdentityRegistryAdded**: Emitted when the Identity Registry is set for the token, linking it to the compliance infrastructure. * **ComplianceAdded**: Emitted when the Compliance contract is set, ensuring the token is subject to regulatory rules. * **RecoverySuccess**: Emitted when a successful recovery of tokens is executed, ensuring lost tokens can be reclaimed. * **AddressFrozen and TokensFrozen**: Emitted when addresses or specific amounts of tokens are frozen, providing an audit trail for compliance actions. * **Paused and Unpaused**: Emitted when the token contract is paused or unpaused, signaling changes in the operational status of the token. # Tokens Interface The Token Smart Contract interface defines a comprehensive set of functions and events essential for managing and regulating the lifecycle of the token. Below is a detailed breakdown of the interface functions, explaining their purpose, source, and functionality. **`UpdatedTokenInformation`** **Event** **Description**: Emitted when the token information is updated. This includes updates to the token's name, symbol, decimals, version, and onchainID. ```solidity event UpdatedTokenInformation( string indexed _newName, string indexed _newSymbol, uint8 _newDecimals, string _newVersion, address indexed _newOnchainID ); ``` *** **`IdentityRegistryAdded`** **Event** **Description**: Emitted when the Identity Registry has been set for the token. ```solidity event IdentityRegistryAdded(address indexed _identityRegistry); ``` *** **`ComplianceAdded`** **Event** **Description**: Emitted when the Compliance contract has been set for the token. ```solidity event ComplianceAdded(address indexed _compliance); ``` *** **`RecoverySuccess`** **Event** **Description**: Emitted when an investor successfully recovers their tokens from a lost wallet to a new wallet. ```solidity event RecoverySuccess( address indexed _lostWallet, address indexed _newWallet, address indexed _investorOnchainID ); ``` *** **`AddressFrozen`** **Event** **Description**: Emitted when the wallet of an investor is frozen or unfrozen. ```solidity event AddressFrozen( address indexed _userAddress, bool indexed _isFrozen, address indexed _owner ); ``` *** **`TokensFrozen`** **Event** **Description**: Emitted when a certain amount of tokens is frozen on a wallet. ```solidity event TokensFrozen( address indexed _userAddress, uint256 _amount ); ``` *** **`TokensUnfrozen`** **Event** **Description**: Emitted when a certain amount of tokens is unfrozen on a wallet. ```solidity event TokensUnfrozen( address indexed _userAddress, uint256 _amount ); ``` *** **`Paused`** **Event** **Description**: Emitted when the token contract is paused. ```solidity event Paused(address _userAddress); ``` *** **`Unpaused`** **Event** **Description**: Emitted when the token contract is unpaused. ```solidity event Unpaused(address _userAddress); ``` *** **`setName`** **Source**: `IToken` **Description**: Sets the token name. Only the owner of the token contract can call this function. ```solidity function setName(string calldata _name) external; ``` *** **`setSymbol`** **Source**: `IToken` **Description**: Sets the token symbol. Only the owner of the token contract can call this function. ```solidity function setSymbol(string calldata _symbol) external; ``` *** **`setOnchainID`** **Source**: `IToken` **Description**: Sets the onchain ID of the token. Only the owner of the token contract can call this function. ```solidity function setOnchainID(address _onchainID) external; ``` *** **`pause`** **Source**: `IToken` **Description**: Pauses the token contract, preventing token transfers. Only an agent of the token can call this function. ```solidity function pause() external; ``` *** **`unpause`** **Source**: `IToken` **Description**: Unpauses the token contract, allowing token transfers. Only an agent of the token can call this function. ```solidity function unpause() external; ``` *** **`setAddressFrozen`** **Source**: `IToken` **Description**: Sets the frozen status of a specific address. Only an agent of the token can call this function. ```solidity function setAddressFrozen(address _userAddress, bool _freeze) external; ``` *** **`freezePartialTokens`** **Source**: `IToken` **Description**: Freezes a specific amount of tokens on a given address. Only an agent of the token can call this function. ```solidity function freezePartialTokens(address _userAddress, uint256 _amount) external; ``` *** **`unfreezePartialTokens`** **Source**: `IToken` **Description**: Unfreezes a specific amount of tokens on a given address. Only an agent of the token can call this function. ```solidity function unfreezePartialTokens(address _userAddress, uint256 _amount) external; ``` *** **`setIdentityRegistry`** **Source**: `IToken` **Description**: Sets the Identity Registry for the token. Only the owner of the token contract can call this function. ```solidity function setIdentityRegistry(address _identityRegistry) external; ``` *** **`setCompliance`** **Source**: `IToken` **Description**: Sets the Compliance contract for the token. Only the owner of the token contract can call this function. ```solidity function setCompliance(address _compliance) external; ``` *** **`forcedTransfer`** **Source**: `IToken` **Description**: Forces a transfer of tokens between two whitelisted addresses. Only an agent of the token can call this function. ```solidity function forcedTransfer( address _from, address _to, uint256 _amount ) external returns (bool); ``` *** **`mint`** **Source**: `IToken` **Description**: Mints new tokens to a verified address. Only an agent of the token can call this function. ```solidity function mint(address _to, uint256 _amount) external; ``` *** **`burn`** **Source**: `IToken` **Description**: Burns tokens from a specified address. Only an agent of the token can call this function. ```solidity function burn(address _userAddress, uint256 _amount) external; ``` *** **`recoveryAddress`** **Source**: `IToken` **Description**: Recovers tokens from a lost wallet to a new wallet for an investor. Only an agent of the token can call this function. ```solidity function recoveryAddress( address _lostWallet, address _newWallet, address _investorOnchainID ) external returns (bool); ``` *** **`batchTransfer`** **Source**: `IToken` **Description**: Transfers tokens in batch to multiple addresses. ```solidity function batchTransfer(address[] calldata _toList, uint256[] calldata _amounts) external; ``` *** **`batchForcedTransfer`** **Source**: `IToken` **Description**: Forces transfers of tokens in batch between multiple pairs of addresses. Only an agent of the token can call this function. ```solidity function batchForcedTransfer( address[] calldata _fromList, address[] calldata _toList, uint256[] calldata _amounts ) external; ``` *** **`batchMint`** **Source**: `IToken` **Description**: Mints tokens in batch to multiple addresses. Only an agent of the token can call this function. ```solidity function batchMint(address[] calldata _toList, uint256[] calldata _amounts) external; ``` *** **`batchBurn`** **Source**: `IToken` **Description**: Burns tokens in batch from multiple addresses. Only an agent of the token can call this function. ```solidity function batchBurn(address[] calldata _userAddresses, uint256[] calldata _amounts) external; ``` *** **`batchSetAddressFrozen`** **Source**: `IToken` **Description**: Sets the frozen status of multiple addresses in batch. Only an agent of the token can call this function. ```solidity function batchSetAddressFrozen(address[] calldata _userAddresses, bool[] calldata _freeze) external; ``` *** **`batchFreezePartialTokens`** **Source**: `IToken` **Description**: Freezes tokens partially in batch for multiple addresses. Only an agent of the token can call this function. ```solidity function batchFreezePartialTokens(address[] calldata _userAddresses, uint256[] calldata _amounts) external; ``` *** **`batchUnfreezePartialTokens`** **Source**: `IToken` **Description**: Unfreezes tokens partially in batch for multiple addresses. Only an agent of the token can call this function. ```solidity function batchUnfreezePartialTokens(address[] calldata _userAddresses, uint256[] calldata _amounts) external; ``` *** #### ERC20 Functions **`Transfer`** **Event** **Description**: Emitted when `value` tokens are moved from one account (`from`) to another (`to`). ```solidity event Transfer(address indexed from, address indexed to, uint256 value); ``` *** **`Approval`** **Event** **Description**: Emitted when the allowance of a `spender` for an `owner` is set by a call to `approve`. `value` is the new allowance. ```solidity event Approval(address indexed owner, address indexed spender, uint256 value); ``` *** **`totalSupply`** **Source**: `IERC20` **Description**: Returns the total supply of tokens in existence. ```solidity function totalSupply() external view returns (uint256); ``` *** **`balanceOf`** **Source**: `IERC20` **Description**: Returns the amount of tokens owned by a specific account. ```solidity function balanceOf(address account) external view returns (uint256); ``` *** **`transfer`** **Source**: `IERC20` **Description**: Moves `amount` tokens from the caller's account to a specified address. ```solidity function transfer(address to, uint256 amount) external returns (bool); ``` *** **`allowance`** **Source**: `IERC20` **Description**: Returns the remaining number of tokens that `spender` is allowed to spend on behalf of `owner` through `transferFrom`. ```solidity function allowance(address owner, address spender) external view returns (uint256); ``` *** **`approve`** **Source**: `IERC20` **Description**: Sets `amount` as the allowance of `spender` over the caller's tokens. ```solidity function approve(address spender, uint256 amount) external returns (bool); ``` *** **`transferFrom`** **Source**: `IERC20` **Description**: Moves `amount` tokens from `from` to `to` using the allowance mechanism. `amount` is then deducted from the caller's allowance. ```solidity function transferFrom(address from, address to, uint256 amount) external returns (bool); ``` # Onchain identities ONCHAINID is providing a robust system for managing identities on the blockchain. This system ensures compliance with regulatory requirements and offers flexibility and reusability of claims issued by trusted entities. ## What is ONCHAINID? ONCHAINID is a blockchain-based identity management system that creates a unique, globally accessible identity for each participant. These identities are stored on the public blockchain, making them decentralized, immutable, and beyond the control of any single organization. ## Key Features of ONCHAINID 1. **Decentralized and Immutable**: * ONCHAINIDs are stored on the public blockchain, ensuring that they cannot be hidden or deleted. This guarantees that no service or organization can remove access rights to an ONCHAINID. 2. **Standards-Based**: * ONCHAINID complies with the ERC-734 and ERC-735 standards, ensuring compatibility with any service that supports these standards. Identities are smart contracts deployed on the Polygon Network, supporting implementations that adhere to these ERC proposals. 3. **Claims and Verifiable Credentials**: * The value of an ONCHAINID comes from the information (claims) attached to it. These claims can be self-attested or issued by trusted entities known as Claim Issuers. Claims are essential for verifying that an identity has passed specific checks, such as KYC. ## How ONCHAINID Works ### **Identity and Claims** * **Unique Identifier**: Each ONCHAINID has a unique address on the blockchain. * **Claim Issuers**: Trusted entities, approved by the Identity Owner, can issue claims about the identity. These claims are digital attestations that verify specific attributes or statuses of the identity. * **Private Data**: Sensitive information, such as ID card details or photos, is stored off-chain by the Claim Issuer. Only a signature of this data is stored on-chain, ensuring privacy while allowing verification. ### **Flexibility and Reusability** * **Self-Attested Information**: Some claims can be self-attested, useful for non-regulated contexts like usernames on websites. * **Regulated Exchanges**: For security tokens and other regulated assets, claims need to be issued by trusted entities, ensuring that the identity is linked to a real person or organization. ## Practical Applications 1. **Authentication**: * ONCHAINID enables password-less authentication with compatible websites using hardware security keys or plugins like MetaMask. 2. **Regulated Asset Participation**: * Participants can use their ONCHAINID to engage in compliant, regulated tokenized asset offerings and exchanges. 3. **Information Management**: * Identities can store and manage various types of information, including names, email addresses, and more. Information Providers can securely store this data off-chain and control access based on the Identity Owner's permissions. 4. **Claim Management**: * Claims can be managed by the Identity Owner, who can add or remove claims and control who is allowed to issue claims about their identity. ## Identity Claims and Compliance * **Generic and Specific Claims**: * Claims can be generic, applicable across multiple tokens and issuers, or specific to particular tokens or issuers. For example, an accreditation status might be a generic claim, while eligibility for a specific token offering might be a specific claim. * **Privacy and Security**: * To comply with privacy regulations, sensitive data is stored off-chain. The on-chain component includes a hash of this data to ensure integrity without exposing the data itself. ## Deployment and Cross-Chain Compatibility 1. **Upgradeable Proxies and IdFactory**: * All ONCHAINIDs are deployed as upgradeable proxies (beacon proxy) through an IdFactory contract. This factory ensures that the same user (same deployer wallet address) can deploy the same ONCHAINID on different EVM chains. This is possible because the factory is deployed at the same address on every chain and uses the CREATE2 opcode, enabling the deployment of ONCHAINID at a deterministic address. This cross-chain compatibility allows claims signed on one chain to be valid across multiple chains without requiring new signatures from claim issuers. 2. **Multi-Chain Claims**: * Most claim signatures are based on the content of the claim and the address of the ONCHAINID. By having the same ONCHAINID address across multiple chains, claims can be utilized on different chains without the need for re-signature by the claim issuer. This significantly enhances the efficiency and usability of the ONCHAINID system. ## Enhanced Functionality 1. **Direct Wallet Use**: * ONCHAINIDs can function directly as wallets, holding tokens and interacting with smart contracts through the execute and approve functions inherited from ERC-734. This capability allows ONCHAINIDs to perform transactions and manage assets natively on the blockchain. 2. **Compatibility with ERC-4337**: * The ONCHAINID standard can be compatible with ERC-4337 (account abstraction) by implementing a userOperation function that triggers an execute call following ERC-734. This implementation would make ONCHAINID an abstract account, further enhancing its functionality and integration within the blockchain ecosystem. # ONCHAINID Interface The ONCHAINID interface defines the set of functions and events used to manage identities and claims on the blockchain. It extends the functionality of two key interfaces: `IERC734` and `IERC735`. **`isClaimValid`** **Source**: `IIdentity` This function checks if a claim is valid based on the identity contract, claim topic, signature, and data provided. ```solidity function isClaimValid( IIdentity _identity, uint256 claimTopic, bytes calldata sig, bytes calldata data ) external view returns (bool); ``` **Description**: Validates a claim by verifying the signature and data against the specified claim topic and identity contract. *** **`addKey`** **Source**: `IERC734` This function adds a key to the identity for a specified purpose and key type. ```solidity function addKey(bytes32 _key, uint256 _purpose, uint256 _keyType) external returns (bool success); ``` **Description**: Adds a new key to the identity, where `_purpose` defines the purpose of the key (e.g., management or execution), and `_keyType` specifies the type of key (e.g., an Ethereum address or a hash of a public key). *** **`approve`** **Source**: `IERC734` This function approves an execution request. ```solidity function approve(uint256 _id, bool _approve) external returns (bool success); ``` **Description**: Approves or rejects an execution request identified by `_id`. If approved, the execution proceeds; if not, it is cancelled. *** **`removeKey`** **Source**: `IERC734` This function removes a key for a specified purpose. ```solidity function removeKey(bytes32 _key, uint256 _purpose) external returns (bool success); ``` **Description**: Removes a key associated with a particular purpose from the identity, effectively revoking its rights. *** **`execute`** **Source**: `IERC734` This function executes an operation on behalf of the identity. ```solidity function execute(address _to, uint256 _value, bytes calldata _data) external payable returns (uint256 executionId); ``` **Description**: Executes a transaction on behalf of the identity. The `_to` parameter specifies the recipient address, `_value` is the amount of Ether to send, and `_data` contains the call data. Returns an `executionId` for tracking the operation. *** **`getKey`** **Source**: `IERC734` This function retrieves the full data for a specified key. ```solidity function getKey(bytes32 _key) external view returns (uint256[] memory purposes, uint256 keyType, bytes32 key); ``` **Description**: Returns the purposes, key type, and key value for a specified key. Useful for understanding the roles and permissions associated with a key. *** **`getKeyPurposes`** **Source**: `IERC734` This function returns the list of purposes associated with a key. ```solidity function getKeyPurposes(bytes32 _key) external view returns (uint256[] memory _purposes); ``` **Description**: Retrieves all purposes assigned to a specified key, providing insight into what the key can be used for. *** **`getKeysByPurpose`** **Source**: `IERC734` This function returns an array of keys associated with a specific purpose. ```solidity function getKeysByPurpose(uint256 _purpose) external view returns (bytes32[] memory keys); ``` **Description**: Lists all keys that serve a particular purpose, aiding in the management and audit of keys within the identity. *** **`keyHasPurpose`** **Source**: `IERC734` This function checks if a key has a given purpose. ```solidity function keyHasPurpose(bytes32 _key, uint256 _purpose) external view returns (bool exists); ``` **Description**: Verifies whether a specific key is assigned a particular purpose, returning `true` if it exists and `false` otherwise. *** **`addClaim`** **Source**: `IERC735` This function adds or updates a claim. ```solidity function addClaim( uint256 _topic, uint256 _scheme, address issuer, bytes calldata _signature, bytes calldata _data, string calldata _uri ) external returns (bytes32 claimRequestId); ``` **Description**: Adds a new claim or updates an existing claim. The claim is associated with a `_topic`, uses a `_scheme` for the signature, and includes the claim's data and URI. *** **`removeClaim`** **Source**: `IERC735` This function removes a claim from the identity. ```solidity function removeClaim(bytes32 _claimId) external returns (bool success); ``` **Description**: Deletes a claim identified by `_claimId`, revoking the associated attestation. *** **`getClaim`** **Source**: `IERC735` This function retrieves a claim by its ID. ```solidity function getClaim(bytes32 _claimId) external view returns( uint256 topic, uint256 scheme, address issuer, bytes memory signature, bytes memory data, string memory uri); ``` **Description**: Returns the full details of a claim, including its topic, scheme, issuer, signature, data, and URI. *** **`getClaimIdsByTopic`** **Source**: `IERC735` This function returns an array of claim IDs for a given topic. ```solidity function getClaimIdsByTopic(uint256 _topic) external view returns (bytes32[] memory claimIds); ``` **Description**: Lists all claim IDs associated with a specific topic, facilitating the management and audit of claims. # Identity Registry The Identity Registry is responsible for managing and verifying the identities of participants in the ecosystem. It ensures that only compliant and verified participants can hold and transfer tokens, thereby enforcing regulatory requirements and enhancing the security of the platform. #### Key Features of the Identity Registry 1. **Identity Verification**: * The Identity Registry maintains a registry of verified identities. Each identity is linked to an ONCHAINID, which contains the necessary claims and credentials to verify the identity of the participant. * By verifying identities, the registry ensures that all token holders and participants in the ecosystem meet the required compliance standards, such as KYC (Know Your Customer), AML (Anti-Money Laundering) and other required criterias. 2. **Compliance Enforcement**: * The Identity Registry interacts with the Compliance contract to enforce transfer rules and restrictions. This interaction ensures that only eligible investors can participate in token transactions, maintaining the integrity of the security token market. 3. **Claims Management**: * The registry manages claims associated with each identity. Claims are issued by trusted entities known as Claim Issuers and are essential for verifying various aspects of an identity, such as its KYC status. * The system supports both self-attested claims and third-party verified claims, providing flexibility and robustness in identity management. 4. **Global Accessibility**: * The Identity Registry is designed to be globally accessible, allowing participants from different jurisdictions to be verified and compliant with local regulations. * The use of blockchain technology ensures that the registry is transparent, secure, and immutable, providing a reliable source of truth for identity verification. #### How the Identity Registry Works 1. **Registration Process**: * Participants create an ONCHAINID, which is then registered with the Identity Registry. The ONCHAINID is linked to various claims that verify the participant's identity. * Trusted Claim Issuers can issue claims to ONCHAINIDs, attesting to the participant's compliance with regulatory requirements. 2. **Verification and Compliance**: * During a token transfer or any other regulated action, the Identity Registry checks the participant's ONCHAINID and associated claims to ensure compliance. * If the participant meets all the necessary criteria, the action is approved. If not, it is rejected, maintaining the integrity of the system. #### Interaction with Other Registries 1. **Identity Registry Storage**: * The Identity Registry fetches the ONCHAINID address corresponding to the recipient's wallet from the Identity Registry Storage. This storage can be shared by multiple Identity Registry contracts, allowing for efficient and centralized identity management. 2. **Claim Topics Registry**: * The Claim Topics Registry defines the types of claims required for compliance. The Identity Registry compares the claims held by an ONCHAINID with the requirements specified in the Claim Topics Registry. 3. **Trusted Issuers Registry**: * The Trusted Issuers Registry lists the entities authorized to issue claims. The Identity Registry verifies that the claims on an ONCHAINID are issued by trusted entities listed in this registry. #### Transfer Verification Process When a transfer occurs and the `isVerified` function is called on the Identity Registry to check the eligibility of an investor, the following steps are performed: 1. **Fetch ONCHAINID**: * The Identity Registry fetches the ONCHAINID address corresponding to the recipient's wallet from the Identity Registry Storage. 2. **Compare Claims**: * It compares the claims held by the ONCHAINID with the requirements specified in the Claim Topics Registry and the Trusted Issuers Registry. 3. **Validate Claims**: * The Identity Registry checks the validity of the claims by verifying the signatures on the claims against the Claim Issuer contracts. 4. **Return Verification Status**: * If all claims are valid and meet the requirements, the `isVerified` function returns true, allowing the transfer to proceed. If not, it returns false, blocking the transfer. # Identity Registry Interface The Identity Registry interface defines the set of functions and events used to manage and verify identities within the T-REX protocol. Below is a detailed breakdown of each function and event, explaining its purpose, source, and functionality. **`ClaimTopicsRegistrySet`** **Event** **Description**: Emitted when the Claim Topics Registry has been set for the Identity Registry. ```solidity event ClaimTopicsRegistrySet(address indexed claimTopicsRegistry); ``` *** **`IdentityStorageSet`** **Event** **Description**: Emitted when the Identity Registry Storage has been set for the Identity Registry. ```solidity event IdentityStorageSet(address indexed identityStorage); ``` *** **`TrustedIssuersRegistrySet`** **Event** **Description**: Emitted when the Trusted Issuers Registry has been set for the Identity Registry. ```solidity event TrustedIssuersRegistrySet(address indexed trustedIssuersRegistry); ``` *** **`IdentityRegistered`** **Event** **Description**: Emitted when an identity is registered in the Identity Registry. ```solidity event IdentityRegistered(address indexed investorAddress, IIdentity indexed identity); ``` *** **`IdentityRemoved`** **Event** **Description**: Emitted when an identity is removed from the Identity Registry. ```solidity event IdentityRemoved(address indexed investorAddress, IIdentity indexed identity); ``` *** **`IdentityUpdated`** **Event** **Description**: Emitted when an identity has been updated in the Identity Registry. ```solidity event IdentityUpdated(IIdentity indexed oldIdentity, IIdentity indexed newIdentity); ``` *** **`CountryUpdated`** **Event** **Description**: Emitted when an investor's country information is updated in the Identity Registry. ```solidity event CountryUpdated(address indexed investorAddress, uint16 indexed country); ``` *** **`registerIdentity`** **Source**: `IIdentityRegistry` **Description**: Registers an identity contract corresponding to a user address. Only callable by an agent of the contract. ```solidity function registerIdentity( address _userAddress, IIdentity _identity, uint16 _country ) external; ``` *** **`deleteIdentity`** **Source**: `IIdentityRegistry` **Description**: Removes a user from the Identity Registry. Only callable by an agent of the contract. ```solidity function deleteIdentity(address _userAddress) external; ``` *** **`setIdentityRegistryStorage`** **Source**: `IIdentityRegistry` **Description**: Replaces the current Identity Registry Storage contract with a new one. Only callable by the owner of the contract. ```solidity function setIdentityRegistryStorage(address _identityRegistryStorage) external; ``` *** **`setClaimTopicsRegistry`** **Source**: `IIdentityRegistry` **Description**: Replaces the current Claim Topics Registry contract with a new one. Only callable by the owner of the contract. ```solidity function setClaimTopicsRegistry(address _claimTopicsRegistry) external; ``` *** **`setTrustedIssuersRegistry`** **Source**: `IIdentityRegistry` **Description**: Replaces the current Trusted Issuers Registry contract with a new one. Only callable by the owner of the contract. ```solidity function setTrustedIssuersRegistry(address _trustedIssuersRegistry) external; ``` *** **`updateCountry`** **Source**: `IIdentityRegistry` **Description**: Updates the country corresponding to a user address. Only callable by an agent of the contract. ```solidity function updateCountry(address _userAddress, uint16 _country) external; ``` *** **`updateIdentity`** **Source**: `IIdentityRegistry` **Description**: Updates an identity contract corresponding to a user address. Only callable by an agent of the contract. ```solidity function updateIdentity(address _userAddress, IIdentity _identity) external; ``` *** **`batchRegisterIdentity`** **Source**: `IIdentityRegistry` **Description**: Registers multiple identities in batch. Only callable by an agent of the contract. ```solidity function batchRegisterIdentity( address[] calldata _userAddresses, IIdentity[] calldata _identities, uint16[] calldata _countries ) external; ``` *** **`contains`** **Source**: `IIdentityRegistry` **Description**: Checks whether a wallet address is registered in the Identity Registry. ```solidity function contains(address _userAddress) external view returns (bool); ``` *** **`isVerified`** **Source**: `IIdentityRegistry` **Description**: Checks whether an identity contract corresponding to a user address has the required claims for verification. ```solidity function isVerified(address _userAddress) external view returns (bool); ``` *** **`identity`** **Source**: `IIdentityRegistry` **Description**: Returns the ONCHAINID of an investor based on their wallet address. ```solidity function identity(address _userAddress) external view returns (IIdentity); ``` *** **`investorCountry`** **Source**: `IIdentityRegistry` **Description**: Returns the country code of an investor based on their wallet address. ```solidity function investorCountry(address _userAddress) external view returns (uint16); ``` *** **`identityStorage`** **Source**: `IIdentityRegistry` **Description**: Returns the Identity Registry Storage linked to the current Identity Registry. ```solidity function identityStorage() external view returns (IIdentityRegistryStorage); ``` *** **`issuersRegistry`** **Source**: `IIdentityRegistry` **Description**: Returns the Trusted Issuers Registry linked to the current Identity Registry. ```solidity function issuersRegistry() external view returns (ITrustedIssuersRegistry); ``` *** **`topicsRegistry`** **Source**: `IIdentityRegistry` **Description**: Returns the Claim Topics Registry linked to the current Identity Registry. ```solidity function topicsRegistry() external view returns (IClaimTopicsRegistry); ``` # Identity Registry Storage The Identity Registry Storage is serving as the backbone for storing and managing identity data. It works in conjunction with the Identity Registry to ensure that identity information is securely stored, easily accessible, and efficiently managed. ## Key Features of the Identity Registry Storage 1. **Centralized Storage**: * The Identity Registry Storage acts as a centralized repository for identity data. It stores mappings of wallet addresses to ONCHAINID addresses, ensuring that identity information is consistently and securely maintained. 2. **Interoperability**: * The same Identity Registry Storage can be shared by multiple Identity Registry contracts. This feature enhances interoperability and ensures that identity data can be accessed and managed across different parts of the T-REX ecosystem. 3. **Efficient Data Retrieval**: * The Identity Registry Storage is designed for efficient data retrieval, enabling quick access to identity information. This is particularly important for verifying identities during token transfers and other regulated actions. ## How the Identity Registry Storage Works 1. **Data Storage**: * The Identity Registry Storage stores the ONCHAINID addresses corresponding to participant wallet addresses. This mapping ensures that each wallet address can be linked to an ONCHAINID, which contains the necessary claims and credentials for identity verification. 2. **Integration with Identity Registry**: * When the `isVerified` function is called on the Identity Registry, the Identity Registry fetches the ONCHAINID address corresponding to the recipient's wallet from the Identity Registry Storage. This process is critical for verifying the identity of participants during transactions. ## Benefits of Identity Registry Storage 1. **Security and Reliability**: * By centralizing the storage of identity data, the Identity Registry Storage ensures that identity information is secure and reliable. The use of blockchain technology provides immutability and transparency, making it a trustworthy source of identity data. 2. **Scalability**: * The ability to share the same Identity Registry Storage across multiple Identity Registry contracts enhances the scalability of the T-REX protocol. It allows for efficient management of identity data as the ecosystem grows. 3. **Flexibility**: * The design of the Identity Registry Storage allows for flexible integration with other components of the T-REX protocol. It can easily adapt to different use cases and requirements, providing a robust solution for identity management. # Identity Registry Storage Interface The Identity Registry Storage interface defines the set of functions and events used to manage and store identity data within the T-REX protocol. Below is a detailed breakdown of each function and event, explaining its purpose, source, and functionality. **`IdentityStored`** **Event** **Description**: Emitted when an identity is registered into the storage contract. ```solidity event IdentityStored(address indexed investorAddress, IIdentity indexed identity); ``` *** **`IdentityUnstored`** **Event** **Description**: Emitted when an identity is removed from the storage contract. ```solidity event IdentityUnstored(address indexed investorAddress, IIdentity indexed identity); ``` *** **`IdentityModified`** **Event** **Description**: Emitted when an identity has been updated in the storage contract. ```solidity event IdentityModified(IIdentity indexed oldIdentity, IIdentity indexed newIdentity); ``` *** **`CountryModified`** **Event** **Description**: Emitted when an identity's country has been updated in the storage contract. ```solidity event CountryModified(address indexed investorAddress, uint16 indexed country); ``` *** **`IdentityRegistryBound`** **Event** **Description**: Emitted when an Identity Registry is bound to the storage contract. ```solidity event IdentityRegistryBound(address indexed identityRegistry); ``` *** **`IdentityRegistryUnbound`** **Event** **Description**: Emitted when an Identity Registry is unbound from the storage contract. ```solidity event IdentityRegistryUnbound(address indexed identityRegistry); ``` *** **`addIdentityToStorage`** **Source**: `IIdentityRegistryStorage` **Description**: Adds an identity contract corresponding to a user address in the storage. Only callable by an agent of the contract. ```solidity function addIdentityToStorage( address _userAddress, IIdentity _identity, uint16 _country ) external; ``` *** **`removeIdentityFromStorage`** **Source**: `IIdentityRegistryStorage` **Description**: Removes a user from the storage. Only callable by an agent of the contract. ```solidity function removeIdentityFromStorage(address _userAddress) external; ``` *** **`modifyStoredInvestorCountry`** **Source**: `IIdentityRegistryStorage` **Description**: Updates the country corresponding to a user address. Only callable by an agent of the contract. ```solidity function modifyStoredInvestorCountry(address _userAddress, uint16 _country) external; ``` *** **`modifyStoredIdentity`** **Source**: `IIdentityRegistryStorage` **Description**: Updates an identity contract corresponding to a user address. Only callable by an agent of the contract. ```solidity function modifyStoredIdentity(address _userAddress, IIdentity _identity) external; ``` *** **`bindIdentityRegistry`** **Source**: `IIdentityRegistryStorage` **Description**: Adds an identity registry as an agent of the Identity Registry Storage Contract. Only callable by the owner of the contract. ```solidity function bindIdentityRegistry(address _identityRegistry) external; ``` *** **`unbindIdentityRegistry`** **Source**: `IIdentityRegistryStorage` **Description**: Removes an identity registry from being an agent of the Identity Registry Storage Contract. Only callable by the owner of the contract. ```solidity function unbindIdentityRegistry(address _identityRegistry) external; ``` *** **`linkedIdentityRegistries`** **Source**: `IIdentityRegistryStorage` **Description**: Returns the identity registries linked to the storage contract. ```solidity function linkedIdentityRegistries() external view returns (address[] memory); ``` *** **`storedIdentity`** **Source**: `IIdentityRegistryStorage` **Description**: Returns the ONCHAINID of an investor based on their wallet address. ```solidity function storedIdentity(address _userAddress) external view returns (IIdentity); ``` *** **`storedInvestorCountry`** **Source**: `IIdentityRegistryStorage` **Description**: Returns the country code of an investor based on their wallet address. ```solidity function storedInvestorCountry(address _userAddress) external view returns (uint16); ``` # Trusted Issuers Registry The Trusted Issuers Registry (TIR) is responsible for managing and verifying the list of entities authorized to issue claims. This registry ensures that only verified and trusted issuers can contribute to the identity verification process, thereby enhancing the security and reliability of the protocol. ## Key Features of the Trusted Issuers Registry 1. **Authorization of Issuers**: * The TIR maintains a list of authorized claim issuers. These issuers are trusted entities that can issue claims verifying various aspects of an identity, such as KYC status, AML compliance, and more. 2. **Interoperability with Identity Verification**: * The TIR works in conjunction with the Identity Registry and the Claim Topics Registry to verify the claims associated with an ONCHAINID. This integration ensures that all claims are issued by recognized and trusted entities. 3. **Dynamic Management**: * The registry allows for the dynamic addition and removal of trusted issuers. This flexibility ensures that the list of trusted issuers can be updated as new issuers are verified or existing issuers are revoked. ## How the Trusted Issuers Registry Works 1. **Listing Trusted Issuers**: * The TIR lists the addresses of entities authorized to issue claims. Each trusted issuer is added to the registry through a formal process to ensure their credibility and reliability. 2. **Verification Process**: * During the identity verification process, the Identity Registry checks the claims on an ONCHAINID against the list of trusted issuers in the TIR. If the claims are issued by entities listed in the TIR and meet the required claim topics, they are considered valid. 3. **Integration with Other Components**: * The TIR integrates with the Identity Registry Storage and the Claim Topics Registry to provide a comprehensive verification process. This ensures that all claims are valid and issued by trusted entities, maintaining the integrity of the protocol. ## Interaction with Other T-REX Components * **Identity Registry**: The TIR provides the list of trusted issuers to the Identity Registry. This information is used to verify the claims on an ONCHAINID during the identity verification process. * **Claim Topics Registry**: The TIR works with the Claim Topics Registry to ensure that only claims issued by trusted entities are considered valid. This collaboration enhances the security and reliability of the verification process. ## Benefits of the Trusted Issuers Registry 1. **Enhanced Security**: * By maintaining a list of trusted issuers, the TIR ensures that only verified and credible entities can issue claims. This reduces the risk of fraudulent claims and enhances the security of the T-REX protocol. 2. **Regulatory Compliance**: * The TIR supports regulatory compliance by ensuring that all claims used for identity verification are issued by trusted entities. This compliance is crucial for maintaining the legal integrity of the protocol. 3. **Flexibility and Adaptability**: * The ability to dynamically manage the list of trusted issuers allows the TIR to adapt to changing regulatory requirements and new entrants in the market. This flexibility ensures long-term compliance and operational efficiency. # Trusted Issuers Registry Interface The Trusted Issuers Registry interface defines the set of functions and events used to manage and verify trusted claim issuers within the T-REX protocol. Below is a detailed breakdown of each function and event, explaining its purpose, source, and functionality. **`TrustedIssuerAdded`** **Event** **Description**: Emitted when a trusted issuer is added to the registry. ```solidity event TrustedIssuerAdded(IClaimIssuer indexed trustedIssuer, uint256[] claimTopics); ``` *** **`TrustedIssuerRemoved`** **Event** **Description**: Emitted when a trusted issuer is removed from the registry. ```solidity event TrustedIssuerRemoved(IClaimIssuer indexed trustedIssuer); ``` *** **`ClaimTopicsUpdated`** **Event** **Description**: Emitted when the set of claim topics is changed for a given trusted issuer. ```solidity event ClaimTopicsUpdated(IClaimIssuer indexed trustedIssuer, uint256[] claimTopics); ``` *** **`addTrustedIssuer`** **Source**: `ITrustedIssuersRegistry` **Description**: Registers a ClaimIssuer contract as a trusted claim issuer. This function can only be called by the owner of the Trusted Issuers Registry contract and emits a `TrustedIssuerAdded` event. ```solidity function addTrustedIssuer(IClaimIssuer _trustedIssuer, uint256[] calldata _claimTopics) external; ``` *** **`removeTrustedIssuer`** **Source**: `ITrustedIssuersRegistry` **Description**: Removes the ClaimIssuer contract of a trusted claim issuer. This function can only be called by the owner of the Trusted Issuers Registry contract and emits a `TrustedIssuerRemoved` event. ```solidity function removeTrustedIssuer(IClaimIssuer _trustedIssuer) external; ``` *** **`updateIssuerClaimTopics`** **Source**: `ITrustedIssuersRegistry` **Description**: Updates the set of claim topics that a trusted issuer is allowed to emit. This function can only be called by the owner of the Trusted Issuers Registry contract and emits a `ClaimTopicsUpdated` event. ```solidity function updateIssuerClaimTopics(IClaimIssuer _trustedIssuer, uint256[] calldata _claimTopics) external; ``` *** **`getTrustedIssuers`** **Source**: `ITrustedIssuersRegistry` **Description**: Returns an array of all claim issuers registered in the Trusted Issuers Registry. ```solidity function getTrustedIssuers() external view returns (IClaimIssuer[] memory); ``` *** **`getTrustedIssuersForClaimTopic`** **Source**: `ITrustedIssuersRegistry` **Description**: Returns an array of all claim issuer addresses that are allowed to issue a given claim topic. ```solidity function getTrustedIssuersForClaimTopic(uint256 claimTopic) external view returns (IClaimIssuer[] memory); ``` *** **`isTrustedIssuer`** **Source**: `ITrustedIssuersRegistry` **Description**: Checks if a given ClaimIssuer contract is trusted. ```solidity function isTrustedIssuer(address _issuer) external view returns (bool); ``` *** **`getTrustedIssuerClaimTopics`** **Source**: `ITrustedIssuersRegistry` **Description**: Returns the set of claim topics that a given trusted issuer is allowed to emit. ```solidity function getTrustedIssuerClaimTopics(IClaimIssuer _trustedIssuer) external view returns (uint256[] memory); ``` *** **`hasClaimTopic`** **Source**: `ITrustedIssuersRegistry` **Description**: Checks if a given trusted issuer is allowed to emit a certain claim topic. ```solidity function hasClaimTopic(address _issuer, uint256 _claimTopic) external view returns (bool); ``` # Claim Topics Registry The Claim Topics Registry (CTR) is responsible for listing the claim topics required for a token. Each token has its own Claim Topics Registry, which specifies the types of claims that must be present on an ONCHAINID for an investor to be considered eligible. The CTR works in conjunction with the Identity Registry, the Identity Registry Storage, and the Trusted Issuers Registry to ensure comprehensive compliance verification. ## Key Features of the Claim Topics Registry 1. **Definition of Required Claims**: * The Claim Topics Registry lists the claim topics that are mandatory for an ONCHAINID to be eligible. These claims can include KYC, AML, accreditation, and other regulatory requirements. 2. **Integration with Identity Verification**: * The CTR plays a vital role in the identity verification process. When the `isVerified` function is called on the Identity Registry, it fetches the required claim topics from the CTR to verify the ONCHAINID. 3. **Dynamic Management**: * The Claim Topics Registry allows for the dynamic addition and removal of claim topics. This ensures that the registry can adapt to evolving regulatory requirements and specific needs of different tokens. ## How the Claim Topics Registry Works 1. **Listing Claim Topics**: * The CTR lists the claim topics required for a specific token. Each claim topic is represented by a unique identifier. These topics are essential for compliance and regulatory verification. 2. **Verification Process**: * During the verification process, the Identity Registry fetches the ONCHAINID address from the Identity Registry Storage and retrieves the list of required claim topics from the CTR. * The Identity Registry also fetches the list of Trusted Issuers from the Trusted Issuers Registry and compares the claims held on the ONCHAINID with the required claim topics. * If the ONCHAINID has the required claims and the claims are issued by trusted issuers, the `isVerified` function then checks the cryptographic signatures to ensure validity. 3. **Ensuring Compliance**: * By defining the required claim topics, the CTR ensures that all participants in the ecosystem meet the necessary regulatory standards. This compliance is crucial for maintaining the integrity and legality of the token transactions. ## Interaction with Other T-REX Components * **Identity Registry**: The CTR provides the necessary claim topics for the Identity Registry to verify the eligibility of ONCHAINIDs. This integration ensures that all identity verifications are based on standardized and required claims. * **Identity Registry Storage**: The CTR works with the Identity Registry Storage to fetch the ONCHAINID addresses. This ensures that the verification process has access to the correct identity information. * **Trusted Issuers Registry**: The CTR lists the required claim topics, while the Trusted Issuers Registry provides the list of entities authorized to issue these claims. This collaboration ensures that only valid claims from trusted sources are accepted. ## Benefits of the Claim Topics Registry 1. **Regulatory Compliance**: * The CTR ensures that all participants comply with regulatory requirements by mandating specific claim topics. This reduces the risk of legal issues and enhances the credibility of the T-REX protocol. 2. **Flexibility**: * The ability to dynamically manage claim topics allows the CTR to adapt to changing regulatory environments. This flexibility is essential for maintaining long-term compliance and operational efficiency. 3. **Enhanced Security**: * By defining and verifying required claims, the CTR enhances the security of the T-REX protocol. It ensures that only participants with valid and verified claims can engage in token transactions. ## **Adding a new Claim Topic** To define investor eligibility criteria for an ERC-3643 token, the token owner must add claim topics and trusted issuers. This process ensures that investors are verified according to the framework standards. The following sequence diagram illustrates this process:
# Claim Topics Registry Interface The Claim Topics Registry interface defines the set of functions and events used to manage the required claim topics for tokens within the T-REX protocol. Below is a detailed breakdown of each function and event, explaining its purpose, source, and functionality. **`ClaimTopicAdded`** **Event** **Description**: Emitted when a claim topic has been added to the Claim Topics Registry. ```solidity event ClaimTopicAdded(uint256 indexed claimTopic); ``` *** **`ClaimTopicRemoved`** **Event** **Description**: Emitted when a claim topic has been removed from the Claim Topics Registry. ```solidity event ClaimTopicRemoved(uint256 indexed claimTopic); ``` *** **`addClaimTopic`** **Source**: `IClaimTopicsRegistry` **Description**: Adds a trusted claim topic to the Claim Topics Registry. Only callable by the owner of the contract. This function emits a `ClaimTopicAdded` event. ```solidity function addClaimTopic(uint256 _claimTopic) external; ``` *** **`removeClaimTopic`** **Source**: `IClaimTopicsRegistry` **Description**: Removes a trusted claim topic from the Claim Topics Registry. Only callable by the owner of the contract. This function emits a `ClaimTopicRemoved` event. ```solidity function removeClaimTopic(uint256 _claimTopic) external; ``` *** **`getClaimTopics`** **Source**: `IClaimTopicsRegistry` **Description**: Returns the list of trusted claim topics for the token. ```solidity function getClaimTopics() external view returns (uint256[] memory); ``` # Compliance management The Compliance contract is ensuring that all token operations adhere to regulatory requirements and standards. It works in conjunction with the Identity Registry and other components to enforce rules and restrictions on token transfers, maintaining the integrity and legality of the security token ecosystem. ## Key Features of the Compliance Contract 1. **Regulatory Compliance**: * The Compliance contract enforces regulatory rules and restrictions on token transfers. This includes ensuring that only eligible investors can participate in token transactions and that all transactions comply with KYC (Know Your Customer) and AML (Anti-Money Laundering) regulations. 2. **Flexible Rule Management**: * The Compliance contract allows for the dynamic addition and modification of compliance rules. This flexibility ensures that the contract can adapt to changing regulatory landscapes and specific requirements of different token offerings. 3. **Interoperability with Identity Registry**: * The Compliance contract interacts closely with the Identity Registry to verify the identity and eligibility of participants. By leveraging the verified identities stored in the Identity Registry, the Compliance contract ensures that all participants meet the necessary regulatory standards. ## How the Compliance Contract Works 1. **Binding Tokens**: * The Compliance contract can bind and unbind tokens through the `bindToken` and `unbindToken` functions. These functions emit `TokenBound` and `TokenUnbound` events respectively, ensuring transparency and traceability of the binding process. 2. **Transaction Monitoring**: * The Compliance contract monitors all token transfers, creations, and destructions using the `transferred`, `created`, and `destroyed` functions. These functions update state variables within the contract, which are then used to enforce compliance rules. 3. **Compliance Verification**: * The `canTransfer` function checks whether a proposed token transfer complies with the set rules. This function verifies the sender's and receiver's eligibility and other parameters, returning `true` if the transfer is compliant and `false` otherwise. * The `isTokenAgent` and `isTokenBound` functions provide additional checks to ensure that only authorized agents and bound tokens interact with the compliance mechanisms. ## Integration with Other T-REX Components * **Identity Registry**: The Compliance contract relies on the Identity Registry to provide verified identity data. This integration ensures that all compliance checks are based on accurate and up-to-date information. * **Token Smart Contract**: The Compliance contract works with the Token Smart Contract to enforce compliance rules during token transfers. It acts as a gatekeeper, allowing only those transactions that meet all regulatory requirements. ## Benefits of the Compliance Contract 1. **Regulatory Assurance**: * By enforcing strict compliance rules, the Compliance contract provides assurance that all token transactions are legal and compliant with relevant regulations. This reduces the risk of legal issues and enhances the credibility of the T-REX protocol. 2. **Flexibility and Adaptability**: * The ability to dynamically manage compliance rules ensures that the T-REX protocol can adapt to changing regulatory environments and specific requirements of different token offerings. This flexibility is crucial for maintaining long-term compliance and operational efficiency. 3. **Enhanced Security**: * The Compliance contract enhances the security of the T-REX protocol by ensuring that only verified and eligible participants can engage in token transactions. This reduces the risk of fraud and unauthorized activities within the ecosystem. # Compliance Interface The Compliance contract interface defines the set of functions and events used to enforce regulatory compliance within the T-REX protocol. Below is a detailed breakdown of each function and event, explaining its purpose, source, and functionality. **`TokenBound`** **Event** **Description**: Emitted when a token has been bound to the compliance contract. ```solidity event TokenBound(address _token); ``` *** **`TokenUnbound`** **Event** **Description**: Emitted when a token has been unbound from the compliance contract. ```solidity event TokenUnbound(address _token); ``` *** **`bindToken`** **Source**: `ICompliance` **Description**: Binds a token to the compliance contract. This function emits a `TokenBound` event. ```solidity function bindToken(address _token) external; ``` *** **`unbindToken`** **Source**: `ICompliance` **Description**: Unbinds a token from the compliance contract. This function emits a `TokenUnbound` event. ```solidity function unbindToken(address _token) external; ``` *** **`transferred`** **Source**: `ICompliance` **Description**: Called whenever tokens are transferred from one wallet to another. This function can update state variables in the compliance contract, which are used by `canTransfer` to decide if a transfer is compliant. ```solidity function transferred( address _from, address _to, uint256 _amount ) external; ``` *** **`created`** **Source**: `ICompliance` **Description**: Called whenever tokens are created on a wallet. This function can update state variables in the compliance contract, which are used by `canTransfer` to decide if a transfer is compliant. ```solidity function created(address _to, uint256 _amount) external; ``` *** **`destroyed`** **Source**: `ICompliance` **Description**: Called whenever tokens are destroyed. This function can update state variables in the compliance contract, which are used by `canTransfer` to decide if a transfer is compliant. ```solidity function destroyed(address _from, uint256 _amount) external; ``` *** **`isTokenAgent`** **Source**: `ICompliance` **Description**: Returns true if the address given corresponds to a token agent. ```solidity function isTokenAgent(address _agentAddress) external view returns (bool); ``` *** **`isTokenBound`** **Source**: `ICompliance` **Description**: Returns true if the address given corresponds to a token that is bound with the compliance contract. ```solidity function isTokenBound(address _token) external view returns (bool); ``` *** **`canTransfer`** **Source**: `ICompliance` **Description**: Checks if a transfer is compliant. This is a read-only function that cannot be used to increment counters, emit events, or modify state variables. ```solidity function canTransfer( address _from, address _to, uint256 _amount ) external view returns (bool); ``` # Tokens Factory The T-REX Factory is a pivotal smart contract in the T-REX protocol, deployed at the same address on every EVM-compatible chain where the ERC-3643 association has implemented the protocol. It enables users to deploy the entire T-REX suite (Token, Identity Registry, Identity Registry Storage, Claim Topics Registry, Trusted Issuers Registry, and Compliance) in a single transaction, streamlining the setup process and ensuring consistency across multiple blockchains. ## Benefits of the T-REX Factory 1. **Efficiency and Consistency**: * The single transaction deployment process ensures that all components of the T-REX suite are deployed consistently and efficiently. This reduces the complexity and potential errors associated with manual deployments. 2. **Future-Proof Design**: * The use of upgradeable proxies ensures that deployed contracts can be updated without needing redeployment. This future-proof design allows the T-REX protocol to adapt to new standards and requirements seamlessly. 3. **Enhanced Interoperability**: * The cross-chain consistency provided by the T-REX Factory enhances the interoperability of the T-REX ecosystem. It ensures that claims and credentials can be used across different networks, reducing the need for redundant verification processes. ## Key Features of the T-REX Factory 1. **Single Transaction Deployment**: * The T-REX Factory allows the deployment of the entire T-REX suite in one transaction. This includes the Token, Identity Registry (IR), Identity Registry Storage (IRS), Claim Topics Registry (CTR), Trusted Issuers Registry (TIR), and Compliance contracts. 2. **Predefined Settings**: * Users can predefine a wide range of settings in the deployment transaction, including defining agents for the Token and IR, required claim topics, trusted issuers, and more. This feature ensures that all necessary configurations are set up during deployment. 3. **Reuse of Existing IRS**: * The T-REX Factory can reuse an existing IRS if it needs to be shared with other tokens. If not, it will create a new IRS. This flexibility allows for efficient use of resources and better integration with existing infrastructure. 4. **Upgradeable Proxies**: * All contracts deployed by the T-REX Factory are implemented as upgradeable proxies (beacon proxies). This design ensures that contracts can be updated without requiring redeployment, providing a future-proof solution. 5. **Cross-Chain Consistency**: * Using the CREATE2 opcode, the T-REX Factory ensures that contracts can be deployed at the same address across different EVM chains. This consistency is crucial for cross-chain interoperability and seamless integration. 6. **Linked to IdFactory**: * The T-REX Factory is linked to the IdFactory, which it uses to deploy ONCHAINID contracts. When deploying a T-REX suite, the factory generates an AssetID (the onchain identity of the tokenized asset), ensuring that each tokenized asset has a unique and verifiable identity. ## How the T-REX Factory Works 1. **Deployment Process**: * The T-REX Factory deploys a new T-REX token and sets all the parameters as required. It handles the deployment of the Token, IR, IRS (if not provided), CTR, TIR, and Compliance contracts, setting owners, agents, required claims, and trusted issuers in a single transaction. 2. **Predefined Configurations**: * During deployment, users can define various settings such as token details, agents, compliance modules, and claim details. This comprehensive setup ensures that the deployed contracts are fully configured and ready for use. 3. **Cross-Chain Deployment**: * By leveraging the CREATE2 opcode, the T-REX Factory deploys contracts at predetermined addresses, ensuring that the same address can be used across different EVM chains. This feature supports the seamless use of claims and credentials across multiple networks. 4. **Integration with Other Components**: * The T-REX Factory integrates with the IdFactory to deploy ONCHAINIDs, generating unique identities for tokenized assets. It also interacts with implementation authority contracts to ensure that the correct contract versions are used. # T-REX Factory Interface The T-REX Factory interface defines the set of functions and events used to deploy and manage the T-REX suite of contracts. Below is a detailed breakdown of each function and event, explaining its purpose, source, and functionality. Additionally, the structs `TokenDetails` and `ClaimDetails` are defined to provide a comprehensive understanding of how to interact with the T-REX Factory contract. **Structs** **`TokenDetails`** **Description**: This struct holds all the necessary details for deploying a new T-REX token and its associated contracts. ```solidity struct TokenDetails { address owner; // Address of the owner of all contracts string name; // Name of the token string symbol; // Symbol / ticker of the token uint8 decimals; // Decimals of the token (can be between 0 and 18) address irs; // Identity registry storage address address ONCHAINID; // ONCHAINID of the token address[] irAgents; // List of agents of the identity registry address[] tokenAgents; // List of agents of the token address[] complianceModules; // Modules to bind to the compliance bytes[] complianceSettings; // Settings calls for compliance modules } ``` **`ClaimDetails`** **Description**: This struct holds all the necessary details regarding the claims and claim issuers. ```solidity struct ClaimDetails { uint256[] claimTopics; // Claim topics required address[] issuers; // Trusted issuers addresses uint256[][] issuerClaims; // Claims that issuers are allowed to emit } ``` **`Deployed`** **Event** **Description**: Emitted whenever a single contract is deployed by the factory. ```solidity event Deployed(address indexed _addr); ``` *** **`IdFactorySet`** **Event** **Description**: Emitted when the Identity Factory is set. ```solidity event IdFactorySet(address _idFactory); ``` *** **`ImplementationAuthoritySet`** **Event** **Description**: Emitted when the implementation authority of the factory contract is set. ```solidity event ImplementationAuthoritySet(address _implementationAuthority); ``` *** **`TREXSuiteDeployed`** **Event** **Description**: Emitted by the factory when a full suite of T-REX contracts is deployed. ```solidity event TREXSuiteDeployed(address indexed _token, address _ir, address _irs, address _tir, address _ctr, address _mc, string indexed _salt); ``` *** **`setImplementationAuthority`** **Source**: `ITREXFactory` **Description**: Sets the implementation authority contract address. This contract contains the addresses of all implementation contracts. The proxies created by the factory will use the different implementations available in the implementation authority contract. Only callable by the owner of the T-REX Factory contract. Emits an `ImplementationAuthoritySet` event. ```solidity function setImplementationAuthority(address _implementationAuthority) external; ``` *** **`setIdFactory`** **Source**: `ITREXFactory` **Description**: Sets the identity factory contract address. The identity factory contract is used by the T-REX Factory to deploy the ONCHAINID of the token in case the ONCHAINID is not specified. Only callable by the owner of the T-REX Factory contract. Emits an `IdFactorySet` event. ```solidity function setIdFactory(address _idFactory) external; ``` *** **`deployTREXSuite`** **Source**: `ITREXFactory` **Description**: Deploys a new T-REX token and sets all the parameters as required by the issuer paperwork. This function will deploy and set the Token, Identity Registry (IR), Identity Registry Storage (IRS), Claim Topics Registry (CTR), Trusted Issuers Registry (TIR), and Compliance contracts. All contracts are deployed using the CREATE2 opcode, ensuring that they are deployed at a predetermined address. Only callable by the owner of the T-REX Factory contract. Emits a `TREXSuiteDeployed` event. ```solidity function deployTREXSuite( string memory _salt, TokenDetails calldata _tokenDetails, ClaimDetails calldata _claimDetails ) external; ``` *** **`recoverContractOwnership`** **Source**: `ITREXFactory` **Description**: Recovers the ownership of contracts owned by the factory. Typically used for IRS contracts owned by the factory. Only callable by the owner of the T-REX Factory contract. ```solidity function recoverContractOwnership(address _contract, address _newOwner) external; ``` *** **`getImplementationAuthority`** **Source**: `ITREXFactory` **Description**: Returns the address of the implementation authority contract. ```solidity function getImplementationAuthority() external view returns(address); ``` *** **`getIdFactory`** **Source**: `ITREXFactory` **Description**: Returns the address of the identity factory contract. ```solidity function getIdFactory() external view returns(address); ``` *** **`getToken`** **Source**: `ITREXFactory` **Description**: Returns the address of the token corresponding to a given salt string. ```solidity function getToken(string calldata _salt) external view returns(address); ``` # Tokens Gateway The T-REX Gateway is an essential smart contract in the T-REX protocol, designed to provide flexible and secure access to the T-REX Factory. By acting as an intermediary, the T-REX Gateway manages who can deploy tokens, under what conditions, and with what specific rules. This architecture not only enhances security but also allows for dynamic access management without modifying the factory itself. ## Benefits of the T-REX Gateway 1. **Flexibility and Control**: * By managing access and deployment rules, the Gateway provides a flexible and secure way to control token deployment without modifying the T-REX Factory. 2. **Enhanced Security**: * The controlled generation of deployment salts and role-based access control prevent unauthorized deployments and mitigate cross-chain vulnerabilities. 3. **Interoperability**: * Deployed at the same address across multiple chains, the Gateway ensures consistent and seamless token deployment, enhancing interoperability within the T-REX ecosystem. ## Key Features of the T-REX Gateway 1. **Access Management**: * The T-REX Gateway acts as the owner of the T-REX Factory, granting it the ability to control token deployment. It defines multiple roles with different permissions, ensuring that only authorized entities can deploy tokens. 2. **Role-Based Access Control**: * The T-REX Gateway defines several roles: * **Owner Role**: Super admin with full control, including transferring ownership of the Factory to a new gateway. * **Agent Role**: Agents can add deployers, deploy tokens, and apply fee discounts. They can operate even when public deployments are disabled. * **Deployer Role**: Deployers can deploy tokens for token owners, subject to applicable fees and discounts. * **Public Address**: General users who can deploy tokens when public deployments are enabled. They must pay the required fees and can only deploy for themselves. 3. **Fee Management**: * The Gateway can define fees for deploying tokens, which must be paid in a specified utility token or stablecoin. It also allows for discounts to be applied by agents, making the deployment free if necessary. 4. **Enhanced Security**: * To prevent cross-chain vulnerabilities, the Gateway controls the salt used in deployments. By generating the salt from a hash of the token owner address and the token name, it ensures that tokens cannot be duplicated across different chains. 5. **Cross-Chain Consistency**: * Like the T-REX Factory, the Gateway is deployed at the same address on every EVM-compatible chain where the protocol is implemented. This consistency ensures seamless integration and interoperability across multiple networks. ## How the T-REX Gateway Works 1. **Managing Deployment Access**: * The Gateway sets the factory contract address, controls public deployment status, and manages deployment fees. It adds and removes deployers and agents, ensuring that only authorized addresses can deploy tokens. 2. **Defining Deployment Rules**: * The Gateway allows the owner to set detailed rules for deployment, including enabling or disabling public deployments, setting deployment fees, and applying discounts. This flexibility ensures that deployment conditions can be tailored to meet specific requirements. 3. **Deploying Tokens**: * When a deployment request is made, the Gateway checks the caller's permissions, calculates any applicable fees, and processes the deployment through the T-REX Factory. The salt used for deployment is derived to ensure unique and secure token addresses. ## Interaction with Other Components * **T-REX Factory**: The Gateway acts as the owner of the Factory, controlling who can deploy tokens and under what conditions. * **Utility Token**: The Gateway manages the payment of deployment fees in a specified utility token or stablecoin, ensuring a standardized process for all deployments. # T-REX Gateway Interface The T-REX Gateway interface defines the set of functions and events used to manage and control the deployment of T-REX tokens. This page provides a detailed breakdown of each function and event, explaining its purpose, source, and functionality. Additionally, the `TokenDetails`, `ClaimDetails`, and `Fee` structs are defined to ensure a comprehensive understanding of how to interact with the T-REX Gateway contract. **Structs** **`TokenDetails`** **Description**: Holds all necessary details for deploying a new T-REX token and its associated contracts. ```solidity struct TokenDetails { address owner; // Address of the owner of all contracts string name; // Name of the token string symbol; // Symbol / ticker of the token uint8 decimals; // Decimals of the token (can be between 0 and 18) address irs; // Identity registry storage address address ONCHAINID; // ONCHAINID of the token address[] irAgents; // List of agents of the identity registry address[] tokenAgents; // List of agents of the token address[] complianceModules; // Modules to bind to the compliance bytes[] complianceSettings; // Settings calls for compliance modules } ``` **`ClaimDetails`** **Description**: Holds all necessary details regarding the claims and claim issuers. ```solidity struct ClaimDetails { uint256[] claimTopics; // Claim topics required address[] issuers; // Trusted issuers addresses uint256[][] issuerClaims; // Claims that issuers are allowed to emit } ``` **`Fee`** **Description**: Holds the details for deployment fees. ```solidity struct Fee { uint256 fee; // Amount of fee tokens to pay for 1 deployment address feeToken; // Address of the token used to pay fees address feeCollector; // Address collecting fees } ``` **`FactorySet`** **Event** **Description**: Emitted when the factory variable is set or modified. ```solidity event FactorySet(address indexed factory); ``` *** **`PublicDeploymentStatusSet`** **Event** **Description**: Emitted when the public deployment status is set or modified. ```solidity event PublicDeploymentStatusSet(bool indexed publicDeploymentStatus); ``` *** **`DeploymentFeeSet`** **Event** **Description**: Emitted when the deployment fees details are set or modified. ```solidity event DeploymentFeeSet(uint256 indexed fee, address indexed feeToken, address indexed feeCollector); ``` *** **`DeploymentFeeEnabled`** **Event** **Description**: Emitted when the deployment fees are enabled or disabled. ```solidity event DeploymentFeeEnabled(bool indexed isEnabled); ``` *** **`DeployerAdded`** **Event** **Description**: Emitted when an address is flagged as a deployer. ```solidity event DeployerAdded(address indexed deployer); ``` *** **`DeployerRemoved`** **Event** **Description**: Emitted when a deployer address loses deployment privileges. ```solidity event DeployerRemoved(address indexed deployer); ``` *** **`FeeDiscountApplied`** **Event** **Description**: Emitted when a discount on deployment fees is granted for an address. ```solidity event FeeDiscountApplied(address indexed deployer, uint16 discount); ``` *** **`GatewaySuiteDeploymentProcessed`** **Event** **Description**: Emitted whenever a TREX token has been deployed by the TREX factory through the use of the Gateway. ```solidity event GatewaySuiteDeploymentProcessed(address indexed requester, address intendedOwner, uint256 feeApplied); ``` *** **`setFactory`** **Description**: Sets the factory contract address used for deploying TREX smart contracts. Only the owner can call this method. Emits a `FactorySet` event upon successful execution. ```solidity function setFactory(address factory) external; ``` *** **`setPublicDeploymentStatus`** **Description**: Sets the status for public deployments of TREX contracts. Enables or disables public deployments. Only the owner can call this method. Emits a `PublicDeploymentStatusSet` event upon successful execution. ```solidity function setPublicDeploymentStatus(bool _isEnabled) external; ``` *** **`transferFactoryOwnership`** **Description**: Transfers the ownership of the Factory contract. Only the owner can call this method. ```solidity function transferFactoryOwnership(address _newOwner) external; ``` *** **`enableDeploymentFee`** **Description**: Toggles the deployment fee status for TREX contracts. Enables or disables the deployment fees. Only the owner can call this method. Emits a `DeploymentFeeEnabled` event upon successful execution. ```solidity function enableDeploymentFee(bool _isEnabled) external; ``` *** **`setDeploymentFee`** **Description**: Sets the deployment fee details for TREX contracts. Establishes the amount, token type, and collector address for the deployment fee. Only the owner can call this method. Emits a `DeploymentFeeSet` event upon successful execution. ```solidity function setDeploymentFee(uint256 _fee, address _feeToken, address _feeCollector) external; ``` *** **`addDeployer`** **Description**: Adds an address to the list of approved deployers. Only an admin (owner or agent) can call this method. Emits a `DeployerAdded` event upon successful addition. ```solidity function addDeployer(address deployer) external; ``` *** **`batchAddDeployer`** **Description**: Adds multiple addresses to the list of approved deployers in a single transaction. Only an admin (owner or agent) can call this method. Emits a `DeployerAdded` event for each successfully added deployer. ```solidity function batchAddDeployer(address[] calldata deployers) external; ``` *** **`removeDeployer`** **Description**: Removes an address from the list of approved deployers. Only an admin (owner or agent) can call this method. Emits a `DeployerRemoved` event upon successful removal. ```solidity function removeDeployer(address deployer) external; ``` *** **`batchRemoveDeployer`** **Description**: Removes multiple addresses from the list of approved deployers in a single transaction. Only an admin (owner or agent) can call this method. Emits a `DeployerRemoved` event for each successfully removed deployer. ```solidity function batchRemoveDeployer(address[] calldata deployers) external; ``` *** **`applyFeeDiscount`** **Description**: Applies a fee discount to a specific deployer's address. Only an admin (owner or agent) can call this method. The fee discount is expressed per 10,000 (10000 = 100%, 1000 = 10%, etc.). Emits a `FeeDiscountApplied` event upon successful application. ```solidity function applyFeeDiscount(address deployer, uint16 discount) external; ``` *** **`batchApplyFeeDiscount`** **Description**: Applies fee discounts to multiple deployers in a single transaction. Only an admin (owner or agent) can call this method. Emits a `FeeDiscountApplied` event for each successfully applied discount. ```solidity function batchApplyFeeDiscount(address[] calldata deployers, uint16[] calldata discounts) external; ``` *** **`deployTREXSuite`** **Description**: Deploys a TREX suite of contracts using provided token and claim details. If public deployments are disabled, only approved deployers can execute this function. If public deployments are enabled, an external entity can deploy only on its behalf and not for other addresses unless it's an approved deployer. If deployment fees are enabled and applicable (after considering any discounts for the deployer), the fee is collected from the deployer's address. Emits a `GatewaySuiteDeploymentProcessed` event upon successful deployment. ```solidity function deployTREXSuite( ITREXFactory.TokenDetails memory _tokenDetails, ITREXFactory.ClaimDetails memory _claimDetails ) external; ``` *** **`batchDeployTREXSuite`** **Description**: Deploys multiple TREX suites of contracts in a single transaction using provided arrays of token and claim details. This batch function allows deploying up to 5 TREX suites at once. Performs the same checks as `deployTREXSuite` for each suite. Emits a `GatewaySuiteDeploymentProcessed` event for each deployed suite. ```solidity function batchDeployTREXSuite( ITREXFactory.TokenDetails[] memory _tokenDetails, ITREXFactory.ClaimDetails[] memory _claimDetails ) external; ``` *** **`getPublicDeploymentStatus`** **Description**: Retrieves the current public deployment status. ```solidity function getPublicDeploymentStatus() external view returns(bool); ``` *** **`getFactory`** **Description**: Retrieves the address of the current Factory contract. ```solidity function getFactory() external view returns(address); ``` *** **`getDeploymentFee`** **Description**: Retrieves the current deployment fee details. ```solidity function getDeploymentFee() external view returns(Fee memory); ``` *** **`isDeploymentFeeEnabled`** **Description**: Checks if the deployment fee is currently enabled. ```solidity function isDeploymentFeeEnabled() external view returns(bool); ``` *** **`isDeployer`** **Description**: Checks if the provided address is an approved deployer. ```solidity function isDeployer(address deployer) external view returns(bool); ``` *** **`calculateFee`** **Description**: Calculates the deployment fee for a given deployer after accounting for any discounts. ```solidity function calculateFee(address deployer) external view returns(uint256); ``` # Official Factories & Gateways All ERC3643 association members have access to our official contract factories and gateways deployed across all supported networks. These contracts are deployed with the same addresses on every chain, ensuring a consistent deployment environment for all members. ### Supported Networks Our production deployments are available on the following networks: * **Ethereum** * **Polygon** * **Hedera** * **Arbitrum** * **Avalanche** * **Telos EVM** * **Base** * **Kaia** *Note:* In addition, we maintain deployments on various testing networks. However, for production use only whitelisted wallets from association members are permitted to deploy contracts. ### Deployment Categories: ONCHAINID vs. T-REX We have separated our deployments into two distinct suites designed for different use cases: #### ONCHAINID ONCHAINID is our standard identity solution. It is supported by the following official contracts: * **Factory:** *IdFactory*\ **Address:** `0x23b64FBc42Ef1775F8A099965659c4c5C91e0CeC` * **Gateway:** *Gateway*\ **Address:** `0xa974c2e2fa9bbc14f4d13413e1AAcB5Fe446Cdac` **Deployment Details:**\ The ONCHAINID Gateway features a public function that allows the deployment of identities. However, note that this function can only be triggered by the ONCHAINID owner. To deploy ONCHAINIDs on behalf of end users, only whitelisted association members are permitted to perform such actions. #### T-REX T-REX is the main protocol within ERC-3643. The official T-REX Factory and Gateway enable users to deploy the complete ERC-3643 token suite in one single transaction—ensuring that everything is properly configured and that the token is ready to be used immediately. This streamlined deployment process is designed to eliminate technical hurdles for developers. By using the official factory, you benefit from deployments that are properly executed, audited, and battle tested, which significantly enhances trust and reliability within the ecosystem. It is supported by the following official contracts: * **Factory:** *TREXFactory*\ **Address:** `0x7F1fD450a5c4d91286f00F3297dCD5C12767f17f` * **Gateway:** *TREXGateway*\ **Address:** `0x5FCC3D713dbc8252095E62Af98e62D14D0Be27dB` ### Access and Deployment Authorization For now, **public deployments are not enabled** on the official factories and gateways. Deployments are restricted to wallets that have been explicitly whitelisted for association members. This measure applies to both ONCHAINID and T-REX. #### How to Request Access If you are a member of the ERC3643 association and wish to deploy via these official channels, please follow these steps: 1. **Contact Your Point of Contact:** Reach out to your association representative with your wallet address and the networks you want to get access to. 2. **Provide Required Details:** Include any necessary identification or association credentials along with your request. 3. **Await Whitelisting:** Once your details have been verified, your wallet will be added to the authorized list. After being whitelisted, you will be able to deploy contracts from the official factories through their respective gateways. # Proxies Proxies are used in the T-REX protocol to provide the mechanism for upgradeability and flexibility in the deployment and operation of smart contracts. Each contract in the T-REX suite has a specific proxy contract that is adapted to its constructor and calls the correct implementation contract from the implementation authority contract. This ensures that the T-REX protocol can be upgraded and maintained without redeploying all the smart contracts, thus preserving their state and addresses. ## How Proxies Work Proxies in the T-REX protocol follow the proxy pattern, where the proxy contract delegates calls to an implementation contract. The implementation contract contains the actual logic, while the proxy holds the state and delegates calls to the implementation. 1. **Initialization**: * When a proxy is deployed, it is initialized with the address of the implementation authority contract. This address is stored in a predefined storage slot using the `keccak256` hash of a specific string to ensure uniqueness. 2. **Delegate Calls**: * The proxy contract uses the `delegatecall` opcode to delegate function calls to the implementation contract. This opcode runs the code of the implementation contract in the context of the proxy contract, meaning that the proxy's state is used while executing the logic of the implementation contract. 3. **Fallback Function**: * The proxy contains a fallback function that delegates any calls that do not match any existing function to the implementation contract. This allows the proxy to handle a wide range of function calls dynamically. 4. **Upgradeability**: * The implementation authority contract can be updated, allowing the proxy to point to a new implementation contract. This upgradeability is managed through the `setImplementationAuthority` function, which ensures that the new implementation authority is valid and contains all necessary implementation addresses. ## Example Proxy Contract Below is an example of a proxy contract for the Claim Topics Registry, demonstrating the initialization and fallback mechanisms: ```solidity contract ClaimTopicsRegistryProxy is AbstractProxy { constructor(address implementationAuthority) { require(implementationAuthority != address(0), "invalid argument - zero address"); _storeImplementationAuthority(implementationAuthority); emit ImplementationAuthoritySet(implementationAuthority); address logic = (ITREXImplementationAuthority(getImplementationAuthority())).getCTRImplementation(); (bool success, ) = logic.delegatecall(abi.encodeWithSignature("init()")); require(success, "Initialization failed."); } fallback() external payable { address logic = (ITREXImplementationAuthority(getImplementationAuthority())).getCTRImplementation(); assembly { calldatacopy(0x0, 0x0, calldatasize()) let success := delegatecall(sub(gas(), 10000), logic, 0x0, calldatasize(), 0, 0) let retSz := returndatasize() returndatacopy(0, 0, retSz) switch success case 0 { revert(0, retSz) } default { return(0, retSz) } } } } ``` ## Abstract Proxy Contract All proxies in the T-REX protocol implement the `AbstractProxy` contract, which provides the foundational mechanisms for handling the implementation authority and delegating calls. Below is the `AbstractProxy` contract: ```solidity abstract contract AbstractProxy is IProxy, Initializable { function setImplementationAuthority(address _newImplementationAuthority) external override { require(msg.sender == getImplementationAuthority(), "only current implementationAuthority can call"); require(_newImplementationAuthority != address(0), "invalid argument - zero address"); require( (ITREXImplementationAuthority(_newImplementationAuthority)).getTokenImplementation() != address(0) && (ITREXImplementationAuthority(_newImplementationAuthority)).getCTRImplementation() != address(0) && (ITREXImplementationAuthority(_newImplementationAuthority)).getIRImplementation() != address(0) && (ITREXImplementationAuthority(_newImplementationAuthority)).getIRSImplementation() != address(0) && (ITREXImplementationAuthority(_newImplementationAuthority)).getMCImplementation() != address(0) && (ITREXImplementationAuthority(_newImplementationAuthority)).getTIRImplementation() != address(0) , "invalid Implementation Authority"); _storeImplementationAuthority(_newImplementationAuthority); emit ImplementationAuthoritySet(_newImplementationAuthority); } function getImplementationAuthority() public override view returns(address) { address implemAuth; assembly { implemAuth := sload(0x821f3e4d3d679f19eacc940c87acf846ea6eae24a63058ea750304437a62aafc) } return implemAuth; } function _storeImplementationAuthority(address implementationAuthority) internal { assembly { sstore(0x821f3e4d3d679f19eacc940c87acf846ea6eae24a63058ea750304437a62aafc, implementationAuthority) } } } ``` # T-REX Token Overview The Utility and Governance token powering the ERC-3643 T-REX ecosystem {% hint style="info" %} **IMPORTANT** **DISCLAIMER:** The T-REX utility token is currently not deployed or live. It is still in the development phase and subject to compliance authorization from the relevant regulatory bodies. This means that the token is not available for purchase, sale, or trade, and any such activities are strictly prohibited until further notice. The information provided about the T-REX utility token is for informational purposes only and should not be construed as financial, legal, or investment advice. We make no representations or warranties, express or implied, as to the accuracy or completeness of the information provided. Please be aware that the cryptocurrency market is highly volatile and investing in utility tokens involves significant risks. Before making any decisions, we strongly recommend that you conduct your own research and consult with a financial advisor. We will keep you updated on the progress of the T-REX utility token's development and compliance. Thank you for your understanding and cooperation. {% endhint %} ## Key information | **Token Type** | Utility and Governance Token | | -------------------------- | --------------------------------- | | **Token Name** | T-REX | | **Token Ticker** | TREX | | **Smart Contract Address** | Non deployed yet | | **Token Standard** | ERC-20 permissionless | | **Total Maximum Supply** | 1,000,000,000 | | **Token** **Category** | RWA, Tokenization, Infrastructure | | **Blockchains** | TBD | | **Website** | | | **Governance** | DAO | ## Presentation The primary value proposition of the T-REX utility token is to incentivise and facilitate collaboration among users of the ERC-3643 token protocol. By rewarding tokens to members and contributors, the token encourages active participation and contribution towards the development and growth of the ecosystem. This could involve sharing expertise, providing resources, or promoting the ecosystem to potential new users. In addition to serving as a collaboration incentive, the token also functions as a discount method for accessing services within the ecosystem. Members can use the token to access services at a lower price such as compatible tokenization platforms and tools, legal consultations, technical support, or other services offered by association members. As more users, platforms and service providers join the ecosystem and more assets are tokenized, the utility and demand for the token increases. This creates a network effect that drives the growth and sustainability of the ecosystem. Additionally, the token is used to ensure the governance of the interoperable ecosystem, allowing token holders to vote on key decisions related to the ecosystem and the development of the ERC-3643 token protocol. This gives token holders a direct say in the future direction of the tokenization of the economy and incentivises them to act in the best interests of the ecosystem. The T-REX utility token serves as a powerful tool for promoting collaboration, facilitating tokenization, simplifying access to services, and driving the growth and sustainability of the ecosystem. By incentivising active participation, the token creates a virtuous cycle that benefits all members of the ecosystem. ### Examples of utility | **Receiving tokens** | **Using tokens** | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |
  • ERC-3643 Association to finance developments and promotion
  • Association members for contributions
  • Compatible Services and Applications
  • Developers and ambassadors
  • Users of compatible DeFi applications
|
  • Participate in the governance of the protocol
  • Access the official ERC-3643 onchain factory to deploy tokens
  • Get discounted services with compatible providers
  • Get advanced support from core developers
|
# Token Functionality ## Governance of the DAO The T-REX DAO has no shareholders. T-REX token holders are the beneficiaries of the decentralized community and protocols. Token holders will vote on key decisions and the ecosystem's direction as needed. With the rapid evolution of the tokenization industry, we aim for consensus. The ERC3643.org non-profit association is mandated by the DAO to provide guidelines and open-source tools to the ecosystem. The association comprises large financial institutions, global law firms, recognized web3 players, several tokenization platforms, and different types of solution providers. Each member of the association is selected and must contribute to the open-source projects. ## Ecosystem Revenues The T-REX ecosystem is generating revenues. T-REX holders must stake their tokens to access the yield. * Revenues from the onchain factory of official ERC-3643 tokens * Revenues from data synchronization and AssetID enrichment * Revenues from DINO distribution network fees * Revenues from RWA Incubator rewards: RWA tokens generating yield and capital gains * Revenues from Liquidity pools ### # Tokenomics ### Initial Allocations The initial supply of T-REX tokens will be allocated as follows: * **Contributors**: 40% over a 10 years budget * **Ecosystem Rewards**: 40% * **Liquidity / Market Making / Exchanges**: 20% ### Launch #### Market Capitalization The T-REX token is launching with a market capitalization of $300 million. There is **no token sale**. Instead, funds are deposited to create initial liquidity on decentralized exchanges (DEXs) across various networks. #### Primary Networks The primary target networks for deploying the T-REX token are currently under discussion. Through partnerships with blockchain networks, the [ERC3643 Association](/erc-3643/resources-and-community/the-t-rex-dao/the-erc3643-association) provides liquidity. #### Liquidity Provision To ensure stability and trust in the ecosystem, the liquidity provided by the networks will be subject to the following conditions: * **Lock Period**: The provided liquidity will be locked in the liquidity pool (LP) for 5 years (cliff period). * **Vesting Period**: After the initial 5-year lock period, the liquidity will be accessible over a further 3-year vesting period. These measures ensure that the liquidity remains stable and that the networks are committed to the long-term success of the T-REX token. # Airdrop Allocations The T-REX token airdrop is designed to reward companies, individuals and communities who have contributed significantly to the development and adoption of the ERC-3643 standard and related projects. This page outlines the criteria and methodology for defining eligible users for the T-REX token airdrop. ### Eligible Users #### EIP Contributors All contributors to the Ethereum EIP repository will receive T-REX tokens. The distribution is tiered based on the impact of their contributions: * **General Contributors**: All contributors to the EIP repository will receive tokens. * **Instrumental Contributors**: Contributors to EIPs that have been fundamental to the crafting of ERC-3643, such as ERC-20, ERC-173, ERC-1822, and other critical ERCs, will receive a higher allocation. * **ERC-3643 Contributors**: Contributors directly involved in the creation of ERC-3643 will receive the highest allocation of tokens. #### T-REX ERC3643 and ONCHAINID Contributors Contributors to the T-REX ERC-3643 and ONCHAINID repositories will receive T-REX utility tokens proportionate to their contributions. This ensures that those who have significantly aided in the development and improvement of these projects are duly rewarded. #### ERC-3643 Projects Individuals and companies who have contributed to projects within the ERC-3643 association will be eligible for token rewards. The distribution will be proportional to the extent and impact of their contributions. #### OpenZeppelin Repository Projects Contributors to the OpenZeppelin repository projects will also be included in the airdrop. OpenZeppelin's role in providing secure and reliable smart contract libraries has been crucial, and this allocation acknowledges their contributions. #### Early Adopters of ERC-3643 Early adopters who hold ERC-3643 tokens will be rewarded for their support and belief in the standard. This category includes all current token holders of ERC-3643-compliant tokens. #### Token Holders of Partner Projects Token holders of partner projects such as Floki and TokenFi will also be eligible for the airdrop. This inclusion aims to foster a broader community engagement and collaboration across different projects within the ecosystem. # The T-REX DAO # $T-REX Token Holders # The ERC3643 Association Guidelines and evolution of the ERC-3643 T-REX Protocol ## Overview The ERC3643 ASBL is a non-profit association based in Luxembourg, created in 2023. It currently has more than 70 members: ## Purpose The ERC3643 no-profit association is a collaborative effort between industry key players to catalyze worldwide adoption of the ERC-3643 token standard for real-world assets tokenization to eliminate silos and ensure interoperability. The ERC3643 Association is a non-profit organisation regrouping industry leaders within a shared mission to advance the adoption of the ERC-3643 standard and promote the development of a **standardised, secure, and compliant tokenization framework.** The association brings together the expertise and resources of its members to foster collaboration, drive innovation, and create a more inclusive, efficient, and secure financial landscape. By supporting the widespread adoption of the ERC-3643 standard, the association aims to unlock the full potential of tokenization and pave the way for a new era of global asset management. ### Educate. Enable. Influence The ERC3643 Association is dedicated to three core objectives: * fostering market awareness * empowering developers * influencing decision-makers and lawmakers. There are three main dimensions to working groups dedicated to achieving the missions: * **Technology & Security**: Ensures the technical development and security of the ERC3643 protocol. * **Legal & Compliance**: Validates the ERC3643 compliance framework and tokenization practices. * **Ecosystem & Education**: Builds a collaborative and supportive community. ## Results in 2024 * ERC-3643 mentioned as the main standard for RWA tokenization in many [publications](https://www.erc3643.org/history-of-erc-3643) * 70+ active members: Web3, global law firms, Financial institutions, Tokenization platforms and Integrators * Code open-sourcing and official ERC status for the whole token protocol * Security audit with 10/10 security score * ERC3643 Association received [Initiative of the Year 2024 Award](https://www.erc3643.org/history-of-erc-3643) by Deloitte * ERC tracker on [Dune Analytics](https://dune.com/qualitax/erc-3643-analytics) * Dapp front-end [components](https://github.com/ERC-3643/erc3643-packages) * ERC-3643[ deep dive report](https://www.erc3643.org/knowledge-center/demystifying-erc-3643) * ERC-3643 documentation * ERC-3643 [DApp](https://github.com/ERC-3643/ERC-3643-DApp) (in progress) * DeFi solutions: lending, distribution, etc. (several members working on several projects)
{% hint style="info" %} **DISCLAIMER**: The members of the ERC-3643 non-profit association promoting the ERC-3643 token protocol are not required or forced in any way to use or accept the T-REX utility token for their activities, clients, or users. The tokenomics of the T-REX utility token are designed to incentivize members to contribute to the ecosystem and accept the T-REX utility token. However, it is important to note that the novel and complex nature of utility tokens may pose challenges for regulated financial institutions in terms of compliance and regulatory requirements. As such, these institutions may exercise caution and discretion when dealing with utility tokens, including the T-REX utility token. As such, the use of the T-REX utility token by members of the non-profit association is entirely voluntary and subject to their own discretion and compliance requirements. Members are free to choose whether or not to accept the token for their services, and their decision will not affect their membership status or involvement in the association. Furthermore, the non-profit association promoting the T-REX utility token does not provide any financial, legal, or investment advice regarding the use of the token. Members are encouraged to seek professional advice before making any decisions related to the use or acceptance of the token. We believe that the T-REX utility token has the potential to bring significant benefits to the ecosystem and its participants. However, we also recognize the need for caution and compliance with relevant regulations and laws. Thank you for your understanding and support. {% endhint %} # The Ecosystem Manager # The Builders # Get Involved Official links ## Resources T-REX Network (DAO): [https://t-rex.network/ ]() ERC3643 Association: Members: Documentation ERC-3643: [docs.erc3643.org ](https://docs.erc3643.org/erc-3643) Documentation T-REX Network: Ethereum EIP: Github: ## Join the discussions Linkedin ERC3643 Association: Discord: Telegram: X ERC3643: X T-REX: ## Reward programs All reward programs: [https://t-rex.network/rewards/ ]()