People sometimes refer security token systems as a kind of decentralized finance; Even If this is not conceptually impermissible, this kind of Defi has some vital distinctions with it worth attention. They are hugely different with typical Defi systems as MakerDao and Compound. Typical Defi systems are economic or financial utopia, they have no concern with history or regulation of the real word, they have a beauty of purity or even simplicity. But not for security token systems, they are to face directly the existing complication of real financial world, from perspectives both of business or technology.
This raises specific problem and task for the design of security token system. Simply put, like traditional information system, ST system has to make effort to cope with miscellaneous traditional business complication. In doing this, extensibility and evolution are vital for its success. I do not say Defi does not need extensibility or does not evolve. They upgrade and need be upgradable. But ST systems not only upgrade, they are customized in issuance projects, for different jurisdiction, they try to incorporate and integrate. This kind of activity that is supported by extensibility is heavy and dense. We need raise extensibility of ST system to a high level.
Compliance is an important, maybe the most important part of ST, so we focus on its design in this article.
Design patterns of our compliance subsystem
A highly customizable logical network of compliance components.
1. For token core logic, compliance is a simple interface whose complication is transparent for token core. Core know nothing of the existence of a big network. Compliance has heavy implementation but simple interface with other parts.
2. A configurable component which utilizes investor’s claim to check his compliance. Speak more clearly, this one access an ERC780 claim repository to get claims of investors to see if certain condition is satisfied, and this condition is expressed for ST by a Boolean logical expression like:
“jurisdiction==US&&certificate=AccreditedInvestor||jurisdiction==sigapore&&certificate==* *”
Each security token is configured by such an expression. Obviously, this configurable component has reusability and is enough for lots of situation
3. Logical relation component that is to assemble other components: OR components and AND components. These are components that links to make a logical network.
4. Adaptor components that wrap different identity and claim standard. As an example, the OnchainId adaptor adapts to erc735、erc734 identity system, which is adopted by some ST issuance platform.
5. Other components on the way…
The main pattern of compliance smart contract design is logical composition or assemblage which is recursive and may have arbitrary depth. This assemblage structure makes the compliance system obtain an extensibility almost without any hard constraint. It collects all kinds of components and link them into network to cope with all kinds of compliance problem with elegancy and simplicity, everything under control, different source and technological standard of identity and claim, multi-jurisdictional support, all expected possible changes in the regulation section which is ordinary events in this revolutionary area.
Compliance is essence of ST， it is designed with extensibility in view is essential.
Below we depict several application scenarios or use cases to get a clear conception of this design
Scenario 1: multi-jurisdictional support
Compliance requirement is that investor is American or Singaporean or Japanese and is accredited investor in his nation. Our configuration of the compliance logical network is:
1. Three components each responsible for one jurisdiction. Component will return true when investor satisfies check condition.
2. An OR logical component link to all three components. When one of them returns true, the OR component returns true;
3. Any investor from these three countries and is accredited investor will pass, people outside or with no accredited investor claim will fail.
Scenario 2: OnchainId Adaptor
We know that a great number of investors have invest in security tokens that is issued on platforms adopting OnchainId identity standard as their compliance supporting identity technology, and it is a great thing to make their claim work directly in our issuance!
1.We make an OnchainId adaptor. In OnchainId , identity is based on erc734， claims based on erc735. We know the address of an IdentityRegistry, those methods of this smart contract that is useful for our work is:
Using this, we can check if an investor has an OnchainId identity and is accredited.
2. Another component is based on our identity and claim system which adopt erc780 as claim registry. Investor obtain claims using our identity wallet and claim provider network.
3. An OR logical component links those two components to make a compliance network by which all investors from heterogynous platform is supported. This is smart!
Scenario 3: One step further
Investor from different jurisdiction, some are investors of issuance adopting OnchainId identity.
Solution is quite straight forward：Setup a network that is logical composition of case 1 And case 2. It is so straight forward that it seems an overelaboration to say any more. （remarks： It is also feasible to arrange some “identity transportation” work to make investors from other ecosystem being supported. Which one is better is contextual）
Evolution roadmap of compliance system
Extensibility and composability of this compliance system design makes smooth evolution roadmap possible:
1. Logical components is abstract and makes stable structure.
2. Presently ConfigurableComplianceService compliance component satisfies quite a lot of compliance requirements and can support basic project
3. Miscellaneous Components that support Lockage，percentage ，maximum holder balance, maximum holder count
4. If compliance requirement cannot be well supported by current components, new components is designed and developed.
5. Components will accumulate, optimized, evolve from some narrow-minded into reusable ones…
6. Ubiquitous reusability reached, project cost controlled and reduce, more powerful tool support made possible
Security Token compliance is challenging by real world, all designing technique developed by historical software practice are precious for us. We cannot afford missing it.
