Proposal Framework v.1.0

In order to increase the security of The DAO and improve its governance model with regards to voting, it is required for the Proposal smart contracts submitted to the DAO to adhere to the following Proposal Framework. Only Proposals that adhere to this Framework will be considered for whitelisting.

1. Proposals must allow a grace period to allow for splitting by throwing an exception if executed during the first 8 days after the voting deadline of the proposal.

2. Proposals must check whether they have reached a quorum of 20% yes votes and a majority support 2 days before the voting deadline. If not, they should throw when executed.

3. To prevent the possibility of double spending, Proposals must accept payment from The DAO once and exclusively, for a fixed amount. Note - this is one time payment to the Proposal, not a one time payment to the Contractor itself. The Proposal code could still disburse the funds to the Contractor on a monthly or daily basis.

4. (optional) Proposals must delay any payouts to the Contractor for the first 18 days during which the DAO should be able to get all ether back from the Proposal.

View the Proposal Framework's Solidity code here

Reasoning:

1. This allows for those who voted 'no' to split after the Proposal is accepted, but before it's executed.  

2. Together with #1, this negates the so called 'yes-bias', as a new quorum requirement is added for yes votes. Both this new yes-quorum and the normal 20% quorum are required for a Proposal to be executed. This also negates sniping/ambush attacks.

3. This rule makes it impossible to misuse a contract to regenerate reward tokens and dilute the reward tokens of split DAOs.

4. This would allow for a second voting round to either confirm the first voting or undo it.

Alternative: Pre-vote

A 'pre-vote' is allowed to replace requirement 2).

As part of this mechanism, no Proposal will be added to the whitelist unless the DAO Token Holders have supported an initial, informal 'pre-vote' with a 15% yes votes as the minimal quorum to be reached, alongside majority support.

Reasoning:

This pre-vote solves the yes bias as 'no' voters can safely split in the case the pre-vote was successful. This also mitigates the ambush/sniping attack, since voters who are against a Proposal but didn't vote in the pre-vote, can now down-vote it during the second round, or split.

This mechanism also reduces the workload of the Curators since they will only need to check addresses (check bytecode and identify Contractors) having had a successful pre-vote.