Authorization and Certificate Token — PlatON concept design

Authorization and Certificate Token — PlatON concept design

Continuous from James@Tokyo

Centralization and decentralization governance is switching between each other in the loop of history. Depends on which one is more efficient and vital by that time. Tribes in the stone age, people needs tight cooperation to fight with wild and dangerous animals, as well as natural disasters. Now an individual could enjoy high quality music with good wine at home like a king hundred years back. We are living a decentralization friendly time, people having more freedom, contribute more as an individual, less as a group member, less as a firm employee.

After said above, when the legal environment or the social consensus is not ready in certain area, a centralized mode as a buffer for transform is still required. Traditional finance area is one of them, highly regulated sector due to investor protection, tax revenue, and governance purpose, huge profit generated for the government.

The ACT (Authorization and Certificate Token) is a mixed Token of Soul Bound Token and Semi- fungible Token, based on NFT. Designed for regulated financial service on public chain.

This ACT framework was designed for data flow control, where we imagine the financial services such as transactions are one kind of simplified data flow, and that is why we pick up financial service sector to start with.

Let’s borrow the financial service license structure from Singapore MAS, to make example as below.

Basic license elements

There are different basic elements defined for different financial service categories in appendix

A. For example, there are five categories covering from banking, capital markets, financial advisory, insurance, and payments. In banking service category, it has nine basic elements (types or status) we could define from B001 to B009, from local bank till financial holding company(banking). The relationship shown as below diagram:

Authorization and Certificate Token — PlatON concept design

For each of above basic license elements, there should be a clear definition of service scope, especially for token related financial service we are going to use when introduce traditional service onto public chain such as PlatON.

For example, B001 local bank may has permitting to mint fiat currency bounded stable coin, while B007 money broker may not allowed to mint stable coin and only can trade them with exchange services.

Another example are KYC, AML, CFT procedures, all above financial institutions must compliance with the standard regulation procedure off line before on board any customer, only after they passed the procedure auditing, a Soul Bound Token (SBT) issued by regulator will be transferred to those qualified institution wallets. We call them mandatory SBTs.

Grouping of basic license elements — license model by SBT

Consider how to come up a license from the government agent to a certified institution. First of all, the mandatory SBTs will be verified, e.g. qualification of all mandatory criteria. Once confirmed, based on application and evaluation, one or license SBTs will be mint to target institution’s wallet. These financial service SBTs can be defined as group of basic license elements. If there are licenses have time limit (expire after certain time), or any other dynamically changing permissions, Semi Fungible Tokens could be included as part of SBTs.

For financial license SBT, the government agency (who mint the SBT), should have full control, as I explained in last article.

1. <issuer, other, IC> : Issuer mints SBTs to others, issuer has complete control

A typical license could be like below, a group of basic license elements be granted as one SBT or SBTs.

Authorization and Certificate Token — PlatON concept design

Here control means mint, destroy, and amendment such as expand the valid period. Please consider an expended SBT protocol with owner limited expand valid period method here. Some thing like below ( to be enriched by implementation ):

event Extended(address indexed _owner, address indexed _approved, uint256 indexed _tokenId, uint256 _extendTo);function destroy(address _approved, uint256 _tokenId) public onlyIssuer;function extend(address _approved, uint256 _tokenId, uint256 _extendTo) pubic onlyIssuer;

Institutions with license SBTs, it could construct client service SBT structure

The similar structure could be rallied by institutions. Where they could issue different type of SBTs to indicate

1. customer passed KYC
2. financial service profiling
3. risk profiling level
4. etc

Again, those client service related SBTs have a completely different group of basic service elements. and those elements should be inline with licenses granted. Will take broker trading service as an example to elaborate details.

Authorization and Certificate Token — PlatON concept design

At the end, the implementation is not yet in place, although more than two years passed. Wish there will be community dev team jump in, trigger off discussions and implementations. Also wish there will be feasible better design pops up.

Appendix A financial license basic elements by Singapore MAS Financial Institutions Directory

  1. Banking
Authorization and Certificate Token — PlatON concept design

2.Capital Markets

Authorization and Certificate Token — PlatON concept design

3.Financial Advisory

Authorization and Certificate Token — PlatON concept design


Authorization and Certificate Token — PlatON concept design


Authorization and Certificate Token — PlatON concept design

Appendix B financial service basic elements

  1. Banking services based on MAS Bank Act BA1970
Authorization and Certificate Token — PlatON concept design




Will leave this as home work for business analyzer to come up with development requirements;)

This article is reproduced from

Like (0)
PlatOnWorld-Steven's avatarPlatOnWorld-StevenOfficial
Previous November 4, 2022 14:33
Next November 9, 2022 09:40


Leave a Reply

Please Login to Comment