> 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/concepts-and-development/governance-lifecycle.md).

# Governance lifecycle

[Complete the first governance action](/decentralization-manager/get-started/complete-your-first-governance-action.md)

### Lifecycle summary

Decentralization Manager uses an on-ledger propose, confirm, execute lifecycle for governed actions. The active governance rules define who can propose, which members can confirm, how many eligible confirmations are required, when confirmations expire, and who can execute.

### 1. Governance rules

A governance rules contract identifies:

* Governance party.
* Current member set.
* Approval policy.
* Authorized additional proposers where supported.
* Confirmation timeout.
* Other release-specific controls.

Read the active rules before proposing or executing an action. Do not rely on a cached member set during a membership change.

### 2. Proposal

A proposer creates a typed action or generic governed action. A proposal should include a clear label, description, governance party, proposer, and application-specific payload.

The proposer may receive an initial confirmation automatically in some flows. Check the supported action reference before counting confirmations.

### 3. Confirmation

Each eligible member independently reviews the proposal and creates a confirmation. A confirmation binds that member to a specific proposal contract. It should not be reused for another proposal with a similar description.

### 4. Eligibility

An action becomes executable when the current governance rules recognize enough valid confirmations. Eligibility can change if membership, authorization, policy, or expiry changes before execution.

{% hint style="info" %}
The active contract defines the threshold. Do not rely on a count copied from another Decentralized Party.
{% endhint %}

### 5. Execution

An authorized executor submits the proposal and eligible confirmations. Successful execution archives the consumed pending state and performs the action’s defined behavior.

Execution can update application contracts, deploy a governed contract, change membership, record a generic vote, or perform another module-specific operation.

### 6. Result and audit record

The applicable contracts can record a governance result containing the action, proposer, confirmers, execution time, and result data. Audit evidence is limited to the fields and visibility of the deployed package.

### Cancel and expire

| Action              | Purpose                                        | Typical boundary                                    |
| ------------------- | ---------------------------------------------- | --------------------------------------------------- |
| Revoke confirmation | Withdraw one member’s pending approval         | Available only while the confirmation is active     |
| Cancel proposal     | Stop a pending action before execution         | Authorization depends on the action and package     |
| Expire confirmation | Clean up a confirmation after its timeout      | Uses ledger time and package-specific authorization |
| Retry execution     | Recover from an ambiguous or failed submission | Requires reading current contract state first       |

### Concurrent governance changes

A pending action can overlap a change to membership or approval policy. Clients must evaluate confirmations under the rules that the execution contract applies, not the rules that existed when the proposal was first displayed.

### Module-specific actions

The Generalized Governance Core supplies the lifecycle. Token management, custody, and custom Daml modules define the application action that executes after approval. Modules can add payload validation and authorization beyond the shared lifecycle.

### Operator checklist

* [ ] Confirm the governance party and rules contract.
* [ ] Read the current member set and policy.
* [ ] Verify the proposal contract and payload.
* [ ] Confirm as the intended member party.
* [ ] Check eligibility before execution.
* [ ] Query the result and resulting application state.
* [ ] Reconcile failures before retrying.

### Technical sources

* [Architecture](https://github.com/DLC-link/decentralization-manager/blob/main/docs/ARCHITECTURE.md)
* [Use cases](https://github.com/DLC-link/decentralization-manager/blob/main/docs/USE_CASES.md)
* [Custom Daml templates](https://github.com/DLC-link/decentralization-manager/blob/main/docs/CUSTOM_DAML_TEMPLATES.md)

### Related pages

* [Complete the first governance action](/decentralization-manager/get-started/complete-your-first-governance-action.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)
* [Decentralization Manager membership and governance changes](/decentralization-manager/operations-and-reference/membership-and-governance-changes.md)

### Next step

👉 **Choose the governed capability:** [Decentralization Manager module selection and custom Daml](/decentralization-manager/concepts-and-development/module-selection-and-custom-daml.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/concepts-and-development/governance-lifecycle.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.
