> For the complete documentation index, see [llms.txt](https://docs.builtbydao.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.builtbydao.com/guides/submit-proposal.md). # Submitting Proposals A useful proposal connects a community idea with a clear action. The dashboard lets eligible members prepare proposals, participate in decisions and follow what happens after a result. The aim is to let knowledge close to the work help shape community priorities, while keeping responsibility for a consequential decision visible. Access depends on your membership standing and the kind of proposal. ## Prepare the Idea Open the governance area of the [dashboard](https://app.builtbydao.com). Write a description that explains what you want to change and why. A proposal also needs a category and the specific action being requested. You can save a draft before putting it forward. Review the action, current sponsor requirements and any stake before submitting the wallet transaction. Requirements vary by category; there is no universal stake or approval percentage. A proposal's action must be permitted for its category. For a financial action, read the amount and destination carefully and obtain help if the action details are unclear. Creating a proposal does not by itself fund a project or create a business. ## Understand Who Decides The category identifies the required decision houses: * **Contributors** represent eligible contribution, with bounded contribution, rank and tenure weighting under the applicable rules. * **Investors** participate in the Investor house where the category requires it. * **Council** members record consent or a reasoned objection under that house's rules. Each required non-empty house must independently meet its rules. One combined popularity count is not a substitute for those results. See [Voting](/guides/voting.md) and [Voting Power](/governance/voting.md) for the model. ## Follow the Proposal Through the App 1. **Prepare and submit.** Review the description, category, intended action and stake. Confirm the wallet transaction and wait for its result. 2. **Voting opens.** The authorized process establishes the eligible voter set and voting facts before voting begins. The app shows whether this step has completed. 3. **Eligible members vote.** Read the action, your house, voting power and closing time. A pending transaction is not yet a confirmed vote. 4. **The result is finalized.** After the voting period, finalization records whether the proposal passes the required house rules. 5. **A passed action waits.** The category's cooling-off period must finish before execution is available. 6. **Check execution.** The requested action must still be permitted when carried out. Follow its confirmed result separately from the vote result. The app shows deadlines, house results, stake status and execution state. Use the current values there rather than copying a fixed duration or threshold from an example. Withdrawal before voting opens and separately authorized cancellation have their own rules. ## Begin with a Guild Matter When Appropriate Guilds let members with shared expertise organize around skills, projects and open work. An eligible guild member can open a local proposal. Guild members vote once each; the majority of votes cast decides, and ties do not pass. If an active matter exceeds guild scope, a guild member can escalate it with a reason. The app connects that escalation with the main proposal process. Wider sponsorship, voting and execution requirements still apply. Escalating a local matter is a route to wider consideration, not automatic approval. For example, a guild could consider an approach to shared work, then identify a part that needs broader authority. This is illustrative: choose the actual category and action rules for the matter you are proposing. See [Guilds & Working Groups](/membership/guilds.md) for how the structures fit together and [Proposals](/governance/proposals.md) for the full governance model. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.builtbydao.com/guides/submit-proposal.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.