4.3.Users Identification Mechanism for entire system
Legal Behavior commands directly dispose book-entry interests, have material commercial and legal consequences, and may also establish relationships with other companies registered in ComBoox. Therefore, the system designs a special smart contract of Reg Center and a series of methods thereof on users' identification, so as to verify the identities of users in the entire system.
“Users” in the platform of ComBoox:
(1)can be shareholders, directors, managers within the Company, or the creditors, delegates, or agents outside of the Company;
(2)can establish a contractual relationship with one company, or establish legal relationships with multiple companies simultaneously;
(3)can be a natural person who controls on-chain behaviors through an external account, or a legal person who exercises its corporate legal rights through a contract account.
Therefore, ComBoox adopts a special smart contract Reg Center to manage all the digital identities of users of the entire platform.
ComBoox only takes the account address as the sole label to identify a user, and does not touch the name, nationality, residence or any other social characters of a natural person or a legal person. Therefore, strictly speaking, it is only the "digital identity" that the system actually manages or verifies.
This "de-identified" identity management model is determined by the technical characteristics of the public blockchain on the one hand, and it is also conducive to protecting users' privacy information on the other.
Nevertheless, almost all countries have real-name requirements like KYC or Anti-Money Laundering for commercial activities such as investment, financing, lending, payment, and foreign exchange etc. So please consult with legal experts of the relevant jurisdictions to seek professional advice on securities laws, anti-money laundering laws and other relevant legal issues so as to ensure all the arrangements and activities can be designed and carried out in a legal way.
With the concept of distributed digital identity, Reg Center uses a special user number mapping to register and manage users' identities, and at the same time, it also provides a query API for all smart contracts of the system to query and verify the users' identity in runtime.
4.3.1.User Number Mapping
User Number Mapping takes a structure as "address => uint(40)", which can be queried via special APIs for a specific account’s user number with the corresponding address.
When users exercise their rights, General Keeper of the relevant company will call the query API of Reg Center to get the user number of the message sender, and then pass the returned value to the specific Sub-Keeper, which will further verify the user’s identity and permissions according to the records of specific Register.
For example, when shareholders exercise voting rights, General Keeper of the company will firstly call Reg Center to query the user number of the message sender, upon receiving the response, General Keeper will pass the returned value of user number along with other input parameters to the General Meeting Minutes Keeper ("GMM Keeper"), and GMM Keeper will further call Register of Members to check whether the user is a member of the company. If the answer is yes, GMM Keeper will continue to execute the rest codes accordingly, otherwise, it will terminate the process and return an error message instead.
4.3.2. User Registration
Before using any write functions of ComBoox, users need to apply for a registration number first (only checking, query or conduct other read operations on the platform of ComBoox does not require registration). Reg Center will assign an unique user number to the applicant as per its account address automatically.
After creating new book-entry system for a company, the creator may call "Create Corp Seal" API of General Keeper to register a specific user number for the company with Reg Center. Reg Center will then assign a user number to the address of the General Keeper, which represents the legal person of the company in ComBoox and can be used to send write commands to exercise rights on behalf of the company concerned. (If creating a new book-entry system by calling the "Create Comp" API of Reg Center, predefined scripts will automatically register a user number for the new company.)
4.3.3. Backup Key
To avoid losing control of user account only because losing private key, ComBoox allows the registered users to set ONE additional account address as "Backup Key" (the account address used in registration process is deemed as "Prime Key"). However, to prevent the circumvention of some contractual obligations like "Lock-Up" or "First Refusal", the system does NOT allow to change the Backup Key or add more keys. Therefore, a user can only have maximum two keys, the "Prime Key" and "Backup Key". The address of "Backup key" can also be recognized by Reg Center as having the same user number as the "Prime Key". Any used account address cannot be used again to register user number or to be set as backup key.
4.3.4. Permission for Query User Number
The query API of Reg Center for retrieving user number is only accessibly for the contract accounts already registered in ComBoox and the user's own account. If the query sender is not the relevant user’s account, a sum of royalty will be charged from the target user’s account to pay to the author account when responding the user’s number. To prevent malicious consuming the user’s royalty, external smart contracts not registered with ComBoox will be blocked in the front end.
Topic: ComBoox: A Blockchain-Based Equity Share Book-Entry Platform (Read 177 times)
4.2. Commands Routing Mechanism within the company
A Register usually allows several SubKeepers to call its write APIs, therefore, it is not economic to rely on Access Control solution to control write permissions among different roles for each of the contracts. Therefore, ComBoox sets up two registration mappings of address in General Keeper to satisfy the routing requirements for Algorithmic Control commands among the book-entry Registers of a company.
There are two special registration mappings of address in the General Keeper, which are used to track and record the addresses of "SubKeepers" and "Registers", and adopt a structure of "sequence number => address" so as to ensure a timely search of the smart contract’s address as per its corresponding sequence number.
When deploying the system, the contract addresses of each SubKeeper and Register will be input into the registration mappings accordingly, thereafter, in runtime, the relevant write API of Register will, before processing the write command received, firstly call General Keeper to query and verify whether the message sender’s address equals to the address of the specific contract registered in the mappings, so as to complete the identity verification for the Algorithmic Control Commands.
For example, the share transfer API of Register of Shares will be called by ROA Keeper when closing a share transfer transaction, and will also be called by SHA Keeper when implementing an Anti-Dilution right. Therefore, Register of Shares cannot rely on the unique role of “Direct Keeper” defined by Access Control to control its write permission, instead, it will query the address mapping of General Keeper to check and verify message sender’s identity, i.e. as long as the account address of the caller can match any one of the two contracts mentioned above, the verification will be passed.
A Register usually allows several SubKeepers to call its write APIs, therefore, it is not economic to rely on Access Control solution to control write permissions among different roles for each of the contracts. Therefore, ComBoox sets up two registration mappings of address in General Keeper to satisfy the routing requirements for Algorithmic Control commands among the book-entry Registers of a company.
There are two special registration mappings of address in the General Keeper, which are used to track and record the addresses of "SubKeepers" and "Registers", and adopt a structure of "sequence number => address" so as to ensure a timely search of the smart contract’s address as per its corresponding sequence number.
Address Mappings in General Keeper
Code:
mapping(uint256 => address) private _books;
mapping(uint256 => address) private _keepers;
When deploying the system, the contract addresses of each SubKeeper and Register will be input into the registration mappings accordingly, thereafter, in runtime, the relevant write API of Register will, before processing the write command received, firstly call General Keeper to query and verify whether the message sender’s address equals to the address of the specific contract registered in the mappings, so as to complete the identity verification for the Algorithmic Control Commands.
For example, the share transfer API of Register of Shares will be called by ROA Keeper when closing a share transfer transaction, and will also be called by SHA Keeper when implementing an Anti-Dilution right. Therefore, Register of Shares cannot rely on the unique role of “Direct Keeper” defined by Access Control to control its write permission, instead, it will query the address mapping of General Keeper to check and verify message sender’s identity, i.e. as long as the account address of the caller can match any one of the two contracts mentioned above, the verification will be passed.
Identity Verification Function for Sub-Keepers
Code:
function isKeeper(address caller) external view returns (bool) {
uint256 len = 10;
while (len > 0) {
if (caller == _keepers[len]) return true;
len--;
}
return false;
}
4. Identification and Access Control
The smooth and safe operation of the system heavily relies on users' access control and routing control of write commands. In other words, for the calling commands which can change the world states ("write commands"), it is vital important to review and verify the identity and authority of the message sender (i.e. the calling account that send out the commands), and at the same time, the smart contract that received the write commands also needs to strictly control their further routing path, i.e. the target contract's address as well as its API to be further called. In brief, by strict controlling the write commands' routing path from two directions of "receiving” and “sending", the information of the whole system can be updated as per the predefined commercial and legal logic.
The write commands in the system can be divided into three categories:
(1)System Configuration: refers to the contracts drafting and system configuration actions triggered by external accounts, which will NOT lead to legal consequences;
(2)Legal Behavior: refers to the share transaction and corporate governance activities triggered by external accounts, which WILL directly lead to legal consequences; and
(3)Algorithmic Control: refers to the write commands sent by Bookkeeper, upon receiving the previous two types of write commands, in accordance with the predefined algorithms of system, in an orderly manner and be able to change the states of other smart contracts like Registers, Shareholders Agreement, or Investment Agreement.
For the above write commands, the system adopts three verification methods as per their different nature of behaviors and scopes of influence.
4.1. Access Control Mechanism on smart contracts' level
For System Configuration and Algorithmic Control, these two types of write commands do not dispose any book-entry interests of the system, and usually only take effects within the scope of the company, therefore, belong to the category of technique activities like system configuration, algorithmic control, and operation maintenance. Therefore, ComBoox adopts a special smart contract of Access Control, which is inheritable and with component attributes, to verify identity of message sender by means of checking their address at the level of each smart contract.
Access Control is a reusable, inheritable, component-based smart contract, which specialized in defining roles grouping and their verification algorithms on the level of smart contract. Each and every smart contracts of the system are all sub-contracts of Access Control, so they all can use the methods and attributes inherited from Access Control to define roles with different write permissions and to verify them accordingly.
Access Control defines two special roles, Owner and Keeper, as well as a predefined role group ---- Attorneys (the admin of which is called as "General Counsel").
4.1.1. Owner
Owner can be initially set by the account deploying the smart contract, which has the authority to create new group of roles and to appoint admin of the group. From commercial and legal view, Owner maps the role of "shareholder" of a company who has the rights to create, propose, review, and voting on approval of the legal documents like contracts, bylaws as well as motions of the General Meeting.
Owner can transfer its role to other accounts, and, will lose its role as Owner thereafter.
Direct Keeper is the only role that cannot be influenced by Owner, which ensures its relative independence with respect to the roles appointment and control rights assignment, so as to check and balance the power of Owner from the perspective of system maintenance or duties independence.
4.1.2. Direct Keeper
Direct Keeper can be initially set by the account deploying of the smart contract, which has special authority to configure system, mapping the role of "Company Secretary" or “Accountants” from the commercial and legal view, the authority design of which reflects the characteristics of “Company Secretary” or “Accountants” who are relatively independent from shareholders and senior executives in system maintenance and assuming independent responsibilities.
Direct Keeper can transfer its role to other accounts, and will lose the role of Direct Keeper thereafter.
All write APIs of SubKeepers are set as only accessible for their Direct Keepers, and after their deployment, General Keeper will be set as the only Direct Keeper of all the SubKeepers. In this way, all the write authorities will be collectively authorized to General Keeper, thus excluding any external accounts or external contracts out of the system interfering with the company's governance activities, and ensuring that the company's book-entry records can operate securely and automatically, without any human interference involved.
The "Direct Keeper" of General Keeper has the following special authorities:
(1)Set and update the registration address for each SubKeeper and Register;
(2)Appoint or remove the "Direct Keeper" for each of the SubKeeper and Register;
(3)Input off-chain "oracle" data (e.g. financial data such as revenue, net profit, etc.) into the system as trigger conditions for exercising certain shareholders rights; and
(4)Set up hash lock for pay-in capital, so as for new share subscribers can automatically obtain their Certificates of Contribution upon paying their capital contribution.
Therefore, the characters of its authority are quite similar to "Company Secretary" or "Chief Accountant".
If Direct Keeper of General Keeper transfers its role to "zero address", then it means the possibility of human interference with the company's book-entry system is completely abandoned, and the system will automatically operate by smart contracts. As a cost, such auto-running system cannot be upgraded with new contract templates, neither can use off-chain data as trigger conditions for special rights (like call option or put option) any more.
4.1.3. General Counsel and Attorneys
General Counsel is the admin of the roles group of Attorneys and has authorities to grant Attorney role to any account addresses.
Attorneys can quit their role as Attorney by calling the "Renouce Role" API, and General Counsel can call the "Abandon Role" API to fire all Attorneys at once.
For two types of smart contracts, Shareholders Agreement and Investment Agreement, only Attorney can call their write APIs to "draft" the contents of the contracts (such as rules and terms of Shareholders Agreement), or the deal's elements for trading shares (such as the subject share, price, amount), as well as the procedural conditions concerned (such as the contractual parties, signing deadline, and closing deadline etc.).
Therefore, after creating a smart contract of Shareholders Agreement or Investment Agreement, the creating shareholder as the "Owner" needs to appoint a "General Counsel" (which can further appoint one or more Attorneys) to “draft” the rest terms of the contents. After drafting, Owner can review and confirm the contract contents and then calls "Lock Contents" API to revoke the appointment for all attorneys at once, and to transfer the role of Owner to "zero address", so that, the contents can no longer be altered manually.
It should be emphasized that if Owner does not transfer its role to "zero address", it still can modify the contract by reappointing other address as "General Counsel" or "Attorneys".
The smooth and safe operation of the system heavily relies on users' access control and routing control of write commands. In other words, for the calling commands which can change the world states ("write commands"), it is vital important to review and verify the identity and authority of the message sender (i.e. the calling account that send out the commands), and at the same time, the smart contract that received the write commands also needs to strictly control their further routing path, i.e. the target contract's address as well as its API to be further called. In brief, by strict controlling the write commands' routing path from two directions of "receiving” and “sending", the information of the whole system can be updated as per the predefined commercial and legal logic.
The write commands in the system can be divided into three categories:
(1)System Configuration: refers to the contracts drafting and system configuration actions triggered by external accounts, which will NOT lead to legal consequences;
(2)Legal Behavior: refers to the share transaction and corporate governance activities triggered by external accounts, which WILL directly lead to legal consequences; and
(3)Algorithmic Control: refers to the write commands sent by Bookkeeper, upon receiving the previous two types of write commands, in accordance with the predefined algorithms of system, in an orderly manner and be able to change the states of other smart contracts like Registers, Shareholders Agreement, or Investment Agreement.
For the above write commands, the system adopts three verification methods as per their different nature of behaviors and scopes of influence.
4.1. Access Control Mechanism on smart contracts' level
For System Configuration and Algorithmic Control, these two types of write commands do not dispose any book-entry interests of the system, and usually only take effects within the scope of the company, therefore, belong to the category of technique activities like system configuration, algorithmic control, and operation maintenance. Therefore, ComBoox adopts a special smart contract of Access Control, which is inheritable and with component attributes, to verify identity of message sender by means of checking their address at the level of each smart contract.
Access Control is a reusable, inheritable, component-based smart contract, which specialized in defining roles grouping and their verification algorithms on the level of smart contract. Each and every smart contracts of the system are all sub-contracts of Access Control, so they all can use the methods and attributes inherited from Access Control to define roles with different write permissions and to verify them accordingly.
Access Control defines two special roles, Owner and Keeper, as well as a predefined role group ---- Attorneys (the admin of which is called as "General Counsel").
Structure of Role and Roles Repo
Code:
struct Role {
address admin;
mapping(address => bool) isMember;
}
struct Repo {
address owner;
uint8 state; // 0-pending; 1-initiated; 2-finalized
mapping(bytes32 => Role) roles;
}
4.1.1. Owner
Owner can be initially set by the account deploying the smart contract, which has the authority to create new group of roles and to appoint admin of the group. From commercial and legal view, Owner maps the role of "shareholder" of a company who has the rights to create, propose, review, and voting on approval of the legal documents like contracts, bylaws as well as motions of the General Meeting.
Owner can transfer its role to other accounts, and, will lose its role as Owner thereafter.
Direct Keeper is the only role that cannot be influenced by Owner, which ensures its relative independence with respect to the roles appointment and control rights assignment, so as to check and balance the power of Owner from the perspective of system maintenance or duties independence.
4.1.2. Direct Keeper
Direct Keeper can be initially set by the account deploying of the smart contract, which has special authority to configure system, mapping the role of "Company Secretary" or “Accountants” from the commercial and legal view, the authority design of which reflects the characteristics of “Company Secretary” or “Accountants” who are relatively independent from shareholders and senior executives in system maintenance and assuming independent responsibilities.
Direct Keeper can transfer its role to other accounts, and will lose the role of Direct Keeper thereafter.
All write APIs of SubKeepers are set as only accessible for their Direct Keepers, and after their deployment, General Keeper will be set as the only Direct Keeper of all the SubKeepers. In this way, all the write authorities will be collectively authorized to General Keeper, thus excluding any external accounts or external contracts out of the system interfering with the company's governance activities, and ensuring that the company's book-entry records can operate securely and automatically, without any human interference involved.
The "Direct Keeper" of General Keeper has the following special authorities:
(1)Set and update the registration address for each SubKeeper and Register;
(2)Appoint or remove the "Direct Keeper" for each of the SubKeeper and Register;
(3)Input off-chain "oracle" data (e.g. financial data such as revenue, net profit, etc.) into the system as trigger conditions for exercising certain shareholders rights; and
(4)Set up hash lock for pay-in capital, so as for new share subscribers can automatically obtain their Certificates of Contribution upon paying their capital contribution.
Therefore, the characters of its authority are quite similar to "Company Secretary" or "Chief Accountant".
If Direct Keeper of General Keeper transfers its role to "zero address", then it means the possibility of human interference with the company's book-entry system is completely abandoned, and the system will automatically operate by smart contracts. As a cost, such auto-running system cannot be upgraded with new contract templates, neither can use off-chain data as trigger conditions for special rights (like call option or put option) any more.
4.1.3. General Counsel and Attorneys
General Counsel is the admin of the roles group of Attorneys and has authorities to grant Attorney role to any account addresses.
Attorneys can quit their role as Attorney by calling the "Renouce Role" API, and General Counsel can call the "Abandon Role" API to fire all Attorneys at once.
For two types of smart contracts, Shareholders Agreement and Investment Agreement, only Attorney can call their write APIs to "draft" the contents of the contracts (such as rules and terms of Shareholders Agreement), or the deal's elements for trading shares (such as the subject share, price, amount), as well as the procedural conditions concerned (such as the contractual parties, signing deadline, and closing deadline etc.).
Therefore, after creating a smart contract of Shareholders Agreement or Investment Agreement, the creating shareholder as the "Owner" needs to appoint a "General Counsel" (which can further appoint one or more Attorneys) to “draft” the rest terms of the contents. After drafting, Owner can review and confirm the contract contents and then calls "Lock Contents" API to revoke the appointment for all attorneys at once, and to transfer the role of Owner to "zero address", so that, the contents can no longer be altered manually.
It should be emphasized that if Owner does not transfer its role to "zero address", it still can modify the contract by reappointing other address as "General Counsel" or "Attorneys".
3.4. Investment Agreement
Investment Agreement dynamically defines all necessary elements of deals for issuing or transferring shares, such as the subject equity shares, price, amounts, buyer's identity, signing deadline, closing deadline, contractual parties and so on.
After an Investment Agreement is properly signed on-chain, the parties can call the relevant API of Bookkeepers to push forward the rest procedures concerning the deals' execution, like General Meeting's reviewing and approving, paying consideration and closing etc. The relevant Bookkeepers will, strictly in line with the rules and terms set out in Shareholders Agreement, automatically verify the caller's identy, check the fulfillment of pre-conditions, and control the transaction's procedure, until realizing the final business purpose ---- updates the Register of Shares.
The nature of Investment Agreement is actually a special script (or, a batch file) consisting of a series of write operation commands to update the book-entry states of the equity shares (i.e. update the Register of Shares), which will be automatically executed in an orderly manner, under the control of the relevant Bookkeepers in line with predefined conditions and procedures set out in the Shareholders Agreement, and will eventually realize the business objectives of updating book-entry states of equity shares, i.e. to realize the legal consequences of issue new shares or transfer existing shares.
If there are any special arrangements stipulated in Shareholders Agreement, such as "First Refusal", "Drag-Along", "Tag-Along", or "Anti-Dilution" etc., the right holders can call the relevant API of Bookkeeper to exercise their rights during the specific exercising period, then, Bookkeeper will automatically change the counter party (for first refusal), add free transaction for gift shares (for anti-dilution), or add new transactions with the same price and conditions (for drag-along or tag-along), in accordance with the algorithm and methods defined in Shareholders Agreement, so as to realize the business purpose thereof.
Inside Investment Agreement, the substantive elements of a share transaction (subject equity, buyer, amount, price, closing deadline, etc.) are defined by a type of structured object, called "Deal"; while, the procedural elements (such as contract parties, signing deadline, closing deadline, etc.) are defined by a reusable and inheritable smart contract component, called "Signature Page".
3.4.1. Deal
The object of Deal defines all necessary factors to issue new shares or transfer existing shares in Register of Shares, which also defines a hash lock in form of bytes32 for parties to arrange off-chain or cross-chain payment for equity consideration.
The share transactions can be categorized into three basic types: “capital increase”, “external transfer”, and “internal transfer” as per the different types of buyer, and, by combinations of these 3 basic types, it can be further deduced into 7 types of deals in total. In Shareholders Agreement, different voting rules can be tailored for each of the said 7 types, so as to satisfy the customized requirements of investors.
3.4.2. Signature Page
Signature page is an independent, reusable and inheritable component smart contract that defines several key attributes of contract’s execution, including contractual parties, signature fields, signing deadline and closing deadline etc..
Investment Agreement defines an initial Signature Page and a supplemental Signature Page, the former is to be signed by the contracting parties during the contract’s formation, while the latter will be automatically filled up by Bookkeeper when the relevant right holders exercise their special rights (such as "First Refusal", "Tag-along, "Drag-along", and "Anti-Dilution" etc.)
When a party calls the API of Bookkeeper to sign an Investment Agreement, Bookkeeper will record the block number and timestamp of the signing action in the signature field, moreover, the signature field also can store a special hash value generated by hashing handwriting signatures or scanned copy of company seal, which can be used to verify digital documents in future.
Investment Agreement dynamically defines all necessary elements of deals for issuing or transferring shares, such as the subject equity shares, price, amounts, buyer's identity, signing deadline, closing deadline, contractual parties and so on.
After an Investment Agreement is properly signed on-chain, the parties can call the relevant API of Bookkeepers to push forward the rest procedures concerning the deals' execution, like General Meeting's reviewing and approving, paying consideration and closing etc. The relevant Bookkeepers will, strictly in line with the rules and terms set out in Shareholders Agreement, automatically verify the caller's identy, check the fulfillment of pre-conditions, and control the transaction's procedure, until realizing the final business purpose ---- updates the Register of Shares.
The nature of Investment Agreement is actually a special script (or, a batch file) consisting of a series of write operation commands to update the book-entry states of the equity shares (i.e. update the Register of Shares), which will be automatically executed in an orderly manner, under the control of the relevant Bookkeepers in line with predefined conditions and procedures set out in the Shareholders Agreement, and will eventually realize the business objectives of updating book-entry states of equity shares, i.e. to realize the legal consequences of issue new shares or transfer existing shares.
If there are any special arrangements stipulated in Shareholders Agreement, such as "First Refusal", "Drag-Along", "Tag-Along", or "Anti-Dilution" etc., the right holders can call the relevant API of Bookkeeper to exercise their rights during the specific exercising period, then, Bookkeeper will automatically change the counter party (for first refusal), add free transaction for gift shares (for anti-dilution), or add new transactions with the same price and conditions (for drag-along or tag-along), in accordance with the algorithm and methods defined in Shareholders Agreement, so as to realize the business purpose thereof.
Inside Investment Agreement, the substantive elements of a share transaction (subject equity, buyer, amount, price, closing deadline, etc.) are defined by a type of structured object, called "Deal"; while, the procedural elements (such as contract parties, signing deadline, closing deadline, etc.) are defined by a reusable and inheritable smart contract component, called "Signature Page".
3.4.1. Deal
The object of Deal defines all necessary factors to issue new shares or transfer existing shares in Register of Shares, which also defines a hash lock in form of bytes32 for parties to arrange off-chain or cross-chain payment for equity consideration.
Structure of Object Deal
Code:
struct Head {
uint8 typeOfDeal;
uint16 seqOfDeal;
uint16 preSeq;
uint16 classOfShare;
uint32 seqOfShare;
uint40 seller;
uint32 priceOfPaid;
uint32 priceOfPar;
uint48 closingDeadline;
uint16 votingWeight;
}
struct Body {
uint40 buyer;
uint40 groupOfBuyer;
uint64 paid;
uint64 par;
uint8 state;
uint16 para;
uint16 argu;
bool flag;
}
struct Deal {
Head head;
Body body;
bytes32 hashLock;
}
The share transactions can be categorized into three basic types: “capital increase”, “external transfer”, and “internal transfer” as per the different types of buyer, and, by combinations of these 3 basic types, it can be further deduced into 7 types of deals in total. In Shareholders Agreement, different voting rules can be tailored for each of the said 7 types, so as to satisfy the customized requirements of investors.
3.4.2. Signature Page
Signature page is an independent, reusable and inheritable component smart contract that defines several key attributes of contract’s execution, including contractual parties, signature fields, signing deadline and closing deadline etc..
Investment Agreement defines an initial Signature Page and a supplemental Signature Page, the former is to be signed by the contracting parties during the contract’s formation, while the latter will be automatically filled up by Bookkeeper when the relevant right holders exercise their special rights (such as "First Refusal", "Tag-along, "Drag-along", and "Anti-Dilution" etc.)
When a party calls the API of Bookkeeper to sign an Investment Agreement, Bookkeeper will record the block number and timestamp of the signing action in the signature field, moreover, the signature field also can store a special hash value generated by hashing handwriting signatures or scanned copy of company seal, which can be used to verify digital documents in future.
Structure of Signature Page
Code:
struct Signature {
uint40 signer;
uint48 sigDate;
uint64 blocknumber;
bool flag;
uint16 para;
uint16 arg;
uint16 seq;
uint16 attr;
uint32 data;
}
struct Blank{
EnumerableSet.UintSet seqOfDeals;
Signature sig;
bytes32 sigHash;
}
struct Page {
// party => Blank
mapping(uint256 => Blank) blanks;
EnumerableSet.UintSet buyers;
EnumerableSet.UintSet sellers;
}
3.3. Shareholders Agreement
Shareholders Agreement is to dynamically define rules and conditions relating to share transaction and corporate governance, which can be deemed as a constitutional document of the company.
When users exercise their rights, Shareholders Agreement will, as per the query request of Bookkeepers, search and obtain specific rules or terms, based on which a specific threshold value, parameter, or testing result will be parsed and reverted, so as for Bookkeepers to conduct further calculation or processing.
For example, when a shareholder casts vote for a motion, the relevant Bookkeeper will call Shareholders Agreement to query the voting period of certain governing voting rule, and then, based on the number of voting days obtained, the motion’s proposal date, as well as the current block timestamp, Bookkeeper will determine whether it is in the voting period.
The detailed terms and rules of Shareholders Agreement are abstractly defined as different data objects and methods according to the legal logic of corporate governance. During the drafting process, different values can be dynamically set to the different attributes, so as to define the different rules of the legal behavior concerned. A draft Shareholders Agreement will become effective upon approval of the general meeting of shareholders.
For example, when setting voting rules for different types of share transaction, a 30-days' review period and a two-thirds voting threshold can be set for capital increase deals, while, a 15-days' review period and a one-half voting threshold can be set for share transfer deals. Thereafter, during the process when a transaction is submitted to the shareholders’ meeting for reviewing and voting, Bookkeeper will calculate and determine the time period and voting results as per the transaction type accordingly.
In the Shareholders Agreement, the rules of corporate governance and share transaction can be categorized into "Rules" and "Terms" according to their respective complexity and governing matters.
3.3.1.Rules
“Rules” are defined in bytes32, which depend on the public library of Rules Parser to parse their key attributes, length of period or key threshold of conditions, so as to transform into structured objects.
Each rule has its own sequence number, so it’s quite easy to set up a mapping from “sequence number” to the bytes32 “rule”.
Currently the rules include following types: General Governance Rules, Voting Rules, Position Allocate Rules, First Refusal Rules, Grouping Update Orders, and Listing Rules.
3.3.2.Terms
"Terms" are defined in form of independent smart contracts, and are relied on structured data objects and their methods to define specific pre-conditions of rights and intermediate parameters algorithm.
Each term has its own sequence number, so it’s quite easy to set up a mapping from “title number” to the “address of term”.
Currently the terms include the following types: Anti Dilution, Lock Up, Drag Along, Tag Along, Put Option and Call Option.
Therefore, Shareholders Agreement can be deemed as a data base comprises of “rules mapping” and “terms mapping”, which is to dynamically define the parameters and attributes of different rules so as to retrieve them in runtime. As for the functions of Rules Parser and Terms, they are to set up models for the rules and terms in line with legal logic, and to abstractly define their core attributes and methods, thereafter, expose certain APIs so as for users to dynamically define various attributes or parameters of those rules and terms accordingly. So that, during runtime, in accordance with user’s commands, specific Bookkeeper may search Shareholders Agreement as per the predefined logic of specific legal behavior, to get specific attribute or parameter of certain rule, and then, to further determine certain condition or to further control certain process.
Shareholders Agreement is to dynamically define rules and conditions relating to share transaction and corporate governance, which can be deemed as a constitutional document of the company.
When users exercise their rights, Shareholders Agreement will, as per the query request of Bookkeepers, search and obtain specific rules or terms, based on which a specific threshold value, parameter, or testing result will be parsed and reverted, so as for Bookkeepers to conduct further calculation or processing.
For example, when a shareholder casts vote for a motion, the relevant Bookkeeper will call Shareholders Agreement to query the voting period of certain governing voting rule, and then, based on the number of voting days obtained, the motion’s proposal date, as well as the current block timestamp, Bookkeeper will determine whether it is in the voting period.
The detailed terms and rules of Shareholders Agreement are abstractly defined as different data objects and methods according to the legal logic of corporate governance. During the drafting process, different values can be dynamically set to the different attributes, so as to define the different rules of the legal behavior concerned. A draft Shareholders Agreement will become effective upon approval of the general meeting of shareholders.
For example, when setting voting rules for different types of share transaction, a 30-days' review period and a two-thirds voting threshold can be set for capital increase deals, while, a 15-days' review period and a one-half voting threshold can be set for share transfer deals. Thereafter, during the process when a transaction is submitted to the shareholders’ meeting for reviewing and voting, Bookkeeper will calculate and determine the time period and voting results as per the transaction type accordingly.
In the Shareholders Agreement, the rules of corporate governance and share transaction can be categorized into "Rules" and "Terms" according to their respective complexity and governing matters.
3.3.1.Rules
“Rules” are defined in bytes32, which depend on the public library of Rules Parser to parse their key attributes, length of period or key threshold of conditions, so as to transform into structured objects.
Structure of Voting Rule
Code:
// Object of VotingRule
struct VotingRule{
uint16 seqOfRule;
uint8 qtyOfSubRule;
uint8 seqOfSubRule;
uint8 authority;
uint16 headRatio;
uint16 amountRatio;
bool onlyAttendance;
bool impliedConsent;
bool partyAsConsent;
bool againstShallBuy;
uint8 frExecDays;
uint8 dtExecDays;
uint8 dtConfirmDays;
uint8 invExitDays;
uint8 votePrepareDays;
uint8 votingDays;
uint8 execDaysForPutOpt;
uint40[2] vetoers;
uint16 para;
}
Function of Voting Rule Parser
Code:
function votingRuleParser(bytes32 sn) public pure returns (VotingRule memory rule)
{
uint _sn = uint(sn);
rule = VotingRule({
seqOfRule: uint16(_sn >> 240),
qtyOfSubRule: uint8(_sn >> 232),
seqOfSubRule: uint8(_sn >> 224),
authority: uint8(_sn >> 216),
headRatio: uint16(_sn >> 200),
amountRatio: uint16(_sn >> 184),
onlyAttendance: uint8(_sn >> 176) == 1,
impliedConsent: uint8(_sn >> 168) == 1,
partyAsConsent: uint8(_sn >> 160) == 1,
againstShallBuy: uint8(_sn >> 152) == 1,
frExecDays: uint8(_sn >> 144),
dtExecDays: uint8(_sn >> 136),
dtConfirmDays: uint8(_sn >> 128),
invExitDays: uint8(_sn >> 120),
votePrepareDays: uint8(_sn >> 112),
votingDays: uint8(_sn >> 104),
execDaysForPutOpt: uint8(_sn >> 96),
vetoers: [uint40(_sn >> 56), uint40(_sn >> 16)],
para: uint16(_sn)
});
}
Each rule has its own sequence number, so it’s quite easy to set up a mapping from “sequence number” to the bytes32 “rule”.
Rules Mapping
Code:
// seq => rule
mapping(uint256 => bytes32) rules;
Currently the rules include following types: General Governance Rules, Voting Rules, Position Allocate Rules, First Refusal Rules, Grouping Update Orders, and Listing Rules.
3.3.2.Terms
"Terms" are defined in form of independent smart contracts, and are relied on structured data objects and their methods to define specific pre-conditions of rights and intermediate parameters algorithm.
Each term has its own sequence number, so it’s quite easy to set up a mapping from “title number” to the “address of term”.
Term Mapping
Code:
// title => body
mapping(uint256 => address) terms;
Currently the terms include the following types: Anti Dilution, Lock Up, Drag Along, Tag Along, Put Option and Call Option.
Therefore, Shareholders Agreement can be deemed as a data base comprises of “rules mapping” and “terms mapping”, which is to dynamically define the parameters and attributes of different rules so as to retrieve them in runtime. As for the functions of Rules Parser and Terms, they are to set up models for the rules and terms in line with legal logic, and to abstractly define their core attributes and methods, thereafter, expose certain APIs so as for users to dynamically define various attributes or parameters of those rules and terms accordingly. So that, during runtime, in accordance with user’s commands, specific Bookkeeper may search Shareholders Agreement as per the predefined logic of specific legal behavior, to get specific attribute or parameter of certain rule, and then, to further determine certain condition or to further control certain process.
Interface of Lock-Up
Code:
interface ILockUp {
struct Locker {
uint48 dueDate;
EnumerableSet.UintSet keyHolders;
}
function setLocker(uint256 seqOfShare, uint dueDate) external;
function delLocker(uint256 seqOfShare) external;
function addKeyholder(uint256 seqOfShare, uint256 keyholder) external;
function removeKeyholder(uint256 seqOfShare, uint256 keyholder) external;
function isLocked(uint256 seqOfShare) external view returns (bool);
function getLocker(uint256 seqOfShare) external view returns (uint48 dueDate, uint256[] memory keyHolders);
function lockedShares() external view returns (uint256[] memory);
function isTriggered(DealsRepo.Deal memory deal) external view returns (bool);
function isExempted(address ia, DealsRepo.Deal memory deal) external view returns (bool);
}
3.2. Bookkeepers
Bookkeepers defined dozens of APIs of legal behaviors regarding corporate governance and share transactions, so as to manage and control the identification of actors, conditions, procedures and legal consequences of the relevant legal behaviors.
3.2.1. Functions of Bookkeepers
When users exercise their rights, Bookkeepers will call Shareholders Agreement and the relevant Registers as per legal logic, so as to check what conditions need to be satisfied to conduct the relevant legal behaviors (or what parameters need to be relied on for the subsequent calculations), and, together with the input parameters obtained from the API, Bookkeepers will make decisions on whether the conditions are fulfilled or calculate the specific values of the intermediate parameters. If all conditions are fulfilled, Bookkeepers will call the relevant Registers to update the states of book-entry interests or record the contents of the legal behaviors, such as expression of intention, or action tracks of the behaviors.
For example, when a shareholder votes on a motion, it needs to call the "Cast Vote" API of General Keeper, input the subject motion number and express its attitude as support, against or abstain, thereafter, General Keeper will call Reg Center to retrieve the user number of shareholder and further call the “Cast Vote” API of General Meeting Minutes Keeper (“GMM Keeper”) so as to hand over the control rights on the subsequent processing steps, and then, GMM Keeper will:
(1)retrieve the motion object from General Meeting Minutes;
(2)retrieve the voting rule from Shareholders Agreement as per the voting rule number specified in the motion object, and deduce the voting period accordingly;
(3)determine whether it is in the voting period as per the current timestamp;
(4)if within the voting period, call the Register of Members to verify whether the voter is a shareholder of the company;
(5)If it is a shareholder, then check the entrust arrangements from the Delegate Map of the motion, and then call the Register of Members again to retrieve and calculate the total voting rights entrusted from the principals as well as represented by the voter;
(6)Finally, store the voting information (user number, voting attitude, total voting rights, voting time, etc.) in the General Meeting Minutes.
From the above example, it can be deduced that Bookkeeper acts as the control center of verifying the conditions precedent and monitoring the logical flows of the legal behaviors.
In order to satisfy the size requirements of EIP-170, ComBoox defines two types of smart contracts, namely, General Keeper and several Sub-Bookkeepers.
3.2.2.General Keeper
General Keeper sits at the uppermost layer of the company book-entry system and has the following functions:
(1)Acts as the only entry of the company's book-entry system for write operation commands and is responsible for routing write commands to specific Sub-Bookkeeper;
(2)Acts as the address registration center for Registers, and responses the address of specific Register as per its sequence number;
(3)Represents the legal entity of the company and conducts legal behaviors on behalf the company on-chain, e.g. signing or executing smart contracts, making payments in tokens, exercising voting rights, etc;
(4)Represents the company to hold cryptocurrencies such as ETH and CBP etc., and makes payments in accordance with the resolutions of General Meeting of Members or Board of Directors;
(5)Temporarily keeps ETH consideration incurred from share transfer transactions, which can be picked up by the seller to its public key account thereafter.
3.2.3.Sub-Bookkeepers
Sub-Bookkeepers are the core computation layer controlling the identity verification, conditions, procedures and legal consequences of legal behaviors, which includes:
(1)Register of Constitutions Keeper ("ROC Keeper"): has write permissions to Register of Agreements, and controls the legal behaviors of creating, circulating, signing, enactivating, and accepting Shareholders Agreements;
(2) Register of Directors Keeper ("ROD Keeper"): has write permissions to Register of Directors, and controls the legal behaviors of inauguration, dismissal, and resignation of directors or executive officers;
(3) Board Meeting Minutes Keeper ("BMM Keeper"): has write permissions to Board Meeting Minutes, and controls the legal behaviors of creating and proposing board motions, appointing voting delegate, casting vote, counting of vote results, and executing actions. The motions concerned include the appointing and removing managers, reviewing contracts, paying tokens, and calling on-chain smart contracts;
(4) Register of Members Keeper ("ROM Keeper"): has write permissions to Register of Shares and Register of Members, and controls the legal behaviors of setting the maximum number of shareholders, setting hash locks on paid-in shares, releasing and withdrawing paid-in shares, and decreasing registered capital;
(5) General Meeting Minutes Keeper ("GMM Keeper"): has write permissions to General Meeting Minutes, and controls the legal behaviors of creating and proposing motions, appointing voting delegate, casting votes, counting vote results, and executing resolutions. The motions include nominating and removing directors, reviewing contracts, paying tokens and calling smart contracts;
(6) Register of Agreements Keeper ("ROA Keeper"): has write permissions to Register of Agreements and Register of Shares, and controls the legal behaviors of creation, circulation, and signing of Investment Agreements, as well as locking the subject equity, releasing and withdrawing the subject equity, issuing new shares, transferring share, terminating transaction, and paying consideration;
(7) Register of Options Keeper ("ROO Keeper"): has write permissions to Register of Options and Register of Shares, and controls the legal behaviors of inputting trigger events, exercising options, setting option’s pledge, paying off option, executing option’s pledge, requesting the against member to buy, paying consideration for the rejected deal’s equity shares, and executing the against member's pledge;
(
Register of Pledges Keeper ("ROP Keeper"): has write permissions to Register of Pledges, Register of Shares, and Register of Agreements, and controls the legal behaviors of refunding debts, extending secured period, creating, transferring, executing, locking, releasing, withdrawing and revoking pledges;
(9) Shareholders Agreement Keeper ("SHA Keeper"): has write permissions to Register of Shares and Register of Agreements, and controls the legal behaviors of exercising and accepting special shareholders' rights like Drag-Along, Tag-Along, Anti-Dilution and First Refusal;
(10) List of Orders Keeper ("LOO Keeper"): has write permissions to List of Orders, Register of Shares, and Register of Members, and controls legal behaviors of registering, approving and revoking accredited investors, listing and withdrawing initial offers, sell orders, and placing buy orders;
Bookkeepers defined dozens of APIs of legal behaviors regarding corporate governance and share transactions, so as to manage and control the identification of actors, conditions, procedures and legal consequences of the relevant legal behaviors.
3.2.1. Functions of Bookkeepers
When users exercise their rights, Bookkeepers will call Shareholders Agreement and the relevant Registers as per legal logic, so as to check what conditions need to be satisfied to conduct the relevant legal behaviors (or what parameters need to be relied on for the subsequent calculations), and, together with the input parameters obtained from the API, Bookkeepers will make decisions on whether the conditions are fulfilled or calculate the specific values of the intermediate parameters. If all conditions are fulfilled, Bookkeepers will call the relevant Registers to update the states of book-entry interests or record the contents of the legal behaviors, such as expression of intention, or action tracks of the behaviors.
For example, when a shareholder votes on a motion, it needs to call the "Cast Vote" API of General Keeper, input the subject motion number and express its attitude as support, against or abstain, thereafter, General Keeper will call Reg Center to retrieve the user number of shareholder and further call the “Cast Vote” API of General Meeting Minutes Keeper (“GMM Keeper”) so as to hand over the control rights on the subsequent processing steps, and then, GMM Keeper will:
(1)retrieve the motion object from General Meeting Minutes;
(2)retrieve the voting rule from Shareholders Agreement as per the voting rule number specified in the motion object, and deduce the voting period accordingly;
(3)determine whether it is in the voting period as per the current timestamp;
(4)if within the voting period, call the Register of Members to verify whether the voter is a shareholder of the company;
(5)If it is a shareholder, then check the entrust arrangements from the Delegate Map of the motion, and then call the Register of Members again to retrieve and calculate the total voting rights entrusted from the principals as well as represented by the voter;
(6)Finally, store the voting information (user number, voting attitude, total voting rights, voting time, etc.) in the General Meeting Minutes.
From the above example, it can be deduced that Bookkeeper acts as the control center of verifying the conditions precedent and monitoring the logical flows of the legal behaviors.
In order to satisfy the size requirements of EIP-170, ComBoox defines two types of smart contracts, namely, General Keeper and several Sub-Bookkeepers.
3.2.2.General Keeper
General Keeper sits at the uppermost layer of the company book-entry system and has the following functions:
(1)Acts as the only entry of the company's book-entry system for write operation commands and is responsible for routing write commands to specific Sub-Bookkeeper;
(2)Acts as the address registration center for Registers, and responses the address of specific Register as per its sequence number;
(3)Represents the legal entity of the company and conducts legal behaviors on behalf the company on-chain, e.g. signing or executing smart contracts, making payments in tokens, exercising voting rights, etc;
(4)Represents the company to hold cryptocurrencies such as ETH and CBP etc., and makes payments in accordance with the resolutions of General Meeting of Members or Board of Directors;
(5)Temporarily keeps ETH consideration incurred from share transfer transactions, which can be picked up by the seller to its public key account thereafter.
3.2.3.Sub-Bookkeepers
Sub-Bookkeepers are the core computation layer controlling the identity verification, conditions, procedures and legal consequences of legal behaviors, which includes:
(1)Register of Constitutions Keeper ("ROC Keeper"): has write permissions to Register of Agreements, and controls the legal behaviors of creating, circulating, signing, enactivating, and accepting Shareholders Agreements;
ROC Keeper API
Code:
function createSHA(uint version, uint caller) external;
function circulateSHA(address body, bytes32 docUrl, bytes32 docHash, uint caller) external;
function signSHA(address sha, bytes32 sigHash, uint caller) external;
function activateSHA(address body, uint caller) external;
function acceptSHA(bytes32 sigHash, uint caller) external;
(2) Register of Directors Keeper ("ROD Keeper"): has write permissions to Register of Directors, and controls the legal behaviors of inauguration, dismissal, and resignation of directors or executive officers;
ROD Keeper API
Code:
function takeSeat(uint256 seqOfMotion, uint256 seqOfPos, uint caller) external;
function removeDirector (uint256 seqOfMotion, uint256 seqOfPos, uint caller) external;
function takePosition(uint256 seqOfMotion, uint256 seqOfPos, uint caller) external;
function removeOfficer (uint256 seqOfMotion, uint256 seqOfPos, uint caller) external;
function quitPosition(uint256 seqOfPos, uint caller) external;
(3) Board Meeting Minutes Keeper ("BMM Keeper"): has write permissions to Board Meeting Minutes, and controls the legal behaviors of creating and proposing board motions, appointing voting delegate, casting vote, counting of vote results, and executing actions. The motions concerned include the appointing and removing managers, reviewing contracts, paying tokens, and calling on-chain smart contracts;
BMM Keeper API
Code:
function nominateOfficer(uint256 seqOfPos, uint candidate, uint nominator) external;
function createMotionToRemoveOfficer(uint256 seqOfPos, uint nominator) external;
function createMotionToApproveDoc(uint doc, uint seqOfVR, uint executor, uint proposer) external;
function proposeToTransferFund(
address to, bool isCBP, uint amt,
uint expireDate, uint seqOfVR, uint executor, uint proposer
) external;
function createAction(
uint seqOfVR, address[] memory targets, uint256[] memory values,
bytes[] memory params, bytes32 desHash, uint executor, uint proposer
) external;
function entrustDelegaterForBoardMeeting(uint256 seqOfMotion, uint delegate, uint caller) external;
function proposeMotionToBoard (uint seqOfMotion, uint caller) external;
function castVote(uint256 seqOfMotion, uint attitude, bytes32 sigHash, uint caller) external;
function voteCounting(uint256 seqOfMotion) external;
function transferFund(
address to, bool isCBP, uint amt,
uint expireDate, uint seqOfMotion, uint caller
) external;
function execAction(
uint typeOfAction, address[] memory targets, uint256[] memory values,
bytes[] memory params, bytes32 desHash, uint256 seqOfMotion
uint caller
) external;
(4) Register of Members Keeper ("ROM Keeper"): has write permissions to Register of Shares and Register of Members, and controls the legal behaviors of setting the maximum number of shareholders, setting hash locks on paid-in shares, releasing and withdrawing paid-in shares, and decreasing registered capital;
ROM Keeper API
Code:
function setMaxQtyOfMembers(uint max) external;
function setPayInAmt(
uint seqOfShare,
uint amt,
uint expireDate,
bytes32 hashLock
) external;
function requestPaidInCapital(bytes32 hashLock, string memory hashKey) external;
function withdrawPayInAmt(bytes32 hashLock, uint seqOfShare) external;
function payInCapital(uint seqOfShare, uint amt, uint caller) external payable;
function decreaseCapital(uint256 seqOfShare, uint paid, uint par) external;
function updatePaidInDeadline(uint256 seqOfShare, uint line) external;
(5) General Meeting Minutes Keeper ("GMM Keeper"): has write permissions to General Meeting Minutes, and controls the legal behaviors of creating and proposing motions, appointing voting delegate, casting votes, counting vote results, and executing resolutions. The motions include nominating and removing directors, reviewing contracts, paying tokens and calling smart contracts;
GMM Keeper API
Code:
function nominateDirector(uint256 seqOfPos, uint candidate, uint nominator) external;
function createMotionToRemoveDirector(uint256 seqOfPos, uint caller) external;
function proposeDocOfGM(
uint doc, uint seqOfVR, uint executor, uint proposer
) external;
function proposeToDistributeProfits(
uint amt, uint expireDate, uint seqOfVR, uint executor, uint caller
) external;
function proposeToTransferFund(
address to, bool isCBP, uint amt, uint expireDate,
uint seqOfVR, uint executor, uint proposer
) external;
function createActionOfGM(
uint seqOfVR, address[] memory targets, uint256[] memory values,
bytes[] memory params, bytes32 desHash, uint executor, uint proposer
) external;
function entrustDelegaterForGeneralMeeting(uint256 seqOfMotion, uint delegate, uint caller) external;
function proposeMotionToGeneralMeeting(uint256 seqOfMotion, uint caller) external;
function castVoteOfGM(
uint256 seqOfMotion, uint attitude, bytes32 sigHash, uint caller
) external;
function voteCountingOfGM(uint256 seqOfMotion) external;
function distributeProfits(uint amt, uint expireDate, uint seqOfMotion, uint caller) external;
function transferFund(
address to, bool isCBP, uint amt,
uint expireDate, uint seqOfMotion, uint caller
) external;
function execActionOfGM(
uint seqOfVR, address[] memory targets, uint256[] memory values,
bytes[] memory params, bytes32 desHash, uint256 seqOfMotion, uint caller
) external returns(uint);
(6) Register of Agreements Keeper ("ROA Keeper"): has write permissions to Register of Agreements and Register of Shares, and controls the legal behaviors of creation, circulation, and signing of Investment Agreements, as well as locking the subject equity, releasing and withdrawing the subject equity, issuing new shares, transferring share, terminating transaction, and paying consideration;
ROA Keeper API
Code:
function createIA(uint256 version, address primeKeyOfCaller, uint caller) external;
function circulateIA(address ia, bytes32 docUrl, bytes32 docHash, uint256 caller) external;
function signIA(address ia, uint256 caller, bytes32 sigHash) external;
function pushToCoffer(
address ia,
uint256 seqOfDeal,
bytes32 hashLock,
uint closingDeadline,
uint256 caller
) external;
function closeDeal(address ia, uint256 seqOfDeal, string memory hashKey) external;
function transferTargetShare(address ia, uint256 seqOfDeal, uint256 caller) external;
function issueNewShare(address ia, uint256 seqOfDeal, uint caller) external;
function terminateDeal(address ia, uint256 seqOfDeal, uint256 caller) external;
function payOffApprovedDeal(address ia, uint seqOfDeal, uint msgValue, uint caller) external;
(7) Register of Options Keeper ("ROO Keeper"): has write permissions to Register of Options and Register of Shares, and controls the legal behaviors of inputting trigger events, exercising options, setting option’s pledge, paying off option, executing option’s pledge, requesting the against member to buy, paying consideration for the rejected deal’s equity shares, and executing the against member's pledge;
ROO Keeper API
Code:
function updateOracle(uint256 seqOfOpt, uint d1, uint d2, uint d3) external;
function execOption(uint256 seqOfOpt, uint caller) external;
function createSwap(
uint256 seqOfOpt,
uint seqOfTarget,
uint paidOfTarget,
uint seqOfPledge,
uint caller
) external;
function payOffSwap(uint256 seqOfOpt, uint256 seqOfSwap, uint caller) external payable;
function terminateSwap(uint256 seqOfOpt, uint256 seqOfSwap, uint caller) external;
function requestToBuy(
address ia,
uint seqOfDeal,
uint paidOfTarget,
uint seqOfPledge,
uint caller
) external;
function payOffRejectedDeal(
address ia,
uint seqOfDeal,
uint seqOfSwap,
uint caller
) external payable;
function pickupPledgedShare(
address ia,
uint seqOfDeal,
uint seqOfSwap,
uint caller
) external;
(
Register of Pledges Keeper ("ROP Keeper"): has write permissions to Register of Pledges, Register of Shares, and Register of Agreements, and controls the legal behaviors of refunding debts, extending secured period, creating, transferring, executing, locking, releasing, withdrawing and revoking pledges;ROP Keeper API
Code:
function createPledge(
bytes32 snOfPld,
uint paid,
uint par,
uint guaranteedAmt,
uint execDays,
uint caller
) external;
function transferPledge(
uint256 seqOfShare,
uint256 seqOfPld,
uint buyer,
uint amt,
uint caller
) external;
function refundDebt(uint256 seqOfShare, uint256 seqOfPld, uint amt, uint caller) external;
function extendPledge(uint256 seqOfShare, uint256 seqOfPld, uint extDays, uint caller) external;
function lockPledge(uint256 seqOfShare, uint256 seqOfPld, bytes32 hashLock, uint caller) external;
function releasePledge(
uint256 seqOfShare,
uint256 seqOfPld,
string memory hashKey,
uint caller
) external;
function execPledge(
bytes32 snOfDeal,
uint256 seqOfPld,
uint version,
uint buyer,
uint groupOfBuyer,
uint caller
) external;
function revokePledge(uint256 seqOfShare, uint256 seqOfPld, uint caller) external;
(9) Shareholders Agreement Keeper ("SHA Keeper"): has write permissions to Register of Shares and Register of Agreements, and controls the legal behaviors of exercising and accepting special shareholders' rights like Drag-Along, Tag-Along, Anti-Dilution and First Refusal;
SHA Keeper API
Code:
function execAlongRight(
address ia,
uint256 seqOfDeal,
uint256 seqOfShare,
uint paid,
uint par,
uint caller,
bytes32 sigHash
) external;
function acceptAlongDeal(
address ia,
uint256 seqOfDeal,
uint caller,
bytes32 sigHash
) external;
function execAntiDilution(
address ia,
uint256 seqOfDeal,
uint256 seqOfShare,
uint caller,
bytes32 sigHash
) external;
function takeGiftShares(address ia, uint256 seqOfDeal, uint caller) external;
function execFirstRefusal(
uint256 seqOfRule,
uint256 seqOfRightholder,
address ia,
uint256 seqOfDeal,
uint caller,
bytes32 sigHash
) external;
function computeFirstRefusal(address ia, uint256 seqOfDeal, uint caller) external;
(10) List of Orders Keeper ("LOO Keeper"): has write permissions to List of Orders, Register of Shares, and Register of Members, and controls legal behaviors of registering, approving and revoking accredited investors, listing and withdrawing initial offers, sell orders, and placing buy orders;
LOO Keeper API
Code:
function regInvestor(uint userNo, uint groupRep, bytes32 idHash) external;
function approveInvestor(uint caller, uint caller, uint seqOfLR) external;
function revokeInvestor(uint caller, uint caller, uint seqOfLR) external;
function placeInitialOffer(
uint caller, uint classOfShare, uint execHours,
uint paid, uint price, uint seqOfLR
) external;
function withdrawInitialOffer(
uint caller, uint classOfShare, uint seqOfOrder, uint seqOfLR
) external;
function placeSellOrder(
uint caller, uint seqOfClass, uint execHours, uint paid,
uint price, uint seqOfLR, bool sortFromHead
) external;
function withdrawSellOrder(uint caller, uint classOfShare, uint seqOfOrder) external;
function placeBuyOrder(uint caller, uint classOfShare, uint paid, uint price) external payable;
(2)Register of Directors ("ROD"): records all information about the positions of directors or managers with respect to their candidate’s user number, nominator, the voting rules applied for election, the start and end date of tenure etc., so as to enable users or smart contracts to search or verify the identity, authorities or duties of executive officers;
(3) Board Meeting Minutes ("BMM"): records all the motions submitted to the Board of Directors for approval with respect to their proposer, proposal date, start and end time of voting, voting results, delegate arrangements, executor, execution status, etc, so as to enable users or smart contracts to check or verify the motions of Board;
(4)Register of Members ("ROM"): records all information about members or shareholders with respect to their equity shares, voting rights, amount of subscribed / paid-in / clean capital (i.e. capital contribution with no pledges, transfer arrangements or other legal encumbrances), so as to enable users or smart contracts to check or verify the shareholding status of a member;
(5) General Meeting Minutes ("GMM"): records all the motions submitted to the General Meeting of Shareholders for approval with respect to their proposer, proposal time, voting start and end time, voting results, delegate arrangements, executor, execution state, etc, so as to enable users or smart contracts to check or verify the relevant information of the motion submitted to General Meeting of Members;
(6) Register of Agreements ("ROA"): records all the Investment Agreements with respect to their address, status, transaction type and detailed arrangements, parties, procedural schedules for exercising special rights, so as to enable users or smart contracts to check and retrieve the relevant Investment Agreements, and, to enable the parties concerned to execute the deals under these Investment Agreements. Moreover, ROA also can mock the transaction results and calculate the ultimate controller of the company after closing of the deals concerned, so as to anticipate whether the conditions of drag-along or tag-along will be triggered (i.e. change of controlling power);
(7) Register of Options ("ROO"): record all information of (call / put) options with respect to their right holders, obligors, execution period, closing period, trigger conditions, exercise price, class and amount of the subject equity, etc;
（8） Register of Pledges ("ROP"): record all pledges attached to the equity shares with respect to their creditor, debtor, pledgor, pledged amount, guaranteed amount, debt expiration date, guarantee period etc.;
(9) Register of Shares ("ROS"): record all equity shares issued by the company with respect to their shareholders, class, voting weight, issue date, paid-in deadline / date, par value, paid-in amount, issue price and so on;
(10) List of Orders ("LOO"): record all information about listing trade of shares with respect to the subject shares class, sequence number, investors, limited sell orders, limited buy orders, and deals closed etc.
Structure of Object Position
Code:
struct Position {
uint16 title;
uint16 seqOfPos;
uint40 acct;
uint40 nominator;
uint48 startDate;
uint48 endDate;
uint16 seqOfVR;
uint16 titleOfNominator;
uint16 argu;
}
(3) Board Meeting Minutes ("BMM"): records all the motions submitted to the Board of Directors for approval with respect to their proposer, proposal date, start and end time of voting, voting results, delegate arrangements, executor, execution status, etc, so as to enable users or smart contracts to check or verify the motions of Board;
Structure of Object Motion
Code:
struct Head {
uint16 typeOfMotion;
uint64 seqOfMotion;
uint16 seqOfVR;
uint40 creator;
uint40 executor;
uint48 createDate;
uint32 data;
}
struct Body {
uint40 proposer;
uint48 proposeDate;
uint48 shareRegDate;
uint48 voteStartDate;
uint48 voteEndDate;
uint16 para;
uint8 state;
}
struct Motion {
Head head;
Body body;
RulesParser.VotingRule votingRule;
uint contents;
}
(4)Register of Members ("ROM"): records all information about members or shareholders with respect to their equity shares, voting rights, amount of subscribed / paid-in / clean capital (i.e. capital contribution with no pledges, transfer arrangements or other legal encumbrances), so as to enable users or smart contracts to check or verify the shareholding status of a member;
Structure of Object Member
Code:
struct Head {
uint16 typeOfMotion;
uint64 seqOfMotion;
uint16 seqOfVR;
uint40 creator;
uint40 executor;
uint48 createDate;
uint32 data;
}
struct Body {
uint40 proposer;
uint48 proposeDate;
uint48 shareRegDate;
uint48 voteStartDate;
uint48 voteEndDate;
uint16 para;
uint8 state;
}
struct Motion {
Head head;
Body body;
RulesParser.VotingRule votingRule;
uint contents;
}
(5) General Meeting Minutes ("GMM"): records all the motions submitted to the General Meeting of Shareholders for approval with respect to their proposer, proposal time, voting start and end time, voting results, delegate arrangements, executor, execution state, etc, so as to enable users or smart contracts to check or verify the relevant information of the motion submitted to General Meeting of Members;
(6) Register of Agreements ("ROA"): records all the Investment Agreements with respect to their address, status, transaction type and detailed arrangements, parties, procedural schedules for exercising special rights, so as to enable users or smart contracts to check and retrieve the relevant Investment Agreements, and, to enable the parties concerned to execute the deals under these Investment Agreements. Moreover, ROA also can mock the transaction results and calculate the ultimate controller of the company after closing of the deals concerned, so as to anticipate whether the conditions of drag-along or tag-along will be triggered (i.e. change of controlling power);
(7) Register of Options ("ROO"): record all information of (call / put) options with respect to their right holders, obligors, execution period, closing period, trigger conditions, exercise price, class and amount of the subject equity, etc;
Structure of Object Option
Code:
struct Cond {
uint32 seqOfCond;
uint8 logicOpr;
uint8 compOpr1;
uint64 para1;
uint8 compOpr2;
uint64 para2;
uint8 compOpr3;
uint64 para3;
}
struct Head {
uint32 seqOfOpt;
uint8 typeOfOpt;
uint16 classOfShare;
uint32 rate;
uint48 issueDate;
uint48 triggerDate;
uint16 execDays;
uint16 closingDays;
uint40 obligor;
}
struct Body {
uint48 closingDeadline;
uint40 rightholder;
uint64 paid;
uint64 par;
uint8 state;
uint16 para;
uint16 argu;
}
struct Option {
Head head;
Cond cond;
Body body;
}
（8） Register of Pledges ("ROP"): record all pledges attached to the equity shares with respect to their creditor, debtor, pledgor, pledged amount, guaranteed amount, debt expiration date, guarantee period etc.;
Structure of Object Pledge
Code:
struct Head {
uint32 seqOfShare;
uint16 seqOfPld;
uint48 createDate;
uint16 daysToMaturity;
uint16 guaranteeDays;
uint40 creditor;
uint40 debtor;
uint40 pledgor;
uint8 state;
}
struct Body {
uint64 paid;
uint64 par;
uint64 guaranteedAmt;
uint16 preSeq;
uint16 execDays;
uint16 para;
uint16 argu;
}
struct Pledge {
Head head;
Body body;
bytes32 hashLock;
}
(9) Register of Shares ("ROS"): record all equity shares issued by the company with respect to their shareholders, class, voting weight, issue date, paid-in deadline / date, par value, paid-in amount, issue price and so on;
Structure of Share
Code:
struct Head {
uint16 class;
uint32 seqOfShare;
uint32 preSeq;
uint48 issueDate;
uint40 shareholder;
uint32 priceOfPaid;
uint32 priceOfPar;
uint16 votingWeight;
uint8 argu;
}
struct Body {
uint48 payInDeadline;
uint64 paid;
uint64 par;
uint64 cleanPaid;
uint8 state;
uint8 para;
}
struct Share {
Head head;
Body body;
}
(10) List of Orders ("LOO"): record all information about listing trade of shares with respect to the subject shares class, sequence number, investors, limited sell orders, limited buy orders, and deals closed etc.
Structure of Sell Order
Code:
struct Node {
uint32 prev;
uint32 next;
uint32 seqOfShare;
uint64 paid;
uint32 price;
uint48 expireDate;
uint16 votingWeight;
}
3.1.2.Types of Registers
Based on the types of information recorded, Registers can be divided into two basic categories: Registers of book-entry interests and Registers of governance records, which includes:
(1) Register of Constitutions ("ROC"): records all editions of Shareholders Agreements with respect to their address, legal force status, procedural schedules for creation, review and voting etc., so as to enable users or smart contracts to retrieve or check the currently valid version of Shareholders Agreement, as well as all its historical revoked versions;
Based on the types of information recorded, Registers can be divided into two basic categories: Registers of book-entry interests and Registers of governance records, which includes:
(1) Register of Constitutions ("ROC"): records all editions of Shareholders Agreements with respect to their address, legal force status, procedural schedules for creation, review and voting etc., so as to enable users or smart contracts to retrieve or check the currently valid version of Shareholders Agreement, as well as all its historical revoked versions;
Structure of Object File
Code:
struct Head {
uint48 circulateDate;
uint8 signingDays;
uint8 closingDays;
uint16 seqOfVR;
uint8 frExecDays;
uint8 dtExecDays;
uint8 dtConfirmDays;
uint48 proposeDate;
uint8 invExitDays;
uint8 votePrepareDays;
uint8 votingDays;
uint8 execDaysForPutOpt;
uint64 seqOfMotion;
uint8 state;
}
struct Ref {
bytes32 docUrl;
bytes32 docHash;
}
struct File {
bytes32 snOfDoc;
Head head;
Ref ref;
}
struct Repo {
mapping(address => File) files;
EnumerableSet.AddressSet filesList;
}
3. System Architecture
ComBoox consists of four major types of smart contracts: Registers, Bookkeepers, Shareholders Agreements and Investment Agreements.
https://i.ibb.co/BKwnzND/Sys-Architecture.png
3.1.Registers
Registers defined registration books to record the various book-entry interests (such as equities, pledges, options) or corporate governance documents (such as general meeting minutes and board meeting minutes). The core functions of which are to define the attributes composition of various bookkeeping objects, and the data structure, parameter and logical verification algorithm thereof, as well as the basic methods and APIs for adding, deleting, modifying and querying these objects.
3.1.1.Functions of Registers
When users exercise their rights:
(1) In accordance with the calling commands sent or routed from Bookkeepers, Registers will retrieve and provide specific states of book-entry interests or historical records of legal behaviors;
(2) Based on the above feedback, Bookkeepers will verify or determine whether the conditions for exercising certain rights are fulfilled, or calculates values of the relevant parameters concerned; and
(3) Bookkeepers will call specific Register to update the states of specific book-entry interests, or store the contents, consequences or historical records of the legal behaviors concerned.
For example, when a director takes his/her seat, he/she needs to call the "Take Seat" API of General Keeper, inputting the shareholders meeting resolution's sequence number which approved him/her to be director and the position number of the director, and then:
(1) General Keeper will query and obtain the user number of the message sender account, and call the “Take Seat” API of Register of Directors Keeper (“ROD Keeper”) so as to process the subsequent actions thereof;
(2) ROD Keeper will firstly call the General Meeting Minutes (“GMM”) to verify: whether the type of motion is to elect director and whether the motion has been approved;
(3) If the type and approval status of the motion are all verified, ROD Keeper will further call the GMM to verify whether the user number of the message sender is equal to the candidate’s number as defined in the position’s description of the motion of nomination, if yes, then update the state of the motion into "executed";
(4) If the message sender's identity is verified, ROD Keeper will call Register of Directors (“ROD”) to record the user number, timestamp, as well as the block number concerned, so as to complete the entire process of “Taking Position”.
https://i.ibb.co/Bq2c90Q/Director-Take-Position.jpg
In the above process, GMM and ROD are the two types of Registers. GMM provides the motion’s type and its voting results by answering the query request of ROD Keeper, so as to determine whether the conditions for exercising the rights has been fulfilled, thereafter, verifies the caller's identity against the user number of the motion's candidate. Then, ROD Keeper write the user number, date and block number of inauguration into ROD, so as to write down the action records of "inauguration".
ComBoox consists of four major types of smart contracts: Registers, Bookkeepers, Shareholders Agreements and Investment Agreements.
https://i.ibb.co/BKwnzND/Sys-Architecture.png
3.1.Registers
Registers defined registration books to record the various book-entry interests (such as equities, pledges, options) or corporate governance documents (such as general meeting minutes and board meeting minutes). The core functions of which are to define the attributes composition of various bookkeeping objects, and the data structure, parameter and logical verification algorithm thereof, as well as the basic methods and APIs for adding, deleting, modifying and querying these objects.
3.1.1.Functions of Registers
When users exercise their rights:
(1) In accordance with the calling commands sent or routed from Bookkeepers, Registers will retrieve and provide specific states of book-entry interests or historical records of legal behaviors;
(2) Based on the above feedback, Bookkeepers will verify or determine whether the conditions for exercising certain rights are fulfilled, or calculates values of the relevant parameters concerned; and
(3) Bookkeepers will call specific Register to update the states of specific book-entry interests, or store the contents, consequences or historical records of the legal behaviors concerned.
For example, when a director takes his/her seat, he/she needs to call the "Take Seat" API of General Keeper, inputting the shareholders meeting resolution's sequence number which approved him/her to be director and the position number of the director, and then:
(1) General Keeper will query and obtain the user number of the message sender account, and call the “Take Seat” API of Register of Directors Keeper (“ROD Keeper”) so as to process the subsequent actions thereof;
(2) ROD Keeper will firstly call the General Meeting Minutes (“GMM”) to verify: whether the type of motion is to elect director and whether the motion has been approved;
(3) If the type and approval status of the motion are all verified, ROD Keeper will further call the GMM to verify whether the user number of the message sender is equal to the candidate’s number as defined in the position’s description of the motion of nomination, if yes, then update the state of the motion into "executed";
(4) If the message sender's identity is verified, ROD Keeper will call Register of Directors (“ROD”) to record the user number, timestamp, as well as the block number concerned, so as to complete the entire process of “Taking Position”.
https://i.ibb.co/Bq2c90Q/Director-Take-Position.jpg
In the above process, GMM and ROD are the two types of Registers. GMM provides the motion’s type and its voting results by answering the query request of ROD Keeper, so as to determine whether the conditions for exercising the rights has been fulfilled, thereafter, verifies the caller's identity against the user number of the motion's candidate. Then, ROD Keeper write the user number, date and block number of inauguration into ROD, so as to write down the action records of "inauguration".
2.Computational Control Model
ComBoox adopts the "state machine model" to simulate and control the share transactions and corporate governance activities, specifically:
2.1.State
Information contents of the book-entry registers at each moment are deemed as different states, which will be stored in the smart contracts of Registers (such as Register of Shares, Register of Members and Meeting Minutes etc.).
2.2.Transition Process
Share transactions, corporate governance behaviors and other relevant legal actions are considered as the transition process between different states of the book-entry Registers, and which will be defined and controlled by the smart contracts of Bookkeepers with respect to the subject’s identity, action process, terms and conditions, as well as legal consequences thereof.
https://i.ibb.co/WWkXF39/States-Transition.png
2.3.Conditions and process
The corporate governance rules (such as voting rules, nomination rules and other rules stipulated in the bylaws or other similar company constitutional documents), as well as the shareholders' special rights (such as First Refusal, Tag-Along and Drag Along, Anti-Dilution, Put Option and Call Option etc.) are deemed as rules, conditions and procedures to be followed in the transition process between the different states, which will be defined by the smart contract of Shareholders Agreement with respect to values of attributes, duration or determination thresholds for the said rules or rights. In runtime, Shareholders Agreement will timely answer the queries sent from Bookkeepers so as to provide parameters to automatically control the execution process of the legal behaviors concerned.
2.4.Write Operation Scripts
Investment Agreement can be deemed as a special script or batch file consisting of a series of write operation commands to cause the states transition of Register of Shares. And, the transaction factors defined in Investment Agreement as attributes of object Deal (such as subject equity, parties concerned, quantities and price etc.) can be deemed as input parameters (or specific trigger events) of the said write operations concerned, which will be executed by the relevant Bookkeepers automatically.
ComBoox adopts the "state machine model" to simulate and control the share transactions and corporate governance activities, specifically:
2.1.State
Information contents of the book-entry registers at each moment are deemed as different states, which will be stored in the smart contracts of Registers (such as Register of Shares, Register of Members and Meeting Minutes etc.).
2.2.Transition Process
Share transactions, corporate governance behaviors and other relevant legal actions are considered as the transition process between different states of the book-entry Registers, and which will be defined and controlled by the smart contracts of Bookkeepers with respect to the subject’s identity, action process, terms and conditions, as well as legal consequences thereof.
https://i.ibb.co/WWkXF39/States-Transition.png
2.3.Conditions and process
The corporate governance rules (such as voting rules, nomination rules and other rules stipulated in the bylaws or other similar company constitutional documents), as well as the shareholders' special rights (such as First Refusal, Tag-Along and Drag Along, Anti-Dilution, Put Option and Call Option etc.) are deemed as rules, conditions and procedures to be followed in the transition process between the different states, which will be defined by the smart contract of Shareholders Agreement with respect to values of attributes, duration or determination thresholds for the said rules or rights. In runtime, Shareholders Agreement will timely answer the queries sent from Bookkeepers so as to provide parameters to automatically control the execution process of the legal behaviors concerned.
2.4.Write Operation Scripts
Investment Agreement can be deemed as a special script or batch file consisting of a series of write operation commands to cause the states transition of Register of Shares. And, the transaction factors defined in Investment Agreement as attributes of object Deal (such as subject equity, parties concerned, quantities and price etc.) can be deemed as input parameters (or specific trigger events) of the said write operations concerned, which will be executed by the relevant Bookkeepers automatically.
Data Structure of Deal
Code:
struct Head {
uint8 typeOfDeal;
uint16 seqOfDeal;
uint16 preSeq;
uint16 classOfShare;
uint32 seqOfShare;
uint40 seller;
uint32 priceOfPaid;
uint32 priceOfPar;
uint48 closingDeadline;
uint16 votingWeight;
}
struct Body {
uint40 buyer;
uint40 groupOfBuyer;
uint64 paid;
uint64 par;
uint8 state;
uint16 para;
uint16 argu;
bool flag;
}
struct Deal {
Head head;
Body body;
bytes32 hashLock;
}
1.4. Features and Advantages
To accommodate different demands, ComBoox adheres to the concept of "dynamic configuration and plug-and-play" to maintain the flexibility and scalability of its smart contract system. Specifically:
To accommodate different demands, ComBoox adheres to the concept of "dynamic configuration and plug-and-play" to maintain the flexibility and scalability of its smart contract system. Specifically:
- Operation Model: is compatible to both the members management model of DAO, as well as the managers management model for regular companies.
- Number of Owners: the number of owners can be limited to 50 or fewer (for small-scale limited liability companies), or expanded to an unlimited level of public listed companies.
- Equity Classification: can implement ordinary equity structure of "same shares, same rights", and also can flexibly define special classes of shares so as to grant special rights or voting weights to them;
- Governance Rules: can flexible set general corporate governance rules like motion proposal rules, voting rules, (executive officials) position allocation rules, (affiliated members) grouping rules, and (equity) listing rules, and also can set out special terms of members' right, such as First Refusal, Tag Along, Drag Along, Call Option, Put Option, Anti-Dilution, Lock Up, so as to satisfy the requirements of private equity investment.
- Payment Methods: the consideration for equity, pledge, or option can be paid on-chain with native cryptocurrency, or be paid off-chain or cross-chain with fiats or central bank digital currencies, by using technologies like hash time lock, so as to fully compatible with all kinds of payment requirements.
- Legal Entities: can book equities of the direct invested companies, and can also make further investments by controlling the first tier companies to set up their subsidiaries, and to indirectly control the corporate governance activities of subsidiaries as well, so that forming a complex network shareholding structure accordingly.
- Version Upgrades: can create book-entry system based on existing smart contract templates, and also allows customization or upgrades to new templates to satisfy special requirements.
1.3. Tokenization and Company Evaluation
Equity share is a typical kind of book-entry interests, and also an important trading object of capital markets.
(1) IPO creates capital premium
A company may select to list its shares on an open market, so as to facilitate public investors to buy in and sell out its equity more conveniently, which means to release the liquidity of its equity greatly, and as a direct consequence, the equity value of the company or its stock price will usually increase within a very short period of time dramatically. This is the basic principle that IPO can create capital premium.
(2) Tokenization of Equity Shares
Similarly, if adopting blockchain to book companies' equity, it will become very convenient to use cryptocurrencies or Central Bank Digital Currencies to pay the equity consideration, and, under the automatic control of smart contracts, some concepts like "Delivery Versus Payment", "Payment as Settlement" and "No Clearing Transfer" etc. can be fully realized with a fairly low cost and much higher efficiency. This is equivalent to connecting the companies' equity to the crypto markets which have trillion dollars’ liquidity, so that the companies may have an opportunity to have their equity re-evaluated and re-confirmed with the robust support of the huge liquidity.
(3) Web 3.0 Capital Markets
However, tokenization of equity shares does not simply mean to define a structured digital object representing equity value or capital contribution, or to move the booking records of “Register of Shareholders” or "Register of Members" onto the blockchain. What's more important is to coordinate all facts that may influence the equity value of a company into the automatic system of blockchain, and to enable smart contracts to get full control over all activities of share transaction and corporate governance, so as to ensure all those legal behaviors can be carried out strictly in line with the internal governance rules (like the articles of association or bylaws), as well as the external governing laws and regulations (such as the Securities Act and the Securities Exchange Act). So that, the capital markets can rely on the rigid logic of smart contracts to automatically control the creation, change, exercising, and elimination of the equity rights of shareholders, i.e. by implementing the concept of "Code Is Law" to establish a decentralized and trustless “Web3.0 Capital Market” in real sense.
Equity share is a typical kind of book-entry interests, and also an important trading object of capital markets.
(1) IPO creates capital premium
A company may select to list its shares on an open market, so as to facilitate public investors to buy in and sell out its equity more conveniently, which means to release the liquidity of its equity greatly, and as a direct consequence, the equity value of the company or its stock price will usually increase within a very short period of time dramatically. This is the basic principle that IPO can create capital premium.
(2) Tokenization of Equity Shares
Similarly, if adopting blockchain to book companies' equity, it will become very convenient to use cryptocurrencies or Central Bank Digital Currencies to pay the equity consideration, and, under the automatic control of smart contracts, some concepts like "Delivery Versus Payment", "Payment as Settlement" and "No Clearing Transfer" etc. can be fully realized with a fairly low cost and much higher efficiency. This is equivalent to connecting the companies' equity to the crypto markets which have trillion dollars’ liquidity, so that the companies may have an opportunity to have their equity re-evaluated and re-confirmed with the robust support of the huge liquidity.
(3) Web 3.0 Capital Markets
However, tokenization of equity shares does not simply mean to define a structured digital object representing equity value or capital contribution, or to move the booking records of “Register of Shareholders” or "Register of Members" onto the blockchain. What's more important is to coordinate all facts that may influence the equity value of a company into the automatic system of blockchain, and to enable smart contracts to get full control over all activities of share transaction and corporate governance, so as to ensure all those legal behaviors can be carried out strictly in line with the internal governance rules (like the articles of association or bylaws), as well as the external governing laws and regulations (such as the Securities Act and the Securities Exchange Act). So that, the capital markets can rely on the rigid logic of smart contracts to automatically control the creation, change, exercising, and elimination of the equity rights of shareholders, i.e. by implementing the concept of "Code Is Law" to establish a decentralized and trustless “Web3.0 Capital Market” in real sense.
1.2.Blockchain Solution
The emergence of blockchain and smart contract technology presents a good opportunity to solve the above mentioned problems. If using blockchain to book equity shares, and using smart contracts to define and automatically control share transactions and corporate governance activities, then, the potential human influences can be excluded to an extreme extent, so as to realize:
(1) Rights holders directly exercise their rights
Rights holders may, by means of electronic signature technology, have their identities verified and send out their instruction calls of exercising rights, by triggering the specific API of smart contracts to call the relevant functions and methods, directly update the Register of Shares, Meeting Minutes, and other Book-Entry records in accordance with the predefined conditions and procedures, thereby achieves the desired legal consequences accordingly. Throughout this process, there is no need to seek assistance or engagement of secretary, agent, authority or any third party, to exercise rights as a representative, proxy or delegate, so that the actions of exercising rights will not be intervened or controlled by any third party.
(2) Obligors have no opportunities to default
The reason why defaults occurred is because the realization of contractual rights depends on obligors to make cooperation behaviors actively. When turning over the control rights of book-entry records like Register of Shares and Meeting Minutes to smart contracts for automatic operation, then, a lot of traditional “claim rights” requiring cooperation of obligors will be changed into "disposal rights" that can be unilaterally exercised by right holder, therefore, the possibility of defaults will be completely eliminated.
As for the constitutional documents like articles of association, bylaws or shareholders agreement, many defaults are actually Ultra Vires behaviors (either substantive or procedural) of the controlling shareholder or executive managers. Smart contracts have rigid and strict programming logic, and can precisely control the timeline, permissions, procedures and other conditions of business operations, which may fundamentally eliminates the said Ultra Vires challenges to corporate governance.
(3) Real-time information disclosure
Corporate governance behaviors can generally be categorized as signing documents, voting, paying consideration, nominating candidates, taking position, resigning and several other types, and the existing technologies are fully capable to implement all of these legal actions that takes "Expressing Intent" or "Updating Rights and Interests" as its core attributes on blockchain, i.e. using blockchain to book the digital tracks of these legal behaviors, and using smart contracts to automatically verify identity of the actors, determine the conditions precedent, and control the process and procedures.
Blockchain is a distributed system that synchronize information in real-time among the nodes, therefore, legal behaviors conducted on blockchain will complete the information disclosure at the same time when updating the book-entry records or realizing the legal consequences concerned. Legal behavior and information disclosure are not separate activities any more, which will be integrated together and have no time lag or contents differences. Therefore, current disclosure issues like untimely delay, misrepresentation, or misleading statements etc. should become impossible to occur.
The emergence of blockchain and smart contract technology presents a good opportunity to solve the above mentioned problems. If using blockchain to book equity shares, and using smart contracts to define and automatically control share transactions and corporate governance activities, then, the potential human influences can be excluded to an extreme extent, so as to realize:
(1) Rights holders directly exercise their rights
Rights holders may, by means of electronic signature technology, have their identities verified and send out their instruction calls of exercising rights, by triggering the specific API of smart contracts to call the relevant functions and methods, directly update the Register of Shares, Meeting Minutes, and other Book-Entry records in accordance with the predefined conditions and procedures, thereby achieves the desired legal consequences accordingly. Throughout this process, there is no need to seek assistance or engagement of secretary, agent, authority or any third party, to exercise rights as a representative, proxy or delegate, so that the actions of exercising rights will not be intervened or controlled by any third party.
(2) Obligors have no opportunities to default
The reason why defaults occurred is because the realization of contractual rights depends on obligors to make cooperation behaviors actively. When turning over the control rights of book-entry records like Register of Shares and Meeting Minutes to smart contracts for automatic operation, then, a lot of traditional “claim rights” requiring cooperation of obligors will be changed into "disposal rights" that can be unilaterally exercised by right holder, therefore, the possibility of defaults will be completely eliminated.
As for the constitutional documents like articles of association, bylaws or shareholders agreement, many defaults are actually Ultra Vires behaviors (either substantive or procedural) of the controlling shareholder or executive managers. Smart contracts have rigid and strict programming logic, and can precisely control the timeline, permissions, procedures and other conditions of business operations, which may fundamentally eliminates the said Ultra Vires challenges to corporate governance.
(3) Real-time information disclosure
Corporate governance behaviors can generally be categorized as signing documents, voting, paying consideration, nominating candidates, taking position, resigning and several other types, and the existing technologies are fully capable to implement all of these legal actions that takes "Expressing Intent" or "Updating Rights and Interests" as its core attributes on blockchain, i.e. using blockchain to book the digital tracks of these legal behaviors, and using smart contracts to automatically verify identity of the actors, determine the conditions precedent, and control the process and procedures.
Blockchain is a distributed system that synchronize information in real-time among the nodes, therefore, legal behaviors conducted on blockchain will complete the information disclosure at the same time when updating the book-entry records or realizing the legal consequences concerned. Legal behavior and information disclosure are not separate activities any more, which will be integrated together and have no time lag or contents differences. Therefore, current disclosure issues like untimely delay, misrepresentation, or misleading statements etc. should become impossible to occur.
1.1. “Pain Points” of Corporate Governance
The capital markets have long been suffered from some "pain points" of corporate governance, which can be summarized into following three aspects:
(1) Right holders can hardly exercise their rights smoothly
No matter it is to replace executive managers, to change accounting policies, to convene an extraordinary shareholders' meeting, or to enforce a Put Option, Drag-Along, or Anti-Dilution of the shareholders agreement, when exercising its shareholders rights, investors will often inevitably need the cooperation of other parties like company secretary, actual controller, executives, registration agents and even the official registration offices. Sometimes, this could be very difficult and challenging, not only time-consuming and costly, but also may change into a protracted shareholders’ disputes, even lead to a serious consequences like business shutdown.
(2)Obligors sometimes deliberately violate their obligations
During an equity share transaction, buyer may delay paying of the consideration, whereas, seller may maliciously retain the company's seal, license, or postpone the closing process; In a company's daily operation, managers may abuse their authority, actual controller may misappropriate operational funds... To sum up, all of such bad behaviors can be categorized as "acts of breach", either breaching a share transaction contract (such as share subscription agreement or share transfer agreement), or violating a constitutional document of the company (e.g. the articles of association, bylaws, shareholders agreement, or operational agreement).
(3)Untimely and inaccurate information disclosure
Transfer of control rights, private placements, acquiring material voting shares exceeding reporting threshold ratio, such significant changes of shareholding structure of a company, as well as the company’s governance records like shareholders meeting resolutions or board meeting minutes etc., all these information are crucial indicators for assessing a company's future strategy, profitability, and valuation of equity shares, and will directly influence the investment decisions of investors and the valuation of the company concerned. Untimely, inaccurate or incomplete information disclosure often becomes major reasons that caused shareholders disputes or securities transaction disputes.
The capital markets have long been suffered from some "pain points" of corporate governance, which can be summarized into following three aspects:
(1) Right holders can hardly exercise their rights smoothly
No matter it is to replace executive managers, to change accounting policies, to convene an extraordinary shareholders' meeting, or to enforce a Put Option, Drag-Along, or Anti-Dilution of the shareholders agreement, when exercising its shareholders rights, investors will often inevitably need the cooperation of other parties like company secretary, actual controller, executives, registration agents and even the official registration offices. Sometimes, this could be very difficult and challenging, not only time-consuming and costly, but also may change into a protracted shareholders’ disputes, even lead to a serious consequences like business shutdown.
(2)Obligors sometimes deliberately violate their obligations
During an equity share transaction, buyer may delay paying of the consideration, whereas, seller may maliciously retain the company's seal, license, or postpone the closing process; In a company's daily operation, managers may abuse their authority, actual controller may misappropriate operational funds... To sum up, all of such bad behaviors can be categorized as "acts of breach", either breaching a share transaction contract (such as share subscription agreement or share transfer agreement), or violating a constitutional document of the company (e.g. the articles of association, bylaws, shareholders agreement, or operational agreement).
(3)Untimely and inaccurate information disclosure
Transfer of control rights, private placements, acquiring material voting shares exceeding reporting threshold ratio, such significant changes of shareholding structure of a company, as well as the company’s governance records like shareholders meeting resolutions or board meeting minutes etc., all these information are crucial indicators for assessing a company's future strategy, profitability, and valuation of equity shares, and will directly influence the investment decisions of investors and the valuation of the company concerned. Untimely, inaccurate or incomplete information disclosure often becomes major reasons that caused shareholders disputes or securities transaction disputes.
System Overview
ComBoox is a blockchain-based company book-entry system designed for equity share registration and statutory books keeping, which is aimed to assist users to quickly establish a legal, secure, transparent, and reliable smart contracts system on blockchain for registering equity share and keeping records of corporate governance, so as to enable rights holders such as investors, shareholders, managers, and business partners be able to directly engage in almost all the share transactions and corporate governance activities under the automatically control of smart contracts, including share subscription, transfer, pledge, consideration payment, contracts signing, motion submission, voting, nomination, appointment, resignation etc.
Different from simple tokenization of equity certificates, ComBoox does NOT rely on legal documents to restrict off-chain behaviors to ensure the realization of rights and interests, instead, it fully takes over equity transactions and corporate governance activities through smart contracts, completely eliminating the possibility of defaults. So that, it may fundamentally solve the corporate governance problems such as "Insider Control" and "Misleading Statements" that have plagued the capital market for many years, and completely realize:
(1) right holders may directly exercise rights;
(2) obligor has no chance to default; and
(3) real-time information disclosure.
By booking equity shares on Blockchain, investors may use cryptocurrency or Central Bank Digital Currencies to pay for share consideration, which means effectively connecting the company's equity share to the trillion-dollar crypto-markets, so that the companies may have an opportunity to have their value reevaluated and reconfirmed with the robust support of the huge liquidity.
ComBoox is a blockchain-based company book-entry system designed for equity share registration and statutory books keeping, which is aimed to assist users to quickly establish a legal, secure, transparent, and reliable smart contracts system on blockchain for registering equity share and keeping records of corporate governance, so as to enable rights holders such as investors, shareholders, managers, and business partners be able to directly engage in almost all the share transactions and corporate governance activities under the automatically control of smart contracts, including share subscription, transfer, pledge, consideration payment, contracts signing, motion submission, voting, nomination, appointment, resignation etc.
Different from simple tokenization of equity certificates, ComBoox does NOT rely on legal documents to restrict off-chain behaviors to ensure the realization of rights and interests, instead, it fully takes over equity transactions and corporate governance activities through smart contracts, completely eliminating the possibility of defaults. So that, it may fundamentally solve the corporate governance problems such as "Insider Control" and "Misleading Statements" that have plagued the capital market for many years, and completely realize:
(1) right holders may directly exercise rights;
(2) obligor has no chance to default; and
(3) real-time information disclosure.
By booking equity shares on Blockchain, investors may use cryptocurrency or Central Bank Digital Currencies to pay for share consideration, which means effectively connecting the company's equity share to the trillion-dollar crypto-markets, so that the companies may have an opportunity to have their value reevaluated and reconfirmed with the robust support of the huge liquidity.
Jump to: