TokenF vs ERC-3643 (T-REX)

Diamond Pattern Architecture

Let's start our comparison with the architecture. The T-REX standard accommodates a large number of contracts that need to be properly linked together. Upgradable functionality is present, but it is almost impossible to extend the token contract or any other protocol contract. The connection between all contracts is quite tight, so it is difficult to implement custom logic, which is needed quite often. As a result, we have a solution that may be suitable for a narrow list of cases, provided everything is properly configured.

The TokenF framework architecturally has one central token contract and a set of custom modules for a specific business task. TokenF contract itself is made according to the Diamond pattern, so it allows you to easily customize the basic logic, expand it, and upgrade as needed. As a result, we have a small and flexible core that can be easily integrated with other protocol contracts and is almost infinitely extendable in terms of functionality.

Solarity Based Role Management

In large systems, a good role system is often needed to manage access to contracts. In T-REX there are only two roles: owner and agent. All agents are equal to each other, while the owner can do absolutely anything. This approach is not very flexible, because all custom functions for a token have the onlyAgent modifier, which takes away the ability to configure accesses for each function of the same ERC-20 token. For small and simple projects, it may be a good solution, but for medium and large protocols it becomes a problem.

TokenF has a more flexible role system, based on the AccessControl contract from the Solarity library (which is also used in our TokenE solution). The idea behind AccessControl itself is quite simple - we have roles to which we can add or remove addresses. Accordingly, in the TokenF contract, we can manage existing roles and flexibly customize them. For all functions of system contracts where at least some access is required, roles can be configured independently of each other. For example, for mint and burn functions there can be different roles.

KYC Providers Integration

Here we come to the key parts of our tokenization protocol - these are the rules for the various regulations. Let's start with KYC. In the T-REX protocol, contracts are hardwired into the OnChain ID protocol only. Everyone using T-REX must measure up to the fact that they will only use OnChain ID for KYC functionality. This part of T-REX protocol is completely inflexible and does not allow the use of other KYC and identity protocols.

TokenF has a separate type of compliance for KYC. The essence of this approach is that we can implement the necessary KYC modules to meet the specific requirements of the project. These modules can integrate with absolutely any KYC provider, which gives full freedom for customization. You can easily integrate TokenF with the open-source zk-powered Rarimo identity solution based on biometric passports. Also, TokenF allows you to integrate with several providers at once. Accordingly, there is also a logic of claim topics, so you can flexibly configure different ways of KYC checking for different contexts if such logic is necessary.

Claim Topics and Context Execution Flow

The second key part of regulation is setting up rules for interacting with the tokens. That is forwarding, creating, restoring, freezing, etc. ERC-3643 (T-REX) has different hooks in which modules will check conditions, but there is a nuance, modules do not know anything about the context of the transaction, so it is impossible to set different checks for transfer and, for example, for mint functions. You will check the same thing everywhere, which is very inconvenient and sometimes is a critical problem.

As it was mentioned earlier, TokenF has a system of context and claim topics, which can be set by custom keys. Accordingly, developers, depending on the business requirements of the project, will be able to determine how specific rules should be implemented. Also, the handler system allows to avoid huge if-else structures in module functions, which makes the code clearer and cheaper for execution.