General Meeting Proxy Voting on Distributed Ledger
Yüklə 257,46 Kb.
|
Voting Party must be able to see that the cast votes have been properly used and counted in on the outcome of the voting. Requirement № 165: The voting campaign and the meeting can be closed by either the Issuer Agent or automatically by the system process according to the pre-set rules. Closing the meeting is an important cutoff point in the process that prevents further instructions to be issued and allows the results to be calculated. The closing time acts as a point in the process from which finality (in business sense) can be achieved. Requirement № 170: All actors are able to calculate the outcome of the voting campaign once it has finished. It must be possible to independently verify the results of the voting process. The distributed ledger must contain proof that the result has not been tampered with and that all actions are traceable to their origin. This verification must respect various confidentiality requirements of the system. The DLT technology itself provides most of the functionality to satisfy this requirement. 2.3.8 Post-meeting actions Requirement № 220: It is not possible for Voting Parties to see or deduce the identities of the beneficial owners (or proxies) using the system. All actors may only see that voting rights have been allocated, but only the Voting Party who owns them may see how many voting rights it has. Only the Voting Party who has cast a voting instruction is able to see its effect on the voting process. Anonymity of the beneficial owners and confidentiality of their actions is important to both them and the regulators. If the identities behind the Voting Parties are exposed, they may become subject to pressure by other interested parties so that they vote in a way that may not serve their best interest. The system must conform to the information security practices of handling personal data in a way that the identity of the beneficial owners cannot be deduced using the analysis of the data that is openly available. Requirement № 221: It is possible for the Voting Party to disclose some of its private information to parties that require it by the process. This information may be disclosed either voluntarily or if the process demands it. Anonymity is typically required to protect private data against other voters, but it may be necessary (by law or otherwise) to disclose some of the private information to certain parties (e.g. auditors/regulators or the issuer) for the voting process to work legitimately.
The system must support this functionality in a way that allows the process to function, but does not compromise the privacy of the Voting Parties. Requirement № 230: There exists an Auditor/Regulator role with the elevated access rights to the blockchain. The Auditor/Regulator can review the data with limited access. It must be possible to assign the Auditor role to multiple independent trusted parties. The financial industry is heavily regulated in all jurisdictions and the regulator requires access to a lot of confidential information. The system must be able to provide access for the regulator and auditors to that information to simplify and reduce the cost of many compliance processes.
Extensions Requirements Alongside the MVP, we have listed a set of additional requirements that could be used to extend the system. A local implementation may add any or all of them. This list is not exhaustive or complete, but allows the markets of Russia, South Africa, Switzerland, France, Chile, Argentina, Nordic countries and Baltic countries, and possibly others, to be serviced. The extension requirements are presented in the same way as MVP requirements, but are structured according to the functional area that they modify, rather than by the process step. It is possible that a single set of extensions affects actions in multiple process steps. 2.4.1 Agenda Management Requirement № 11: The supplementary material can be attached to the meeting agenda and viewed through the system. The supplementary material itself is not stored on the distributed ledger. The supplementary material can contain financial statements, reports and any other media that may be of interest to the shareholders prior to or after the meeting. The supplementary material can be of significant size and should not be stored on the distributed ledger by default, but the ledger can provide access links and/or verification hashes to it. The implementation of the actual storage of these materials can be decided individually by each service provider.
Requirement №12
: The Issuer Agent is able to specify cash premium payable to the security owners who elect to participate in the general meeting. In some countries there is a practice that allows Issuers to provide an incentive to shareholders to participate in the general meeting by offering them a cash bonus. This practice may be used in order to more easily reach quorum or to obtain higher involvement rates from the shareholders. Requirement № 20: A Voting Party is able to propose meeting agenda items to the Issuer Agent. In many cases, the meeting agenda is formed before it is published and does not change afterwards. In some cases, however, a process for proposing new agenda items is required. This may be necessary, for example, when new agenda items are proposed during the actual meeting. Requirement № 30: The Issuer Agent is able to accept or reject the proposed meeting agenda items. When shareholders propose new agenda items, processing them is dependent on legislation or rules of a particular organization. It is necessary for the Issuer Agent to be able to enforce these rules. It can be implemented in various ways, including encoding the rules directly into the system or allowing the administrator to explicitly accept or reject proposals. 2.4.2 Meeting Notification Requirement № 12: The system is able to perform the initial notification of all potential Voting Parties. It is important that all potential voters are notified of the meeting details in advance. Reaching all of them can be very difficult and is a process of its own, but a simple feature of using standard contact details (email or SMS) can be implemented by the proxy voting system. This capability will not be built on blockchain, although its use can be triggered by the initialization of the meeting on the blockchain. Yüklə 257,46 Kb. Dostları ilə paylaş:
|