Governance of the CIP-0082 Development Fund

Rationale

CIP-0082 describes the purpose of the fund as follows:

The Fund exists to sustain long-term investment in the Canton protocol (core R&D, dev tools, security, audits, reference implementations, DeFi app(s) liquidity seeding, critical infra).

The contributions targeted by this fund are of a nature where they deliver value over extended periods of time, and in conjunction with the rest of the ecosystem. As such, the governance of contributions and grants must consider:

• Long term maintenance of contributions, even if the original contributors do not continue their work.
• The interplay of contributions with the existing ecosystem and other contributors’ plans to evolve it.
• Contributions to core OSS repositories (e.g. Canton, Daml, Splice) depend on the maintainers of those repositories to accept proposed changes.
• Assessment of technical delivery if business or strategic impact is expected only later.

The governance structures laid out here create the structures for the foundation to prioritize and fund strategic topics, while ensuring contributors that are approved for funding are set up to succeed from the get-go, and held to account for delivering quality. This is achieved by involving existing experienced contributors in the process of evaluating and assessing contribution proposals and their delivery, and feeding their recommendations back into the fund governance process.

Involved Bodies

Foundation Tech & Ops Committee

The primary governance body for the 5% ecosystem development fund is the CF Tech & Ops committee. Spending decisions and accountability for the effectiveness of the development fund lie with this group. Its charter would be changed/expanded as follows:

• Any member organization of the CF may attend the committee meetings.
• The committee elects 5 voting members and 2 alternates for administering the development fund.
  • These voting members are elected on a quarterly basis, or through an extraordinary election through the appeals process.
  • These voting members act as the executive of the tech & ops committee. With the exclusion of the appeals process, wherever this doc says that the Tech & Ops committee decides/designates, it’s these voting members that make the decision in practice, based on the input of the overall committee.
  • Minimum three voting members are needed for quorum.
• The voting members meet weekly with an agenda and report decisions back to the full committee.
• The tech & ops committee can deputize other subcommittees.
  • E.g. the existing operations sub-committee.
  • E.g. sub-committees to manage the lists of qualified node as a service or wallet providers.

Appeals & Conflicts

Decisions of the committee can be appealed as follows. This process can also be used to force a vote of the full committee on any matter, up to and including a re-election of the voting members.

• Any 20% of the full committee membership can request an appeal or an extraordinary vote, up to and including a re-election of the voting members.
  • This quorum of 20% is formed by turning up in quorum to a committee meeting or in writing via email, where each member can agree to the appeal by replying to the original email.
• An appeal takes the form of a specific matter to be voted on - e.g. accepting or rejecting a proposal, a change in voting members, etc.
• If a 20% quorum for the appeal is presented, the appeal is added to the agenda of the next committee meeting that is at least 7 days in the future.
• All attendees of that next meeting vote on the appeal.To pass, a ⅔ majority needs to accept the appeal.
• An appeal decision is final. The same matter can not be tabled as an appeal for another quarter. It can also not be overturned by the voting members.

All conflicts within the Tech & Ops committee or its subcommittees are handled by escalating first to the voting members, and second through the appeals process.

Security Subcommittee

The Tech & Ops Committee designates a small, highly trusted subcommittee that handles the governance of security-critical proposals where public discussion could reveal exploitable vulnerabilities in the network.

Core Contributors Group

The Tech & Ops Committee designates a subcommittee called the Core Contributors Group. These are technical members of organizations who have evidenced an ability to make quality technical contributions to the ecosystem already. This group has a dual role:

• It advises the tech & ops committee at a technical level, both by assessing contribution proposals and the quality of delivered proposals. This includes advising the tech&ops committee who else to admit into the Core Contributors Group.
• It directly feeds recommended projects / areas of investment into the tech & ops committee on an ongoing basis.

Members of the Core Contributors Group (or their named delegates) attend the Tech & Ops Committee meetings to fulfill the above role. They may bring along specialists as needed if they themselves don’t have the expertise to advise on a particular discussion.

OSS Maintainers

The OSS Maintainers are those individuals who act as the maintainers of the CF OSS repositories. Governance of the OSS repositories is not covered in this CIP, but will be a separate OSS governance framework which will include the processes for individuals to be admitted as maintainers of the foundation’s OSS repos. The Tech & Ops committee should, by default, admit any org to the Core Contributors Group that has been admitted as a maintainer of one of the CF’s core OSS projects (Canton, Daml, Splice, OSS Wallet).

Note that this is a strictly narrower group than the above contributors group. The contributors group may include entities and individuals that contribute to the ecosystem at large, building language SDKs, tooling, etc., but are not directly contributing to the OSS projects under the foundation. It may also include entities that contribute to the OSS projects under the foundation, but do not maintain them in the sense of managing community contributions. The OSS maintainers are strictly those entities and individuals that lead the development of the OSS projects under the Canton Foundation.

Any decisions on proposals that require changes to the CF’s OSS repos should take particular note of the advice coming from the OSS Maintainers. If the OSS Maintainers disagree with the technical changes to the core OSS repos, they can block the contributions through the OSS governance processes, which are separate to the governance of the CIP development fund. Put differently, the Tech & Ops committee should only fund projects that require changes to the core OSS repos if they have the buyin of the code maintainers of those repos.

Governance Process

The governance manages a pipeline of specific proposals for projects, their approval, funding, and evaluation.

Development Fund Proposals

A Development Fund Proposal is, at its core, a proposal for the CF to fund a specific body of work that adds value to the Canton ecosystem in the areas outlined in CIP-0082. A development fund proposal should generally consist of:

1. A description of an objective that will be met by full delivery of the proposal.
2. Incremental milestones towards that overall objective, usually no larger than one quarter of the expected delivery in size, with time estimates and with acceptance criteria that can be evaluated by the tech & ops committee or the core contributor group.
   1. Where appropriate, including an ongoing “maintenance” milestone that starts applying quarter on quarter after initial delivery.
   2. Grants are generally expected to be weighed towards adoption milestones which generate utility & value to the ecosystem.
3. A description of how the milestones will be delivered, detailed enough for the tech & ops committee and contributor group to assess feasibility.
4. The funding needed per milestone.
5. Any projected co-marketing needs or asks.

In many respects, this is not unlike some recent CIPs that propose rewarding contributions to the ecosystem with incremental SV weights for milestones.

Proposal Generation

There are fundamentally three starting points for proposals:

• Strategic / Tech & Ops: The Tech & Ops committee prioritizes and possibly funds strategic topics and asks for proposals in a lightweight RFP-style process.
• Contributors: Members of the contributor group make concrete proposals for work and funding of that work.
• External: Someone outside the tech & ops committee proposes a topic or project. This avenue is available to anyone from the general public.

Tech & Ops Generated requests for proposals

The Tech & Ops committee may ask the contributor community to come forward with proposals pertaining to a particular strategic objective. It is open to the Tech & Ops committee how much steer and detail they want to give:

• Just an objective.
• Objective and direction for the types of solutions that are requested.
• The funding that’s available for the objective.
• etc.

The Tech & Ops Committee should specify whether the request for proposals is open to all (including externals), or just the core contributors group - the contributor group should be asked for advice on the matter, as reviewing and assessing external proposals comes with its own cost. Such requests for proposals are made publicly and should be responded to with fully fleshed-out development fund proposals that are communicated and stored in the same location as the request. The Tech & Ops Committee can make exceptions to the public process where a public process would be detrimental to the ecosystem. This applies first and foremost to security-critical topics. The security subcommittee may ask specific contributors to work on security topics without consulting the rest of the committee. See section Security.

The Tech & Ops Committee should ask the contributor group to assess the proposals brought forward. The contributor group should assess the proposals for factors, including but not limited to:

• Feasibility
• Quality / value of the proposed solution
• Cost effectiveness of the proposal relative to other solutions
• Adequacy of long term maintenance provisions
  • In particular, should the proposer stop the maintenance, could the core contributors pick it up at the proposed level of funding?
• Security & Scalability implications
• Dependency on changes to core OSS repositories and how likely those are to be a sticking point to achieving the objectives.

If there’s a consensus amongst the contributor group with respect to whether a particular proposal should be taken forward, the Tech & Ops Committee should follow that advice. If there's a split opinion, members of the Tech & Ops Committee should hear the contributor groups’ opinions and make their decision based on those.

The Tech & Ops committee can extend and iterate on requests and proposals until a suitable proposal is found or the committee decides to put a process on hold.

Contributor Generated Proposals

Members of the contributor group may bring forward fully formed proposals. Members of the contributor group should then advise the Tech & Ops committee in the same vein as for proposals generated in response to requests for proposals. Based on the feedback received, the Tech & Ops committee can decide to use the existing proposal as the basis for requesting counter-proposals before making a decision.

External Proposals

External parties can bring forward proposals by emailing an appropriate mailing list. The Tech & Ops committee should request one of its members to become the "champion" of the external contributor and work with them through the process and represent them in the committee. If no champion can be found, the Tech & Ops committee should communicate back to the proposer(s) that the proposal will not be taken forward, meaning the tech & ops committee will not discuss it, and funding from the development fund will not be available.

Receiving Proposals

The Tech & Ops committee will set up a moderated (to prevent spam), but public mailing list to receive incoming ideas/proposals.

Funding, Milestone Assessment, and Continuation

On a quarterly basis, the Development Fund gets a budget in Canton Coin from the foundation board, likely informed by the finance committee. Taking into account existing grant commitments, the quarterly budget specifies how much Canton Coin may be committed to new grants both in the upcoming and future quarters.

The Development Fund budgets and emits in Canton Coin. As such, by default, the funding of all milestones is expected to be expressed in Canton Coin. However, since Canton Coin can be expected to fluctuate relative to USD over time, proposals that run over extended periods should include stipulations how the funding is to be adjusted if the Canton Coin price changes significantly. Specifically:

• For proposals expected to run for <= 6 months, the milestones are by default in Canton Coin and the recipient carries any upside and volatility risk. The proposal MAY stipulate adjustments due to price fluctuations at the discretion of the Tech & Ops committee.
• For proposals with milestones >= 6 months in the future, the proposal MUST explicitly specify how price volatility will be taken into account. What, if any, adjustment mechanism is used is at the discretion of the Tech & Ops committee, it merely has to be part of the proposal to avoid any ambiguity or surprises.

Overall the process proceeds like this:

1. Proposals are set out in Canton Coin terms and selected on that basis.
2. Upon Tech & Ops agreement of a proposal, the milestone funding for the milestone(s) expected to be reached in the next quarter are budgeted for.
3. Every time the contributor claims to have hit a milestone, the Tech & Ops committee assesses this claim relative to the stated acceptance criteria.
   1. They should ask the contributor group for their assessment as part of this if the milestone is for a technical delivery as opposed to reaching a business or growth milestone.
4. Upon completion of a milestone, the Tech & Ops committee votes on continuation, in which case the next quarters’ funding is again budgeted for.
   1. If project milestones were accepted on time, the Tech & Ops committee should continue the project as originally laid out, and apply price change adjustments as specified in the proposal.
5. Should acceptance of reaching a milestone not have occurred by the estimated time, or if the acceptance criteria are under dispute, the Tech & Ops committee can decide to halt a proposal altogether and/or renegotiate it using the same process as for a new proposal.

Emissions and Recourse

See Implementation Mechanics for details. In short, the foundation controls a special party called the “development fund manager” (dfm) that is specified in the Splice/Amulet models and set as part of the Super Validator governance process. The dfm can create a minting right for the grant receiver that allows the receiver to mint the Canton Coin directly. Whenever a recipient has been determined to have met the conditions of their grant, the foundation will create such a mining right.

There is no MSA or other legal agreement between the foundation and grant recipients. The path for recourse in case of disputes is the appeals & conflicts process specified above.

Core Contributor, Security, And OSS Maintainer Funding

Standing items in terms of proposals on a quarterly basis make sure the management of the governance process itself is funded. This includes, but is not exclusive to:

1. A proposal from the security subcommittee to offer funding for security work that is not communicated publicly.
   1. Any undisclosed security work will be later following a security disclosure policy.
2. A proposal from the members of the contributor group for reviewing and assessing proposals and deliverables for the Tech & Ops committee.
3. A proposal from the OSS Maintainers for running repo infrastructure and reviewing contributions.

Bugfixes and Bounties

Note that the standing items above do not include maintenance of the OSS software in the sense of funding bugfixes, or allow the maintainers to put bounties on small topics that don’t merit the whole Proposal process. This is intentional. It is left to the Tech & Ops committee, or the core contributor group to structure a proposal (with quarterly assessment and continuation) to structure a bug and security bounty program or fund continuous bugfixing and software maintenance of the core OSS repos.

Reporting

On a quarterly basis, the Tech & Ops committee must produce a public report covering:

• All new proposals that were considered the past quarter, whether they were accepted or not, and why.
• All active proposals, which milestones they reached, were projected to be reached, but slipped, and whether the projects was continued or halted.
• Impact / quality assessments of the work funded in the last quarter. This should include the assessments of the contributors’ group.
• Full account of funds emitted.
• Full account of existing commitments for the coming quarter, including a forecast of funds emitted assuming all forecast milestones will be reached.
• Current fund balance, changes from last quarter, projection for coming quarter.

On an annual basis, an independent audit and report will be commissioned that covers all of the above on an annual basis.

The resources and funding for these reporting requirements are expected to be taken out of the grant itself.

Development Fund Assessment & Sunsetting

All changes to the development funds’ funding level (5% of all rewards), or indeed discontinuation of the development fund are done through the CIP process.

Launch & Marketing of the Development Fund

Marketing

The development fund is to be considered a marketing tool in its own right. The Tech & Ops committee, in collaboration with the marketing committee, should use the fund to pull in developers and use-cases into the Canton Network ecosystem. To facilitate this, the development fund SHOULD also take into consideration grant proposals for developer marketing and developer relations activities that have as their milestone objectives pulling more developers into the ecosystem or enabling them to go to market and scale.

At a minimum, direct marketing activities of the Tech & Ops committee, in collaboration with the marketing committee should include:

• A PR announcing the launch of the development fund.
• An online presence advertising the grant program and explaining how it works (sample).
• A quarterly campaign aligning around the report touting the achievements of the fund and advertising the funding available in the near future.
• Co-marketing activities with fund receivers as agreed in the proposals.

Initial Call for Topics

Canton Network already has a thriving community and contributors with original ideas on how to improve the ecosystem’s utility and attractiveness. To give all stakeholders an equal chance to feed into the initial set of proposals, the Tech & Ops committee will, as a one-off, communicate a formal call for proposals for a two-week period ahead of the launch of the development fund as defined by approving the first proposal(s). In terms of community preparation for this call, the publication of this CIP itself gives advance notification for the community at large that proposals/ideas should be prepared for submission.

The inbound ideas will be triaged in line with the normal process. However, no voting on proposals shall take place before the two week period is up so that for budgeting purposes the committee has a full picture of the requests for the first quarterly budgeting period.

The voting members (or their delegates) will present an initial bundle of grants to the tech & ops committee for discussion, amend based on input, and then vote on said bundle.

Implementation Mechanics

The goal of the implementation mechanics is to keep book keeping simple by making sure that the Canton Coin denominated milestone based rewards are minted by the recipients directly, and don’t need to go via the balance sheet of the foundation first.

To achieve this, the Splice/Amulet smart contract code will specify a new party Id referred to here as the “Development Fund Manager” (dfm). This is the primary on-chain address referred to in CIP-0082 specification S1 and has the ability to manage minting rights from the development fund.

The 5% allocated to the development fund are not minted each round. Instead they are treated as a new kind of unminted rewards, likely resulting in a special type of “unminted development fund coupon” each round, visible and signed by the dso party, and queryable via Scan.

The dfm party gets the ability to give minting rights from the development fund to parties of their choosing. These parties can then mint the specified quantity of Canton Coin directly to themselves. The process consumes a corresponding amount of unminted development fund coupons.

Reference implementation

The final implementation was merged into the Splice main branch via the following PRs:

• https://github.com/hyperledger-labs/splice/pull/3594
• https://github.com/hyperledger-labs/splice/pull/3705
• https://github.com/hyperledger-labs/splice/pull/3727
• https://github.com/hyperledger-labs/splice/pull/3758
• https://github.com/hyperledger-labs/splice/pull/3888
• https://github.com/hyperledger-labs/splice/pull/3951
• https://github.com/hyperledger-labs/splice/pull/4025
• https://github.com/hyperledger-labs/splice/pull/4052
• https://github.com/hyperledger-labs/splice/pull/4387
• https://github.com/hyperledger-labs/splice/pull/4489

Changelog

• 2025-01-07: Initial draft of the proposal.
• 2026-01-07: CIP approved.
• 2026-03-24: Implementation linked.