Voting and Counting

Casting a ballot and counting it are two separate steps. You sign your ballot. The app hands ballots to the ledger in batches, and the ledger checks each one before it adds it to the proposal's count.

Casting a Ballot

Your ballot is a contract signed by your key. It carries your vote and your units, and it does not touch the proposal or anyone else's ballot. That is why thousands of members can vote at the same time.

The app lets you vote on a proposal only when:

• it is open and more than 90 seconds from its deadline;
• you were a member, with your current units, when it was made;
• you have not voted on it yet, or its votes may change and your ballot is not counted yet.

The 90 seconds leave time to sign your ballot and for it to reach the ledger before the deadline.

Counting

The app counts. It hands the uncounted ballots of a proposal to the ledger in batches of up to 200, oldest first. It does this whenever something changes on the ledger, and at least every 30 seconds.

For each ballot it is handed, the ledger checks that:

• it belongs to this DAO and this proposal;
• it was cast before the deadline, against the proposal's deadline and rule;
• the voter was a member when the proposal was made, and their units have not changed since;
• it has not been counted before;
• it answers the right question: yes, no or abstain on a decision or a change; on a choice, options that exist, each at most once, and several only where the proposal allows it.

A ballot that fails a check is refused and never counted. The app finds it by splitting the batch, leaves it out, and counts the rest. The ledger then adds the ballots to the proposal's totals and checks whether the rule is met.

When It Is Decided

Rule	Counted	Decided
Settles early	As ballots arrive	As soon as the outcome can no longer change, or at the deadline
Settles at the deadline	As ballots arrive	At the deadline
Votes may change	Only after the deadline	At the deadline

The Grace Period

A ballot signed just before the deadline can reach the ledger just after it. The ledger accepts it, because it was cast in time. So the app waits 3 minutes after the deadline before it makes the final count. Until then the proposal shows Counting.

The final count is the one thing the ledger takes on the app's word: that no ballots are left. It then decides the proposal by the ballots it has.

What the Page Shows

Before the ledger has counted anything, the tally shows the ballots cast, marked (not yet counted). Where votes may change, it keeps showing the ballots cast until the deadline. In the ballot list, members see not counted yet or may change next to ballots the ledger has not counted.

All percentages are shares of the whole vote at the time the proposal was made. On a Decision, the middle figure is what yes must reach. On a Choice, the line under the bars says what the leading option (or, with several picks, any option) needs.

Execution

When a change to the DAO passes, the app executes it on the ledger with the DAO's authority. The ledger checks that the proposal passed and that the change is the one voted on.

• Most changes take one transaction.
• A Members or Shares change is executed in batches of 200 parties. The proposal page shows how many entries are done, for example 400 of 1,000 executed.

Retries and Stuck Execution

If a count or an execution fails, for example because the network is busy, the app tries again: after 30 seconds, then after twice as long each time, up to every 15 minutes. After 5 failures in a row, a passed change shows Not executed yet with the reason, and the app keeps trying. The note goes away once it succeeds.

Who Pays for Counting

Counting and execution are transactions too. Where the DAO pays, they come out of its balance. Where each member pays, they come out of the proposer's own balance. They run even when that balance is empty, and it can go below zero. See Balances and Traffic.