Electus Whitepaper by Somesh Yadav

<< open framework for governance systems on the blockchain >>

ELECTUS WHI TEPAP ER.

Electus Whitepaper Contents

CONTENTS ABSTRACT INTRODUCTION

ELECTUS ECOSYSTEM

Participants Tools

USE CASES & PRODUCTS ID Issuance Anti-piracy in Gaming Corporate Structures EVM Recountabuility

ARCHITECTURE Entity Standard Poll Standard Action Standard Universal Entity Scanner Universal Poll Scanner Electus Services Vault Polis

SPECIFICATIONS Events and functions of an entity Events and functions of a poll Functions of an action

ELECTUS TOKEN Protocol governance Time-lock Staking Sub-staking

APPENDIX DISCLAIMER

04 07 08 09 09 10 10 12 13 13 14 16 17 18 19 19 23 26 26 33 41 43 43 44 45 46 47

ABSTRACT

Electus Whitepaper Abstract

We present the design of Electus, a permissionless protocol for governance that facilitates capital allocation, compliance, consensus collection. This could be on matters that either concern assets on the blockchain, or assets outside of the blockchain, using the blockchain only as a tool for collecting consensus. The protocol seeks to replace inefficient systems that function in industries that fundamentally require permissioning, such as financial regulation, elections, licencing and most importantly, collective resource allocation. The inefficiency in these systems stem from the fact that they execute sensitive decisions, and there is no easy way to maintain transparency in these situations without compromising their security. As a result, they are time consuming, expensive, and in some cases, unreliable. Electus protocol maintains memberships to certain organizations on the blockchain, without storing any details that can be used to identify an individual. These memberships can be used to enforce certain transparent and agreed upon rules and constraints between participants of the organization. The protocol itself does not impose any fees on participants, however an organization using the protocol to offer a service may charge a fee at their discretion, based on market demand for the service itself. The protocol also enables a lot of possibilities which were previously out of question, such as a direct democracy platform, or attack-resistant DAOs. The expansion and adoption of the protocol will be accompanied with decentralized governance to ensure that the protocols functionality is aligned with the interests of its stakeholders.

Electus Whitepaper Introduction

INTRODUCTION Governance systems are systems that exist to facilitate co-operation, ensure good behaviour, discourage malpractices, or aid decision making. They exist in several diﬀerent industries, and are usually very sensitive systems, because stakes are usually high. As governance systems start to govern more and more people, not only do they become more sensitive (greater incentive to cheat), but it also increases the ease of cheating, because apathy among the members of the system increases (Dunbar number) and more operational resources(and more trust) are needed to ensure their proper functioning. The Electus protocol (ERC-1261+ERC-1417+ERC-1425) aims to leverage smart contracts to aid the operation of such systems by adding transparency and eﬃciency into these processes.

DISRUP TING DEMOC RACY

Democracy is a difficult system to scale. Gathering consensus has historically been a tough process. In smaller numbers, people can put chits in an urn and tally votes. But as we scale as a society it is difficult to record and tally consensus, mainly because we are not able to fully leverage computers. This is because an internet based democracy would require someone to store votes and such data. The holder of such data carries immense power, and defeats the purpose of democracy. Blockchain voting offers an avenue for us to transform and scale democracy in a manner where consensus can be gathered without trusting any one party.

Electus Whitepaper Introduction

SIMPLIFY ING MEM BERSHIP ISSUANCE

The Electus protocol makes issuing memberships simple and cheap, in addition to being secure and tamper-proof. It can act as a tool for issuing memberships such as business licences, certiďŹ cates of graduation, loyalty programme memberships, software licences and insurance subscriptions on-chain. The non transferable and revocable nature of the membership veriďŹ cation token is perfect for such applications, and enables companies and organizations to not only add transparency to their systems, but also programmatically run subscriptions or payments based on membership.

AUTO MATIC RESOUR CE ALLO CATION

Electus Whitepaper Introduction

Governance extends not only to membership and consensus collection but also allocation of resources. This is something that simply does not exist in conventional systems. There is no system that allows a group of people to fund a project with a drip feed from a collective pool, and at the same time have the option of cutting off funding when the project is about to die. Electus is designed with the vision that such funding methods will slowly start gaining traction, because they minimize the risk of backers, and help projects get breathing space. It also roots out scam projects and discourages slacking off. Action contracts are designed specifically to be flexible and allow for different kinds of outcomes for such resource allocation problems. The best part is that all of this can be done without a trusted intermediary.

FISCAL POLICY ON BLOCK CHAIN

Finally, another leg of governance is to cover fiscal policy on the blockchain. Lack of fiscal control is one of the biggest reasons why governments across the world are paranoid about blockchain. Electus aims to build systems that can enable governments to decide their fiscal policies using a crypto-based national currency, and allow individual lenders, and borrower rating agencies to replace conventional banks altogether. The lack of issuance and debt in cryptocurrencies is one of the bottlenecks in its adoption. While shady debts and issuance is one of the factors that make cryptocurrency important, Electus has the potential to design systems which are transparent, and make such policies accountable. This can potentially combine the best of both worlds.

Electus Whitepaper Electus Ecosystem

ELECTUS ECOSYSTEM The Electus ecosystem consists of the following components which come together to form governance structures:

PARTICIPANTS

MEMBERS These are externally owned addresses which act as representatives of the end-users who govern using the Electus Protocol.

Admins are special users who have access to special functions of certain key smart contracts that gives them control over who is part of what group and who can vote where. Admins are usually there to permission and manage the system, whose main purpose is to govern a common interest.

ADMINS

SERVICE PROVIDERS

Service providers assign membership to individuals on the blockchain that proves a certain quality about them, such as drivers licence, accreditation, certificate of incorporation, college degree, in exchange for an upfront fee or a periodic rent contract. Service providers are - in a technical sense - admins. However they are specifically running a service for profit.

Electus Whitepaper Electus Ecosystem

TOOLS

MEMBERSHIP DEPENDANT ASSETS Membership dependent assets are assets which are coded in such a fashion that their possession requires some special membership, or privileges. Some examples could be accreditation for holding securities, or national citizenship to hold certain local assets

DEMOCRATIC TREASURIES Democratic treasuries are vaults of money that are locked up with a drip release formula to a pre-decided vendor, which can be revoked at any time through a democratic veto at a pre-decided quorum

Electus Whitepape Use Cases & Products

USE CASES & PRODUCTS This section highlights potential use cases of the Electus protocol, that the Electus team is not necessarily working on. The purpose is to highlight several ways to use the protocol. Electus is an open source sandbox, and everyone is free to build on any of the ideas presented below:

ID ISSUANCE

Many blockchain identity players are offering id verification on the blockchain without the need of hot servers. This allows a blockchain address to be mapped to a user ID, however the ID issuance is still centrally controlled with n o transparency or accountability. Electus protocol can allow for Identity issuers to issue non-transferable revokable tokens as placeholders for an identity document. A very convenient example is: Every country issues a passport token similar specific to the country to all eligible citizens, and the following checks can be performed without the need of any physical documentation: A. Imigration at airports with the use of QR code + biometric B. Issuance of visa through QR code C. E-inspection of passport for travel history during visa applications D. Police in foreign country wants to view your passport, you show a qr code, he scans with an Electus powered app, and gets the necessary data E. Cannot lose the passport because QR code is easy to store

Electus Whitepape Use Cases & Products

ANTI-PIRACY IN GAMING

A lot of gaming consoles have online game shops where game downloads are subject to the availability of a 'ticket'(which is purchased), and hackers have built alternate shops where a ticket can be alternatively sourced (the double spend problem isn’t solved) in order to download paid games for free. This can be prevented by making each device possess a blockchain address, and sending over 'membership tokens’* to an address upon purchase. These tokens are revokable, and hence prevent misbehaviour on the part of devices, and are non transferable - meaning false tokens cannot be obtained. For transfering the game to a diﬀerent device, the gamer can request a transfer which the gaming company can process easily as the 'entity admin'*. Not only can games be purchased but also rented. * See protocol document

CORPORATE STRUCTURES Entire companies can be built on to the electus protocol, the 'membership token' becomes an employee token, and entire structures like EXECUTIVE = (CEO/CTO/BOARD OF DIRECTORS) can be built , to which 'managers’ and 'employees' report. All members have an employee token, but:

Electus Whitepape Use Cases & Products

1. Executive collectively assigns a delegation = [ 1. Agenda; 2. Budget ], to a manager who can choose to approve or negotiate the budget. 2. Once a delegation* has been assigned, the managers salary is sent to the address with managers employee token from the delegation Smart Contract, and the remaining amount is assigned by the manager to sub-managers in the form of sub-delegations (sub agenda with sub budget) the sub manager iterates the same thing to his subordinates, or the manager can assign a task to employees (non manager) who instead of recieving their own delegation contracts will recieve only a salary stream from the original delegation address. *Delegation is a smart contract with some funds in it 3. Employees will recieve salaries into address with the employee token (This token is transferable upon request)

The following comparisons show how actions on the protocol can become representations of actual corporate decisions: FIRING OF EMPLOYEES = REVOKE TOKEN NOTICE PERIOD = PAYDAY CONTINUES AFTER REVOKE PROBATION = NO NOTICE PERIOD COMPANY CONSENSUS CAN BE TAKEN BY VOTING WITH THE HELP OF EMPLOYEE. TOKENS ARE USED TO MANAGE ELECTORATES.

Employees work cannot go unnoticed by upper management, this means they will know how much value for money each employee is, how much middlemen cost, and employees dont worry about boss taking the credit for their work.

Electus Whitepape Use Cases & Products

EVM RECOUNTABILITY

Electronic voting machines today face problems of verifiability. There are some solutions in the market presently, such as VVPAT and so on. But a glaring challenge is ensuring that there is no tampering of information in the stages of counting and transporting of these paper trails. Since the result of such recounting is unreliable, all involved parties are usually suspicious of EVM results. With Electus protocol, each EVM has a blockchain address, and is treated as a member to an entity. JS applications can recount votes automatically for fool proof verification of election results - anyone who does not trust can perform a check using blockchain event logs. Voters can verify their individual votes when committed to the blockchain. Voters votes remain confidential because thousands of people vote from the same machine (same blockchain address).

Electus Whitepaper Architecture

ARCHITECTURE

ENTITY STANDARD

The entity standard is a smart contract standard developed by Electus Foundation. It is designed to function as a representative of an organization or governing body on the blockchain. Its main function happens to be that of maintaining a list of addresses that are treated as part of the organization. Additionally, the entity maintains a list of addresses that have ever been part of the organization. This feature is implemented to ensure that it will always be possible to ďŹ nd out which users have been removed from the contract and which users were never a part of the contract. The entity also carries information regarding attributes of each member address. This information, along with membership details can be called on-chain by other smart contracts. This facilitates the creation of permissioned actions such as polls, and ďŹ nancial licencing and so on. An attribute of any member is represented by an integer in the BLACK smart contract against their public EYES BROWN address. This is carried out as HAIR follows: While deployment, the owner declares an array containing the header name of each attribute. For example: Hair color, Eye color, AMERICAN Nationality & Gender Other than this, there is a mapping MALE table where the keys are the elements of the above array, and values themselves are arrays.

KEY

HAIR

Black

Brown

Blonde

EYE COLOR

Blue

Black

Brown

Green

NATIONALITY

American

Chinese

Others

GENDER

Male

Female

Electus Whitepaper Architecture

Let the mapping be: [ Hair color: [Black, Brown, Blonde], Eye color: [Blue, Black, Brown, Green], Nationality: [American, Chinese, other], Gender: [Male, Female] ] Now the attribute array for an american male with brown eyes and blonde hair would be [2, 2, 0, 0], which is the same size of the header array, and each element points to the value of the attribute present in the mapping table against the appropriate attribute name.

POLL STANDARD

The poll standard is a smart contract standard developed by the Electus Foundation. Its purpose is to record votes into a smart contract, in a way such that a simple web application can read the data in real time and present to users a picture of the consensus brought in by users. The poll is comprised of four major modules which carry out diďŹ&#x20AC;erent roles. The standard lays out these 4 modules.

VOTERBASE FUNCTION

The voterbase function is a function in this smart contract that evaluates whether a transacting address is a part of the permitted voterbase. This is done with the help of entities. For instance, a poll may decide that only members of a certain entity are allowed to vote. This is not restricted to the use of a single entity. A poll could create a complicated expression of logic gates, with membership criteria of several entity and even ďŹ ltering individuals based on attributes. This results in immense ďŹ&#x201A;exibility of the voterbase without having to write too much code.

VOTE WEIGHT CALCULATION

This function is responsible for deciding which voter has how much of a vote weight. For a one person one vote poll, this function is trivial - it simply returns 1 for any voter who is part of the voterbase. However this function can be designed to code several complicated polls, such as delegated voting, karma based voting, and token proportional voting. Coding these vote weight functions is not necessarily straightforward. Hence the Electus Foundation has coded several standard vote weight schemes, as listed below:

Electus Whitepaper Architecture

1. TOKEN PROPORTIONAL VOTING

2. TOKEN PROPORTIONAL VOTING WITH CAPPED ALLOCATIONS

3. DELEGATED VOTING

4. KARMA BASED VOTING

However, developers are free to create more such vote weight functions and contribute to the electus repository. Some ideas for further nuanced voting functions are Quadratic Voting functions.

VOTE CONSEQUENCE

Vote consequence is a function that executes a payoﬀ or a cost for voting. The cost is not necessarily a monetary one, but can also be that of locking up a certain token. In the case of quadratic voting, the vote consequence would be that of deducting the appropriate amount of money from the voter’s wallet. In some polls, this function may be left empty. Failure to meet the consequence may result in failure of the vote.

4.TALLYING FUNCTION

This is the function that updates the ballot for each candidate or proposal present in the poll. It ﬁrst adds the vote weight of the voter to the appropriate ballot, and then adds 1 to a NoV(number of voters) count for that particular proposal. This is done so that a record is kept not only of which proposal has how much vote share, but also how many voters chose each proposal. For an unvote transaction, the tallying function will simply subtract the voters previous vote, and remove 1 from the NoV count for that particular proposal.

EVENT LOGS In addition to the above functions, the poll contract makes event logs on the blockchain in order to make reading of events quicker. CAST VOTE

WHEN A VOTE IS SUCCESSFULLY CAST

Electus Whitepaper Architecture

UNVOTE FAILED VOTE

WHEN A VOTE IS REMOVED

WHEN A TRANSACTION FAILS TO GET COUNTED AS A VOTE

ACTION STANDARD

The action standard is the last and the lightest contract standard made by the Electus Foundation. The purpose of the action contract is to be able to execute a certain set of actions based on the outcome of a poll, or based on certain membership criterion. The action contract would consist of two standard functions:

CONDITION FUNCTION

This function checks for some logic, and evaluates whether the criterion coded in the function is true or not. The function is hard coded, and takes in no arguments. It reads data in other smart contracts on the blockchain and then uses that data to give a true/false output by evaluating the logical expression.

EXECUTION FUNCTION

This function performs a hardcoded set of actions based on the result of the condition function. By hardcoding these 2 functions in tandem, the action contract becomes a standard contract for ‘promise on the blockchain’. It is an immutable request that processes upon the fulﬁllment of a certain criterion.

The way the contract is described above is reminiscent of betting market contracts, except that the execution function allows for more ﬂexibility. Action contracts in general would contain several other methods other than the above mentioned methods. This is because action contracts would typically have some additional role, depending on the context in which they are placed. However the 2 methods above are designed to leverage the automation of blockchain in tandem with governance outcomes that the Electus Protocol produces.

Electus Whitepaper Architecture

UNIVERSAL ENTITY SCANNER

The Electus foundation will build and maintain a contract explorer for entity contracts, which will produce the details of any entity once the contract address is available. This scanner will use the interface of the entity to produce a list of member addresses, and a list of addresses that have ever been members, along with their attributes. The scanner will also produce a log of admin activity, showing when the admin has added or removed members. These activities can be then ﬁltered based on nature, or time stamp. If the interface of a given contract doesn’t match the speciﬁcation of the entity standard, the scanner will throw an appropriate error. The purpose of this scanner is to have transparent access to the activity happening on an entity. It is similar to what www.etherscan.io does for the ethereum network. The scanner will additionally perform advanced code checks. If a person has the source code of the contract, the entity scanner will enable this person to do 2 things:

A. B.

Check whether the bytecode of the contract matches the source code that the person has Check whether the source code actually does what it claims to do we run test cases in our backend to verify that the code is a properly functioning entity.

The above 2 checks are associated with a small fee in the ballpark of $1 each. Once the 2 checks are done, the individual may wish to label the contract as verified on Electus Foundation servers, this will allow other people to see that it has been verified, and can be trusted. The fee for listing verifications has not yet been decided, and will depend on demand, and server costs at the time.

Electus Whitepaper Architecture

UNIVERSAL POLL SCANNER

The Electus foundation will build and maintain a contract explorer for poll contracts, which will query the data present in a poll contract like time remaining, vote share of each proposal, winner - if applicable, number of voters for each proposal, list of voters, and so on. This data will be produced by accessing the public functions in a poll contract, and the poll scanner will throw an error message if the given contract address is not a poll contract, ie. has a diﬀerent interface. Other than making poll information easily accessible, the poll scanner will allow (for a small fee) users to:

A. B.

Verify whether a certain source code matches the byte code, meaning that the deployer has deployed the code that he claims to have deployed Verify that the poll is functioning the way it is intended to function, based on the declared poll type - Electus foundation has prepared test cases for several poll types, and will continue adding more poll types.

Once these are verified, the user can choose to list the poll as verified, for a certain verification listing fee, which is to be decided. The poll scanner also will have a hard audit mechanism, where the user may look at the past and present voterbases, add back removed voters, remove recently added voters, and make modifications to the voterbase, to simulate the poll offchain, based on logs for attempted votes on the blockchain. This is a computationally expensive procedure, and hence a small fee will be charged. Along with the entity scanner, the poll scanner forms the infrastructure for the Electus Protocol, and provides transparency and ease of audit to developers and end users who are using the Electus standard for governance.

Electus Whitepaper Architecture

ELECTUS SERVICES

Electus services are applications or application sandboxes that can be used to deploy independent, sovereign governance structures. While the Electus Protocol is an open source framework, these dApps are not open source. They will be revenue sources for the Electus foundation. Customers may avail discounts on service fees, upon locking up certain amounts of Electus token. The exact number of tokens to locked up will depend on the price of the service the price of the token, and duration for which the tokens are locked up. The exact procedure for locking up tokens is described in a future section. This section describes Vault, a DAICO platform powered by the Electus Protocol, and Polis, a micro-government sandbox.

This section explains Vault, a service based platform created by the Electus foundation. This is only a short summary, for more details please refer to Vault’s product description document, which is a separate document. Vault is a platform powered by the Electus protocol, that enables individuals to easily raise funds in an accountable manner. These are initial coin offerings which allow the backers to vote for no confidence, and to regulate the rate of cashflow. Such an ICO is called a Decentralized Autonomous ICO, or a DAICO in short. There are some weaknesses in the original DAICO proposal, which are mitigated using the Electus Protocol. Vault not only prevents misappropriation of funds, but also prevents raising of excessive amount of funds by allowing for multi layered fund raises.

FUNCTIONALITY The functionality of a Vault DAICO can be divided into 3 roles or phases, described as follows:

Electus Whitepaper Architecture

CROWDSALE

The DAICO first acts as a system for fund collection, until a certain amount of funds have been raised. This amount is similar to a soft cap in typical ICOs, however it will be regarded as the ‘first round’ of the DAICO. After the first round, the issuer may commence subsequent rounds as he sees fit.

GOVERNANCE

This phase begins as soon as the ﬁrst round of the DAICO is completed successfully. This is the phase where token holders can make decisions that govern the ﬂow of capital. It can allow the people to increase tap, approve exceptional fund requests, or kill the DAICO.

REFUND

This phase is initiated in 2 cases, either the ﬁrst round of DAICO did not complete on time, or the round completed, but the DAICO was killed by participants during the governance phase. This phase allows participants to recieve salvaged refunds based on their token share and the amount remaining in DAICO.

SUCCESS

GOVERNANCE

FAILURE

CROWDSALE

FAILURE

REFUND

STRUCTURE In addition to mitigating the above mentioned issues, Vault makes DAICO deployment similar to a black box, where the issuer needs to enter some parameters, and the code for DAICO smart contract Ecosystem is created by Vault’s intelligent code-factory. Vault’s code-factory deploys the following smart contracts, which collectively comprise of a DAICO:

Electus Whitepaper Architecture

MODIFIED ERC20

A special ERC20 token which is modiďŹ ed to accommodate to allow freezing, and tracking of number of tokens in governance base.

CROWDSALE

This is a smart contract which has information of multiple ICO rounds, and stopping times, along with token price. It is the contract where people send the money, and is allowed to mint tokens into recipient addresses. This contract is also responsible for sending funds into the treasury contract.

TREASURY

The treasury smart contract is at the heart of the DAICO. It controls withdrawal rations, and triggers the refund mode if the contract gets killed. The treasury also contains a poll factory which deploys several polls, that are part of the DAICO.

WHITELIST

This is an ERC-1261 smart contract which assigns membership to people who have been whitelisted. Used by crowdsale contract to allow contributions.

LOCKED TOKENS

This contract contains the unsold tokens which are kept locked until all the kill polls have been executed successfully without a motion of no conďŹ dence.

TAP POLLS

Vault DAICOs allow the token issuer to withdraw funds at a pre-set rate called the tap (wei/second). This tap is set before collecting funds, and the tap may be increased if people allow for that. Tap polls are polls that record consensus of people in the matter of tap increments. Once the tap poll has crossed 60%, the tap value increases 50%, and a new tap poll is deployed, which is used until the next tap increment. There is no time deadline on these polls.

Electus Whitepaper Architecture

KILL POLLS

Vault DAICOs allow the investors or contributors to vote for no conďŹ dence in the project, upon an 80% consensus in no conďŹ dence, this poll shifts the treasury into a refund mode. Once in refund mode, no more funds can be withdrawn by issuer, and contributors can withdraw their share of the salvage value present in the treasury. There are a total of 8 kill polls, each one spanning a duration of approximately 3 months (89 days). Once these polls reach expiration, their vote tallies are frozen and any person from the crowd may call the kill function in the treasury to trigger refund mode. Locked tokens are immediately burned after this kill, and tokens held by contributors are burned as and when they claim their refund.

EXCEPTIONAL FUND REQUEST (XFR) POLLS

An issuer can ask permission from contributors to withdraw an amount that bypasses the tap. This is present to allow issuers to meet unforeseen requirements. One XFR takes approximately 30 days to expire. No withdrawal can be made before expiry. This poll starts with a 100% yes, and gives investors 30 days to change their vote to no. There can be no more than 2 simultaneous XFRs

Vault is created not only to make DAICO deployment easy, but also in order to allow DAICO investors to do their due diligence, and make informed government decisions. While the Electus protocol ensures a secure governance infrastructure, it is also important for governance participants to be aware of critical information. Hence, other than the smart contract deployment system, Vault will provide for a sleek UI, along with a whitelisting system, and a membership system which allows for issuers to set a maximum vote-share cap. Vault is also focused on giving the investors important analytics on the coin distribution and spending history of the issuer. The above description is only a summary, and not a detailed description of the Vault DAICO system. A detailed description will be available in the Vault product document.

Electus Whitepaper Architecture

Polis is a sandbox for micro-governments. It puts into usage the three building blocks of the Electus protocol and allows companies or other organizations to form micro-governments, where there exists a citizenship criterion, and citizens collectively take part in decision making. As the Electus protocol is open source, anyone is free to use the protocol to build their own Polis using the Electus framework. However, for clients that have speciﬁc needs, and wish to have a custom deployment readymade, Electus Foundation will oﬀer services that entail complete construction and deployment of governance systems from scratch. From time to time, the foundation will launch Polis templates, which are pre-made governance systems, where a customer can plug in their desired parameters and get started with governance. Some examples of templates are: 1. UNIVERSITY GOVERNANCE 2. OPEN SOURCE SOFTWARE GOVERNANCE 3. POLITICAL PARTY INTERNAL GOVERNANCE 4. MUNICIPAL CORPORATION GOVERNANCE 5. GOVERNANCE OF CHARITABLE ORGANIZATIONS The above examples are only for explanatory purposes, and not a statement of plans of the Electus Foundation.

FUNCTIONALITY A micro government is called a polis (plural: poleis), and it allows for 4 major functionalities that generally span several governance applications:

MEMBERSHIP

A micro government allows for membership. Membership is what tells the blockchain who has the right to govern. This is the ﬁrst step for a user to go through before starting governance. The polis has an admin, who

Electus Whitepaper Architecture

has the power to add or remove members from the polis, however admin activity is transparent, and will be visible to anyone who can access the blockchain. This ensures ﬂexibility of governance while keeping the admin activity in check

CATEGORIZATION

A micro government functions more eﬀectively if the blockchain is aware of citizen categorization. This is because various decision making processes can work with specialists in certain areas, such as doctors, legal experts, etc. Categories can be exclusive and exhaustive, meaning that all members must belong to exactly one of the categories, and they can be non exclusive non exhaustive, meaning that members may or may not belong to them. Exclusive and exhaustive groups can be implemented by using attributes within the ERC-1261 contract (explained in section 5) while non exclusive and non exhaustive subgroups are maintained as separate ERC 1261 smart contracts. Non exclusive and non exhaustive categories can serve as indicators of subscription.

CONSENSUS

One of the key oﬀerings of a micro governments is that it allows participants to make collective decisions by using polls. The Polis is able to deploy several polls with granular speciﬁcations such as the poll type, and voterbase. The poll type decides how the votes are weighed. It could be a delegated voting poll, or a karma/reputation based poll and so on. The voterbase sets a criterion for accepting votes. Votes are accepted if they are coming from members that pass the criterion set in the voterbase.

CAPITAL ALLOCATION

A micro government can deploy treasuries. A treasury is deﬁned as a smart contract that releases funds based on certain pre set policy, and can be destroyed by consensus from a pre decided poll. The purpose of such a smart contract is to allow micro governments to succesfully deploy publicly funded projects transparently while ensuring that the contractors do not default or misbehave.

Electus Whitepaper Architecture

STRUCTURE The Polis is generally composed of the following elements:

ENTITIES

An entity is the main smart contract which tells people whether an individual is a member of the system or not. It also contains information about who existed in the system in the past, and has attributes, which describe the exclusive and exhaustive subgroups of the entity. There may be other entities to describe non exclusive non exhaustive subgroups.

POLL FACTORIES

These are smart contracts that deploy poll smart contracts. There is a poll factory for each diﬀerent type of poll, and these factories take in inputs to specify voter base, and proposal set, and deploy a poll of the required type and speciﬁcations.

TREASURY FACTORIES

These are smart contracts capable of deploying other smart contract systems called treasuries. A treasury is an action contract containing certain amount of funds - coming from the polis admin, that are released like drip feed to some contractor, and a set of polls that allow for conditional destruction of the treasury, which refunds the amount of money present in the action contract to the polis admin. All diﬀerent kinds of poleis are composed of the above components, however some may diﬀer in the way that they interact with each other. Certain commonly used combinations will be released as templates. The above description of Polis is only a summary, and not a detailed description. More details on Polis will be present in the Polis product document which will be separately released.

Electus Whitepaper Speciﬁcations

SPECIFICATIONS

EVENTS AND FUNCTIONS OF AN ENTITY

An entity is the representation of an organization on the blockchain in the form of a smart contract. It maintains a list of members, and ex-members. It allows for each member to have a set of attributes, which are chosen from a hard coded set of options.This section will describe clearly how each function and event helps the user interact with the smart contract.

FUNCTIONS

isCurrentMember

This function can be used to query whether a specific address is a member of a given entity. This function will return a boolean value conveying the answer. This can be used effectively while filtering members for polls, or checking membership. /// /// /// /// ///

@notice Queries whether a member is a current member of the organization. @dev MVT's assigned to the zero address are considered invalid, and this function throws for queries about the zero address. @param _to An address for whom to query the membership. @return Whether the member owns the token. function isCurrentMember(address _to) external view returns (bool);

getAllMembers

This function brings up a list of all members who have ever held the token, regardless of whether or not they are currently holding the token.

Electus Whitepaper SpeciďŹ cations

When used in combination with isCurrentMember, this is helpful in ďŹ guring out which members have previously been in the group. /// /// /// ///

@notice Returns the list of all past and present members. @dev Use this function along with isCurrentMember to find wasMemberOf() in Js. It can be calculated as present in getAllMembers() and !isCurrentMember(). @return List of addresses who have owned the token and currently own the token. function getAllMembers() external view returns (address[]);

3.getAttributeNames

This allows us to query a list of attribute names that exist within the group, for example: hair color, country, occupation, gender are attribute names, and an organization could use these to categorize individuals on-chain to reďŹ ne poll voterbases. /// /// /// /// /// /// /// /// ///

@notice Returns the list of all attribute names. @dev Returns the names of attributes as a bytes32 array. AttributeNames are stored in a bytes32 Array. Possible values for each attributeName are stored in a mapping (attributeName => attributeValues). AttributeName is bytes32 and attributeValues is bytes32[]. Attributes of a particular user are stored in bytes32[]. Which has a single attributeValue for each attributeName in an array. Use web3.toAscii(data[0]).replace(/\u0000/g, "") to convert to string in JS. @return The names of attributes. function getAttributeNames() external view returns (bytes32[]);

4.getAttributes

This function returns the current attribute values stored for a particular member. This can be used by client side apps to describe the state of a user. /// /// /// /// ///

@notice Returns the attributes of `_to` address. @dev Throws if `_to` is the zero address. Use web3.toAscii(data[0]).replace(/\u0000/g, "") to convert to string in JS. @param _to The address whose current attributes are to be returned. @return The attributes associated with `_to` address. function getAttributes(address _to) external view returns (bytes32[]);

Electus Whitepaper SpeciďŹ cations

5.getAttributeByName

This function returns the value of a chosen attribute - by name, for a particular user. This is relevant for polls that wish to reďŹ ne results by acccepting votes from speciďŹ c subsets of the entity. /// /// /// /// /// /// ///

@notice Returns the àttribute` stored against `_to` address. @dev Finds the index of the àttribute`. Throws if the attribute is not present in the predefined attributes. Returns the attributeValue for the specified àttribute`. @param _to The address whose attribute is requested. @param attribute The attribute name which is required. @return The attribute value at the specified name. function getAttributes(address _to, bytes32 attribute) external view returns (bytes32[])

getAttributes

This function is designed to allow the entity admin to add a new set of attributes. For instance, an admin may decide classify the organization members by their blood group one day. They would not need to create new entities, but only add a new array containing a list of all possible blood groups. /// /// /// /// ///

@notice Adds a new attribute (key, value) pair to the set of pre-existing attributes. @dev Adds a new attribute at the end of the array of attributes and maps it to `values`. Contract can set a max number of attributes and throw if limit is reached. @param _name Name of the attribute which is to be added. @param values List of values of the specified attribute. function getAttributes(byte32 _name, bytes32[] values) external;

modifyAttributeByName

This function allows the admin to edit an attribute of a given user by choosing the users address, attribute name, and new value for the user. This is handy if members have changing attributes, like a member changing their geographical location. ///

@notice Modifies the attribute value of a specific attribute for a given

Electus Whitepaper Speciﬁcations

/// /// /// /// ///

`_to` address. @dev Use appropriate checks for whether a user/admin can modify the data. Best practice is to use onlyOwner modifier from ERC173. @param _to The address whose attribute is being modified. @param _attributeName The attribute name which is being modified. @param _modifiedValueIndex The index of the new value which is being assigned to the user attribute. function modifyAttributeByName(address _to, bytes32 _attributeName, uint _modifiedValueIndex) external;

8.requestMembership

This function will allow an end user to request membership in the group. The function may be designed to wait for admin approval before membership, or may use some onchain criteria to assign membership - such as ownership of some token in a minimum quanta - or check membership of a diﬀerent entity - or create a subscription fee system. /// /// /// /// /// /// ///

@notice Requests membership from any address. @dev Throws if the `msg.sender` already has the token. The individual `msg.sender` can request for a membership and if some existing criteria are satisfied. The individual `msg.sender` receives the token. When the token is assigned, this function emits the Assigned event. @param data the attribute data associated with the member. This is an array which contains indexes of attributes function requestMembership(uint[] data) external payable;

forfeit

This function is designed to allow users to forfeit their membership without needing admin assistance. It can be useful in situations where an individual wants to give up citizenship of one entity in order to become citizen of a diﬀerent entity - similar to modern policy of ‘no dual citizenship’ in some countries. /// /// ///

@dev Throws if the `msg.sender` already doesn't have the token. The individual `msg.sender` can revoke his/her membership. When the token is forfeited, this function emits the Revoked event. function forfeit() external payable;

Electus Whitepaper SpeciďŹ cations

10.

assignTo

This function is intended to be the most common way to add people into the group. It is an admin access only function which can assign membership to any externally owned address or smart contract address. /// /// /// /// /// /// /// /// ///

@notice Assigns membership of an MVT from owner address to another address. @dev Throws if the member already has the token. Throws if `_to` is the zero address. Throws if the `msg.sender` is not an owner. The entity assigns the membership to each individual. When the token is assigned, this function emits the Assigned event. @param _to The address to which the token is assigned. @param data The attribute data associated with the member. This is an array which contains indexes of attributes function assignTo(address _to, uint[] data) external;

11.

revokeFrom

This function is another admin access only function which can be used to revoke memberships from any current member. /// /// /// /// /// /// ///

@notice Only Owner can revoke the membership. @dev This removes the membership of the user. Throws if the `_from` is not an owner of the token. Throws if the `msg.sender` is not an owner. Throws if `_from` is the zero address. When transaction is complete, this function emits the Revoked event. @param _from The current owner of the MVT. function revokeFrom(address _from) external;

Events are logs on the blockchain which help read and track what has happened in a smart contract. The entity ďŹ res the following events.

EVENTS

Electus Whitepaper Speciﬁcations

1. Assigned

This event ﬁres when a new member is added

///

@dev This emits when a token is assigned to a member. event Assigned(address indexed to);

Revoked This event ﬁres when an existing member is removed

///

@dev This emits when a membership is revoked. event Revoked(address indexed to);

ModifiedData This event ﬁres when the data against a certain member is edited

/// ///

@dev This emits when data of a member is modified. Doesn't emit when a new membership is created and data is assigned. event ModifiedData(address indexed to);

In addition to the above, the entity contract will contain the following metadata: { "title": "Organization Metadata", "type": "object", "properties": { "name": { "type": "string", "description": "Identifies the organization to which this MVT represents" }, "description": { "type": "string", "description": "Describes the organization to which this MVT represents"

}

Electus Whitepaper SpeciďŹ cations

HOW ENTITY CONTRACTS WORK The larger circles denote entities, the smaller ones denote members The direction of the arrow denotes the ďŹ&#x201A;ow of the memebership token. An entity can be a member of another entity. A user can be a member of an entity. User cannot issue membership tokens, only entities can. Polls can be deployed to selectively reject votes based on membership criteria on a user

Electus Whitepaper Speciﬁcations

EVENTS AND FUNCTIONS OF A POLL

A poll is a smart contract that records votes coming in from a pre decided voterbase and tallies all the votes. It has some additional functionality to make it behave like a real poll. There is a function which filters out votes coming from outside the voterbase, a function to calculate vote weightage, and a function for executing the consequence of a vote in addition to the final function that tallies the incoming votes. The last function also maintains a record of how many individuals have voted for a certain proposal. Finally, the poll also fires event logs when there is a successful vote, or a failed vote or an unvote.

FUNCTIONS

getProposals

This function is present in the interface to allow easy access to a list of valid proposals in the poll. It returns an array of strings. /// /// ///

@notice gets the proposal names @dev limit the proposal count to 32 (for practical reasons), loop and generate the proposal list @return the list of names of proposals function getProposals() external view returns (bytes32[]);

canVote

This function is present in the interface to allow users to quickly ﬁnd out whether a certain address is permitted to vote. /// /// /// /// ///

@notice returns a boolean specifying whether the user can vote @dev implement logic to enable checks to determine whether the user can vote if using eip-1261, use protocol addresses and interface (IERC1261) to enable checking with attributes @param _to the person who can vote/not @return a boolean as to whether the user can vote

Electus Whitepaper SpeciďŹ cations

function canVote(address _to) external view returns (bool);

getVoteTally

This function helps to read from the poll, how much vote a certain proposal has accrued. /// /// /// ///

@notice gets the vote weight of the proposalId @dev returns the current cumulative vote weight of a proposal @param _proposalId the index of the proposal in the proposals array @return the cumulative vote weight of the specified proposal function getVoteTally(uint _proposalId) external view returns (uint);

getVoterCount

This function helps to read from the poll, how many voters have voted in favour of a certain proposal. /// /// /// ///

@notice gets the no. of voters who voted for the proposal @dev use a struct to keep a track of voteWeights and voterCount @param _proposalId the index of the proposal in the proposals array @return the voter count of the people who voted for the specified proposal function getVoterCount(uint _proposalId) external view returns (uint);

5.calculateVoteWeight

This function calculates the vote weight corresponding to a given voters public address /// /// /// /// ///

@notice calculates the vote weight associated with the person `_to` @dev use appropriate logic to determine the vote weight of the individual For sample implementations, refer to end of the eip @param _to the person whose vote weight is being calculated @return the vote weight of the individual function calculateVoteWeight(address _to) external view returns (uint);

Electus Whitepaper SpeciďŹ cations

winningProposal

/// /// /// ///

This function returns the index of the winning proposal in the poll. @notice gets the leading proposal at the current time @dev calculate the leading proposal at the current time For practical reasons, limit proposal count to 32. @return the index of the proposal which is leading function winningProposal() external view returns (uint);

vote

/// /// /// ///

This is the function which is used by the application to cast a vote.

@notice Handles the vote logic @dev updates the appropriate data structures regarding the vote. stores the proposalId against the user to allow for unvote @param _proposalId the index of the proposal in the proposals array function vote(uint _proposalId) external;

unVote

This function is used by the application layer to remove a vote for a voter who has already cast his vote. /// ///

@notice Handles the unvote logic @dev updates the appropriate data structures regarding the unvote function revokeVote() external;

getName

This function retrieves the name of the poll kept by the owner

/// @notice gets the name of the poll e.g.: "Admin Election for Autumn 2018" /// @dev Set the name in the constructor of the poll /// @return the name of the poll

Electus Whitepaper Speciﬁcations

function getName() external view returns (bytes32);

10.

getPollType

This function retrieves the type of the poll as declared by the owner at the time of deployment. /// /// ///

@notice gets the type of the Poll e.g.: Token (XYZ) weighted poll @dev Set the poll type in the constructor of the poll @return the type of the poll function getPollType() external view returns (bytes32);

11.

getVoterBaseLogic

This function returns a string containing information about which voters are eligible in this poll. The string is ﬁlled in by the owner of the contract while deploying it. ///

@notice gets the logic to be used in a poll's `canVote` function e.g.: "XYZ Token | US & China(attributes in erc-1261) | Developers(attributes in erc-1261)" /// @dev Set the Voterbase logic in the constructor of the poll /// @return the voterbase logic function getVoterBaseLogic() external view returns (bytes32);

12. getStartTime

This function retrieves the time at which the poll starts recording votes. It returns the ﬁrst block after which votes are allowed. /// /// ///

@notice gets the start time for the poll @dev Set the start time in the constructor of the poll as Unix Standard Time @return start time as Unix Standard Time function getStartTime() external view returns (uint);

Electus Whitepaper SpeciďŹ cations

13.

getEndTime

This function retrieves the type of the poll as declared by the owner at the time of deployment. /// /// ///

@notice gets the end time for the poll @dev Set the end time in the constructor of the poll as Unix Standard Time or specify duration in constructor @return end time as Unix Standard Time function getEndTime() external view returns (uint);

14.

getProtocolAddress

This returns an optional array which contains a list of addresses which are used in combination to come up with the voterbase. Ideally this information combined with the voterbase logic should be enough information to decipher the voterbase

/// /// ///

@notice retuns the list of entity addresses (eip-1261) used for perimissioning purposes. @dev the protocol addresses list can be used along with IERC1261 interface to define the logic inside `canVote()` function @return the list of addresses of entities function getProtocolAddress() external view returns (address[]);

15.

getVoteTallies

This returns an array containing the vote tallies of each proposal in the same order as the getProposals function. /// /// ///

@notice gets the vote weight against all proposals @dev limit the proposal count to 32 (for practical reasons), loop and generate the vote tally list @return the list of vote weights against all proposals function getVoteTallies() external view returns (uint[]);

Electus Whitepaper Speciﬁcations

16.

getVoterCounts

This returns an array containing the number of voters voting in favour of each proposal in the same order as the getProposals function. /// /// ///

@notice gets the no. of people who voted against all proposals @dev limit the proposal count to 32 (for practical reasons), loop and generate the vote count list @return the list of voter count against all proposals function getVoterCounts() external view returns (uint[]);

Other than these functions, the polls also log events when certain things happen. Here is a list of events ﬁred by the poll and the rationale behind them:

EVENTS

1. CastVote

This event is ﬁred along with details on the vote value, voter, and vote weight at the time when a vote is added into the tally. /// /// /// ///

@dev This emits when a person votes successfully @param _from User who successfully voted @param _to the index of the proposal he voted to @param voteWeight the weight of his vote event CastVote(address indexed_from, uint8 indexed_to, uint voteWeight);

FailedVote

This event is ﬁred along with details on vote value, voter, and vote weight at the time when a vote is rejected due to non membership of voterbase, or failure to comply with vote consequence(not enough eth balance etc).

Electus Whitepaper SpeciďŹ cations

/// /// /// /// ///

@dev This emits when a person tries to vote without necessary permissions. Useful for auditing purposes. E.g.: This is to prevent an admin to revoke permissions and to calculate the poll result had they not been removed. @param _from User who tried to vote @param _to the index of the proposal he voted to @param voteWeight the weight of his vote event TriedToVote(address indexed_from, uint8 indexed_to, uint voteWeight);

Unvote

This event is ďŹ red along with the voters address at the time when a vote is removed, and the tally is subtracted in the contract. /// /// /// ///

@dev This emits when a person revokes his vote @param _from User who successfully unvoted @param _to the index of the proposal he unvoted @param voteWeight the weight of his vote event RevokedtVote(address indexed_from, uint8 indexed_to, uint voteWeight);

Electus Whitepaper SpeciямБcations

HOW POLL CONTRACTS WORK MEMBER TRYING TO VOTE

MEMBER TRYING TO UNVOTE

NON-MEMBER TRYING TO VOTE

NON-MEMBER TRYING TO UNVOTE REVERTED

CHECK IF MEMBER

VOTE WEIGHT & CONSEQUENCE CHECK

VOTE CONSEQUENCE CHECK FAILS

LOGGED AS VOTED

LOGGED AS UNVOTED

LOGGED AS TRIED TO VOTE

Electus Whitepaper SpeciďŹ cations

FUNCTIONS OF AN ACTION

An action is a smart contract used to enforce the consequences of poll results in the context of capital allocation. This allows governance systems to maintain treasuries and deal with them when necessary:

FUNCTIONS

canExecute

This is a function that calculates an output based on information coming from other smart contracts, and hardcoded logic. The output is an integer, so the space of potential outcomes is huge, if poll outcomes are used as information sources in this functions. /// /// ///

@notice checks whether the action can be executed @dev perform checks and return an appropriate uint corresponding to the executable block @return the number corresponding to the executable block function canExecute() external view returns (uint);

execute

This is a function that uses the output of the above function as a switch case input, in order to trigger certain permissioned actions on the blockchain. This will be useful in consensus driven allocation of capital. /// ///

@notice executes the action @dev executes the action based on the result from `canExecute` function execute() external;

Electus Whitepaper SpeciямБcations

HOW ACTION CONTRACTS WORK CAN EXECUTE FUNCTIONS EXECUTE FUNCTIONS KILL

VOTE

TAP

REDEEM

CAN KILL

CAN VOTE

CAN TAP

CAN REDEEM

BLOCKCHAIN

Electus Whitepaper Electus Token

ELECTUS TOKEN The Electus protocol is an open framework, and because it is an open framework, it will need a governance system of its own. The Electus token will primarily be a representation of governance power in the Electus network. This is done in such a way, that the Electus token has the ability to hold its value through a number of mechanisms. This section explains in detail the governance mechanism and the token economics.

PROTOCOL GOVERNANCE

Electus foundation will set up a governance system called Apex, along the lines of Polis, for the governance of the Electus protocol. There will be an ERC-1261 entity, which gives membership to stakeholders in the Electus protocol. This will be decided by the foundation subjectively based on who is using the protocol in what manner and the number of users that they have. It is not a permissionless system which allows any coin-holder to participate. Additionally, Apex will set up polls from time to time, when consensus collection is needed for making a collective decision on updating the protocol. This is an important aspect of the Electus community, because good governance ensures adaptability and ďŹ&#x201A;exibility of the software repository. The members of Apex take part in polls set up by the Apex admin. Each vote is proportional to the members stake in the Electus token pool. The admin role of the Apex system will be taken up by Electus foundation initially, but in the future, the admin selection may be made a democratic process.

Electus Whitepaper Electus Token

TIME LOCK STAKING

The vote weighing policy on the Apex system will continue to evolve over time. As more and more people join the system, the vote weighing policy will be re evaluated again and again and may be revised. However at the beginning of the Apex system, the Electus foundation has decided upon a certain vote weighing policy. Members of Apex will be able to stake Electus tokens in a time locked system, in order to gain voting power in the Apex deployed polls.

STAKING PROCEDURE

The staking involves selection of a number of Electus tokens, and a period for lock in. Once these parameters are entered, and a lock is committed, the tokens can no longer be unlocked or moved until the commit time has elapsed.

VOTE WEIGHT POLICY

When an Apex poll is deployed, it begins to accept votes from Apex member addresses. The votes are tallied with a vote weighing policy where each vote weight is calculated as follows:

V(n, t) = n Ă&#x2014; min(t, T) Where, n is the number of locked tokens. t is the number of blocks between the poll end time and the lock commitment end time. T is a constant, corresponding to the number of blocks that make up approximately 2 years time.

VOTE WEIGHT POLICY UPDATE

If the community decides in the future that vote weighing should be done in a diďŹ&#x20AC;erent manner, it will require the deployment of a new token. This is because the vote weight consequence (locking, etc.) is coded in the ERC-20 token. The re-deployment of the token will be followed by airdropping the updated token to holders of the old token. Old tokens will be deprecated. Future polls will be weighed with the new policy and the newly airdropped token.

The above description is a summary. Detailed description of the inaugural vote weight policy can be found in the Apex product document.

Electus Whitepaper Electus Token

SUB-STAKING

Sub-staking is a mechanism introduced in the Apex system in order to allow participants to increase their vote share not only on the basis of how many coins they own, but also based on how large the userbase is. Participants on the Apex system are users of the Electus protocol. They use the protocol to create some value or service, and hence they have a user base. Sub staking is a method to get a participants user base to stake on their behalf. An organization having a large number of members can declare that members who stake Electus tokens on behalf of the organization, will receive certain beneﬁts. These beneﬁts can be in multiple forms, such as:

INTERNAL GOVERNANCE INCENTIVES Governing power in exchange for delegated stake.

2.SERVICE DISCOUNTS

A service provider using Electus protocol may oﬀer discounts for users that stake tokens on its behalf.

3.EXCLUSIVE SERVICES staking.

Some services may be kept exclusively available in exchange for

This document does not provide a technical description of how the sub-staking smart contracts function. These technical details will be presented in the Apex product documentation.

Electus Whitepaper Appendix

APPENDIX

EIP 1261 https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1261.md

A standard interface for Membership Veriﬁcation Token (MVT).

2. EIP 1417

https://github.com/ethereum/EIPs/issues/1417

A standard interface for Polls to be used with EIP-1261 (MVT).

EIP 1425

EIP 20

DAICO

https://github.com/ethereum/EIPs/issues/1425

A standard interface for Action Contract for enforcing consensus-driven capital allocation.

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md

A standard interface for tokens.

https://ethresear.ch/t/explanation-of-daicos/465

An idea for improving the ICO model by merging in some of the beneﬁts of DAOs.

Electus Whitepaper Disclaimer

DISCLAIMER This white paper is meant to describe the anticipated plans for the Electus Protocol, which will be an open-source software on the blockchain. Nothing in this document should be treated or read as a guarantee or promise of how the Electus Protocol will develop or of the utility or value of the Electus Token and related components. Any offer or sale of the Electus tokens or any related instrument will occur only based on definitive offering documents.