CF Onboarding & Dev Fund Guide

Install the Daml Package Manager (dpm).

curl https://get.digitalasset.com/install/install.sh | sh

Then create a new project:

dpm new my-project --template daml-intro-contracts

• Full documentation

Before moving to DevNet, you can try the Canton Network Quickstart to run a LocalNet.

git clone https://github.com/digital-asset/cn-quickstart.git
cd cn-quickstart/quickstart
make setup    # choose standard/test mode, OAuth options
make build
make start    # first run triggers setup assistant

Once running, access the local UIs:

Decide how you want to run your validator node before requesting any network access.

All traffic from your validator to the Super Validators must leave from a static egress IP that the SVs add to their allowlists. Provision it before requesting network access.

You need an existing Super Validator (SV) to sponsor your onboarding. Your sponsor will:

• Get your egress IP added to the SV allowlists for each network you join.
• Provide your onboarding secret on TestNet and MainNet. You can't self-serve it on those networks (on DevNet you can, see Step 6c).
• Point you to the Canton software packages needed to set up your node.

Browse active Super Validators and reach out directly. Confirm your sponsor before submitting any allowlisting forms, since their contact details will be required.

• Super Validator directory

Joining TestNet requires approval to join MainNet, so you apply for both at once. Submit your application while you're still working on DevNet: approval runs in parallel, so you don't need to wait until DevNet testing is complete.

• Validator application form
• TestNet / MainNet access request form
• Validator onboarding process docs

Start with the Strategic Roadmap and decide which path your proposal takes:

• Check whether your work responds to one of the 28 published RFPs, and note its number and any maximum amount or duration.
• Gather evidence that the problem is real and important enough to solve: who's affected, and how many of them.
• If you can, sound out the relevant SIG, maintainers, or affected teams early. It makes Step 4 much faster.

• 2026–2028 Strategic Roadmap & RFPs

Write your proposal as a Markdown file using the current template at proposals/_template.md, and don't skip sections. The header asks for the proposal type (RFP-aligned or individual initiative), the RFP / roadmap area, your Champion or Needs Champion, a SIG label, the total funding request in CC, and the project duration. The body covers:

• Abstract: a concise summary of the value delivered to the ecosystem.
• Objective: one specific problem and outcome. Several objectives on different timelines should be separate proposals.
• Implementation mechanics: how it will be built, clear enough for an expert in an adjacent area.
• Architectural alignment & backward compatibility: fit with Canton architecture, priorities, and relevant CIPs, plus any impact on existing systems.
• Milestones and deliverables: each with a committed date, focus, and value metrics.
• Acceptance criteria: based on ecosystem value, not just delivering an artifact.
• Funding: CC per milestone, plus the volatility stipulation.
• Co-marketing, motivation & rationale: expected adoption, who benefits, alternatives considered, and why you're extending what exists rather than replacing it.

What makes a strong proposal

• Proposal template
• AI policy

Once your proposal document is ready:

1. Fork the canton-dev-fund repository and create a new branch.
2. Add your proposal as a Markdown file under proposals/<project-name>.md. This applies to both RFP-aligned proposals and individual initiatives.
3. Open a Pull Request titled Proposal: <Project Name>.
4. Fill in the PR template and its submission checklist, including your SIG label and RFP number if applicable.

Bots check new proposal PRs and apply SIG and RFP labels based on your content, so name both clearly.

• canton-dev-fund repository

Once your PR is open, connect with the Special Interest Group (SIG) that matches your proposal. SIGs are architects, engineers, and domain experts organized by technical area. They review proposals, give feedback to make them stronger, and recommend promising ones to the Tech & Ops Committee. There are two ways to reach them:

Need access to a SIG's discussion channel? Request it with the SIG participation form.

Review

SIG members self-assign proposals in their area from the proposal board. A proposal moves to In Review once a Champion or reviewer picks it up. Promising proposals that still need refinement may be moved to Needs Champion by Core Contributors or Voting Committee members. Anyone in the ecosystem is welcome to leave feedback on the PR.

Why a proposal moves to "Needs Revision"

• Milestones are unclear or not measurable.
• Scope is too broad or underspecified.
• Ecosystem benefit is not clearly demonstrated.
• Adoption metrics or success criteria are missing.
• Security or operational implications need clarification.

Reviewers leave specific feedback in the PR. Update the proposal file directly to address it, and it can move back to In Review for another pass.

Moving toward a vote

When the Champion believes the proposal is ready, it moves to Ready for Vote, where it generally stays for about one week so Voting Committee members, Core Contributors, and the Security Group can read it and raise concerns. If deeper technical review is needed first, it moves to Needs Review by Core Contributors / Security instead. The Voting Group then votes on the PR.

• Proposal tracking board
• Full review process