Announcing The SFT Protocol - Part 2: On The Philosophy of our Protocol

This is the second part in our series of articles introducing the SFT Protocol, a set of compliance-oriented smart contracts for Ethereum based security tokens. You can read the first part here, or the third part here.

When issuing tokenized securities, each jurisdiction presents a unique set of guidelines, restrictions and challenges. Regardless of which regulatory agency is in charge, the issuer must navigate complex reporting obligations, trade restrictions, KYC/AML procedures, and provide support to their investors for the entire life-cycle of the security. Failure to meet these requirements can result in costly legal battles or even jail time.

To meet these obligations, a token issuer will typically enlist the services of a technology provider. In turn, this developer must understand and account for all of the issuer’s needs, communicating with lawyers, auditors, tax advisers, and government regulators to ensure that all legal requirements in their jurisdiction are able to be met.

The SFT Protocol provides automated on-chain compliance to reduce costs for securities issuers, allow for rapid settlement of trades, and simplify reporting requirements and regulatory supervision. The modular design of the framework allows issuers to adapt it based on their own needs and evolving regulations. Robust, granular KYC compliance rules ensure tokens remain in the hands of verified and authorized investors. SFT minimizes friction in enforcing compliance for both investors and issuers, removing the need for middlemen and reducing barriers to entry. Through increased transparency, it is a step towards a more open and fair market.

Why Another Protocol?

At HyperLink Technology we are not the first to attempt to navigate this path. In formulating our own approach toward security tokenization we first looked to what others have done, and identified areas that we felt were lacking within the industry. For example, we too often see one or more of the following characteristics:

  • Walled Gardens: Often marketed as “end to end”, this approach is one where tokens can only be issued, maintained and traded within the confines of a single marketplace. This is the antithesis of interoperability, using blockchain as a marketing play without utilizing any of the actual benefits it offers. Erecting a walled garden does nothing to advance this industry, and when presented as groundbreaking it has the potential to distract or confuse newcomers who do not yet see the full potential that blockchain provides.
  • Rent Seeking: Any business that raised money by shoehorning a token into a system that doesn’t require one, without offering a benefit to the token holders, is morally suspect at best and likely offside with regulators. This is not a strong starting position when seeking to enter such a highly regulated area, and should serve as a red flag to any would-be issuers contemplating which technical approach to implement. More importantly, using an unnecessary utility token as an entry ticket does nothing but create more friction in an industry desperate for adoption.
  • Closed Source: A closed-source code base is an economic moat which keeps issuers dependent upon the technology provider for the entire life-cycle of their token. Ultimately this stifles the growth of their protocol by preventing other companies from developing around it. In keeping their code obfuscated, the developer dictates who else can interact with the system, and those deemed to be too much in direct competition are not admitted. This manner of protocol can only grow outward as quickly as the company that created it, and runs the risk of being overshadowed by another more open system.

It is understandable that businesses choose to engage in these practices; after all they are profit-driven machines and giving competitors any advantage seems counterproductive. However, we believe these approaches to be short-sighted. Though they may result in more profits in the short term, they ultimately slow innovation and hold back the development of industry as a whole.

Our Philosophy

Now that we have established what we do not wish to do, we may consider the areas that we do value. The SFT Protocol has been developed around the following core beliefs:

1. The protocol must be open-source and non-rent seeking.

The best technical approach is one that allows and encourages use by many market participants. Service providers within the ecosystem can and should seek to be compensated financially, however the design must be such that at no point can a single company act as a gatekeeper and so maintain an effective monopoly. Similarly, no functionality should require a proprietary token in order to be accessed. Practices such as these will only recreate the existing disconnected markets and hinder growth and innovation.

2. Compliance should be handled on-chain whenever possible.

Automated compliance allows for massive reductions in settlement time and can render custodians and central securities depositories obsolete. Whenever if a permission must be provided by an off-chain authority it increases friction in the system and introduces a chance for non-compliance due to maliciousness, negligence, or error. Handling compliance on-chain is one of the fundamental areas that sets digital securities apart from the current financial structure. If we truly seek to innovate, this is an area we must be focused on.

3. Consideration must be given to the entire life-cycle of a security, across multiple jurisdictions, and with the future in mind.

A good protocol will examine the needs of all market participants and seek to reduce friction for the entire life-cycle of a security. It must consider issuance, secondary trading, on-chain governance including events like dividend distribution or voting, and redemption.

Additionally, the protocol must work just as well for securities issued in the USA, China, the EU, or any other jurisdiction. It must also be able to accommodate and apply restrictions based on the laws of more than one country, facilitating international transfers where permitted.

Finally, issuers must be able to adapt to an ever-changing regulatory landscape. We cannot know what the future will bring. A protocol must be robust, modular and able to adapt over time as the requirements of an issuer change along with the regulatory landscape.

4. A degree of trust is acceptable in a system where identification is a prerequisite to participation.

Tokenized securities and STOs are very different from the utility tokens that were sold via ICOs. Issuers and custodians are known companies with established businesses that can and will be taken to court if they act illegally. Investors must pass KYC/AML checks before they can hold tokens. There are well established legal frameworks to protect and enforce the rights of investors in these projects, and anonymity has no place in the ecosystem.

For this reason, it is legally obligatory that an issuer has a level of technical authority over the tokens that they create. Being able to freeze or transfer an investor’s tokens is not only acceptable, but a requirement in the case of a court order or economic sanction. Investors need not fear that an issuer has this authority, as it is a registered and previously verified company and not a fly-by-night anonymous dev who might one day decide to steal all the tokens and disappear.

5. We must consider real world use cases.

A good protocol is one that allows for many market participants to come together and interact. The unfortunate reality though is that each new participant is another chance for maliciousness or negligence. The more decentralized a system becomes, the harder it is to maintain authority within it.

This is the real world, bad things will happen. Investors will lose their private keys. Issuers will get hacked. Courts will order that tokens be seized. Custodians will be found to be acting in bad faith. KYC providers will misidentify an investor.

In building a framework that allows the participation of many, it is imperative that there are tools in place to deal with the unexpected situations that can and will arise between different parties.


In part 3, we will outline the technical approach of the SFT Protocol and how we meet the challenges we identified.

We invite you to view our code on GitHub, read our yellow paper for an overview, and see our technical documentation for a detailed breakdown of the protocol’s functionality.

Visit our website, Twitter or Telegram channel to get in touch.