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 getting 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.

Your validator node requires a static IP address for all outbound traffic. Provision this before requesting network access, whitelisting is tied to this IP across DevNet, TestNet, and MainNet.

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

• Submit your TestNet and MainNet whitelisting requests to the Featured Applications and Validators committee.
• Provide your onboarding secret on TestNet and MainNet (You do NOT need Secert on DevNet) as you cannot self-serve this on live networks.
• Supply the Canton software packages needed to set up your node.

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

• Super Validator directory

You can submit your MainNet application while still working on DevNet, the 2 to 3 week approval process runs in parallel, so you don't need to wait until DevNet testing is complete.

• Validator application form
• TestNet / MainNet access request form

A champion vouches for your proposal, helps you refine it, and guides it through review. Champions aren't responsible for delivering the work, they help ensure the proposal reaches the bar the committee expects.

To find a champion:

• Cross-reference the SIG Directory to find named individuals with expertise relevant to your work, the best signal of who is engaged in your area.
• Or reach out via approved GitHub PRs to the championing organizations in them. Be specific: describe your proposal in 2 to 3 sentences and ask whether they'd be willing to champion it.

• SIG Directory

All proposals are submitted as Markdown files via Pull Request to the canton-dev-fund repository's proposals/ directory. Use the PR template at .github/pull_request_template.md and don't skip sections. It requires:

• Objective and scope: what problem does this solve, and for whom?
• Technical approach: how will the work be implemented, in depth?
• Architectural alignment: how does it fit Canton's architecture and priorities?
• Milestones and deliverables: what will be produced, and by when?
• Acceptance criteria: how will reviewers objectively verify each milestone?
• Funding request: how much $CC per milestone?

What makes a strong proposal

Once your proposal document is ready:

1. Fork the canton-dev-fund repository.
2. Add your proposal as a Markdown file under proposals/<project-name>.md.
3. Open a Pull Request.

• canton-dev-fund repository

SIG review

Special Interest Groups (SIGs) are architects, engineers, and domain experts organized by technical area, from Daml Language & Developer Tooling to DeFi Protocols, Token Standards, and Node Operations. SIG members may self-assign your proposal and provide feedback. Indicate in your PR which SIG you believe your proposal aligns with so the right reviewers find it quickly. SIG membership is open to any ecosystem participant.

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, GTM, or success criteria are missing.
• Security or operational implications need clarification.

Reviewers leave specific feedback in the PR. Address comments by updating the proposal file directly, and it re-enters the review queue.

Moving toward a vote

When a champion believes the proposal is ready, it moves to Ready for Vote, reviewed by Voting Committee members, Core Contributors, and the Security Group, giving all reviewers time to read and comment before voting begins.

• Proposal tracking board