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:
A reverted transaction in a DS Token
(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:
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.
Give access to a wallet in MyEtherWallet
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):
Interacting with smart contracts using MyEtherWallet
Once you have accessed the “Interact with Contract” section, you will see a form with two fields:
The contract address for a DS Token
Once the contract address and the ABI have been provided, you will see a screen like this that will allow you to continue:
Filling the contract address and ABI
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:
Selecting the method to interact with the contract
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:
preTransferCheck() parameters
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:
An invalid transaction
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:
A valid transaction
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.
Securitize delivers trusted global solutions for creating compliant digital securities. The Securitize compliance platform and protocol provide a proven, full-stack solution for issuing and managing digital securities (security tokens). Securitize’s innovative DS Protocol has the highest adoption rate in the industry and enables seamless, fully compliant trading across multiple markets simultaneously. Multiple Securitize powered digital securities are already trading globally on public marketplaces with many more in the pipeline.
You can learn more about Securitize at our website: www.securitize.io
And you can join the conversation about the Digital Securities revolution in our Telegram channel.