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