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.

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.

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.

Examples of Compliance Modules

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

event IdentityStored(address indexed investorAddress, IIdentity indexed identity);

IdentityUnstored

Event

Description: Emitted when an identity is removed from the storage contract.

event IdentityUnstored(address indexed investorAddress, IIdentity indexed identity);

IdentityModified

Event

Description: Emitted when an identity has been updated in the storage contract.

event IdentityModified(IIdentity indexed oldIdentity, IIdentity indexed newIdentity);

CountryModified

Event

Description: Emitted when an identity's country has been updated in the storage contract.

event CountryModified(address indexed investorAddress, uint16 indexed country);

IdentityRegistryBound

Event

Description: Emitted when an Identity Registry is bound to the storage contract.

event IdentityRegistryBound(address indexed identityRegistry);

IdentityRegistryUnbound

Event

Description: Emitted when an Identity Registry is unbound from the storage contract.

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.

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.

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.

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.

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.

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.

function unbindIdentityRegistry(address _identityRegistry) external;

linkedIdentityRegistries

Source: IIdentityRegistryStorage

Description: Returns the identity registries linked to the storage contract.

function linkedIdentityRegistries() external view returns (address[] memory);

storedIdentity

Source: IIdentityRegistryStorage

Description: Returns the ONCHAINID of an investor based on their wallet address.

function storedIdentity(address _userAddress) external view returns (IIdentity);

storedInvestorCountry

Source: IIdentityRegistryStorage

Description: Returns the country code of an investor based on their wallet address.

function storedInvestorCountry(address _userAddress) external view returns (uint16);

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.

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.

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.

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.

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.

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.

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.

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, 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.

The need for a common tokenization framework

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.

ClaimTopicRemoved

Event

Description: Emitted when a claim topic has been removed from the Claim Topics Registry.

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.

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.

getClaimTopics

Source: IClaimTopicsRegistry

Description: Returns the list of trusted claim topics for the token.

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.

TrustedIssuerRemoved

Event

Description: Emitted when a trusted issuer is removed from the registry.

ClaimTopicsUpdated

Event

Description: Emitted when the set of claim topics is changed for a given trusted issuer.

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.

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.

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.

getTrustedIssuers

Source: ITrustedIssuersRegistry

Description: Returns an array of all claim issuers registered in the Trusted Issuers Registry.

getTrustedIssuersForClaimTopic

Source: ITrustedIssuersRegistry

Description: Returns an array of all claim issuer addresses that are allowed to issue a given claim topic.

isTrustedIssuer

Source: ITrustedIssuersRegistry

Description: Checks if a given ClaimIssuer contract is trusted.

getTrustedIssuerClaimTopics

Source: ITrustedIssuersRegistry

Description: Returns the set of claim topics that a given trusted issuer is allowed to emit.

hasClaimTopic

Source: ITrustedIssuersRegistry

Description: Checks if a given trusted issuer is allowed to emit a certain claim topic.

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.

IdentityRegistryAdded

Event

Description: Emitted when the Identity Registry has been set for the token.

ComplianceAdded

Event

Description: Emitted when the Compliance contract has been set for the token.

RecoverySuccess

Event

Description: Emitted when an investor successfully recovers their tokens from a lost wallet to a new wallet.

AddressFrozen

Event

Description: Emitted when the wallet of an investor is frozen or unfrozen.

TokensFrozen

Event

Description: Emitted when a certain amount of tokens is frozen on a wallet.

TokensUnfrozen

Event

Description: Emitted when a certain amount of tokens is unfrozen on a wallet.

Paused

Event

Description: Emitted when the token contract is paused.

Unpaused

Event

Description: Emitted when the token contract is unpaused.

setName

Source: IToken

Description: Sets the token name. Only the owner of the token contract can call this function.

setSymbol

Source: IToken

Description: Sets the token symbol. Only the owner of the token contract can call this function.

setOnchainID

Source: IToken

Description: Sets the onchain ID of the token. Only the owner of the token contract can call this function.

pause

Source: IToken

Description: Pauses the token contract, preventing token transfers. Only an agent of the token can call this function.

unpause

Source: IToken

Description: Unpauses the token contract, allowing token transfers. Only an agent of the token can call this function.

setAddressFrozen

Source: IToken

Description: Sets the frozen status of a specific address. Only an agent of the token can call this function.

freezePartialTokens

Source: IToken

Description: Freezes a specific amount of tokens on a given address. Only an agent of the token can call this function.

unfreezePartialTokens

Source: IToken

Description: Unfreezes a specific amount of tokens on a given address. Only an agent of the token can call this function.

setIdentityRegistry

Source: IToken

Description: Sets the Identity Registry for the token. Only the owner of the token contract can call this function.

setCompliance

Source: IToken

Description: Sets the Compliance contract for the token. Only the owner of the token contract can call this function.

forcedTransfer

Source: IToken

Description: Forces a transfer of tokens between two whitelisted addresses. Only an agent of the token can call this function.

mint

Source: IToken

Description: Mints new tokens to a verified address. Only an agent of the token can call this function.

burn

Source: IToken

Description: Burns tokens from a specified address. Only an agent of the token can call this function.

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.

batchTransfer

Source: IToken

Description: Transfers tokens in batch to multiple addresses.

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.

batchMint

Source: IToken

Description: Mints tokens in batch to multiple addresses. Only an agent of the token can call this function.

batchBurn

Source: IToken

Description: Burns tokens in batch from multiple addresses. Only an agent of the token can call this function.

batchSetAddressFrozen

Source: IToken

Description: Sets the frozen status of multiple addresses in batch. Only an agent of the token can call this function.

batchFreezePartialTokens

Source: IToken

Description: Freezes tokens partially in batch for multiple addresses. Only an agent of the token can call this function.

batchUnfreezePartialTokens

Source: IToken

Description: Unfreezes tokens partially in batch for multiple addresses. Only an agent of the token can call this function.

ERC20 Functions

Transfer

Event

Description: Emitted when value tokens are moved from one account (from) to another (to).

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.

totalSupply

Source: IERC20

Description: Returns the total supply of tokens in existence.

balanceOf

Source: IERC20

Description:

Returns the amount of tokens owned by a specific account.

transfer

Source: IERC20

Description: Moves amount tokens from the caller's account to a specified address.

allowance

Source: IERC20

Description: Returns the remaining number of tokens that spender is allowed to spend on behalf of owner through transferFrom.

approve

Source: IERC20

Description: Sets amount as the allowance of spender over the caller's tokens.

transferFrom

Source: IERC20

Description: Moves amount tokens from from to to using the allowance mechanism. amount is then deducted from the caller's allowance.

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.

ClaimDetails

Description: This struct holds all the necessary details regarding the claims and claim issuers.

Deployed

Event

Description: Emitted whenever a single contract is deployed by the factory.

IdFactorySet

Event

Description: Emitted when the Identity Factory is set.

ImplementationAuthoritySet

Event

Description: Emitted when the implementation authority of the factory contract is set.

TREXSuiteDeployed

Event

Description: Emitted by the factory when a full suite of T-REX contracts is deployed.

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.

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.

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.

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.

getImplementationAuthority

Source: ITREXFactory

Description: Returns the address of the implementation authority contract.

getIdFactory

Source: ITREXFactory

Description: Returns the address of the identity factory contract.

getToken

Source: ITREXFactory

Description: Returns the address of the token corresponding to a given salt string.

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.

IdentityStorageSet

Event

Description: Emitted when the Identity Registry Storage has been set for the Identity Registry.

TrustedIssuersRegistrySet

Event

Description: Emitted when the Trusted Issuers Registry has been set for the Identity Registry.

IdentityRegistered

Event

Description: Emitted when an identity is registered in the Identity Registry.

IdentityRemoved

Event

Description: Emitted when an identity is removed from the Identity Registry.

IdentityUpdated

Event

Description: Emitted when an identity has been updated in the Identity Registry.

CountryUpdated

Event

Description: Emitted when an investor's country information is updated in the Identity Registry.

registerIdentity

Source: IIdentityRegistry

Description: Registers an identity contract corresponding to a user address. Only callable by an agent of the contract.

deleteIdentity

Source: IIdentityRegistry

Description: Removes a user from the Identity Registry. Only callable by an agent of the contract.

setIdentityRegistryStorage

Source: IIdentityRegistry

Description: Replaces the current Identity Registry Storage contract with a new one. Only callable by the owner of the contract.

setClaimTopicsRegistry

Source: IIdentityRegistry

Description: Replaces the current Claim Topics Registry contract with a new one. Only callable by the owner of the contract.

setTrustedIssuersRegistry

Source: IIdentityRegistry

Description: Replaces the current Trusted Issuers Registry contract with a new one. Only callable by the owner of the contract.

updateCountry

Source: IIdentityRegistry

Description: Updates the country corresponding to a user address. Only callable by an agent of the contract.

updateIdentity

Source: IIdentityRegistry

Description: Updates an identity contract corresponding to a user address. Only callable by an agent of the contract.

batchRegisterIdentity

Source: IIdentityRegistry

Description: Registers multiple identities in batch. Only callable by an agent of the contract.

contains

Source: IIdentityRegistry

Description: Checks whether a wallet address is registered in the Identity Registry.

isVerified

Source: IIdentityRegistry

Description: Checks whether an identity contract corresponding to a user address has the required claims for verification.

identity

Source: IIdentityRegistry

Description: Returns the ONCHAINID of an investor based on their wallet address.

investorCountry

Source: IIdentityRegistry

Description: Returns the country code of an investor based on their wallet address.

identityStorage

Source: IIdentityRegistry

Description: Returns the Identity Registry Storage linked to the current Identity Registry.

issuersRegistry

Source: IIdentityRegistry

Description: Returns the Trusted Issuers Registry linked to the current Identity Registry.

topicsRegistry

Source: IIdentityRegistry

Description: Returns the Claim Topics Registry linked to the current Identity Registry.

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:

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:

Overview

The ERC3643 ASBL is a non-profit association based in Luxembourg, created in 2023. It currently has more than 70 members: https://www.erc3643.org/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

• 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 by Deloitte

• ERC tracker on Dune Analytics

• Dapp front-end components

• ERC-3643 deep dive report

• ERC-3643 documentation

• ERC-3643 DApp (in progress)

• DeFi solutions: lending, distribution, etc. (several members working on several projects)

Resources

ERC3643 Association: https://www.erc3643.org/

Members: https://www.erc3643.org/members

T-REX Ecosystem:

Documentation: docs.erc3643.org

Ethereum EIP: https://eips.ethereum.org/EIPS/eip-3643

Github: https://github.com/ERC-3643

Join the discussions

Linkedin ERC3643 Association: https://www.linkedin.com/company/erc3643

Telegram: https://t.me/erc3643_Portal

X: https://twitter.com/ERC3643Org

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.

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.

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.

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.

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.

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.

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.

event FactorySet(address indexed factory);

PublicDeploymentStatusSet

Event

Description: Emitted when the public deployment status is set or modified.

event PublicDeploymentStatusSet(bool indexed publicDeploymentStatus);

DeploymentFeeSet

Event

Description: Emitted when the deployment fees details are set or modified.

event DeploymentFeeSet(uint256 indexed fee, address indexed feeToken, address indexed feeCollector);

DeploymentFeeEnabled

Event

Description: Emitted when the deployment fees are enabled or disabled.

event DeploymentFeeEnabled(bool indexed isEnabled);

DeployerAdded

Event

Description: Emitted when an address is flagged as a deployer.

event DeployerAdded(address indexed deployer);

DeployerRemoved

Event

Description: Emitted when a deployer address loses deployment privileges.

event DeployerRemoved(address indexed deployer);

FeeDiscountApplied

Event

Description: Emitted when a discount on deployment fees is granted for an address.

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.

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.

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.

function setPublicDeploymentStatus(bool _isEnabled) external;

transferFactoryOwnership

Description: Transfers the ownership of the Factory contract. Only the owner can call this method.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

function batchDeployTREXSuite(
    ITREXFactory.TokenDetails[] memory _tokenDetails,
    ITREXFactory.ClaimDetails[] memory _claimDetails
) external;

getPublicDeploymentStatus

Description: Retrieves the current public deployment status.

function getPublicDeploymentStatus() external view returns(bool);

getFactory

Description:

Retrieves the address of the current Factory contract.

function getFactory() external view returns(address);

getDeploymentFee

Description: Retrieves the current deployment fee details.

function getDeploymentFee() external view returns(Fee memory);

isDeploymentFeeEnabled

Description: Checks if the deployment fee is currently enabled.

function isDeploymentFeeEnabled() external view returns(bool);