Authorization and Certiﬁcate 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 efﬁcient and vital by that time. Tribes in the stone age, people needs tight cooperation to ﬁght 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 ﬁrm 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 ﬁnance area is one of them, highly regulated sector due to investor protection, tax revenue, and governance purpose, huge proﬁt generated for the government.

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

This ACT framework was designed for data ﬂow control, where we imagine the ﬁnancial services such as transactions are one kind of simpliﬁed data ﬂow, and that is why we pick up ﬁnancial service sector to start with.

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

Basic license elements

There are different basic elements deﬁned for different ﬁnancial service categories in appendix

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

For each of above basic license elements, there should be a clear deﬁnition of service scope, especially for token related ﬁnancial 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 ﬁat 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 ﬁnancial 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 qualiﬁed 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 certiﬁed institution. First of all, the mandatory SBTs will be veriﬁed, e.g. qualiﬁcation of all mandatory criteria. Once conﬁrmed, based on application and evaluation, one or license SBTs will be mint to target institution’s wallet. These ﬁnancial service SBTs can be deﬁned 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 ﬁnancial 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.

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. ﬁnancial service proﬁling
3. risk proﬁling 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.

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.