Proposal: Continuous Security Partnership for Canton Core Infrastructure and Ecosystem x Vulsight

[salmaansaeed94]

Development Fund Proposal Submission

Proposal file:
Link to the proposal added in this PR proposals/Continuous-Security-Partnership-for-Canton-Core-Infrastructure-and-Ecosystem.md

Summary

The proposal is for a continuous security partnership for Canton's core infrastructure and ecosystem by VulSight, structured in two stages.

Stage 1 is a pay-per-vulnerability core protocol audit of Canton's Scala codebase at zero upfront cost to the Foundation - VulSight is paid only for confirmed, exploitable vulnerabilities.

If VulSight finds nothing, Canton does not pay anything but gets a complete audit report. The Foundation's downside is zero.

Stage 2, dependent on Stage 1 demonstrating value, delivers permanent ecosystem security capabilities: Public Daml security research knowledge base, quarterly protocol re-audits, ecosystem application audit capacity, and incident response retainer.

Value to the Canton ecosystem:
Stage 1 carries no risk for the Foundation.

Stage 2 only moves forward if Stage 1 clearly proves its value. This directly supports the Development Fund's mandate (CIP-0082) to invest in security as a core public good

The maximum commitment for Stage 2 is $65,000, and in return the Foundation gets long term security support for the Canton ecosystem. This includes permanent open source security research, three quarterly re-audits, nine security office hours sessions, and incident response support.

Canton is evolving continuously. New updates like CIP-0089, CIP-0092, and CIP-0094 each introduce new paths, features, and risks, which means the attack surface keeps changing too.

That is why VulSight’s Stage 2 matters. Instead of starting from scratch every time, it keeps security review ongoing and carries forward everything learned in Stage 1. This means each quarterly reaudit builds on real context and deeper understanding, rather than repeating the same work from zero.

Overall, this is a very cost effective way to build strong, ongoing security coverage across the Canton ecosystem.

---

Checklist

• Proposal file added under /proposals/
• Milestones and funding amounts defined
• Acceptance criteria included
• Alignment with Canton priorities described

---

Notes for Reviewers:

Canton Network is important infrastructure for institutional finance. The Canton Foundation created this Development Fund under CIP-0082 because it sees security as a core public good. The fact that multiple teams are now proposing security work for Canton shows how important and urgent this need is. But the Foundation should look closely at what each proposal really offers and what level of financial risk it creates.

VulSight’s pay per vulnerability model is different because it puts no financial risk on the Foundation for the core protocol audit. We are not asking Canton to pay for time spent or for a process on paper. We are asking to be paid only if we deliver real security value through confirmed, exploitable vulnerabilities.

We can make that offer because we have the track record to stand behind it:

• CVE-2026-26314:
  We responsibly disclosed a high severity vulnerability in Ethereum’s Geth client, the most widely used L1 execution client in production. This was deep protocol level security research, which is the same kind of work needed for Canton’s Scala codebase.

• Top 15 all-time on Cantina:
  Cantina is one of the leading competitive audit platforms, where researchers are tested directly against other top security experts. Our results there are strong, consistent, and publicly verifiable.

• 100+ completed security audits:
  across EVM, Move such as Aptos and Sui, and Rust ecosystems such as Solana. Canton’s architecture is broad and complex, so it benefits from a team with experience across multiple systems and security models.

• $500K+ in bug bounties:
  rewards earned through responsible disclosure across live protocols and multiple chains.

This model reflects how we work. We take on the effort and the risk first, and we ask to be paid for proven results.

[nycnewman]

This is functionally structured very similar to a bug bounty program with only one bounty hunter. There should be a discussion of whether a open bug bounty program would be an alternative.

[salmaansaeed94]

Its a great point and this is a distinction we want to be very clear about.

Depth vs. breadth: Bug bounties attract surface-level findings. Most hunters optimize for speed, known patterns and low-hanging fruit. A dedicated audit means VulSight spends time understanding Canton's unique architecture and then applies systematic adversarial pressure across the full attack surface. Subtle logic flaws in governance automation, race conditions in mediator aggregation, privacy leakage through metadata, these rarely surface through bounty programs.

Canton's unique stack: Daml is not Solidity. The pool of researchers who can meaningfully audit Daml + Canton's Scala infrastructure is extremely small today. An open bounty would receive very few qualified submissions. VulSight provides a dedicated team that invests ramp-up time into genuine Canton/Daml expertise and retains that context across releases.

Structured output: A bounty produces individual findings. Our engagement produces a comprehensive audit report with threat modeling, severity classification, remediation guidance, and an executive summary. The deliverable institutional participants evaluating Canton's security posture actually need.

That said, we think bounties and dedicated audits are complementary. After our initial audit, the Security Framework outputs could inform the scope for a future open bounty program, giving hunters the context they need against Canton's non-standard architecture. Happy to discuss.

[nycnewman]

This would be valuable but should be an open contribution from across the many security researchers investigating Canton Network. There are other proposals offering to create this.

[salmaansaeed94]

We completely agree. Our intention is not to be the exclusive source of Canton security research but it's to kickstart it.
Today there's no public body of Canton/Daml-specific security research to build on. VulSight produces the foundational artifacts, threat models, vulnerability pattern catalogs, Daml authorization edge cases and publishes them under an open-source license so any researcher can build on top.
Happy to revise the language: VulSight produces the initial framework, publishes it openly, and the community owns it from there. If other proposals are working on similar contributions, we'd welcome coordination through the Tech & Ops Committee to avoid duplication and ensure complementary outputs.

[nycnewman]

There are already discussions ongoing about the correct vulnerability disclosure process and responsible disclosure. This should follow industry practices so that vulnerability is not disclosed publicly before remediation / work-arounds agreed.

[salmaansaeed94]

Absolutely, responsible disclosure is non-negotiable for us.

To clarify: "public knowledge base" means anonymized, abstracted vulnerability patterns, not raw findings with exploit details. Think of it like educational resources describing risk categories and how to avoid them, without exploitation recipes for specific live vulnerabilities.

We can add explicit proposal language committing to:

Private disclosure of all findings to the Foundation with agreed embargo
No public disclosure until remediation is confirmed and deployed
Knowledge base entries contain only abstracted patterns, never specific exploit paths for unpatched issues

If the Foundation is developing a formal disclosure policy, we'd welcome the opportunity to contribute to that process.

VulSight has direct experience with responsible disclosure at the highest stakes. We identified a critical vulnerability in Ethereum's Geth client (CVE-2026-26314), the execution client running the majority of the network and coordinated private disclosure with the core development team, with the fix deployed before any public knowledge of the issue. We understand what's at stake when infrastructure of this magnitude is involved, and we apply the same discipline to every engagement.

[nycnewman]

Not speaking on behalf of the Foundation but I would expect non-core projects to obtain security audits independently and at their own cost.

[salmaansaeed94]

That's totally fair. Our scope is focused on core protocol and shared infrastructure: Splice, Global Synchronizer governance, the Canton protocol's mediator/sequencer, Token Standard interfaces, and validator node security.
We are not proposing that the Fund subsidize audits for individual applications.

"Ecosystem security" in our proposal means producing public-good tooling (Security Framework, threat models, best practices docs) that helps independent teams conduct their own evaluations, not VulSight auditing their apps on the Foundation's budget.

We'll tighten the language. The only non-core component in scope is the Token Standard (CIP-0056), which qualifies as shared infrastructure since every application using Canton tokens depends on it.

[nycnewman]

Would a cap cost model be acceptable. Potential costs could be high to Foundation.

[salmaansaeed94]

Yes, absolutely. Here's what we'd propose:

Hard Cap with Tiered Payouts:
Fixed maximum ceiling for Stage 1. Payouts tiered by severity (Critical, High, Medium), total not exceeding the cap. If findings exceed it, VulSight still reports everything but additional payout requires a follow-on proposal.

We think it preserves the zero-risk proposition while giving the Foundation budget certainty. Happy to discuss specific numbers with the Committee.

[nycnewman]

Please take a look at #410