Digital security platforms offer an environment to execute smart contracts, but what terms go into the contracts, how does this change current practices (e.g., ‘custody’), and how do these platforms work together. Here are a few of the issues of the transformation to digital securities.
1 – What are the terms that should be incorporated on-chain as best practice?
Many current consortia efforts are underway to define exhaustive smart contract terms to be comprehensively incorporated into each blockchain transaction (e.g., Hyperledger, Corda). But establishing these semantics is a major effort & there are those that doubt the near term success of generalised smart contracts. [It certainly is possible to encode highly standardised contracts for niche applications].
OTOH to fulfill the Digital Security promise of improved secondary market liquidity, Digital Securities need at least to incorporate the terms of restriction of transfer (e.g., KYC/AML restrictions [number of shareholder restrictions, ROFR clause, restricted time period, voting requirements for any secondary sales, etc.). Further to ensure that these terms are executed the secondary trading needs to be done on a ‘permissioned blockchain’ where restrictions on the ownership of the security can be enforced, rather than unrestricted general exchanges.
2 – How does the custodian function change, what are the implementation options?
In traditional security sales there is provision for a custodian to hold shares privately or in a ‘street name’. The owner does not have to take physical delivery of the shares, and future transactions are not delayed by physical transfer.
How does DLT change this?
One simple argument is that the share owner holds the keys to the wallet containing the digital share and this constitutes the equivalent of ‘self custody’. But more fluid markets are based on intermediary transactions and certain classes of investors (e.g., funds) require a custodian function. Also trading one share is not very risky, But there are already some serious operational security issues around very large volume cryptocurrency transactions. A currently popular technical mechanism is to implement custodian services on ‘multisignature’ tokens, where the custodian or transfer agent has an additional signature and the transaction scheme may require 1of2, 2of2, 2of3 signatures etc. to transfer. Other providers are implementing more traditional schemes of auditable custody rules, but where the broker-dealer, custodian and exchange are linked.
3 – ATS / Secondary Market Interoperability
The viability of digital secondary markets has yet to be fully demonstrated. Most current implementors are concentrating on captive secondary Alternative Trading Systems (ATSs), where you are trading security tokens issued for that platform, or wrapping the existing security in a new smart contract ‘token’ specific to the ATS. This of course significantly restricts the liquidity promise of digital secondary markets. An interoperable token specification that supports secondary trading is the desirable future and there is some work going on, In the short term standardised trading semantics as mentioned in Q1, might enable efficiency in listing a digital security on an independent ATS
BUT in any case Model 2 (standardised terms with quick API wrapping for an ATS) may represent the most pragmatic on-chain/off-chain design balance to be ready for future interoperable secondary markets and is readily ingested for any near term captive/proprietary secondary markets.
Interoperability is an issue not just for secondary market liquidity, but across the full ecosystem (e.g., issuer, token specification (e.g., DS, R-token, ST20), token issuance platform (eg., Ethereum), token architecture (eg., ERC20 vs. ERC23), KYC/AML services, custodian, compliance and reporting, broker-dealer, attorneys, smart-contract semantics, cap chart and shareholder management, secondary trading platform).
4 – Consideration of international inter-jurisdictional accommodations / mapping
Where there are regional jurisdictional differences, these have been reflected in the implementation of industry standards and smart contracting semantics. For example, the ST-20 token, developed by Polymath, incorporates a verifyTransfer function to ensure each transaction complies with any coded US regulatory restrictions. How can these requirements be mapped to a ERC-223 token (e.g., Neufund), and vice versa, to ensure both US and EU compliance?