This article presents technical and advanced concepts with some abstraction of complexity; for a comprehensive exploration, readers are encouraged to consult the ERC3643 whitepaper.
When engaging in security token transactions, Investors and Agents have access to various types of transfers. In this article, we will explore the main types of transfers available for security tokens and delve into important considerations for seamless and compliant transactions.
Direct Transfer:
Direct transfers adhere to the principle of direct ownership, and are the most simple and straightforward type of transfer. They are analogous to cryptocurrency transfers, allowing Investors to send security tokens to any qualified recipients. This is not a trade as there is only one leg (asset involved), thus there is no counterparty risk as nothing is expected in return.
Simple transfers can be performed directly from the Investor wallet, outside the Tokeny platform. They can also be initiated from the Tokeny Investor Portal, in that case the Investor should provide the recipient's wallet address and upon validation by the platform that the compliance and eligibility is respected, the transfer can be executed from the wallet pop-up.
Swap Transfer (i.e. Delivery-versus-Delivery - DVD):
The Swap Transfer, available in the ERC3643 repository, is a smart contract known as a Delivery-versus-Delivery (DVD) Transfer Manager. It ensures the secure and reliable transfer of ERC3643 security tokens against another token (such as ERC-20, ERC-3643, stable coins, cryptocurrencies, security tokens, etc.) between eligible investors. This process is achieved without necessitating mutual trust between the involved parties. With a Swap Transfer, the counterparty risk is mitigated by the smart contract, ensuring that both investors receive their leg of the trade. The DVD smart contract acts as the intermediary and provides the necessary trust.
Swap Transfers are mostly used in the secondary market, for example after finding a potential counterparty through the Billboard. In that case, the legs will be exchanging ERC3643 tokens against stablecoins.
Please find below an extract from the ERC3643 whitepaper, illustrating a sequence diagram of a DVD contract, including potential fees collection and distribution.
Figure 1 : sequence diagram of the execution of a DVD contract
The steps for executing a Swap Transfer are as follows:
-
To initiate a trade, Investors A and B must first reach an off-chain agreement regarding the transaction details, with Investor A needing to know Investor B's wallet address.
-
Investor A authorizes the DVD contract for Token A, the token they will send to Investor B in exchange for Token B. The granted allowance must be at least equal to the amount of Token A involved in the DVD transfer.
-
Similarly, Investor B authorizes the DVD contract for Token B, the token they will send to Investor A in exchange for Token A. Again, the granted allowance must be at least equal to the amount of Token B involved in the DVD transfer.
-
Investor A initiates the DVD transfer by calling the relevant function with the previously agreed parameters.
-
Investor B verifies the parameters set by Investor A against their preliminary agreement. If everything aligns, Investor B triggers the DVD transfer on the transfer ID created by Investor A by calling the relevant function.
-
The DVD smart contract completes the token distribution as per the DVD contract parameters in a single transaction. This ensures that if either investor fails to provide the promised tokens, the entire transaction is reversed, preventing any loss of tokens.
Conditional Transfers (i.e. Delivery-vs-Approval - DVA):
Conditional Transfers require various layers of approvals, providing an additional oversight for the issuer. In a Conditional Transfer, the process for the investor is different from a simple transfer. They have to first increase the allowance to the DvA contract then call the initiateTransfer function with the parameters of the transfer. The DvA contract has to register itself as an eligible address in the IRS because it will store the tokens of the sender when a transfer has been initiated, until the transfer is processed or cancelled. However, the transfer will not be executed until the required approvals are executed. Transfer requests appear on the issuer's platform, forming a queue of required approvals. This process ensures compliance and adherence to specific conditions set by the issuer, promoting transparency and security in the transfer process.
Agents can enable Conditional Transfers through a specific smart contract by simply registering the address of that DvA contract in the IRS (i.e. Identity Registry Storage smart contract) and by adding the necessary claim(s) on its OID to make it eligible. When enabled, all transfers for that token will be managed through that smart contract, except the Force Transfer described in the next part.
When enabling Conditional Transfers, the Agents should define the conditions to be met for the transfer to take place, i.e. approval criteria of the Conditional Transfer. These conditions will be required for all transfers.
Below are the creation steps followed in this specific order:
-
The creation of the Conditional Transfer is triggered when the initiateTransfer function is called by the sender.
-
Tokens are blocked while the transfer has not been Canceled, Rejected or Completed.
-
The recipient approves the trade.
-
One Agent approves the trade.
-
Additional approvers approve the trade (optional).
If tokens are sent through a classic transfer, it will require an Agent to force transfer them back.
For each of these approvals, a wallet signature is required by the approver (sender, receiver, Agent...).
Once all approvals have been fulfilled, the transfer is automatically executed by the smart contract. In case the transfer is Canceled or Rejected, tokens are transferred back from the DVA Transfer smart contract to the sender wallet.
Conditional transfers can be implemented when one or multiple validation needs to be performed before any security token is sent or exchanged.
Considerations for Security Token Transactions
-
Regulatory Compliance: Security token transactions must adhere to specific regulatory requirements in each jurisdiction. This often includes conducting Know Your Customer (KYC) and Anti-Money Laundering (AML) checks to verify the identities of the involved parties. Adhering to these compliance measures ensures the legitimacy and legality of the transactions.
-
Ownership Validation: Ensuring the validity of ownership is crucial in security token transactions. Verifying the eligibility of recipients and confirming their status as qualified Investors helps maintain the integrity of the transfer process and aligns with regulatory standards. Thorough ownership validation contributes to a transparent and secure ecosystem for security token transactions.
-
Issuer Authority: Conditional transfers grant issuers and their Agents the authority to approve or deny transfers, allowing them to exercise control even over secondary market transactions. By monitoring and approving transfers based on predefined criteria, issuers can enforce compliance and safeguard the interests of all involved parties.