Skip to content

_template.md

Latest commit

 

History

History
129 lines (94 loc) · 4.38 KB

_template.md

File metadata and controls

129 lines (94 loc) · 4.38 KB

Development Fund Proposal

Author: Status: Draft / Submitted / Under Review Created: YYYY-MM-DD Label: Pick 1 below

  • dapp-integration
  • wallet-apps
  • attestor-pools-daos-multisig
  • defi-liquidity
  • party-portability-data-resilience
  • token-asset-standards
  • tokenomics
  • onchain-governance
  • daml-tooling
  • dar-app-management
  • canton-protocol-multi-synchronizer
  • canton-apis
  • node-deployment-operations
  • global-synchronizer-scaling
  • financial-workflows-composability
  • regulatory-compliance

Champion: List Champion OR need Champion

Abstract

Provide a concise summary of the proposal and the value it delivers to the Canton ecosystem.

Specification

1. Objective

Describe the specific problem being solved and the intended outcome. A proposal should have a single objective and avoid: having several objectives that are delivered on different time frames, deliverables that only have a technology in common, or deliverables have greatly different levels of difficulty. Multiple grant proposals are recommended for these situations.

2. Implementation Mechanics

Explain how the solution will be implemented and what it will do so that a technical expert in an adjacent area will understand what is being built. Convince the reader that your grasp of the problem and solution are broad enough to have confidence in the result. Include technologies, components, workflows, and operational approach.

3. Architectural Alignment

Describe how this work aligns with Canton architecture, ecosystem priorities, and relevant CIPs.

4. Backward Compatibility

Describe any impact on existing systems, integrations, or workflows. If none, state: No backward compatibility impact.

Milestones and Deliverables

Milestone 1: (Name)

  • Estimated Delivery:
  • Focus:
  • Deliverables / Value Metrics:

Milestone 2: (Name)

  • Estimated Delivery:
  • Focus:
  • Deliverables / Value Metrics:

Milestone N: (Name)

  • Estimated Delivery:
  • Focus:
  • Deliverables / Value Metrics:

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

(Add any project-specific acceptance conditions.)

The acceptance criteria is to be based on value to the ecosystem and not delivery of an artifact. For example, a milestone of "10 dApps adopting this capability by August" shows value. A milestone of "Deliver this feature with 100% of CI/CD tests passing" does not demonstrate ecosystem value.

Funding

Total Funding Request:

Payment Breakdown by Milestone

  • Milestone 1 (Name): XX CC upon committee acceptance
  • Milestone 2 (Name): XX CC upon committee acceptance
  • Milestone N (Name): XX CC upon final release and acceptance

Volatility Stipulation

If the project duration is greater than 6 months: The grant is denominated in fixed Canton Coin and will require a re-evaluation at the 6-month mark.

If the project duration is under 6 months: Should the project 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, the implementing entity will collaborate with the Foundation on:

  • Announcement coordination
  • Case study or technical blog
  • Developer or ecosystem promotion

(Add any specific commitments.)

Motivation

Why is this valuable to the Canton ecosystem? Describe the ecosystem impact, expected adoption, or strategic importance. Provide an estimate of the portion of the ecosystem that benefits (e..g, 50% of dApps use TypeScript and we expect 50% of them will use our TypeScript library).

Rationale

Why is this the right approach to deliver that value? Explain design decisions, alternatives considered, and why this solution is preferred. In particular, explain how this proposal fits into the existing ecosystem tooling, libraries, frameworks, etc. If this is a proposal to replace something that exists, then explain why the proposal cannot fit into the existing component by extending what exists. The default approach should be to extend what exists.