> For the complete documentation index, see [llms.txt](https://docs.bitsafe.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bitsafe.finance/decentralization-manager/get-started/complete-your-first-governance-action.md).

# Complete your first governance action

[Decentralization Manager overview](/decentralization-manager/overview.md) · [Create a Decentralized Party](/decentralization-manager/get-started/create-a-decentralized-party.md)

### Why start with a generic vote?

A generic vote demonstrates the propose-confirm-execute lifecycle without pausing a service, transferring a token, changing membership, or modifying a threshold. The approved description is recorded through the governance execution result while the action itself has no application-specific side effect.

### Before you start

* A Decentralized Party exists and is visible to all participating nodes.
* The approved governance rules contract is deployed for that party.
* Member parties and the approval policy are correct.
* Each participating operator has the required authentication and Canton rights.
* The selected release supports generic votes through the intended UI or API.
* The confirmation timeout is long enough for the planned test.

### 1. Define the decision

Write a short, unambiguous statement that can be approved or rejected as written. Include no secrets, personal data, mutable contract identifiers, or unsupported promises.

Example development decision:

> Approve the documentation workflow test for this development Decentralized Party.

### 2. Create the proposal

From an authorized member or approved additional proposer, create a generic vote proposal for the intended governance rules and Decentralized Party.

Verify:

* Governance party.
* Proposer.
* Action label.
* Description.
* Governance rules contract.
* Expiry or confirmation window.

The proposer may receive an initial confirmation automatically. Check the supported release behavior before counting confirmations.

### 3. Inspect the pending action

On each member node, open pending governance actions and match the proposal by its contract identifier, label, description, and proposer. Do not confirm an action based on description alone.

### 4. Confirm the proposal

Each participating member reviews the full proposal and submits a confirmation through its own authenticated node. Continue only until the governance rules report that the required approval policy is satisfied.

{% hint style="info" %}
The active governance rules contract determines the required confirmations. Do not rely on a threshold copied from another Decentralized Party.
{% endhint %}

### 5. Execute the approved action

Once the action is eligible, an authorized member submits execution using the proposal and the required confirmation contracts.

Execution should consume the applicable pending confirmation state and create the approved governance execution record.

### 6. Verify the result

Confirm that:

* The proposal is no longer pending after successful execution.
* The confirmations used for execution are no longer active.
* A governance execution result records the action label, description, confirmers, and timestamp or equivalent reviewed fields.
* No application resource or membership state changed as a side effect.
* Every member node can observe the expected result under its permissions.

### Cancel or expire

Before execution:

* A member may revoke an eligible confirmation through the supported cancel flow.
* A stale confirmation may be expired after the contract’s timeout under the supported authorization rules.
* A proposer may be able to cancel the proposal through the applicable interface.

Treat cancellation of a confirmation, cancellation of a proposal, and expiry as distinct actions.

### If governance changes during the vote

Membership, approval policy, or proposer authorization can change while a proposal is in flight. The active rules at execution may alter which confirmations count or whether more confirmations are required. Keep the first test short and avoid concurrent governance changes.

### Troubleshooting

| Symptom                  | Check                                                                      | Safe next action                                                          |
| ------------------------ | -------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| Proposal is not visible  | Governance party, observer visibility, package IDs, and target environment | Confirm the proposal contract before recreating it.                       |
| Confirmation is rejected | Member identity, proposer authorization, expiry, and rules contract        | Refresh the active governance state.                                      |
| Action cannot execute    | Eligible confirmations under the current member set and policy             | Do not substitute unrelated confirmation contracts.                       |
| Proposal expires         | Confirmation timeout and current ledger time                               | Expire or clean up under the approved process, then re-propose if needed. |
| Result is not observable | Party visibility, query interface, and transaction result                  | Capture sanitized contract and update identifiers.                        |

### Technical sources

* [Governance architecture](https://github.com/DLC-link/decentralization-manager/blob/main/docs/ARCHITECTURE.md)
* [Generic-vote walkthrough](https://github.com/DLC-link/decentralization-manager/blob/main/docs/USE_CASES.md)
* [Custom action lifecycle](https://github.com/DLC-link/decentralization-manager/blob/main/docs/CUSTOM_DAML_TEMPLATES.md)

### Related pages

* [Decentralization Manager governance lifecycle](/decentralization-manager/concepts-and-development/governance-lifecycle.md)
* [Decentralization Manager module selection and custom Daml](/decentralization-manager/concepts-and-development/module-selection-and-custom-daml.md)
* [Decentralization Manager package and contract operations](/decentralization-manager/operations-and-reference/package-and-contract-operations.md)

### Next step

👉 **Understand the control flow:** [Decentralization Manager governance lifecycle](/decentralization-manager/concepts-and-development/governance-lifecycle.md).


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.bitsafe.finance/decentralization-manager/get-started/complete-your-first-governance-action.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.