From e5c79fd17c242bda98a9de30792051f62d1ccd6d Mon Sep 17 00:00:00 2001 From: Nuno Braz <61276105+Nunobrazz@users.noreply.github.com> Date: Tue, 26 May 2026 10:25:07 +0200 Subject: [PATCH] Fix stale DSO delegate references (delegateless automation, CIP-0064) The SV Governance Reference still described execution by an elected "DSO delegate," which was replaced by delegateless automation in CIP-0064. - "Governance Roles": any SV can now execute once the threshold is met, not a designated delegate. - "On-Chain Governance Architecture": removed "the DSO delegate" from the list of authoritative DsoRules state. Source: CIP-0064 (Delegateless Automation). --- docs-main/overview/reference/sv-governance-reference.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs-main/overview/reference/sv-governance-reference.mdx b/docs-main/overview/reference/sv-governance-reference.mdx index 9b3564671..241deac87 100644 --- a/docs-main/overview/reference/sv-governance-reference.mdx +++ b/docs-main/overview/reference/sv-governance-reference.mdx @@ -48,7 +48,7 @@ This threshold ensures two properties: **integrity** (a dishonest minority canno ## Governance Roles -Any SV can propose a governance action by creating a `VoteRequest` on-chain. All other SVs can then cast votes (accept or reject) on that request. Once the vote threshold is met, the DSO delegate executes the action. +Any SV can propose a governance action by creating a `VoteRequest` on-chain. All other SVs can then cast votes (accept or reject) on that request. Once the vote threshold is met, any SV can execute the action. Execution no longer depends on a designated DSO delegate, which was replaced by delegateless automation per [CIP-0064](https://github.com/canton-foundation/cips/blob/main/cip-0064/cip-0064.md). There are two execution paths for actions that require confirmation: @@ -132,7 +132,7 @@ The GSF does not have unilateral control over the network. Its SV node carries t ## On-Chain Governance Architecture -All governance state lives on-chain as Daml contracts. The `DsoRules` contract holds the authoritative record of DSO membership (`svs` map), the DSO delegate, and the current configuration. The `AmuletRules` contract holds the Canton Coin configuration schedule. Vote requests, confirmations, and SV state contracts are all ledger-visible, making governance auditable by any party with access to the Scan app. +All governance state lives on-chain as Daml contracts. The `DsoRules` contract holds the authoritative record of DSO membership (`svs` map), and the current configuration. The `AmuletRules` contract holds the Canton Coin configuration schedule. Vote requests, confirmations, and SV state contracts are all ledger-visible, making governance auditable by any party with access to the Scan app. The decentralized party model means that the DSO party itself has a confirmation threshold of `ceiling(numSVs * 2.0 / 3.0)`. Every transaction signed by the DSO party must be confirmed by at least that many SV participant nodes, enforcing BFT at the Canton protocol layer independent of the application-level voting logic.