Governance of security tokens

Securities can be outstanding for many years, while a company works with its investors. An issuing company needs to manage the related security tokens or “programmable securities” for their full life cycle. That management requires governance — some rules about who does what for important actions like issuing new stock. We were forced to think this through when we did our Aboveboard stock distribution. In this article, we will cover the roles and actions that you will need to govern your security.

The problem

A programmable security is not like a cryptocurrency. Cryptocurrencies usually cannot be updated after they are issued. Their goal is to eliminate questions about governance. Companies are constantly making adjustments to their securities.

• A cryptocurrency token usually has a fixed, pre-programmed issuance schedule. Companies issue new shares as approved by the directors and shareholders.
• Cryptocurrency token code typically cannot be updated after it is issued. We will adjust the code of programmable securities to account for new types of shareholders and jurisdictions and exchanges, and just to fix problems.
• Cryptocurrency is typically lost if the holder loses the related private key or gets hacked. This is not acceptable for a security. If we sell a security to grandma, and grandma dies without leaving the key, we still owe the securities to the estate. If a professional money manager buys securities, he can’t run the risk of losing them. A company needs to be able to replace a lost stock certificate.

A programmable security is also not like a paper security. The rules for handling a paper security are rather loose. The company will have internal processes for doing things like issuing new stock, or replacing a stock certificate. If someone complains that there is a mistake, they can fix it up later with a corporate resolution and some editing. We want our blockchain records to be more accurate than that.

Roles

We do need to apply normal corporate governance to our security. This means that major actions, such as issuing new securities, are approved by a board of directors. The company, and not an individual, should have control over distributions. The board of directors can assign an officer to do the day to day work of distributing stock and managing the trading of stock. The officers hire programmers to implement tools, and they can hire agents to qualify investors and sell securities.

We found it useful to think about the following roles for handling a programmable security.

Code owner

The implementer or programmer is the code owner. When they deploy your code to the blockchain, the account that deploys it becomes the “owner” and gains special powers to update it. By default, everything you do with your programmable security can be done by the programmers or technical service provider. That’s convenient when you are setting up your programmable security. However, it could become a complete disaster if you find that your programmer or technical service provider quits or gets fired right when you want to make other changes. The company as a group should control the security. In this case, some set of representatives of the board of directors should actually handle the security.

Multisig Group and Wallet

A “multisig group” will represent the company and the company’s board of directors. A majority of the group will sign off on important actions that affect the security. Each member of this group has a private key. The group can replace its members by adding and removing signers.

This group will also control a company multisig wallet. We found it convenient to have one multisig wallet for the company. The signers on this wallet make up the multisig group for approving important actions. They also control the distribution of stock. New stock can be minted, but it can only be minted to the company wallet. This account holds the stock that has not been distributed to blockchain users. This wallet can always receive stock from shareholders, ignoring lockup rules, in order to handle cases like people leaving the company, or a buyout or windup of the company.

Issuing officer

We can’t ask the multisig group to approve every action. For example, we need a fast way to add new potential shareholders to our employee and affiliates list. We want a fast way to turn trading on and off, and use the other controls in the registry. The multisig group will assign an issuing officer with these permissions.

Qualifiers

The company may hire agents to qualify investors. These agents have the authority to update whitelists of potential investors. The issuer then decides what lists to use.

Putting it all together

Finally, we string this together into a well-governed security issue:

• Create the multisig wallet and assign company representatives to handle it
• “Mint” all of the issued shares into the company wallet. At this point, the company is holding all of those shares in custody for its shareholders.
• Send tokens from the company account, to approved addresses of shareholders.
• Assign an issuer account to manage the registry.

Then, for maintenance, we can:

• Issue new shares by minting them to the company wallet, the only type of minting that is allowed by the code. Then, they can be distributed by the company.
• Replace lost shares with a special feature that allows the multisig group to approve a transfer from an old, dead account with a lost key, to a new account. This is like replacing a lost stock certificate.
• Collect shares into the company account from shareholders if someone leaves the company, or if the company is bought out, or if there are other deals. Lockup rules will never prevent a transfer of shares to the company account. It’s a special case.
• Manage the multisig group by adding and removing members as needed.
• Update the code, including the trading rules, whitelists, and exchange interfaces. We have focused on making sure that the code is upgradable. We still need to do more work to control the update process. We looked closely at token implementations from Polymath ST20 and OpenFinance, and found them lacking in upgradability, so those standards also have more work to do.

For futureproofing, we need the ability to move to our security to new exchange transfer agents, a new token or even a new blockchain. We get this ability from our registry, which can push the correct list of shareholders into the new format.

Governance actions in the Aboveboard Issuer Registry beta test