The Future of Security Token: 4 Ways to Build a Security Token System

By Matthew Hine, First appeared on He3Labs

Security token offerings (STOs) have been in the news of late. The image of the ICO utility token has rapidly tarnished under regulatory scrutiny and rampant fraud, but the hunger for more democratic forms of fundraising remains. Security tokens offer a potential solution: combining the liquidity and democratic access of cryptocurrencies with the necessary regulatory controls for a token to properly represent a security (such as various forms of company stock).

Making a token securities-regulation-compliant however isn’t so simple. After all, most DLTs are built on principles of radical open access and freedom from control, while regulatory compliance requires limitations such as:

• Only certain parties can hold the token (region locking, AML/KYC, accredited investor status).
• The token can only be sold following a lockup or other time limit.
• A maximum number of token holders must be respected.

All of these come down to limiting the movement of tokens (that represent securities) based on rules. Traditionally these limitations and rules were enforced more or less bureaucratically through process and intermediaries such as “transfer agents”. Given that tokens allow us to ensure things like ownership and uniqueness directly with DLT rather than bureaucracy or intermediaries, an ideal solution would also apply a more technological approach to providing the necessary controls on token movement. But how?

Companies working on solutions (often specialized exchanges such as Tzero, Securrency, Templum, and many others) are keeping their cards close to the chest, but here are four fundamental technological methods for limiting token movement that I believe describe the forms that all securities token solutions may take:

Method 1 – The Walled Garden

(Private token, private wallets)

This is essentially the model of stock exchanges, ATS’s, and other traditional exchanges. The “token” is really just an internal representation of securities on the exchange system. Rules regulating token movement would be directly enforced within the walled garden exchange for its users.

Certainly, a private DLT with private token representations offer significant operational efficiencies, and trading of these private tokens could be offered alongside more general crypto trading. But ultimately the private token inherently cannot move outside of the singular exchange system, although two separate walled garden exchanges could agree on coordinated destruction and creation of tokens to allow them to “move” between them.

With this method, any interaction between a business and its own tokens must be conducted through the exchange(s). The company has no direct interaction with the tokens or a DLT.

Good:

• Because the model is familiar, it seems most likely to be comfortable to regulators.
• The fact that these are not public tokens means that there is no risk of them escaping regulation out into the wild (ie. into uncontrolled private crypto wallets and crypto exchanges).

Bad:

• The complexity of “moving” tokens between walled gardens makes these tokens less liquid and more likely to end up locked within particular exchanges.
• In the worst case, non-DLT-enforced “movement” of tokens between walled gardens could introduce errors leading to loss of tokens.

Method 2 – Oases in the Desert

(Public token, platform-specific private wallets)

In this method, the token itself is carried on a public DLT and inherently freely tradable (ERC20, Stellar, etc.), but investors never directly touch the token or hold it privately. Each oasis exchange maintains wallets for their users (much like typical crypto exchanges today), but does not allow users to withdraw tokens to private wallets. Each exchange would need enforce the rules regulating movement of the token for its users, and verify that other oasis exchanges are also enforcing those rules before allowing a user to request to move the tokens to that exchange.

An issuing company could directly manage its token in this method, but would be responsible for enforcing correct rules itself just like an exchange, which could introduce a requirement for the company to be regulated as an exchange itself.

Good:

• Use of “standard” crypto tokens makes this method more flexible and liquid than the Walled Garden method in theory, with technically simple movement of tokens between exchanges.

Bad:

• Because the tokens themselves are inherently freely tradable, all regulation of movement is enforced by process (whitelists, and the like). These controls may be prone to error – and with a financial incentive for users to exploit errors – creating risk of tokens escaping into the wild. This could concern regulators.

• Because private wallet holdings cannot be allowed, investors must fully trust the security of their funds to the exchanges – opening the potential risk of unrecoverable loss of funds much like with crypto exchange hacks we have seen.

Method 3 – The Smart Wallet

(Public token, controlled public wallets)

In this method, the token itself is still public and inherently freely tradable (ERC20, Stellar, etc.), but a single, central authority ensures that tokens can only move between whitelisted wallets associated with exchanges or users who are authorized to hold the token. These could still be public wallets, but would require special DLT-enforced controls regulating the actions users can take based on the DLT addresses for those wallets. This might be implemented by way of smart contract, or on-DLT multi-sig controls. Regardless of implementation, the wallet would be designed to “phone home” to the central authority to ensure that a token transfer is acceptable, with the authority making that judgment based on KYC or other data for each wallet in question.

A business could clearly directly manage its token in this method, with the central authority enabling the business’s rights to do so.

Good:

• This method is highly flexible and liquid, potentially allowing tokens to be carried on open crypto exchanges without enormous additional exchange support.
• Investors could have their own private wallets to avoid having to trust the security practices of an exchange.

Bad:

• This method is highly reliant on a single authority to ensure correct enforcement of rules and to ensure continuing investor access to their controlled wallets.
• This could be a fairly complex system to develop and the centralization of control could place extraordinary regulatory burdens on the entity providing it.
• If the central authority were to die, particular care would have been necessary to ensure that investors using private wallets can move their tokens (likely to an exchange platform, essentially falling back to Oasis method).

Method 4 – The Smart Token

(Controlled public token, public wallets)

Here, the “phone home” functionality in the Smart Wallet method is built into the design of a specialized public token itself. This would require either a custom (and highly complex) smart contract defining the token, or protocol-level DLT functionality enabling this kind of token definition. Essentially, the token itself must be able to “ask” if it may be transacted from one wallet to another.

This could ultimately be very similar to the Smart Wallet method in that there might still be a central authority that is providing the judgment of what transactions are acceptable based on KYC or other information associated with wallet addresses. In concept, however, this could be a fully decentralized system whereby the token is checking directly with a decentralized definition of rules and qualifications provided by the issuing company, providers of KYC, and more. However, designing such a system would be complex and would require broad industry adoption to be functional.

Good:

• This method is extremely liquid, essentially behaving like a regular public crypto token except that transactions that don’t meet relevant rules would simply be impossible when attempted.
• Investors would be able to make use of standard private wallet software/hardware options without constraint (assuming the specialized token is supported by that wallet solution).

Bad:

• Because the token itself is specialized, support on exchanges and in wallet solutions is not necessarily guaranteed unless it is interface-compatible with an existing popular token standard.
• Who will build the standard, and who will provide the necessary regulatory compliance inputs to the system to create a functional and complete ecosystem solution?
• Standard security concerns about smart contract-driven logic apply: a bug in the smart contract could irreversibly break the system.

Which method will win? Time will tell. In the near-term, I think it’s likely that Walled Garden and Oasis methods will be the quickest to market with the lowest risk. I have seen at least one Smart Wallet approach in development as well.  But despite the complexities and unknowns of the Smart Token approach, that’s my bet in the long-term. Once built and adopted, this method should deliver immense efficiencies, greater investor control, and a more democratized ecosystem that still meets the full intent of regulatory requirements. That’s precisely the kind of thing that DLT should do.