Development Fund Proposal
Author: Eric Mann (Avro Digital)
Status: Approved
Created: 2026-04-15
Approved: 2026-05-06
Label: onchain-governance
Champion: Avro Digital
Abstract
Avro Digital requests 2,500,000 Canton Coin (CC) to design, implement, and prepare for rollout a standalone SV governance dApp that separates non-operational governance voting from node operations on the Global Synchronizer.
Today, the governance experience is embedded in the Splice SV application and tied to the same identity path used for node automation. This project extracts that workflow into a dedicated dApp, introduces the minimal Daml/CIP changes needed for a separate governance-voting identity for non-operational votes, proves external signing through the Canton wallet stack, and packages the result for SV-operated deployment alongside existing SV node infrastructure within the current one-vote-per-node model.
This proposal is intentionally narrow. It does not attempt to redesign governance, expand direct on-chain voting to a broader stakeholder set, or introduce a general-purpose external identity platform. Its purpose is to deliver the technical separation and operator-ready UX needed for future governance evolution.
Specification
1. Objective
Deliver a standalone governance dApp and supporting Daml changes that prepare for a future separation of governance voting from node operations while preserving the current one-vote-per-node model through Phase 1.
The project includes:
- A standalone governance dApp derived from the existing SV governance flow
- Daml/CIP template infrastructure that enables a future distinction between operational and governance vote categories via configuration, without activating that split in Phase 1
- External-signing support through the Canton wallet stack using CIP-103 compatibility
- Operator-administered governance-voter/key binding for the current SV workflow
- UX improvements that adapt the existing governance UI rather than rebuilding it from scratch
Explicit non-goals:
- Broader redesign of governance rights or governance process
- Direct on-chain voting by a wider stakeholder set
- Tokenomics changes
- Independent voter-hosted deployment
- A generalized external identity platform
- Long-tail UX work such as mobile apps, notification systems, or broader collaboration workflows
These should be treated as follow-on work, not as implied scope within this proposal.
2. Implementation Mechanics
The implementation is organized around four tightly scoped workstreams:
Daml and CIP work
The current DsoRules model assumes governance voting follows the operator identity path. This project introduces configurable vote-category infrastructure while preserving existing one-vote-per-SV semantics and the current voting path through Phase 1.
The Phase 1 model is:
- Each SV retains one vote
- All votes continue to be exercised by the same voters through the same identity path as today
- The on-chain model introduces template infrastructure that can support a future split between operational and governance vote categories via configuration
- Phase 1 configuration preserves the status quo: no vote-category routing is activated in production or exposed in the dApp UI
- A follow-on CIP and governance process will be required before specific vote types are reassigned to operational or governance paths
The contract work documents an intended operational versus non-operational categorization that will be finalized during contract review and CIP drafting:
- Operational votes (future category) are those directly tied to running, securing, or coordinating the SV node and its required operational responsibilities. Examples include emergency operational actions, release coordination, or upgrade-related actions where the SV operator is responsible for executing the resulting operational change.
- Non-operational votes (future category) are governance decisions that do not themselves require the SV operator's day-to-day operational authority to carry out. Examples include voting on governance proposals, committee-level decisions, or other policy choices where the vote can be separated from subsequent node operations.
The Phase 1 objective is not to activate this split or settle every boundary case up front. It is to land reviewable template infrastructure and CIP framing so a future CIP can reassign specific vote types without a disruptive contract rewrite, while the dApp work in later milestones focuses on dAppifying the current voting process under the existing model.
This requires a focused CIP and corresponding changes in splice-dso-governance.
Standalone governance dApp
The governance experience will move into a separate web application rather than remain embedded in the SV-only surface. The dApp will:
- Display pending proposals and vote history
- Make vote actions explicit and auditable
- Show the authority path used for each vote
- Support clearer review and confirmation workflows
- Reuse the existing governance UI wherever practical
The dApp must support both the read path and the write path. Phase 1 assumes proposal discovery and vote-state inspection through existing API surfaces such as Scan rather than broad public visibility of the underlying contracts.
External signing
Rather than building a custom wallet path, the project will use the existing Canton wallet stack:
@canton-network/dapp-sdk- Wallet Gateway
- A compatible signing-provider or wallet path
The target is CIP-103-compatible external signing for governance-voter parties whose confirming participant is not the SV node.
Deployment model
The initial rollout remains conservative:
- SV-operated, with the dApp UI and supporting services packaged to run alongside existing SV node infrastructure
- One vote per node
- Used by current SV operators and governance voters
- Packaged for staged rollout alongside the existing SV UI
The governance-voter party does not need to be hosted on the SV node.
The user model also stays intentionally narrow. Phase 1 assumes operator-administered binding between the approved governance voter and the key or wallet path used for governance voting; it does not introduce self-service registration or a generalized external voter registry.
3. Architectural Alignment
This proposal is aligned with current Canton and Splice architecture in four ways:
- It preserves the existing one-vote-per-node model while decoupling governance voting from node automation, which reduces operational coupling without forcing a broader governance redesign into the same project.
- It builds on the existing Splice governance stack and introduces a narrow, reviewable CIP plus targeted Daml changes rather than a disruptive contract rewrite.
- It uses the Canton wallet stack and targets CIP-103-compatible external signing instead of inventing a parallel signing system, which keeps the implementation aligned with the ecosystem's wallet direction.
- It contributes the output to the open-source Canton/Splice ecosystem under standard open-source licensing, making the work reusable for future governance evolution.
4. Backward Compatibility
Backward compatibility is a core design constraint for this project:
- The initial rollout preserves one-vote-per-node semantics and the current voter set.
- All votes continue on the existing operator identity path through Phase 1.
- Template infrastructure prepares for a future governance-voting identity path without requiring activation in the initial rollout.
- Phase 1 configuration keeps deployment fully compatible with today's SV workflow.
- The dApp is packaged for staged rollout alongside the existing SV UI rather than requiring a hard cutover.
Milestones and Deliverables
Milestone 1: Governance-Voting Identity and CIP
- Estimated Delivery: Month 2-3
- Focus: Introduce configurable vote-category infrastructure in the on-chain model while preserving current voting behavior
- Deliverables / Value Metrics:
- Focused contract review and minimal contract-change package covering the governance surfaces that must change and any new templates or choices proposed in the CIP
- Daml templates and choices that support a future operational versus governance vote split via configuration, with Phase 1 defaults keeping all votes on the current operator identity path
- Documented intended operational versus non-operational vote categorization in the CIP, with activation of any split deferred to a follow-on CIP and governance process
- Unit and integration tests for the template infrastructure under the status-quo configuration
- CIP draft submitted for review
- Draft or submitted Splice PR for the contract-side implementation
- Acceptance conditions:
- Configurable vote-category template infrastructure is demonstrated in code under the status-quo configuration
- The CIP documents intended operational versus non-operational categorization without activating any split
- A follow-on CIP is identified as the path to reassign specific vote types to operational or governance paths
- CIP and Splice PR artifacts are submitted for ecosystem review
Milestone 2: External Signing Proof of Concept
- Estimated Delivery: Month 3-4
- Focus: Prove wallet-based external signing for governance votes
- Deliverables / Value Metrics:
- Initial standalone governance dApp integrated with
@canton-network/dapp-sdk
- Wallet-gateway-backed signing path for governance votes
- End-to-end non-production demo showing an externally signed non-operational governance vote recorded on-chain
- Integration notes for a reference implementation path and a partner-compatible CIP-103 path
Milestone 3: Deployment Packaging and Operator Workflow
- Estimated Delivery: Month 4-5
- Focus: Package the dApp for real operator use in the current model
- Deliverables / Value Metrics:
- Deployment packaging for the governance dApp and minimal supporting services in an SV-operated, node-adjacent model
- Operator-administered governance-voter/key binding workflow
- End-to-end read and vote flows integrated into the standalone application
- Existing governance UI flows adapted into the dApp packaging model with only the changes required by the new signing and routing model
- TestNet or equivalent staging deployment with operator and ecosystem validation
- Scan API extensions for any governance dApp read-path requirements
- Successful staging validation by at least one current SV operator and one governance voter completing the intended end-to-end vote flow
Milestone 4: UX Hardening and Rollout Readiness
- Estimated Delivery: Month 5-6
- Focus: Make the dApp safe for regular governance use and ready for rollout
- Deliverables / Value Metrics:
- UX improvements based on feedback from current operators and governance users
- Confirmation, diff, and audit views for high-confidence vote execution
- Validation against at least one realistic wallet interoperability path
- Operator documentation and rollout guidance for staged production adoption
- Incorporated review feedback from representative governance users and operator stakeholders, with a rollout package suitable for staged adoption
Acceptance Criteria
The Tech & Ops Committee will evaluate completion based on:
- Deliverables completed as specified for each milestone
- Demonstrated functionality or operational readiness
- Documentation and knowledge transfer provided
- Alignment with stated value metrics
Project-specific acceptance conditions:
- Configurable vote-category template infrastructure is demonstrated in code, with Phase 1 configuration preserving the current single-identity voting path and voter set
- The intended operational versus non-operational categorization is documented in the CIP as preparatory design, with activation of any split deferred to a follow-on CIP
- The CIP remains narrow, reviewable, and grounded in an explicit contract review plus stub design
- Phase 1 rollout preserves the current voting model without activating vote-category routing in production or the dApp UI
- Backward compatibility is preserved throughout the Phase 1 rollout
- CIP and implementation artifacts are submitted for ecosystem review
- A governance vote can be signed externally and recorded on-chain
- The governance voter can confirm through a participant that is not the SV node
- The dApp uses the Canton wallet stack rather than a custom signing mechanism
- The dApp can be deployed alongside an SV node
- A current SV operator and governance voter can complete the intended vote flow end to end
- One-vote-per-node semantics remain unchanged
- Staging validation includes successful use by representative operator and governance-voter participants
- Operator-facing documentation and rollout guidance are complete
- The dApp is ready for staged TestNet/MainNet rollout, subject to normal governance and release approvals
Funding
Total Funding Request: 2,500,000 CC
This request reflects:
- Daml/CIP design and implementation on a governance-critical path
- dApp extraction and wallet integration
- Operator-ready deployment packaging and UX hardening
- Upstream contribution, review, and integration overhead
- Targeted architectural consulting to de-risk the contract and integration design
Payment Breakdown by Milestone
- Milestone 1 (Governance-Voting Identity and CIP): 550,000 CC to Avro Digital upon CIP/design package and contract implementation submission for review
- Milestone 2 (External Signing Proof of Concept): 450,000 CC to Avro Digital upon committee-verifiable externally signed vote demo
- Milestone 3 (Deployment Packaging and Operator Workflow): 550,000 CC to Avro Digital upon staging deployment in the SV-operated model and end-to-end operator workflow validation
- Milestone 4 (UX Hardening and Rollout Readiness): 450,000 CC to Avro Digital upon rollout-ready release package, documentation, and operator validation
The milestone amounts above total 2,000,000 CC and fund Avro Digital's implementation workstream. The remaining 500,000 CC is paid to Digital Asset as described below.
Digital Asset Consulting Payment Breakdown
- Milestone 1: 250,000 CC paid to Digital Asset upon acceptance of milestone 1 deliverables
- Milestone 4: 250,000 CC paid to Digital Asset upon acceptance of milestone 4 deliverables
Volatility Stipulation
The project is expected to complete within 6 months. Should the timeline extend beyond 6 months due to Committee-requested scope changes, any remaining milestones must be renegotiated to account for significant USD/CC price volatility.
Co-Marketing
Upon release, Avro Digital will collaborate with the Canton Foundation on:
- Announcement coordination for milestone and release communications
- A case study or technical blog covering the governance architecture, wallet integration, and rollout approach
- Developer and ecosystem promotion tied to the new governance workflow
Motivation
The near-term governance problem is that participation is still operationally coupled to running a node.
Today, a relatively small number of SV nodes represent a larger and growing set of funded organizations. That arrangement is still workable, but it places node operators in the middle of a governance workflow that should have a clearer and more dedicated path. The existing SV application is also not the right long-term place to iterate on governance-specific signing flows, authority boundaries, and user experience.
A focused technical step is available now: extract governance into a standalone dApp, separate non-operational governance voting from node operations, and prove standards-aligned external signing without taking on a broader redesign of governance rights or stakeholder representation in the same project.
This gives the ecosystem a cleaner technical foundation for future governance evolution while delivering immediate practical value to current SV operators and governance participants.
Rationale
The key design choice is to separate governance from node operations without trying to solve every future governance question in the same grant. A standalone dApp gives governance review, signing, and audit flows their own surface, while the narrow Phase 1 scope preserves one-vote-per-node semantics and keeps the CIP and implementation reviewable.
Using the Canton wallet stack and reusing the existing governance UI wherever practical both reduce delivery risk. The project can focus on the contract, signing, read-path, routing, and deployment changes that matter now instead of spending the grant on a bespoke wallet path or a full UI rewrite.
Avro Digital is proposing this as a focused, upstream-collaborative first step grounded in direct Scala, Daml, and production-infrastructure experience.
Team
- Eric Mann: Implementation lead across application architecture, integration, and deployment packaging
- Randy Harrison: CTO responsible for CIP drafting, review, and upstream design coordination
- Ian Hensel: Head of Product responsible for operator workflow validation, product feedback, and rollout planning
Risks and Mitigations
| Risk | Likelihood | Impact | Mitigation |
|---|
| Defining the operational/non-operational vote categorization is harder than expected | Medium | High | Document the intended categorization in the CIP without activating the split in Phase 1, and defer reassignment of specific vote types to a follow-on CIP |
| CIP/review cycle takes longer than planned | Medium | High | Keep the initial contract proposal narrow and start review early |
| Contract design changes during upstream review | Medium | Medium | Treat the current contract shape as representative, not fixed |
| Wallet interoperability is rough in the first implementation | Medium | Medium | Validate one concrete wallet/gateway path before broadening scope |
| Scope drifts toward full external stakeholder voting | High | High | Keep the project explicitly constrained to one vote per node |
| UI hosting and governance-voter party hosting get conflated | Medium | Medium | Keep SV-operated UI deployment in scope while separately allowing governance-voter confirmation through a different participant |
| Production rollout timing depends on external release windows | Medium | Medium | Make rollout readiness, not forced production timing, the milestone target |
Maintenance and Sustainability
The output of this grant is intended to live in the open-source Canton/Splice ecosystem. Avro Digital expects to maintain the work as part of its continuing Canton contribution efforts, but the code and documentation will be structured so that other contributors can continue the work if needed.
Open Source and Licensing
All software deliverables will be contributed under Apache 2.0 to the relevant open-source repositories. Any CIP text will be submitted under the standard licensing used by the canton-foundation/cips repository.
