Jorge Serna • Jul 8, 2019
Thanks to the Digital Securities technology, investors can now hold their securities ownership records in the form of tokens (also known as “Security Tokens”), and these tokens can be kept in any wallet. This brings with it the advantages of fractional ownership, the ability to move those assets between different marketplaces that allow 24/7 trading, and direct access to trades between individuals by the simple mechanism of transferring those tokens.
But Digital Securities are different from other digital assets. Cryptocurrencies like Bitcoin or Ether can be transferred to any wallet in the world without any additional control, but securities are regulated instruments, and as such ownership can only be transferred under certain circumstances. These circumstances will vary from one security to another, because they will depend on the specific kind of asset involved (for instance, equity in a company has different properties than a limited partnership in a venture fund), the way it has been registered (or is exempt from registration) and the current ownership structure (since some limits may have already been reached).
The way to ensure that only transactions that are consistent with the applicable regulation, or the constraints that the issuer has, is for Digital Securities to implement transfer restrictions. Transfer restrictions are coded as part of the smart contract implementing the Digital Security, and are executed for every transaction requested, like transferring tokens from one wallet to another. In Securitize’s Digital Securities Protocol, these rules are part of the Compliance Service, which I covered in some detail in a previous post.
The result of these restrictions is that when a token holder tries to transfer their tokens to a new wallet address, the transaction may fail, and looking at the details in some block explorer like Etherscan will show an error like this one:
(note that the error is marked as Reverted. Different errors may have a transaction fail, which does not mean that it was restricted by the smart contract. An example for this is the “Out of gas” error, which means that the gas limit set for the transaction was too low for it to complete, and that provided more gas the transaction could have been completed).
While the error above shows that the smart contract did not consider the transaction valid, a limitation here is that it is unclear why it was not approved. To improve this situation, Securitize’s DS Protocol provides a mechanism to allow for validating the transfer of tokens before attempting any specific transaction and without having to spend any gas. This is based on the
preTransferCheck() method exposed by DS Tokens, which allows it to simulate a transfer between wallets, returning whether that transfer is valid, and if not a specific reason.
The DS Protocol mechanisms allow these checks to understand immediately whether a transfer of tokens between wallets will be possible without having to spend any gas, and there are two main points in which its usage will improve the interaction with Digital Securities:
preTransferCheck()method) so that when you try to sell or buy your tokens the process is executed smoothly. That is the case, for instance, with OpenFinance Networks, a regulated marketplace that allows the trading of several DS Tokens and has recently opened trading for US investors.
preTransferCheck()can be used without any cost, we expect that wallet providers will integrate this into their experiences, so that when dealing with Digital Securities they will be able to inform users about the potential issues with token transfers before they are executed, and even suggest options that will facilitate transfers to be completed (like transferring a different amount of tokens or checking if the destination address is correct).
But even without these players, anyone can actually invoke these checks in the DS Tokens. This involves calling the
preTransferCheck()method in a smart contract, which may sound like something very complex for someone not familiar with these concepts, but let’s look at how this can be done in three (relatively) simple steps.
Use a browser to go to https://myetherwallet.com/interface/interact-with-contract.
The first thing you will see is that MyEtherWallet requires access to a wallet to allow you to interact with a contract. For checking the validity of transfers, you don’t need to use any specific wallet (it is not necessary to check using any of the wallets involved in the transaction) so any wallet will work, even a completely new wallet you can create in the MyEtherWallet site. I usually use MetaMask for this, but this is not mandatory.
After giving access to your wallet, you will see something like this (and if you don’t, make sure to go to Contract > Interact with Contract in the left-hand menu):
Once you have accessed the “Interact with Contract” section, you will see a form with two fields:
preTransferCheck()method and how to use it. So in order to interact with a DS Token, we only need to provide the DS Token ABI, which luckily is available here, and you simply need to copy and paste the code on that page. Securitize’s DS protocol interfaces were published some weeks ago, and as part of that, the ABIs were also made available precisely to be able to work with the smart contracts, as shown in this post.
Once the contract address and the ABI have been provided, you will see a screen like this that will allow you to continue:
Once you hit Continue, you will be presented with the following screen, which allows you to select one of the methods offered by the DS Token to interact with it:
From the “Select an item” drop-down, you can select which of the DS Token methods you want to use. We will select
preTransferCheck() which will present this screen:
The dialog allows you to provide the parameters that will be used to invoke in
preTransferCheck() , in particular:
Filling this and then hitting “Send” will invoke
preTransferCheck() in the contract and will let you know of the result.
But remember, this will NOT send any tokens, it will only perform the checks to determine whether the operation would be approved if the tokens were actually sent. So you can test this without fear, because no tokens will be moved and no gas will be spent by trying this.
For instance, we can try to send one token (in the _value parameter we see 100000000 because this is a token with 8 decimals, so we have to use that value to represent 1 token) between two addresses as shown here:
The code response shows that the transfer would not be approved, with the ‘additional reason’ information stating “Wallet not in registry Service”. This is because the destination wallet has not been registered to any known investor, and one of the main restrictions imposed by Digital Securities is that all holders must be known, so this kind of arbitrary transfer is not allowed. If instead of checking with
preTransferCheck() the sender wallet owner had directly tried to transfer the tokens, the transaction would have failed with a “Reverted” error as we saw before.
A different test, with a different destination wallet (this time one that has been registered to be able to hold security tokens) would give a different result:
In this case, the response is that this transaction would be “Valid”, so if the wallet owner tries to do the actual transfer of the tokens, this would be approved and the transaction would be successful.
As we have seen, the DS Protocol allows us to immediately check whether a transfer of tokens between wallets will be allowed — without having to spend any gas.
The process described in the sections above is not very complex, but can clearly be a bit cumbersome, which shows that we still are in the early days of Digital Securities. As wallets integrate these mechanisms, and there are more improvements happening both in the experience and capabilities that this technology brings, little by little we will be making financial transactions more flexible and powerful.