One of the key issues that need to be resolved before RWAs can be safely tokenized is the legal compliance of their transfer and transactions. In other words, they need to be regulated.

The ERC-3643 standard is a tokenization standard for RWAs that simplifies their transfer to meet regulatory requirements. It is designed to make it possible to tokenize RWAs at the institutional level.

For better clarity, we will compare the ERC-3643 standard to the ERC-20 standard because the ERC-3643 standard is actually another version of the ERC-20.

ERC-3643 is another version of ERC-20

ERC-20 is a fungible token standard that requires implementation of all the functions that the standard is designed to implement, including token transfer functions and functions that return address balances.

In the case of ERC-20, the standard does not require token transfer restrictions. This means that in most cases, anyone can own these tokens, even if it is not known exactly who owns them, so transfer and transact with them without restrictions. These tokens are called permissionless. Examples of such tokens are USDT, DAI, etc.

In the case of the implementation of the ERC-3643 standard, it implies being permissioned. This means that tokens can only be transferred if all conditions for the transfer are met (e.g. participants are verified and other requirements are met), otherwise, it is not possible.

The ERC-3643 standard is regulated and is called Token For Regulated EXchange , abbreviated as T-REX , i.e. Tyrannosaurus.

The implementation of the ERC-3643 standard also requires a function that is responsible for the recovery of tokens, for example, in case of loss of access to the account. The ERC-20 standard does not require the implementation of such a function, which means that in case of loss of keys to the account access to tokens can be lost without the possibility of recovery.

In the case of ERC-3643, if access to the account is lost, the tokens can be restored to another account due to the required implementation of the recovery function.

The ERC-3643 standard means that accounts that will be able to transact in tokens must be identified, as required by the laws of most countries. With the ERC-20 standard, we have no such requirement, which means that all accounts making transactions remain impersonal due to the lack of identification and such transactions cannot be verified. In the case of ERC-3643, by requiring all accounts to be identified, the blockchain can now become a verifiable ledger (by knowing who is behind each account), and storing data on it will only increase security compared to the current infrastructure.

The ERC-3643 standard is designed for Ethereum networks and allows for the creation of programmable agreements for issuing, managing, and trading RWA tokens. All the data required for this is stored directly in the blockchain, such as the addresses of the owners, conditions for token transfer, account status, etc. Because smart contracts calculate and process data, it is all done automatically, with no need for manual verification.

For example, let's compare a transaction using an ERC-20 token and a transaction with ERC-3643.

In the case of ERC-20, one party calls a function in the token smart contract and there is a transfer of the token to the other party that was specified in that transaction.

Differences of the ERC-3643 standard from ERC-20

In the case of ERC-3643, a party makes a token transfer function call to a smart contract, but in this case, there is no immediate token transfer. First, there is a check of all the conditions that are set for such a token transfer, usually on another contract, which processes all the necessary data and returns a status that reflects whether the token transfer can be completed or not. If this status indicates that all the necessary conditions are met, only in this case the token transfer from one party to another is executed.

Token transfer algorithm for ERC-20 and ERC-3643

2. Essential Contracts of ERC-3643 Implementation

Now let's look at the essential contracts of the ERC-3643 implementation and what each is responsible for:
Identity: Each user is assigned a contract that is responsible for processing their identity and storing all claims associated with it. Each user is represented by an Identity contract.

Claim Topics Registry: This is where the various claim topics that can be added or deleted to the contract Identity are managed. The owner is responsible for managing these registries per his claims.

Trusted Issuers Registry: Represents a registry of contract addresses that are trusted issuers of claims. This is to ensure that claims are only issued by these trusted issuers.

Compliance: Performs a check on Identities against the rule module it contains. This check is needed to ensure that only participants who meet the specified requirements can make deals or token transfers.

Identity Registry: Keeps track of all Identities in the system and stores them all in one place. This provides convenient verification and validation of user identity.

3. How does token transfer control work in ERC-3643?

To better illustrate the key point of how token transfers between addresses are controlled to meet the requirements, we will look at some of the key features of the Token For Regulated EXchanges (T-REX) protocol token contract, which is an implementation of the ERC-3643 standard. It is ERC-20 compliant and therefore contains all the functionalities required by the ERC-20 standard.

Before we move on to the token transfer function itself, let's look at the other aspects that we need to understand before we do so.

There is a special role - Agent, this role is given to an authorized account that performs operational activities. An account with the agent role can freeze addresses, freeze tokens, pause token transfers, issue, burn tokens, etc. We will look at a few of these functions that directly relate to the token transfer function itself.

setAddressFrozen - This function in the token contract is responsible for setting the status for the address (of the user) - whether it is frozen or not. It can be called only by an account with the Agent role. So, if passed true - it will mean that this address will be considered frozen, and if false - it will be considered unfrozen.

function setAddressFrozen(address_userAddress, bool_freeze) public override onlyAgent {
_frozen[_userAddress] = _freeze;
emit AddressFrozen(_userAddress, _freeze, msg-sender);
}

ERC-3643 setAddressFrozen() function implementation example

freezePartialTokens / unfreezePartialTokens - these two functions are responsible for freezing or unfreezing a specific amount of tokens at a specific address ( of the user ). After that the frozen amount of tokens can no longer be transferred, or the number of frozen tokens will be reduced through unfreezing. Available for invocation only for accounts with the Agent role.

freezePartialTokens - accepts the user address and the number of tokens to be frozen. Then it is checked that the total amount of frozen tokens after freezing will not exceed the current token balance of this address. If this condition is reached, the amount of frozen tokens at this address is increased by the amount.

function freezePartialTokens(address
_userAddress, unit256 _amount public override onlyAgent {
uint256 balance = balanceof( _userAddress);
require( balance ≥ _frozenTokens [_userAddress] + _amount, "Amount exceeds available balance");
_frozenTokens[_userAddress] = _frozenTokens[_userAddress] + (_amount);
emit TokensFrozen(_userAddress, _amount);
}

function unfreezePartialTokens(address_userAddress, uint256 _amount) public override onlyAgent ( require(_frozenTokens[_userAddress] ≥ _amount, "Amount should be less than or equal to frozen tokens"); 
_frozenTokens[_userAddress] =_frozenTokens[_userAddress] - (amount);
emit TokensUnfrozen(_userAddress, _amount);
}

ERC-3643 freezePartialTokens() and infreezePartialTokens() functions implementation example

unfreezePartialTokens - here we first check that the amount of unfreeze tokens does not exceed the amount of frozen tokens at this address. If the condition is met, the amount of frozen tokens is reduced by the amount.

Pause/unpause - responsible for the opportunity to pause or unpause transfers. This functionality is available only for accounts with the Agent role. When calling these functions, the value for state variable _tokenPaused is set, if true - transfers are paused, if false - transfers are not paused.

function pause() external override onlyAgent whenNotPaused {
_tokenPaused = true;
emit Paused(msg.sender);
}

function unpause( ) external override onlyAgent whenPaused {
_tokenPaused = false;
emit Unpaused(msg.sender);
}

ERC-3643 pause() and unpause() functions implementation example

Transfer - this function is responsible for transferring tokens from one address to another. It accepts only two arguments: to - the address of the recipient, amount - the amount to be transferred. This function has no restrictions as to who can call it. But its call is available only if transfers are not paused by the Agent role, for this the modifier whenNotPaused is responsible.

First, it is checked that the recipient address and the sender address (sender is the transaction sender) are not frozen. As we have already seen, setAddressFrozen is responsible for freezing accounts, and only an account with the Agent role can do it. If at least one of the transfer participants has a frozen account, the transaction will revert with an error.

Then it is checked that the current available balance of the sender, which is calculated as the difference between the current balance and the amount of frozen tokens, does not exceed the amount.

The next check consists of two conditions at once:

The isVerified function is called in the IndetityRegistry contract, which is the registry for Identity. isVerified checks that the address of the Identity contract (for the recipient account) is listed in the IdentityRegistry, checks the validity of the claimTopics that are listed in Identity and returns state based on these checks. Verification of claimTopics includes requesting them from the ClaimTopicsRegistry contract and checking that these ClaimTopics are issued by TrustedIssuers the registry of which is stored in the ClaimTopicsRegistry.
The next condition to be done is to verify that the sender, recipient and the amount of tokens transferred are in compliance with the offer rules, which are placed in the Compliance contract and can be added as modules or created completely custom from scratch. It can define conditions such as the maximum number of investors per country, the maximum number of tokens per investor and any other necessary conditions for a particular asset. This verification is done by calling the canTransfer function in the Compliance contract.

If all these conditions are met, then the**_transfer** function is executed, which transfers the tokens, then the transferred function in the Compliance contract is called to update the state (what is executed in it depends on what conditions will be written there), and returns true. If the necessary conditions are not reached at any stage, the execution of this function will be reverted with an error.

function transfer(address _to, uint256 _amount) public override whenNotPaused returns (bool) {
require(!_frozen[_to] && !_frozen[msg.sender], "wallet is frozen");
require_amount ≤ balanceof(msg.sender) - (_ frozenTokens[msg.senderl), "Insufficient Balance");
if (_tokenIdentityRegistry.isVerified(_to) && _tokenCompLiance.canTransfer(msg.sender, _to, _amount)) {
_transfer(msg.sender, _to, _amount);
_tokenCompliance.transferred(msg.sender, _to, _amount);
return true;
revert( "Transfer not possible");
}

ERC-3634 transfer() function implementation example

Implementing regulatory rules directly into the code of smart contracts in this way can open up new opportunities by ensuring the legality and control of transactions by authorized entities. It is important to realize that most assets can only be tokenized if these conditions are met.

For example, if we take securities that are recorded by government agencies, they have regulatory requirements and they cannot tokenize them without a guarantee of compliance with those requirements. If these things are not implemented, it makes it impossible for the regulated institutional players, which account for the vast majority of capital in the world, to participate.
Because the institutional players are regulated, they cannot transact in assets that are not allowed for them. The government can allow, the government needs regulation, it's a vicious circle.

You can have different attitudes to control and regulation, but right now there are a lot of pluses in this direction, which can really give a serious impulse to the growth of this direction at the expense of mass adoption and large players.

Ready to Discuss Your Project?

Leave a Request. We'll explore your project, understand your needs, and figure out the best path forward.

By clicking the "Leave a Request" button, I agree to transfer my personal data contained in this form to Crypton Studio LLC for purposes named in Privacy Policy.

4. Use Cases

The ERC-3643 standard has been specifically designed for the regulated tokenization of Real World Assets. This solves many issues regarding assets that need to be regulated and therefore the ERC-3643 standard makes the following use cases possible:

Supply Chains: Tokenization of real commodities in the supply chain using ERC-3643 can increase transparency and efficiency of financing, especially by exactly following the terms and conditions that can be flexibly set in smart contracts, which also strongly reduces counterparty risk.

Private companies and startups: ERC-3643 can be used for the tokenization of private companies or startups, this increases accessibility to a wider range of investors and thus significantly increases liquidity in this area.

Real estate: Tokenization of real estate via the ERC-3643 standard not only increases liquidity for this asset class (especially expensive ones), but also makes transactions with them much more accessible and secure. This is due to the fact that we can set customized conditions for transactions, which will be verified directly in smart contracts.

ERC-3643 Use Cases

Securities: ERC-3643 allows tokenization of any securities, including those backed by commodities (gold, oil etc.). This significantly increases their liquidity, simplifies tracking and control of compliance with the necessary requirements for transactions (due to the fact that we can set any requirements and restrictions). Also in the case of tokenized securities, deals are much faster and the data is immediately updated in the blockchain.

Diamonds and other treasures: By tokenizing diamonds and other treasures through the ERC-3643 standard, we are able to effectively control them and increase liquidity. Liquidity is increased by representing them on the open blockchain as tokens. And by splitting them into smaller pieces, it is possible to lower the entry threshold and increase liquidity even more. The standard is ERC-20 compatible. This means that these tokens can be traded on decentralized exchanges, which adds to diamonds and other treasures the liquidity of funds that are placed on the blockchain. Transactions will be easier to control because they will strictly follow the rules that will be set, and using the blockchain as a ledger makes it easier to track.

Conclusion

ERC-3643 implements the needs of the majority of participants in traditional markets and makes it possible for them to move to the Web3 direction through tokenization. For them, it opens up opportunities to increase efficiency and improve processes. For the Web3 direction itself, it can mean a great inflow of funds and acceleration of development rates, which opens up a great expansion potential.

Tokenization allows optimization and increases the efficiency of owning and circulating RWAs. These benefits include increased security of transactions, 24/7 availability, lower transaction costs, and increased liquidity. These are definitely benefits that are absolutely worth using, but before this can happen, a number of regulatory issues need to be resolved. To solve them, a standard for EVM networks (Ethereum) has been created, which allows for such regulation and makes mass adoption of tokenization of real word assets a step closer.

Disclaimer: The information presented in this article is the subjective opinion of the author and should not be considered a recommendation or a call to action.
The information presented in this article may be incomplete or not fully accurate and readers are advised to conduct their own research to confirm and supplement the information presented.

Readers should understand that making any decisions based on this information involves risks, including loss of capital or other negative consequences. Readers are advised to seek professional advice and evaluate their own circumstances before making any decisions. The author shall not be liable for any loss or damage resulting from the use of information from this article.