Governance lifecycle

Complete the first governance action

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.

The active contract defines the threshold. Do not rely on a count copied from another Decentralized Party.

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
• Use cases
• Custom Daml templates

Related pages

• Complete the first governance action
• Decentralization Manager module selection and custom Daml
• Decentralization Manager package and contract operations
• Decentralization Manager membership and governance changes

Next step

👉 Choose the governed capability: Decentralization Manager module selection and custom Daml.