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

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.

Compliance Service Implementations

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.

Elements of the Compliance Service

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

• Compliance Rules Engine: This is the contract that allows the execution of the different restrictions defined by an issuer according to relevant regulations. It keeps count of investors per categories (eg. U.S. investors, retail investors from certain countries, etc.) so that limits can be enforced. For instance, it can be parametrized to limit the issuance of tokens to less than a certain number of accredited investors in the U.S. or to restrict the number of retail investors per E.U. country to a certain limit. It also allows the blocking of investors from certain countries, setup of automatic lock-up periods for tokens issued to certain types of investors, or preventing transfers from offshore investors to U.S. persons. The specific limits and countries can be parametrized in contract creation so that this engine is suitable to cover most DS Token requirements.
• Wallet Manager: The wallet manager provisions wallets into the Compliance Service that will have certain special behaviors. This is the case of issuer wallets, which will be the only ones that can be involved in seize operations.
• Issuance Information Manager: This holds information elements that may be relevant to other actors in the ecosystem. For instance, in the future, the URL endpoint for the RFE API for a given DS Token will be accessible via this component, so that it can be identified via direct inspection by other actors (like an exchange) or DS Apps.
• Lock Manager: The lock manager allows the issuer to create specific locking for tokens, not necessarily related to regulation. This mechanism can be used to create vesting schedules for issued tokens, implement trading restrictions for capital locks, restrict trading for affiliates, or respect any other transferability restriction that the issuer has reflected in their subscription agreement.

Suitability of DS Tokens for an Investor

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.

So, what’s next?

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:

• The Open Zeppelin team, which provides patterns and code that have been extremely helpful in our development.
• The OpenFinance Network team, who have helped in the final leg of our development process, to ensure the validity of the DS Protocol in the context of trading operations via an exchange environment.
• The Truffle framework, which we have used for our code and tests.