The Proposal Lifecycle

Every decision a ship makes — sending funds, adding a member, changing a rule — travels the same path: it is submitted, sponsored, voted on, given a grace period, and finally processed. Understanding that path is the key to understanding how the crew actually steers.

The state machine

Here is the full journey of a healthy proposal, and the off-ramps where it can end early:

Submitted → (sponsor) → Voting → Grace → Ready → Processed
                                       ↘ Defeated  (failed quorum or majority)
                                       ↘ Expired   (processing window passed)
                ↘ Cancelled            (submitter or GOVERNOR)

DAO Ships tracks nine possible states for a proposal:

The four actions

Four distinct actions move a proposal along. Different people can perform them.

1. Submit

Anyone can submit a proposal. It carries the action to perform (encoded as a batch of one or more steps), a proposal type, and a short text description. A submitter may need to pay a small proposalOffering in QUAI as an anti-spam measure — though a member who can self-sponsor skips the offering entirely.

2. Sponsor

A proposal in Submitted state does nothing until it is sponsored. Sponsoring requires the sponsor to hold at least the sponsorThreshold in Shares. To resist flash-loan attacks, the check reads the sponsor's voting power as of one second in the past — you cannot borrow Shares and sponsor in the same instant. Sponsoring opens the Voting window.

3. Vote

While the proposal is in Voting, Share holders cast yes or no votes weighted by the Shares they held when voting opened. The system tracks both a head count and the share-weighted balance behind each side.

4. Process

After voting ends and the Grace period elapses, anyone — it is permissionless — calls processProposal. If the proposal passed, its action executes. If it failed, processing simply marks it Defeated and clears it from the queue.

The eight proposal types

A proposal carries a proposalType tag (0 through 7) that describes its intent. The tag is primarily for indexers and front-ends — it lets a UI label and filter proposals — while the actual on-chain effect is determined by the encoded action. Typical categories a ship uses are:

1. Spend treasury funds
2. Mint Shares or Loot to members
3. Burn Shares or Loot
4. Add, change, or remove a Navigator
5. Update the guild-token set for ragequit
6. Change governance parameters
7. Run an arbitrary governance action via executeAsGovernance
8. Signal or metadata-only proposals

Parallel processing — no waiting in line

Many DAO frameworks force proposals through a sequential queue: proposal #5 cannot execute until #4 has been processed. DAO Ships removes that bottleneck. Any Ready proposal can be processed in any order, independently of the others.

This matters in two ways:

• Throughput. A busy ship can have dozens of proposals in flight at once.
• Resilience. If one proposal's action reverts, it is recorded as failed and simply set aside — it cannot block the rest of the queue. Even a Defeated proposal can be processed (with empty data) to clear it.

Related

The states above depend on a handful of tunable parameters — quorum, grace, retention, and more. Those are covered next in Quorum, Grace & Retention.