Security Token Market's crowdfund is going live on Securitize Markets on July 6th.
Jun 3, 2019
This fourth post completes our series around our Digital Securities Protocol (DS Protocol) interfaces release. We will keep posting more specifics around the DS Protocol and its applications, but in these initial texts, we wanted to provide an overview about the interfaces defining the different protocol elements, which we complete with the presentation of the Compliance Service.
The Compliance Service is the DS Protocol component that oversees all token transactions to ensure that they are within the parameters defined by the issuer, to comply with specific regulations and their own requirements.
To do this, the Compliance Service handles the standard ERC20transfer()
and transferFrom()
calls from the DS Token contract, as well as calls that are specific to the DS Protocol like preTransferCheck(), issueTokens()
, issueTokensWithLocking()
, and seize()
, which were described in a previous post.
The methods involved in this mechanism are part of the DSComplianceServiceInterface:
function validateIssuance(address to, uint value) /*onlyToken*/ public;function validateBurn(address who, uint value) /*onlyToken*/ public returns (bool);function validateSeize(address from, address to, uint value) /*onlyToken*/ public returns (bool);function validate(address from, address to, uint value) /*onlyToken*/ public;function preIssuanceCheck(address to, uint value) view public returns (uint code, string reason);function preTransferCheck(address from, address to, uint value) view public returns (uint code, string reason);function setCountryCompliance(string country, uint value) /*onlyIssuerOrAbove*/ public returns (bool);function getCountryCompliance(string country) view public returns (uint);
The different validateXXX()
methods are called from the appropriate DS Token operations, and allow the Compliance Service to allow them to happen (true response) or are blocked (false response).
Two additional methods (preIssuanceCheck()
and preTransferCheck()
) allow for checking if an operation is possible before its execution, which allows for a better experience to issuers and investors. We will discuss this later in this post.
Finally, the Compliance Service also includes methods to manage specific country-specific behavior. This allows blocking investors from certain countries to receive tokens during issuance or in secondary trading.
Each issuance may have specific properties and requirements that will impact the behavior of its Compliance Service. From the kind of registration (or exemption) that the issuer has applied for, to the countries it is destined to, or certain restrictions being driven from the nature of the asset being tokenized, each issuance will have specific characteristics that need to be considered by the Compliance Service.
We believe that there will be no one-size-fits-all Compliance Service, and we need to support flexibility to adapt it to each DS Token. But, regardless of this, we aim to cover the most demanded and generic functionalities, so that in most cases we can support issuer demands with some parametrization of existing contracts.
We also provide some interfaces in our repository, to illustrate how the structure of a reference Compliance Service may depend on additional contracts offering additional capabilities. The interfaces provided conform to the following internal structure:
Structure of the Regulated Compliance Service implementation
The different components are
While the Compliance Service ensures that no undesired transfers will occur, this approach may not offer the best customer experience for investors. Imagine a new investor going to an exchange to buy a specific token, only to not be allowed to complete the operation because, for instance, the quota for their investor category has already been covered. The transfer would be prevented, but a better experience would have been to understand this beforehand in order to not offer that DS Token to the investor or to provide guidance on how to make that trade can possible.
To improve this experience, the DSComplianceServiceInterface provides the following method:
function preTransferCheck(address from, address to, uint amount) view /*onlyExchangeOrAbove*/ public returns (uint code, string reason);
This method, which is exposed both at the Compliance Service and at the DSToken level, provides the same basic checks that when the Compliance Service is invoked by transfer()
or transferFrom()
, but it does not store any potential state change that the Compliance Service might require in a regular token transfer, and in the case the transfer is not possible, it returns an explanation as to why.
With these return values it is possible to identify the reason a transfer may have been blocked so that proper feedback can be given to an investor, and sometimes help remedy the situation. For instance, in some cases, a full transfer of tokens could be a solution for a seller. The following table presents the values that should be supported by a standard Compliance Service, but other proprietary error codes can be defined by specific Compliance Services just using code numbers above 100.
With the description of the Compliance Service interface, we complete our first overview of the DS Protocol. But firstfirst is a critical word there because we expect it to keep evolving and increasing the value that Digital Securities on the blockchain will bring to issuers and investors. New DS Services and capabilities, as well as improvements over the existing ones, will come in the following months.
We also expect that the community will be able to contribute to this evolution, so if you identify issues or have suggestions on how to contribute to the evolution of the DS Protocol you can contact with us at protocol@securitize.io.
Finally, we would also like to extend our thanks to all the wonderful people and projects whose work on the blockchain makes this project and others a reality. In particular: