Securitize Logo

Understanding Transfer Restrictions for Digital Securities

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.

How can we use these checks?

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:

  • In regulated marketplaces, to facilitate the trading of Digital Securities, they manage the process behind the scenes. They only present orders that are available to be executed, and they perform all the checks (including using the 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.
  • Directly on wallets. Since the DS Token interfaces are public and 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.

1. Go to the “Interact with Contract” section in MyEtherWallet

Use a browser to go to

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):

2. Set the token address and the DSTokenInterface ABI

Once you have accessed the “Interact with Contract” section, you will see a form with two fields:

  • Contract Address. This is the Ethereum address of the token you want to check for transfer restrictions. If you don’t know the token address, you can search for the token in Etherscan and look for the “Contract” information. For instance, in the case of the SPiCE VC token, their address is available here:
  • ABI/JSON Interface. The ABI, or Application Binary Interface, is the way for a software component to indicate how to interact with it. In the case of a DS Token, it is the way to show that it has a 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:

3. Use preTransferCheck

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:

  • _from, which is the wallet address that will send tokens
  • _to, which is the wallet address that will receive tokens
  • _value, the number of tokens to send (but bearing in mind decimals, so if a token has decimals we will need to add zeros to take this into account)

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.

So, what next?

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.

This site is operated by Securitize, Inc. (“Securitize”), which is not a registered broker-dealer. Securitize does not give investment advice, endorsement, analysis or recommendations with respect to any digital securities. All digital securities powered by Securitize’s technology are offered by, and all information related thereto is the responsibility of, the applicable issuer of such digital securities. Neither Securitize nor any of its officers, directors, agents and employees makes any recommendation or endorsement whatsoever regarding any digital securities powered by Securitize’s technology. Nothing on this website should be construed as an offer, distribution or solicitation of any digital securities. Securitize does not provide custodial services in connection with any digital securities powered by Securitize’s technology.