proposal of DoEth

description::
Contractors submit Proposals for the development of product or services -- these take the form of smart contracts backed by plain English descriptions. To guarantee the Contractors will not act against the interest of the DAO, a group of signatories validates Contractors’ Proposals then add them to the list of addresses authorized to receive ether (ETH) from the DAO.
[https://blog.slock.it/a-primer-to-the-decentralized-autonomous-organization-dao-69fb125bd3cd#.9wdemu25y]

curator of DoEth

description::
Contractors submit Proposals for the development of product or services -- these take the form of smart contracts backed by plain English descriptions. To guarantee the Contractors will not act against the interest of the DAO, a group of signatories validates Contractors’ Proposals then add them to the list of addresses authorized to receive ether (ETH) from the DAO.
This group of signatories is collectively referred to as a Curator. To maintain decentralization, the Curator can be fired by the DAO at any time and for any reason.
[https://blog.slock.it/a-primer-to-the-decentralized-autonomous-organization-dao-69fb125bd3cd#.9wdemu25y]

6.1. Token.

contract TokenInterface {
mapping (address => uint256) balances;
mapping (address => mapping (address => uint256)) allowed;
uint256 public totalSupply;
function balanceOf(address _owner) constant returns (uint256 balance);
function transfer(address _to, uint256 _amount) returns (bool success);
function transferFrom(address _from, address _to, uint256 _amount) returns (bool success);
function approve(address _spender, uint256 _amount) returns (bool success);
function allowance(address _owner, address _spender) constant returns (uint256 remaining);
event Transfer(address indexed _from, address indexed _to, uint256 _amount);
event Approval(address indexed _owner, address indexed _spender, uint256 _amount);
}

Above is the interface of the Token contract.
The interfaces of these contracts are used in the text of this document to give a simple overview of the functions and variables used in the contract, the full implementation can be found in the appendix (A.1).
This contract represents the standard token as described here: https://github.com/ethereum/wiki/wiki/Standardized_Contract_APIs, and the contract https://github.com/ConsenSys/Tokens/blob/master/Token_Contracts/contracts/Standard_Token.sol was used as a starting point for the contracts creation.

The map balances stores the number of DAO tokens which are controlled by an address.
All contracts which derive from TokenInterface can directly modify this map, but only 4 functions do so: createTokenProxy, transfer, transferFrom and splitDAO.

The map allowed is used to track the previously specified addresses that are allowed to send tokens on someone else’s behalf.

The integer totalSupply is the total number of DAO tokens in existence.
The public keyword creates a function with the same name as the variable which returns its value so that it is publically available.

The function balanceOf returns the balance of the specified address.

The function transfer is used to send token from the sender of the message to another address.

The function transferFrom is used to transfer tokens on behalf of someone else who has approved the transfer in advance using the approve function.

The function approve can be used by the DAO token owner to specify a certain spender to transfer a specified value from their account using the transferFrom function.
To check whether a certain address is allowed to spend DAO tokens on behalf of someone else, the allowance function can be used, which returns the number of tokens which can be spent by the spender.
This is similar to writing a check.

The event Transfer is used to inform lightweight clients about changes in balances.

The event Approval is used to inform lightweight clients about changes in allowed.

6.2. TokenCreation.

contract TokenCreationInterface {
uint public closingTime;
uint public minTokensToCreate;
bool public isFueled;
address public privateCreation;
ManagedAccount extraBalance;
mapping (address => uint256) weiGiven;
function TokenCreation(uint _minTokensToCreate, uint _closingTime);
function createTokenProxy(address _tokenHolder) returns (bool success);
function refund();
function divisor() returns (uint divisor);
event FuelingToDate(uint value);
event CreatedToken(address indexed to, uint amount);
event Refund(address indexed to, uint value);
}

Above is the interface of the TokenCreation contract (A.2).

The integer closingTime is the (unix) time at which the Creation Phase ends.

The integer minTokensToCreate is the number of weiequivalent tokens which are needed to be created by the DAO in order to be considered fueled.

The boolean isFueled is true if DAO has reached its minimum fueling goal, false otherwise.

The address privateCreation is used for DAO splits - if it is set to 0, then it is a public Creation, otherwise, only the address stored in privateCreation is allowed to
create tokens.

The managed account (A.5) extraBalance is used to hold the excess ether which is received after the Creation rate is decreased during the Creation Phase.
Anything that has been paid above the initial price goes to this account.

The map weiGiven stores the amount of wei given by each contributor during the Creation Phase and is only used to refund the contributors if the Creation Phase does not reach its fueling goal.

The constructor TokenCreation initiates the Creation Phase with the arguments minTokensToCreate, closingtime and privateCreation, which will be set in the constructor of the DAO contract (A.3) which is only executed once, when the DAO is deployed.
In order to interact with the contract the following functions can be used:

createTokenProxy.
This function creates one unit of the DAO tokens minimum denomination for every wei sent.
The price is calculated as
Ξc · 20/divisor
Here Ξc is the amount of wei given in order to create tokens, and divisor is calculated depending on the time: 20/P(t) , as described in section 5.
The parameter tokenHolder defines the receiver of the newly minted tokens.

refund.
This function can be called by any contributor to receive their wei back if the Creation Phase failed to meet its fueling goal.

divisor.
This function is used to calculate the price of the token during the Creation Phase in the function createTokenProxy.

The events FuelingToDate, CreatedToken and Refund are used to inform lightweight clients of the status of the Creation Phase.

6.3. DAO.

contract DAOInterface {
Proposal[] public proposals;
uint minQuorumDivisor;
uint lastTimeMinQuorumMet;
address public curator;
address[] public allowedRecipients;
mapping (address => uint) public rewardToken;
uint public totalRewardToken;
ManagedAccount public rewardAccount;
ManagedAccount public DAOrewardAccount;
mapping (address => uint) public paidOut;
mapping (address => uint) public DAOpaidOut;
mapping (address => uint) public blocked;
uint public proposalDeposit;
uint sumOfProposalDeposits;
DAO_Creator public daoCreator;

struct Proposal {
address recipient;
uint amount;
string description;
uint votingDeadline;
bool open;
bool proposalPassed;
bytes32 proposalHash;
uint proposalDeposit;
bool newCurator;
SplitData[] splitData;
uint yea;
uint nay;
mapping (address => bool) votedYes;
mapping (address => bool) votedNo;
address creator;
}

struct SplitData {
uint splitBalance;
uint totalSupply;
uint rewardToken;
DAO newDAO;
}

modifier onlyTokenholders {}

function DAO(
address _curator,
DAO_Creator _daoCreator,
uint _proposalDeposit,
uint _minTokensToCreate,
uint _closingTime,
address _privateCreation
)
function () returns (bool success);
function receiveEther() returns(bool);
function newProposal(
address _recipient,
uint _amount,
string _description,
bytes _transactionData,
uint _debatingPeriod,
bool __newCurator
) onlyTokenholders returns (uint _proposalID);
function checkProposalCode(
uint _proposalID,
address _recipient,
uint _amount,
bytes _transactionData
) constant returns (bool _codeChecksOut);
function vote(
uint _proposalID,
bool _supportsProposal
) onlyTokenholders returns (uint _voteID);
function executeProposal(
uint _proposalID,
bytes _transactionData
) returns (bool _success);
function splitDAO(
uint _proposalID,
address _newCurator
) returns (bool _success);
function newContract(address _newContract);
function changeAllowedRecipients(address _recipient, bool _allowed) external returns (bool _success);
function changeProposalDeposit(uint _proposalDeposit) external;
function retrieveDAOReward(bool _toMembers) external returns (bool _success);
function getMyReward() returns(bool _success);
function withdrawRewardFor(address _account) returns(bool _success);
function transferWithoutReward(address _to, uint256 _amount) returns (bool success);
function transferFromWithoutReward(
address _from,
address _to,
uint256 _amount
) returns (bool success);
function halveMinQuorum() returns (bool _success);
function numberOfProposals() constant returns (uint _numberOfProposals);
function getNewDAOAdress(uint _proposalID) constant returns (address _newDAO);
function isBlocked(address _account) internal returns (bool);
function unblockMe() returns (bool);
event ProposalAdded(
uint indexed proposalID,
address recipient,
uint amount,
bool newCurator,
string description
);

event Voted(uint indexed proposalID, bool position, address indexed voter);
event ProposalTallied(uint indexed proposalID, bool result, uint quorum);
event NewCurator(address indexed _newCurator);
event AllowedRecipientAdded(address indexed _recipient);
}

The original contract used as a starting point for the DAO was: http://chriseth.github.io/browser-solidity/?gist=192371538cf5e43e6dab as described in https://blog.ethereum.org/2015/12/04.
The main feature added is the splitting mechanism and all that comes with it.
This section will define the member variables and functions from the above smart contract one at a time.

The array proposals holds all the proposals ever made.

The integer minQuorumDivisor is used to calculate the quorum needed for a proposal to pass.
It is set to 5, but will double in the case a quorum has not been reached for over a year.

The integer lastTimeMinQuorumMet keeps track of the last time the quorum was reached.

The address curator is set at the creation of the DAO and defines the Curator.

The list allowedRecipients is commonly referred to as the whitelist.
The DAO can only send transactions to itself, the curator, extraBalance and addresses in the whitelist.
Only the curator can add/remove addresses to/from the whitelist.

The map rewardToken tracks the addresses that are owed rewards generated by the products of the DAO.
Those addresses can only be DAOs.

The integer totalRewardToken tracks the amount of reward tokens in existence.

The variable rewardAccount is of the type ManagedAccount , which will be discussed in A.5.
It is used to manage the rewards which are to be distributed to the DAO Token Holders.

Similar, DAOrewardAccount is also of the type ManagedAccount.
This account is used to receive all rewards from projects funded by the DAO.
It will then redistribute them amongst all splitted DAOs as well as itself using the function retrieveDAOReward.

The map paidOut is used to keep track how much wei a single token holder has already retrieved from rewardAccount.

Similar, the map DAOpaidOut is used to keep track how much a single DAO has already received from DAOrewardAccount.

The map blocked stores the addresses of the DAO Tokens that have voted and therefore are not allowed to be transferred until the vote has concluded.
The address points to the proposal ID.

The integer proposalDeposit specifies the minimum deposit to be paid in wei for any proposal that does not include a change of the Curator.

The integer sumOfProposalDeposits is the sum of all proposal deposits of open proposals.

The contract daoCreator is used to create a new DAO with the same code as this DAO, used in the case of a split.

A single proposal has the parameters:

recipient: The address where the amount of wei will go to if the proposal is accepted.

amount: The amount of wei to transfer to recipient if the proposal is accepted.

description: A plain text description of the proposal.

votingDeadline: A unix timestamp, denoting the end of the voting period.

open: A boolean which is false if the votes have already been counted, true otherwise.

proposalPassed: A boolean which is true if a quorum has been achieved with the majority approving the proposal.

proposalHash: A hash to check validity of a proposal.
Equal to sha3(_recipient, _amount, _transactionData).

proposalDeposit: The deposit (in wei) the creator of a proposal has send to submit a proposal.
It is taken from the msg.value of a newProposal call; its purpose is to prevent spam.
Its minimal value is set when the contract is deployed as constructor parameter.
But the creator of the proposal can send any amount above this for the deposit.
The proposals will be sorted by the proposal deposit in the GUI, so in the case that a proposal is considered important, the creator of the proposal can deposit extra ether to advertise their proposal.
The creator of the proposal will be refunded the entire deposit if quorum is reached, if it is not reached the deposit remains with the DAO.

newCurator: A boolean which is true if this proposal assigns a new Curator.

splitData: The data used to split the DAO.
This data is gathered from proposals when they require a new Curator.

yea: Number of tokens in favor of the proposal.

nay: Number of tokens opposed to the proposal.

votedYes: Simple mapping to check if a token holder has voted for it.

votedNo: Simple mapping to check if a token holder has voted against it.

creator: The address of the token holder that created the proposal.

The split data structure is used to split the DAO.
It contains:

splitBalance: The balance of the current DAO minus the proposal deposit at the time of split.

totalSupply: The total amount of DAO tokens in existence at the time of the split.

rewardToken: The amount of reward tokens owned by the original DAO at the time of split.

newDAO: The address of the new DAO contract (0 if not created yet).

Those are all the member variables which are stored in this smart contract on the blockchain.
This information can at any time be read from the blockchain using an Ethereum client.

This section will discuss the functions of the DAO contract in detail.
Many of the member variables that are used in this contract are defined in one of the other three contracts.

There is a special function which is called the constructor.
It has the same name as the contract “DAO.”
This function is only executed once, when the DAO is created.
In the DAO constructor, the following variables are set:
• curator
• daoCreator
• proposalDeposit
• rewardAccount
• DAOrewardAccount
• minTokensToCreate
• closingTime
• privateCreation
• lastTimeMinQuorumMet
• minQuorumDivisor
• allowedRecipients

In order to interact with the smart contract the following functions are used:

fallback function. The fallback function is a function without a specific name.
It is called when the contract receives a transaction without data (a pure value transfer).
There are no direct arguments for this function.
The fallback function will call createTokenProxy passing the address of the sender as an argument during the Creation Phase.
This will trigger the immediate creation of tokens.
In order to protect users, this function will send the ether received after the end of the Creation Phase back to the sender for a time period of 40 days.
After which this function is repurposed to receive ether as simple deposit to the DAO using the function receiveEther.

receiveEther. A simple function used to receive ether.
It does nothing but return true when the DAO receives ether.

newProposal. This function is used to create a new proposal.
The arguments of the function are:
recipient: The address of the recipient of the ether in the proposal (has to be the DAO address itself, the current Curator or an address on the whitelist allowedRecipients).
amount: The amount of wei to be sent in the proposed transaction.
description: A string describing the proposal.
transactionData: The data of the proposed transaction.
debatingPeriod: The amount of time to debate the proposal, at least 2 weeks for a normal proposal
and at least 1 week for a new Curator proposal.
newCurator: A boolean defining whether this proposal is for a new Curator or not.
After checking the sanity of the proposal (see code), this function creates a proposal which is open for voting for a certain amount of time.
The function will return a proposal ID which is used to vote.

checkProposalCode. This function is used to check that a certain proposal ID matches a certain transaction.
The arguments of the function are:
proposalID: The proposal ID.
recipient: The address of the recipient of the proposed transaction.
amount: The amount of wei to be sent with the proposed transaction.
transactionData: The data of the proposed transaction.
If the recipient, the amount and the transactionData match the proposal ID, the function will return true, otherwise it will return false.
This will be used to verify that the proposal ID matches what the DAO token holder thinks they are voting on.

vote. This function is used to vote on a proposal.
The arguments of the function are:
proposalID: The proposal ID.
supportsProposal: A boolean Yes/No does the DAO token holder support the proposal
The function simply checks whether the sender has yet to vote and whether the proposal is still open for voting.
If both requirements are met, it records the vote in the storage of the contract.
The tokens used to vote will be blocked, meaning they can not be transferred until the proposal is closed.
This is to avoid voting several times with different sender addresses.

executeProposal. This function can be called by anyone.
It counts the votes, in order to check whether the quorum is met, and executes the proposal if it passed, unless it is a proposal for a new Curator, than it does nothing.
The arguments of the function are:
proposalID: The proposal ID.
transactionData: The data of the proposed transaction
The function checks whether the voting deadline has passed and that the transactionData matches the proposal ID.
Then it checks whether the quorum has been met (see Eq. 1) and if the proposal had a majority of support.
If this is the case, it executes the proposal and refunds the proposal deposit.
If the quorum has been achieved, but the proposal was declined by the majority of the voters, the proposal deposit is refunded and the proposal closes.

splitDAO. After a new Curator has been proposed, and the debating period in which the token holders could vote for or against the proposal has passed, this function is called by each of the DAO token holders that want to leave the current DAO and move to a new DAO with the proposed new Curator.
This function creates a new DAO and moves a portion of the ether, as well as a portion of the reward tokens to the new DAO.
The arguments are:
proposalID: The proposal ID.
newCurator: The address of the new Curator of the new DAO.
After a sanity check (see code), this function will create the new DAO if it hasnt already been created using the contract daoCreator, updates the split data stored in the proposal and stores the address of the new DAO in the split data.
This function moves the portion of ether that belongs to the caller of this function in the original DAO to the new DAO.
This ether amount is denoted by Ξsender, stated in wei and is calculated as follows:

(eqn.4)

Here Tsender is the amount of tokens of the caller of the function and ΞDAO is the balance of the DAO at the time of the split.
This will be used to effectively create tokens in the newly created DAO and fuel the new DAO just as the original DAO was fueled.
In addition to the ether which is moved to the new DAO, the reward tokens Rsender are also transferred.
They are calculated as follows:

(eqn.5)

Where RDAO is the amount of reward tokens owned by the original DAO at the time of the split.
These tokens allow the new DAO to retrieve their portion of the reward using the retrieveDAOReward function of the original DAO.
At the end of this process all original DAO tokens of the sender account are destroyed.
It is important to notice that in all integer division descirbed above, there may be remainders which stay with the DAO.

newContract. This function can only be called by the DAO itself (through a proposal and a vote) and is used to move all remaining ether, as well as all rewardTokens to a new address.
This is used to update the contract.
The new address needs to be approved by the Curator.

transfer and transferFrom. These functions overload the functions defined in the Token contract.
They do call transfer / transferFrom function in the Token contract, but they additionally transfer information about the already paid out rewards attached to the tokens being transferred using the transferPaidOut function.

transferPaidOut. This function is called when making any transfer of DAO tokens using transfer or transferFrom and it updates the array paidOut to track the amount of rewards which has been paid out already, P, and is calculated as follows:

(eqn.6)

Here Pfrom is the total amount of ether which has been paid out to the from address (the sender), Tamount is the amount of tokens to be transferred and Tfrom is the amount of tokens owned by the from address.

transferWithoutReward and transferFromWithoutReward.
The same as transfer and transferFrom, but it calls getMyReward prior to that.

getMyReward. Calls withdrawRewardFor with the sender as the parameter.
This is used to withdraw the portion of the rewards which belong to the sender from the rewardAccount.

withdrawRewardFor. This function is used to retrieve the portion of the rewards in the rewardAccount which belong to the address given as a parameter.
The amount of ether Ξreward which is then sent to the DAO token holder that
calls this function is:

(eqn.7)

Here ΞrewardAccount is the total rewards ever received by the rewardAccount and ΞpaidOut[sender] is the total amount of wei which has already been paid out to the DAO token holder address, which is given as a parameter.
The reward tokens are further elaborated in section 8.

retrieveDAOReward. This function, when called by a DAO, sends the rewards which belong to this DAO from DAOrewardAccount to either the DAO itself, or to the rewardAccount of the respective DAO in order to be distributed among its token holders, depending on the parameter _toMembers.

changeAllowedRecipients. This function can add/remove an address to/from the whitelist, allowedRecipients.
It can only be executed by the Curator.

halveMinQuorum. When called, halves the minimum quorum in the case it has not been met for over 52 weeks, by doubling minQuorumDivisor.
Also the curator can call this function without the 52 weeks limit, but not more than once every other week.

numberOfProposals. Returns the total number of proposals ever created.

getNewDAOAdress. This is just a helper function to read the address of a newly created ‘split DAO‘.
It gets the proposal ID which was used for the split as input parameter and returns the address of the new DAO.

isBlocked. This function returns true when the address given as parameter is currently blocked to transfer tokens due to an ongoing vote it has participated in, otherwise it returns false.
It also unblocks the tokens in the case the voting deadline of the proposal is over.

unblockMe. Calling isBlocked with the address of the sender.

changeProposalDeposit. This function changes the parameter proposalDeposit. It can only be called by the DAO through a transaction which was proposed and voted for by a majority of the token holders.

6.4. Managed Account

contract ManagedAccountInterface {
address public owner;
bool public payOwnerOnly;
uint public accumulatedInput;
function payOut(address _recipient, uint _amount) returns (bool);
event PayOut(address _recipient, uint _amount);
}

This contract is used to manage the rewards and the extraBalance (as explained in section 5).
It has two member variables:

The address owner, is the only address with permission to withdraw from that account (in our case the DAO) and send ether to another address using the payOut function.

The bool payOwnerOnly specifies whether the owner is the only address which can receive ether from this account.

The integer, accumulatedInput, represents the total sum of ether (in wei) which has been sent to this contract so far.

The fallback function is called when the contract receives a transaction without data (a pure value transfer).
There are no direct arguments for this function.
When it is called it counts the amount of ether it receives and stores it in accumulatedInput.

The function payOut can only be executed by the owner (in our case the DAO).
It has two arguments: recipient and amount.
It is used to send amount wei to a recipient and is called by getMyReward in the DAO contract.

A.1. Token

https://github.com/slockit/DAO/blob/develop/Token.sol

A.2. TokenCreation

https://github.com/slockit/DAO/blob/develop/TokenCreation.sol

A.3. DAO

https://github.com/slockit/DAO/blob/develop/DAO.sol

A.4. Sample Offer

https://github.com/slockit/DAO/blob/develop/Offer.sol

A.5. Managed Account

Aragon-desktop

description::
"Aragon Desktop is an Electron app that runs the Aragon client in a fully decentralized way.
It queries the Ethereum blockchain for the latest version of the app, and then serves it over a local IPFS node."
[https://github.com/aragon/aragon-desktop]

name::
* McsEngl.DoAragon'Aragon-Desktop,

Home-page of DoAragon

description::
"The Home page is a simple landing page that shows you the name of the organization you have loaded, as well as different actions that you can take using the pre-installed apps in your organization. For example, in the organization bella.aragonid.eth we can perform the actions Assign Tokens, Vote, Check Finance, and New Payment."
[https://help.aragon.org/article/17-home]

name::
* McsEngl.DoAragon'Home-page,

Token-Manager of DoAragon

description::
"The Token Manager is the app that is used to manage membership and voting power in an organization. To add members to an organization, it’s as easy as minting and assigning a token to them."
[https://help.aragon.org/article/18-token-manager]

name::
* McsEngl.DoAragon'Token-Manager,
* McsEngl.DoAragon-Dapp.Token-Manager,

Voting-Dapp of DoAragon

description::
"The Voting app is where you can see all open and past votes. You can also use the Voting app to start a new vote and poll tokenholders in the organization about an issue that is important to you."
[https://help.aragon.org/article/19-voting]

name::
* McsEngl.DoAragon'Voting-Dapp,

Finance-Dapp of DoAragon

description::
"The Finance app is used to manage the financial resources of an organization. You can see the balance of each asset the organization owns, a history of past transfers, and also create new transfers from the Finance app."

name::
* McsEngl.DoAragon'Finance-Dapp,

Permissions-page of DoAragon

App-Center-page of DoAragon

Settings-page of DoAragon

info-resource of template

name::
* McsEngl.DoAragon-template'Infrsc,

addressWpg::
* https://github.com/aragon/dao-kits,
* https://help.aragon.org/article/8-about-templates,

template.DEMOCRACY

description::
"A “Token project with Democracy” is an organization where the vote cast by a tokenholder is weighted proportionally to their ownership stake of tokens minted by the organization. For example, if a tokenholder owns 5% of the tokens minted by the organization then their vote will count as 5% of the total votes on a given proposal."
[https://help.aragon.org/article/9-create-a-new-democracy-organization]

name::
* McsEngl.DoAragon-template.Democracy,

template.MULTISIG

description::
"A “Token project with Multisig” is an organization where the resources of the organization are controlled by m-of-n members of a multisig contract, where n is 100% of tokenholders and m is the Min. Quorum percentage of tokenholders that must approve a vote for it to pass. For example, in a 2-of-2 multisig organization, two signatures from two different specified accounts are required for a proposal to pass."
[https://help.aragon.org/article/13-create-a-multisig-organization]

name::
* McsEngl.DoAragon-template.Multisig,

GEN-Prediction (link)

GEN-Predictors-Network

description::
· GPN is the-set of DAOstack-predictors.

name::
* McsEngl.DAOstack'GEN-Predictors-Network,
* McsEngl.DAOstack'GPN,
* McsEngl.GEN-Predictors-Network--of-DAOstack,

reputation of governor

description::
"In the initial protocol, a user’s Reputation score represents their decision-making power.
Each DAO built on the stack has its own Reputation ledger that records the Reputation scores of users in that DAO.
In any given DAO, the weight of a user’s vote, their “voting power,” is equal to their Reputation score in that DAO.
Since any Ethereum address can be assigned Reputation, other DAOs can also be Reputation-holders, allowing authority to be flexibly distributed across sub-agencies or partner organizations."
[https://medium.com/daostack/a-guide-to-daostacks-initial-reputation-protocol-f8365f157f7a]
===
"In DAOstack, Reputation has the following properties:
Burnable: namely, it is not really “yours.” It is yours as long as the owner of the Reputation system does not choose to take it away. With DAOstack, there is a hidden assumption that the Reputation system owner is not a single person, but rather a DAO, whose actions are controlled by the DAO’s Reputation holders.
Non-transferable: namely, an account to which some Reputation was allocated can neither transfer nor burn it."
[https://medium.com/daostack/reputation-vs-tokens-6d7642c7a538]
===
"Reputation is quantifiable (for example, I have over 150 reputation), but it has no monetary value. However, it does represent how much influence a user has on the system, and that’s why it is integral to the system. By increasing the amount of reputation that you have, you have a greater ability to determine the outcome of proposals."
[https://medium.com/ethex-market/how-to-use-the-alchemy-dapp-and-the-genesis-dao-6bfd91a357dc]

name::
* McsEngl.DAOstack'reputation!⇒DAOstack-reputation,
* McsEngl.DAOstack'reputation-points!⇒DAOstack-reputation,
* McsEngl.DAOstack'voting-power!⇒DAOstack-reputation,
* McsEngl.DAOstack-governor'reputation!⇒DAOstack-reputation,
* McsEngl.DAOstack-reputation,

voting of governor (link)

GEN-prediction of DAOstack

description::
"GEN Prediction is a prediction system embedded in DAOstack’s unique DAO governance protocol, which can be accessed through the Alchemy interface. It plays a vital role in solving a basic problem of governance: how to efficiently make decisions that accurately represent the views of large groups of people."
[https://medium.com/daostack/joining-the-gen-predictors-network-f7be2d93754d]
===
"In such a DAO, both members and non-members can stake GEN on a proposal, betting that the DAO will either pass or fail it. They have strong motive to do this since correct predictions will earn them a reward. Essentially, both DAO members and outsiders have the opportunity to offer a DAO their expert attention in exchange for a GEN reward, helping the DAO focus on the highest-leverage proposals and make smarter collective decisions. Put another way, any individual who confidently believes a particular proposal will pass can boost it by purchasing a large prediction stake, directly influencing the DAO’s collective attention. This set of incentives is a core part of what we call the “holographic consensus” approach.
... All organizations built on DAOstack are free to install the GEN prediction system in their own governance schemes, and there are some good reasons to include it: 1) GEN prediction puts an existing network of knowledgeable, active predictors to work for you, 2) the module to activate it is pre-built, and 3) it gives the entire GEN ecosystem skin in the game of your DAO’s success."
[https://medium.com/daostack/on-the-utility-of-the-gen-token-eb4f341d770e]

name::
* McsEngl.DAOstack'GEN-prediction,
* McsEngl.DAOstack-govc'GEN-prediction,

reputation-system of DAOstack

description::
"The Reputation system aims to help DAOs maintain and work towards a set of collective preferences or goals."
[https://medium.com/daostack/a-guide-to-daostacks-initial-reputation-protocol-f8365f157f7a]

name::
* McsEngl.DAOstack'reputation-system,
* McsEngl.DAOstack-govc'reputation-system,

GPN of GEN-token (link)

exchange-ogn of GEN-token

description::
"GEN is available on various exchanges and swap services, such as EthFinex, Liquid, IDEX, Slow.trade, and Coinswitch."
[https://medium.com/daostack/joining-the-gen-predictors-network-f7be2d93754d]

name::
* McsEngl.DvGEN'exchange-ogn,

generic-tree::
* Dchain-exchange-ogn,

specific::
* Coinswitch,
* EthFinex,
* IDEX,
* Liquid,
* Slow.trade,
* Uniswap (https://uniswap.exchange/swap)

info-resource of GEN-token

name::
* McsEngl.DvGEN'Infrsc,

addressWpg::
* {2018-10-07} Ezra-Weller, On the Utility of the GEN Token, DAOstack’s Collective Attention Protocol, https://medium.com/daostack/on-the-utility-of-the-gen-token-eb4f341d770e,

title of proposal

name::
* McsEngl.DAOstack-proposal'title,

description of proposal

name::
* McsEngl.DAOstack-proposal'description,

document of proposal

description::
· an online document describing in details the-proposal.
· the-Url of this document is-recorded on Alchemy.

name::
* McsEngl.DAOstack-proposal'document,

Url of proposal

description::
· the-Url of the-document describing the-proposal.

name::
* McsEngl.DAOstack-proposal'Url,

reputation of proposal

description::
"Why should I ask for reputation when submitting a proposal?
You are not required to ask for reputation when submitting a proposal. However, if you would like to be a decision-maker within the DAO, you should request some. Proposals are ultimately passed or failed based off of the voting of reputation holders; without it, you have no ability to help steer the DAO. Generally, having those who submit and execute proposals be the DAO’s decision-makers helps promote a meritocratic governance system."
"How much reputation should I ask for when submitting a proposal?
It’s ultimately up to you, but the norm within the Genesis DAO thus far is a range from 0 to 200 reputation points, varying based on the scope of the project. If you have a good rationale why you should be rewarded more, you are welcome to articulate that in your proposal."
[https://docs.google.com/document/d/1M1erC1TVPPul3V_RmhKbyuFrpFikyOX0LnDfWOqO20Q/edit]

name::
* McsEngl.DAOstack-proposal'reputation,

funding of proposal

description::
"How much funding for my proposal can I ask for?
Any amount, since the DAO can go into debt, so users need to take this into consideration when both making proposals and voting. We advise to check the total amount of funds in the DAO and consider breaking proposals in pieces not to sacrifice much of it’s funds at once."
[https://docs.google.com/document/d/1M1erC1TVPPul3V_RmhKbyuFrpFikyOX0LnDfWOqO20Q/edit]

name::
* McsEngl.DAOstack-proposal'funding,

proposer of proposal

description::
· proposer is a-stakeholder who creates a-proposal.
===
"Proposers receive an automatic Reputation reward if their proposal passes, because passing a proposal is assumed to contribute to the DAO’s collective goals in some way. Setting this reward to be larger relative to a DAO’s total Reputation will cause the DAO’s Reputation distribution to shift more quickly over time, while setting it to be smaller leads to slower change. As with all of these parameters, each DAO will decide for itself what’s appropriate (possibly even setting the parameter to 0)."
[https://medium.com/daostack/a-guide-to-daostacks-initial-reputation-protocol-f8365f157f7a]

name::
* McsEngl.DAOstack'proposer,
* McsEngl.DAOstack-proposal'proposer,

proposing of proposal (link)

stake of proposal

description::
"stakes can be of any size, and they can be either upstakes or downstakes."
[https://medium.com/daostack/joining-the-gen-predictors-network-f7be2d93754d]

name::
* McsEngl.DAOstack-proposal'stake,

confidence-score of proposal

description::
· the-ratio of upstake to downstake.
===
"If a proposal has a confidence score of 3.0 (there is three times as much upstake on it as downstake), that means the DAO “believes” the proposal’s chance of passing is 3 to 1."
[https://medium.com/daostack/joining-the-gen-predictors-network-f7be2d93754d]

name::
* McsEngl.DAOstack-proposal'confidence-score,

proposal.SCHEME

description::
· schemes are-called generic proposals (types of proposals).
[https://docs.google.com/document/d/1M1erC1TVPPul3V_RmhKbyuFrpFikyOX0LnDfWOqO20Q/edit]

name::
* McsEngl.DAOstack-proposal.scheme,

specific::
* Contribution-Reward, distributes funds/reputation,
* Scheme-Registrar, changes the-schemes of a-DAO,
*

proposal.REGULAR

description::
"All proposals start life in the regular queue, and they are immediately open for predicting — i.e. they may have GEN stakes placed on them by predictors."
[https://medium.com/daostack/joining-the-gen-predictors-network-f7be2d93754d]

name::
* McsEngl.DAOstack-proposal.regular,

proposal.PENDING

description::
"When a proposal’s ratio of upstake to downstake (its confidence score) is above the boosting threshold¹, it is moved into the pending queue. A pending proposal is still open for predicting, and if its confidence score remains above the boosting threshold for longer than the pending period, anyone can boost the proposal."
[https://medium.com/daostack/joining-the-gen-predictors-network-f7be2d93754d]

name::
* McsEngl.DAOstack-proposal.pending,

proposal.BOOSTED

description::
"A pending proposal is still open for predicting, and if its confidence score remains above the boosting threshold for longer than the pending period, anyone can boost the proposal.
To incentivize people to take this boosting action, whoever boosts a qualified proposal receives a modest GEN reward.²
Once admitted to the boosted queue, proposals are closed to predictions and will be passed or failed at the close of the boosted period. Once a proposal is passed, anyone can take the execute action on it to trigger whatever actions the proposal specifies (distributing funds, deploying contracts, etc.). The executor of the proposal is rewarded in GEN similarly to the booster."
[https://medium.com/daostack/joining-the-gen-predictors-network-f7be2d93754d]

name::
* McsEngl.DAOstack-proposal.boosted,

proposal.PASSED

description::
· a-passed-proposal is a-boosted-proposal that at the-end of the-boosted-period has positive confidence-score.
[https://medium.com/daostack/joining-the-gen-predictors-network-f7be2d93754d]
===
"How do I get more visibility for my proposal?
Boosted proposals get the most visibility on a DAO’s landing page. The best strategy to get a proposal boosted is to write a compelling proposal that is aligned with the DAO’s purpose. Asking for feedback in a forum with members of the DAO, reaching out to people individually and publishing your proposal in a community channel can also help to convince people to predict your proposal will pass."
[https://docs.google.com/document/d/1M1erC1TVPPul3V_RmhKbyuFrpFikyOX0LnDfWOqO20Q/edit]

name::
* McsEngl.DAOstack-proposal.passed,

proposal.FAILED

description::
· a-failed-proposal is a-boosted-proposal that at the-end of the-boosted-period has negative confidence-score.
[https://medium.com/daostack/joining-the-gen-predictors-network-f7be2d93754d]

name::
* McsEngl.DAOstack-proposal.failed,
* McsEngl.DAOstack-proposal.rejected,

proposal.EXECUTED

description::
"Once admitted to the boosted queue, proposals are closed to predictions and will be passed or failed at the close of the boosted period. Once a proposal is passed, anyone can take the execute action on it to trigger whatever actions the proposal specifies (distributing funds, deploying contracts, etc.). The executor of the proposal is rewarded in GEN similarly to the booster."
[https://medium.com/daostack/joining-the-gen-predictors-network-f7be2d93754d]

name::
* McsEngl.DAOstack-proposal.executed,

proposal.EXAMPLE

name::
* McsEngl.DAOstack-proposal.example,

addressWpg::
* template: https://docs.google.com/document/d/1nBSIO0tOf1CcfzsyO7dlQd_LiYsV3sKPSQXmCkvibhU/edit,
* tutorial article of Alchemy: https://docs.google.com/document/d/16k4pJ7_iWOnFnCjwyDGZUX492fYtPEeHlxavR_cZw4Y/edit,

creating of DAOstack

description::
"Can I create my own DAO using Alchemy?
Not quite yet, but if you are interested in becoming an Alchemy pilot organization, we can potentially assist you in setting up your own DAO. Contact us at alchemy@daostack.io.
In the future you will be able to:
* Create a DAO within Alchemy
* Funnel initial funds to the DAO
* Mint tokens
* Allocate tokens and reputation to your community
* Edit certain governance protocols, for example how much time before a proposal closes, or what majority is needed for a proposal to pass."
[https://docs.google.com/document/d/1M1erC1TVPPul3V_RmhKbyuFrpFikyOX0LnDfWOqO20Q/edit]

name::
* McsEngl.DAOstack'creating,

proposing of DAOstack

description::
"Anyone can propose and predict, however only people who hold reputation (voting power) in that specific DAO can vote."
[https://docs.google.com/document/d/1M1erC1TVPPul3V_RmhKbyuFrpFikyOX0LnDfWOqO20Q/edit]
===
"How do I submit a proposal?
While it’s possible to go directly to Alchemy and simply submit a proposal through the proposal form, we recommend the following steps:
1) Draft your proposal with the help of our guidelines using this template
2) Share your draft with others that are part of the DAO you will be submitting to, to get feedback
3) Adapt the proposal based on the feedback you receive
4) Submit your proposal in Alchemy by clicking “create proposal”, adding the ETH amount and reputation you are requesting, shall your proposal pass"
[https://docs.google.com/document/d/1M1erC1TVPPul3V_RmhKbyuFrpFikyOX0LnDfWOqO20Q/edit]

name::
* McsEngl.DAOstack'proposing,
* McsEngl.DAOstack-govc'proposing,
* McsEngl.DAOstack-proposal'proposing,
* McsEngl.DAOstack-proposal'submitting,

predicting of DAOstack

description::
"Predict whether a proposal is going to pass or not in the DAO. This helps guide the collective voting process by sorting and prioritizing the proposals. Predicting is also called staking.
... Anyone can propose and predict, however only people who hold reputation (voting power) in that specific DAO can vote."
[https://docs.google.com/document/d/1M1erC1TVPPul3V_RmhKbyuFrpFikyOX0LnDfWOqO20Q/edit]

name::
* McsEngl.DAOstack'predicting,
* McsEngl.DAOstack'staking,
* McsEngl.DAOstack-govc'predicting,
* McsEngl.DAOstack-govc'staking,

voting of DAOstack

description::
"Anyone can propose and predict, however only people who hold reputation (voting power) in that specific DAO can vote."
[https://docs.google.com/document/d/1M1erC1TVPPul3V_RmhKbyuFrpFikyOX0LnDfWOqO20Q/edit]

name::
* McsEngl.DAOstack'voting,
* McsEngl.DAOstack-govc'voting,

genesis-member of eosDAC

description::
"1.11 Genesis Member: means BlockMaker Ltd, a company duly incorporated under the Anguilla International Business Companies Act (c. I20)"
[Constitution 1.11]

name::
* McsEngl.eosDAC'BlockMaker-Ltd,
* McsEngl.eosDAC'genesis-member,

member of eosDAC

description::
· member-of-eosDAC is a register holder.
===
"1.13 Member: means a member of the DAC, entitled, qua Member, to all the benefits and subject to all the obligations set out in the Constitution"
[Constitution 1.13]
===
"3.8.3 Upon transfer of any DAC Token, the transferor thereof shall cease to be a Member of the DAC, to the extent of the DAC Tokens transferred, and the transferee thereof shall be constituted as a Member of the DAC and entitled qua Member to all the benefits, and be subject to all the obligations, set out in this Constitution and in proportion to the number of DAC Tokens transferred to such transferee and, for the purposes of the Constitution, all unrealized and/or undistributed benefits and obligations accruing with respect to the transferred DAC Tokens shall be deemed assigned to the transferee as of the date of transfer."
[Constitution 1.8.3]
===
"3.10 Unregistering of Member: Where expressly permitted by the provisions of the Constitution, a Member may be unregistered by Special Resolution of the Custodian Board whereupon any or all benefits accruing to such Member may be blocked, restricted and/or rendered inoperable, including but not limited to Right to Vote in the DAC and Right to Distribution of Assets of the DAC PROVIDED ALWAYS no amendment, restatement, supplement or other modification of the Constitution, providing any additional basis for the unregistering of a Member, shall be effected other than by Extraordinary Resolution"
[Constitution 3.10]

name::
* McsEngl.eosDAC'member,
* McsEngl.eosDAC'register-holder,

EOS-account of custodian

name::
* McsEngl.eosDAC-custodian'account,

votes of custodian

name::
* McsEngl.eosDAC-custodian'votes,

staked-EOSDAC of custodian

name::
* McsEngl.eosDAC-custodian'staked-EOSDAC,

custodian.SPECIFIC

name::
* McsEngl.eosDAC-custodian.specific,

specific::
* https://members.eosdac.io/vote-custodians,
===
* human,
* legal-entity,
===
* Yeates.Michael,
* Stokes.Luke,
* CREAMer, https://members.eosdac.io/profile/cream5eosdac,
* Won.SungHwan, https://members.eosdac.io/profile/angeljeffrey,
* Kim.Soyoung, https://members.eosdac.io/profile/soyoungkimsk,
* Johnson.Dallas, https://members.eosdac.io/profile/dallasjohnso,
* McKenna.Saro,
* Yang.Jeeho, https://members.eosdac.io/profile/yangjeeho123,
* Jeong.Dennis, https://members.eosdac.io/profile/eosdackorean,
* Allen.Rob, https://members.eosdac.io/profile/spaceinvader,
* Wang.Myra, https://members.eosdac.io/profile/khaleesiwang,
* IDOL-KWON, https://members.eosdac.io/profile/kwonwoosang1,
* Buck.Justin, https://members.eosdac.io/profile/jbucksteiner,
* Bindlish.Raman, https://members.eosdac.io/profile/investingwad,
* Lee.Changhyun, https://members.eosdac.io/profile/lcheosdackor,
* zhou.zicheng, https://members.eosdac.io/profile/eosdaciloveu,
* G-H, https://members.eosdac.io/profile/gyzdmmbtgyge, !!!
* PARK.JASON, https://members.eosdac.io/profile/ha3dqnbwgege,
* Astie.Jonathan, https://members.eosdac.io/profile/cryptdfwplay,
* Block-Tree-Team, https://members.eosdac.io/profile/eosblocktree,
* Lystang.Cory, https://members.eosdac.io/profile/ge4tonzxgege,
* Alcrypto, https://members.eosdac.io/profile/alcrypto1522,
* Bobcat-Weaver, https://members.eosdac.io/profile/gi4tomjygege,
* Muther.Mark-Alexander-Julius, https://members.eosdac.io/profile/sstarcitizen,
* Weisberg.Doug, https://members.eosdac.io/profile/dougweisberg,

custodian.Yeates.Michael

description::
"DACs are the future, lets help build them!
I am part of the launch team of eosDAC and have been serving as an interim custodian since launch.
Block Production
Since before the launch of the chain I have been involved in EOS testnets going right back to the days of the Superhero Network. Was heavily involved in the launch of the mainnet and I now have over 1 years experience running EOSIO software. Since launch I have been leading the block production team at eosDAC and we have consistently been within the top 21.
We currently have over 17 machines running our infrastructure and are running on 5 networks (including 2 live blockchains). I have been working closely with members of Block One to find and fix bugs in the EOSIO software and I earned the bug bounty for finding a bug in EOSIO which could crash any node.
Software Architect
I have been the Senior Developer working on the eosDAC suite of contracts, including the voting, token and supporting contracts. We have built the major contracts which support election, as well as designing the permissions layout and a nicely designed front-end to make it possible for non-technical people to be involved in running a DAC.
Community support
As part of our work in enabling DACs - I have been involved in supporting other DAPPs within the EOS ecosystem as a technical advisor. I was a mentor at the London EOS Hackathon in 2018, and regularly support and engage with the EOS community. I will always fight for the interests of the token holders when representing eosDAC and hope that we can be a strong voice in the future of the chain.
The Future
We have achieved a lot so far at eosDAC and it has been much harder than any of us imagined, but there is still a long way to go. I hope that we can continue the work done so far and prove that the concept of a DAC can work, even across international and cultural boundaries."
[https://members.eosdac.io/profile/mryeateshere]

name::
* McsEngl.eosDAC-custodian.Yeates.Michael,

custodian.Stokes.Luke

description::
"My Role With eosDAC
I was first contacted about joining eosDAC in March of 2018. Since then, I've been actively involved in all aspects of the DAC from block production, to technical management, to development and operational coordination. As a custodian, I'll approve worker proposals that directly add value to the DAC and use our funds wisely to build the foundations we need to be sustainable and enable DACs for many years to come.
Philosophy
I think on-chain governance with decentralized autonomous communities is one of the best paths forward for finding non-violent consensus and improving human well-being. I believe all human interactions should be voluntary and monopolies on violence and currency creation within geographic regions will become archaic relics of our past. Our circle of empathy is expanding towards cooperation and abundance. Technologies like EOS empower us all to function as efficient peer networks instead of dominating hierarchies. Non-violent communication, education, and blockchain consensus can help the right BPs secure and protect this collaborative commons. Entrepreneurship, specialization, economic freedom, and mutually beneficial exchange of value will increase prosperity for us all if EOS is run by the right block producers.
Background
I built my first websites in 1996, got a degree in computer science at UPENN in 2001, and eventually co-founded FoxyCart.com which I sold to my business partner in 2018 after ten successful years to focus full-time on projects in the cryptocurrency space. My first bitcoin purchase was in January of 2013 where I paid $50 to get 2.5 BTC. I have been a Steem Witness (block producer) since May of 2017 and joined the launch team of eosDAC in April of 2018. I like to be involved in and learn from many different cryptocurrency projects like BitShares and SmartCash. Since 2013, I have been educating people about cryptocurrency and explaining the complexities of blockchains in simple terms with projects like http://understandingblockchainfreedom.com/"
[https://members.eosdac.io/profile/lukeeosproxy]

name::
* McsEngl.eosDAC-custodian.Stokes.Luke,

custodian.McKenna.Saro

description::
"I am a member of the core senior team of eosDAC, a block producer on the EOS blockchain and decentralised autonomous community.
I am involved at the executive level with our open-source finance and strategy workstreams with respect to such matters as:
- our governance and legal relationships
- our team and team organisation
- how we encode our Constitution (https://github.com/eosdac/constitution/blob/master/constitution.md) into smart contracts, from a non-technical perspective
- how we, as a decentralised autonomous community - an entity not yet recognised in law - interact with the off-chain world, including how we contract for and pay for services
- how we identify and mitigate financial risk
- how we build the EOS ecosystem, including through supporting other DACs and blockchain projects, and how we evaluate those projects
- how we create open-source financial, workflow and HR systems within the DAC, so as to establish maximal alignment of interests and minimal information asymmetry (https://steemit.com/eosdac/@eosdac/eosdac-announces-first-approved-worker-proposals-prioritising-block-production-and-dac-toolkit)
I am a former investment banking and have had a successful independent corporate finance advisory practice for about 5 years, advising private equity, venture and corporate clients on M&A and strategy.
I was formerly regulated by the UK Financial Conduct Authority and remain an inactive member on their register.
Having seen from within the systemic failure of the banking system during the credit crisis, and its notable failure to show remorse or implement systemic changes, I am passionately and personally committed to the implementation of radical freedom as a means of empowering more people."
[https://members.eosdac.io/profile/greentreesom]

name::
* McsEngl.eosDAC-custodian.McKenna.Saro,

Constitution-v4.2019-03-11 of eosDAC

description::
[A decentralized autonomous community]
Last Modified March 11th, 2019
version 4
Direct Link: https://raw.githubusercontent.com/eosdac/constitution/v4/constitution.md

name::
* McsEngl.eosDAC'constitution'version-4,

custodian of Board (link)

committee of Board

description::
"7.12 The Custodian Board may, by a Resolution, designate one or more committees, each consisting of one or more Custodians to do such things, make such investigations or inquiries and make such reports as determined by the Custodian Board by Resolution."
[Constitution]

name::
* McsEngl.eosDAC-board'committee,

record of Board

description::
"7.10 The Custodian Board may, by Resolution, cause the following records ("Records") to be kept:
7.10.1 minutes of any meetings of Custodians;
7.10.2 copies of all Resolutions, Special Resolution or Extraordinary Resolutions by the Custodian Board; and
7.10.3 such other accounts and records as the Custodian Board considered necessary or desirable inorder to reflect the financial position of the Custodian Board or DAC."
[Constitution]

name::
* McsEngl.eosDAC-board'record,

publication-on-blockchain of Board

description::
"7.8 Immediately upon determination of any matter by Resolution, Special Resolution or Extraordinary Resolution, the Custodian Board shall publish on the blockchain (a) whether or not the matter has been approved or rejected by Resolution, Special Resolution or Extraordinary Resolution (b) the number of votes in favour and against in reaching such determination and (c) the vote of each Custodian with respect to such Proposal."
[Constitution 7.8]

name::
* McsEngl.eosDAC'publication,
* McsEngl.eosDAC-board'publication,

members-referendum-proposal of Board

description::
"7.13 The Custodian Board may, but shall not be required to, by Special Resolution determine, from time to time, that specific issues substantially affecting or capable of substantially affecting the DAC shall be put before the DAC for determination by vote of Members ("Members Referendum Proposal")."
[Constitution 7.13]

name::
* McsEngl.eosDAC'members-referendum-proposal,
* McsEngl.eosDAC-board'members-referendum-proposal,

nomination-directive of eosDAC

description::
"1.14 Nomination Directive: means rules and regulations, approved by Special Resolution, as amended, restated, supplemented or otherwise modified from time to time, prescribing the procedure, qualifications (including staking) and mechanism for the nomination, election and appointment of Custodians to the Custodian Board"
[Constitution 1.14]

name::
* McsEngl.eosDAC'nomination-directive,

resolution of eosDAC

description::
"1.19 Resolution: means a resolution, determination or decision consented to by a majority of Custodians of the Custodian Board casting votes on such resolution, determination or decision"
[Constitution 1.19]
===
"7.7 Unless otherwise stated in the Constitution or any Voting Directive, from time to time, all matters for determination by the Custodian Board shall be determined by simple Resolution."
[Constitution 7.7]

name::
* McsEngl.eosDAC'resolution,

special-resolution of eosDAC

description::
"1.20 Special Resolution: means a resolution, determination or decision consented to by not less than 75% of Custodians of the Custodian Board casting votes on such resolution, determination or decision"
[Constitution 1.20]
===
· 9 of 12 custodians or the "med" permission.

name::
* McsEngl.eosDAC'special-resolution,

extraordinary-resolution of eosDAC

description::
"1.10 Extraordinary Resolution: means a resolution, determination or decision consented to by not less than 83% of the Custodians constituting the Custodian Board casting votes on such resolution, determination or decision"
[Constitution 1.10]
===
· 10 out of 12 custodians or "high" permission.

name::
* McsEngl.eosDAC'extraordinary-resolution,

proposal-directive of eosDAC

description::
"1.18 Proposal Directive: means rules and regulations, approved by Special Resolution, as amended, restated, supplemented or otherwise modified from time to time, prescribing the subject matter of, and the procedure, qualifications and mechanism for, the submission of Proposals by Members or Custodians to the Custodian Board for their consideration and determination"
[Constitution 1.18]

name::
* McsEngl.eosDAC'proposal-directive,

info-resource of proposal

name::
* McsEngl.eosDAC-proposal'Infrsc,

addressWpg::
* https://github.com/eosdac/eosdac-contracts/tree/master/dacproposals,