General Meeting Proxy Voting on Distributed Ledger

 

 

22 

Requirement 

№

155:  The  system  must  record  the  events  that  happen  at  the  physical 

meeting and store them on the distributed ledger according to local legislation or company 

requirements. 

Physical meetings have additional requirements to the record-keeping compared to digital 

voting.  In  most  countries  it  is  required  that  the  voters  pre-register,  that  the  protocol  is 

properly  recorded  etc.  Recording  this  information  in  the  blockchain  alongside  the  data 

required for digital voting will increase the transparency of the process. 

Requirement 

№

156: The system must provide services to the users voting electronically 

during the meeting, including the video streaming of the physical meeting. 

Users who vote electronically benefit from the convenience and ease of voting, but pay 

for  it  by  being  absent  at  the  meeting  and  missing  out  on  the  potentially  important 

discussions that happen there. The system would add a lot of value to the whole process 

if  it  could  increase  the  involvement  of  the  online  voters  by  providing  them  with  more 

means to take part in the meeting, e.g. access the video stream, being able to interact, 

ask questions, etc. 

Requirement 

№

157: The Issuer Agent is able to add new items to the agenda during the 

general meeting. 

During the meetings, the shareholders may make additional decisions which were not a 

part of the agenda originally. The system must be able to support management of these 

decisions, as well as voting for them. 

Requirement 

№

171: The Issuer Agent is able to publish meeting minutes and results on 

the distributed ledger.  

In  most  jurisdictions,  Issuers  are  obliged  to  provide  specific  reports  on  the  general 

meeting results and minutes. If these reports were stored in the blockchain, they would 

benefit from its access control and immutability, thus enhancing their legal standing.  

2.4.12 

Review Voting in Progress 

Requirement 

№

180: Certain actors are able to calculate the status of the voting campaign 

when it is in progress and only some of the votes have been cast. 

Voting is normally done blindly, with the Voting Parties not being able to see the progress 

until the results are out. But for the Issuer Agents (e.g. issuers or registrars), regulators 

or auditors it may be necessary to see the progress. 

---

 

 

23 

2.4.13 

 Administrative Adjustments 

Requirement 

№

190: The Issuer Agent is able to adjust the vote amounts. 

In some jurisdictions, legislation and other rules may cause adjustments to votes issued 

by the Voting Parties. The Issuer Agent should be able to detect the instructions liable for 

adjustments  and  execute  the  adjustments.  It  is  only  possible  to  adjust  the  amount  of 

votes, not the selected outcome. This function must be designed in a way that doesn't 

give the administrator possibility to misuse it. 

Requirement 

№

200: The Voting Party is able to see how its votes have been adjusted by 

the Issuer Agent. 

The mechanism for adjusting the votes must be transparent. Voting Parties whose votes 

were  adjusted  must  be  able  to  easily  detect  and  review  the  adjustments  with  any 

additional information (e.g. reasoning behind them). This information must be stored on 

the blockchain so that it can hold weight in the courts should the Voting Party decide to 

challenge the adjustment. 

 

---

 

 

24 

 

TRUST REQUIREMENTS 

The  main  added  value  of  DLT  is  that  it  enables  trust  in  trustless  environments.  In 

traditional systems, trust is typically achieved by designing business processes in a way 

that  create  incentives  for  parties  to  act  with  integrity  and  prudence.  These  processes 

come  with  a  lot  of  double-checking,  audit,  reconciliation  and  other  validation  and 

correction  mechanisms  necessary  to  make  the  process  work.  These  steps  create  a 

significant overhead in otherwise simple business processes.  

DLT-based systems take another approach to trust. DLT technically guarantees that the 

rules of the process are the same for every participant and that these rules are followed. 

It  eliminates  the need to  trust  actors  in  the  transactions 

–

 the trust that  the process  is 

executed  correctly  and  on  time  is  now  placed  in  the  system  itself  and  can  be 

independently verified by any actor. 

At the same time DLT also plays a role of an immutable golden copy of all data 

–

 so that 

no  peer-to-peer  reconciliation  is  needed,  as  the  correct  data  is  always  stored  in  the 

blockchain.  

These  two  properties  together  are  the  foundation  which  can  drastically  decrease  the 

overhead in many typical processes in the finance industry, allowing for a much higher 

level of service that was not possible before. 

The lack of trust essentially means that there are risks that have not been mitigated to an 

acceptable  degree.  These  risks  are  inherent  in  the  traditional  systems.  This  section 

elaborates  on  the  risks  specific  to  the  e-voting  including  proxy-voting  process  and 

discusses how they can be mitigated via a DLT solution. 

It should be noted, that although DLT mitigates a lot of trust issues, strong governance 

and correct implementation of the system is still necessary. Any practical service consists 

of more than just a ledger with a set of process rules, and the whole system is as weak 

as  its  weakest  links.  The  guarantees  of  the  ledger  do  not  prevent  the  need  of  proper 

management of confidential data, information security measures to storing private keys 

for ledger access and other system governance concerns. 

---