General Meeting Proxy Voting on Distributed Ledger

 

 

10 

in  different  order,  but  it  does  not  disrupt  the  general  picture  or  change  functional 

requirements, which can be mapped to the steps regardless of the order of these steps. 

Each step aims to accomplish a certain objective in the process. These objectives usually 

result  in  some  transactions  being  performed  between  the  actors.  We  have  analyzed 

whether these transactions generally occur on the distributed ledger (and benefit from the 

trust enabled by it) or can be recorded independently in traditional systems. 

# 

Step 

Description 

Data records 

1  Meeting Initialisation 

Capturing of agenda and setting of timelines 

(meeting date and record date). Original 

announcement of the meeting. 

On blockchain 

2  Ownership Record 

Loading 

Loading list of owners and ownership records at 

the voting record date into the blockchain. 

On blockchain 

3  Voting Right 

Allocation 

Issuing of tokenized voting rights to all Voting 

Parties who are eligible for voting. 

On blockchain 

4  Voting Party 

Authentication 

Authentication of the user able to vote via one 

of the means supported by the system. 

Not on 

blockchain 

5  Proxy Assignment 

Transfer of voting rights from the initial owner to 

another party. 

On blockchain 

6  Voting 

Issuing voting instructions by the Voting Parties 

using their tokenized voting rights. 

On blockchain 

7  Meeting 

Management 

Live streaming of the general meeting online, 

chat facilities and various services, including 

running and closing the meeting and 

processing and distributing the results. 

Both on and not 

on blockchain 

8  Post-meeting actions  Any events that happen after the meeting 

independently of the rest. 

Not on 

blockchain 

---

 

 

11 

These process steps are also depicted on the figure below: 

 

 

Minimal Viable Product Requirements 

The  goal  of  creating  common  requirements  was  to  reconcile  them,  without  creating  a 

conflict  between  shared  and  market  specific  requirements.  Within  the  scope  of  this 

document MVP requirements accomplish this goal. They encompass all shared parts of 

the  process  that  are  present  in  the  majority  of  reviewed  countries.  The  system  built 

according  to  the  MVP  requirements  would  not  necessarily  correspond  to  any  existing 

market, but could be easily extended to match the requirements of a specific market. 

It is our expectation that this set of MVP requirements represents a globally shared view 

of how the core of the e-voting including proxy voting business could look like and that it 

could be used anywhere to guide the implementation of a new DLT-based solution for e-

voting. 

The  MVP  requirements  are  structured  according  to  the  steps  of  the  process  that  they 

relate to.  

MEETING 

INITIALISATION

OWNERSHIP 

RECORD 

LOADING

VOTING RIGHTS 

ALLOCATION

PROXY 

ASSIGNMENT

VOTING

MEETING 

MANAGEMENT

POST-MEETING 

ACTIONS

Time

[administrator, issuer agent]

[intermediary]

[system]

[intermediary, voting party]

[voting party]

[administrator, issuer agent]

[administrator]

USER 

AUTHENTICATION

VOTING PARTY 

AUTHENTICATION

---

 

 

12 

2.3.1 Meeting Initialization 

Requirement 

№

10:  The  Issuer  or  the  Issuer  Agent  is  able  to  publish  and  update  the 

meeting  agenda  and  supplementary  materials.  Voting  Parties  are  able  to  view  the 

published meeting agenda and receive notifications about it. 

The meeting agenda can contain preliminary or a final list of topics (with voting options) 

that will be discussed at the meeting. The purpose of storing them on the blockchain is to 

ensure  their  immutability  and  legal  significance,  as  well  as  to  provide  proof  of  their 

publication. Any supplementary materials may also be made available, and may be stored 

directly  on  the  distributed  ledger  or  externally.  The  initialization  also  involves  an 

announcement on blockchain, but does not include notifying the beneficial owners, which 

are generally not known at this time. 

Requirement 

№

150: The system must support statutory and cumulative voting types.  

The two most common types of voting are statutory and cumulative voting. In statutory 

voting  the  holder  of  each  voting  right  is  eligible  to  cast  a  vote  for  one  of  the  mutually 

exclusive options, with the option with the majority of votes winning. In cumulative voting, 

votes may be cast for multiple options, as stipulated, with several options where the option 

receiving most votes wins. This form of voting is most commonly used for selecting the 

members of the Board of Directors. 

2.3.2 Ownership Record Loading 

Requirement 

№

40: The Intermediary is able to load the list of all potential Voting Parties 

to the distributed ledger.  

The Intermediary holds shares in the accounts opened in the names of beneficial owners 

or other Intermediaries. It can identify all potential Voting Parties eligible for the meeting 

based on local rules. The list of Voting Parties is then used to provide them with access 

to  the  meeting  agenda  and  actions  related  to  voting.  In  some  cases,  due  to  local 

legislation, it is possible that the Voting Party is not the beneficial owner even before any 

proxies are assigned. 

Requirement 

№

50: The Intermediaries in the custody chain are able to load the list of all 

potential Voting Parties to the distributed ledger even if each one of them individually can't 

achieve that. The custody chain supports propagation of the necessary data up and down 

the chain. 

In  most  countries  the  Intermediaries  are  also  able  to  hold  nominee  accounts  with  the 

registrar, the central securities depository or with other Intermediaries. In this structure 

---