Proposal: Canton Ecosystem Vulnerability Scan Program
Proposal Metadata
| Field | Response |
|---|
| Applicant | Octane |
| Proposal category | Security & Resilience / Developer Ecosystem Hardening / Application Security Coverage |
| Requested funding | $60,000 USD-equivalent in Canton Coin |
| Program size | 30 selected Canton ecosystem projects |
| Total scan events | 60 total scan events: 30 initial vulnerability scans and 30 diff/fix review scans |
| Direct scan unit cost | $850 per scan event |
| All-in program equivalent | $1,000 per scan event inclusive of program operations, intake, reporting, and ecosystem synthesis |
| Delivery model | Three project waves plus closeout reporting |
| Proposed duration | 12 weeks of active delivery plus closeout reporting |
1. Summary
Octane proposes a bounded, milestone-driven vulnerability scan program for the Canton ecosystem. The program will provide 30 selected Canton ecosystem projects with one initial vulnerability scan, one diff/fix review scan, private remediation guidance, and a final anonymized ecosystem-level security report.
The goal is to give Canton ecosystem teams a practical security readiness layer before production deployment, mainnet usage, material user adoption, or deeper grant milestones. This is not intended to replace formal audits, core protocol reviews, bug bounties, or long-term security retainers. It is designed to close the earlier coverage gap where projects need actionable vulnerability discovery and fix verification but may not yet be ready for a full audit cycle.
The expected outcome is simple: more Canton ecosystem projects receive useful security coverage, more teams have a path from finding discovery to remediation, and Canton reviewers receive a safer aggregate view of recurring ecosystem risk without exposing unresolved project-specific vulnerabilities.
2. Problem
Canton is expanding across applications, wallets, developer tooling, integrations, financial workflows, identity, privacy, and infrastructure-adjacent systems. As the ecosystem grows, security coverage becomes harder to scale evenly.
Many teams will not be ready for a full formal audit at the moment they most need early review. Others will be preparing for pilots, production deployment, or follow-on grant milestones while still making architectural and implementation changes. In that stage, the highest-leverage intervention is often not a months-long audit process. It is a fast, structured vulnerability scan with manual triage, clear remediation guidance, and a verification pass after fixes are submitted.
This proposal addresses that specific gap.
The program is intended to help:
- early and mid-stage Canton ecosystem projects find actionable vulnerabilities before production exposure;
- grant reviewers evaluate project readiness with clearer security signals;
- teams validate that critical fixes were actually implemented;
- the ecosystem identify recurring vulnerability classes and engineering patterns before they become systemic risk;
- Canton Foundation and relevant reviewers receive anonymized, non-exploit-ready security insights that can inform future guidance.
3. Objective and Scope
Objective
Create a grant-funded security readiness program that gives selected Canton ecosystem projects practical vulnerability discovery, remediation guidance, and fix verification while producing aggregate security learnings for the broader ecosystem.
Scope
The program covers:
- 30 selected Canton ecosystem projects;
- 30 initial vulnerability scans;
- 30 diff/fix review scans;
- private project-level reports;
- private fix-review reports;
- non-sensitive readiness summaries;
- an anonymized ecosystem-level security report;
- a reviewer-facing closeout memo.
Each project receives one initial scan and one follow-up diff/fix review scan. The follow-up review is a targeted verification pass against submitted fixes and materially relevant diffs. It is not a new full-scope audit.
4. Public-Good Value for Canton
This proposal is structured as ecosystem security infrastructure, not a private security engagement for one team.
The public-good value comes from four outputs:
- Broader security access: 30 projects receive structured review that many early teams would otherwise defer or skip.
- Verified remediation path: each participating project has a defined route from vulnerability discovery to fix validation.
- Reviewer visibility: Canton reviewers receive clearer delivery and readiness signals without forcing public disclosure of sensitive vulnerability details.
- Ecosystem learning: Canton receives an anonymized report covering recurring vulnerability classes, aggregate severity distribution, remediation patterns, and recommendations for future security guidance.
This creates shared benefit without publishing unresolved vulnerabilities, exploit-ready details, secrets, sensitive file paths, or project-specific unresolved security issues.
5. Project Eligibility and Selection
Projects should be prioritized if they are building directly in or around the Canton ecosystem and are approaching one of the following stages:
- production deployment;
- public testnet;
- pilot usage;
- material user adoption;
- integration with financial workflows, assets, identity, privacy, governance, or access-control surfaces;
- deeper grant milestones where security posture materially affects readiness.
Eligible project types may include:
- dApps;
- wallets;
- developer tools;
- APIs and backend services;
- reusable libraries;
- integrations;
- infrastructure-adjacent applications;
- Daml or Canton-connected application logic where applicable;
- financial workflow tooling;
- access-control, identity, or privacy-sensitive systems.
Participating projects must be able to provide:
- repository or scoped code access;
- a defined technical point of contact;
- a remediation owner;
- sufficient setup documentation;
- a bounded scan scope;
- a reasonable fix submission window for the diff/fix review.
Final project selection can be coordinated with Canton Foundation, relevant reviewers, and/or an assigned program champion.
6. Technical Approach
Octane will use software-assisted vulnerability discovery paired with manual security researcher triage. The purpose is to identify actionable risk with lower noise than a purely automated scan and faster delivery than a full manual audit.
Each initial scan will be scoped during intake and may include the following review areas where applicable:
| Review area | Included activities |
|---|
| Code and architecture | Repository structure review, application architecture review, Daml contract logic review where applicable, backend/API integration review, deployment assumptions, and high-risk execution paths. |
| Access control and trust boundaries | Authentication, authorization, party and identity assumptions, permission boundaries, admin/user separation, signer assumptions, backend-to-ledger trust assumptions, and privileged operation handling. |
| Canton-specific logic | Party authorization, multi-party workflow correctness, privacy boundaries, ledger interaction patterns, asset/control-flow assumptions, off-ledger/on-ledger consistency, and integration assumptions where relevant. |
| Application security | Input validation, business logic abuse paths, API misuse, insecure defaults, session/authentication issues, unsafe dependency usage, and common implementation vulnerabilities. |
| Tool-assisted analysis | Static analysis where applicable, dependency/package review, known vulnerability checks, secrets exposure checks, and CI/CD configuration review. |
| Manual triage | Validation of tool findings, exploitability assessment, severity ranking, removal of obvious false positives, and prioritization based on business and ecosystem relevance. |
7. Program Workflow
Step 1: Intake
For each selected project, Octane will collect:
- repository or scoped source access;
- build/setup instructions where available;
- system overview;
- critical assets and trust assumptions;
- known deployment stage;
- primary technical contact;
- remediation owner;
- project-specific exclusions or legal constraints.
The output of intake is a bounded scan scope and project readiness for review.
Step 2: Initial Vulnerability Scan
Octane performs the initial scan and delivers a private report covering:
- executive summary;
- scope reviewed;
- severity-ranked findings;
- affected components;
- validation notes where safe;
- remediation guidance;
- suggested fix priority;
- residual questions or blockers.
Step 3: Remediation Window
Each project receives up to 21 calendar days to submit remediation materials for fix review. A project may submit:
- patched commits;
- pull requests;
- diff summaries;
- design changes;
- compensating controls;
- explanations for accepted risk.
Step 4: Diff/Fix Review Scan
Octane performs a targeted review of submitted fixes and materially relevant diffs.
The diff/fix review will:
- validate whether reported Critical, High, and Medium findings were patched;
- assess whether the submitted diff introduces obvious regression risk;
- confirm whether remediation addresses the original vulnerability class;
- classify each issue as verified, partially verified, not fixed, not submitted, or not applicable;
- document residual risk and unresolved blockers.
Step 5: Program Closeout
At the end of the active delivery period, Octane will deliver:
- final scan and fix-review counts;
- aggregate severity distribution;
- recurring vulnerability classes;
- remediation trends;
- anonymized lessons learned;
- recommendations for future Canton ecosystem security guidance;
- suggested next tranche size if the program is extended.
8. Deliverables
Per-Project Deliverables
| Deliverable | Contents |
|---|
| Private initial vulnerability report | Executive summary, scope reviewed, severity-ranked findings, affected components, validation notes where safe, remediation guidance, and suggested fix priority. |
| Private diff/fix review report | Fix status per finding, verified/partially verified/not fixed/not submitted/not applicable classification, regression notes, and remaining risk summary. |
| Security readiness summary | High-level readiness status, blocker list if any, residual risk notes, and recommended next security step. |
Project-specific vulnerability details will remain private to the affected project team and designated Canton Foundation security contacts where required by the program. Non-sensitive readiness summaries may be shared with Canton reviewers to support grant and milestone review.
Ecosystem-Level Deliverables
| Deliverable | Contents |
|---|
| Program intake summary | Number of projects onboarded, project categories, scope categories, and completion status. |
| Anonymized ecosystem security report | Common vulnerability classes, aggregate severity distribution, recurring engineering patterns, remediation trends, and recommendations for future Canton security guidance. |
| Reviewer-facing closeout memo | Scans completed, fix reviews completed or made available, turnaround metrics, lessons learned, unresolved process blockers, and suggested next tranche size. |
9. Responsible Disclosure and Security Handling
Octane will use a conservative disclosure model throughout the program.
| Finding class | Disclosure handling |
|---|
| Critical / High | Private disclosure to the affected project team and designated Canton Foundation security contact if required by the program. Notification target: within 24 hours of validation. |
| Medium / Low | Delivered privately to the affected project team and summarized only in aggregate. |
| Informational | Delivered privately where useful and summarized only in aggregate where relevant. |
| Public reporting | Anonymized only. No unresolved Critical/High details, exploit-ready steps, secrets, sensitive file paths, or project-specific unresolved vulnerabilities. |
The final ecosystem report will be written to preserve security value without creating new risk for participating projects or users.
10. Timeline
The proposed program is structured as 12 weeks of active delivery plus closeout reporting.
| Step | Target timing |
|---|
| Project intake completed | Day 0 for each project after selection and required access are complete |
| Initial scan starts | Within 3 business days of complete intake |
| Initial report delivered | Within 5 business days of scan start |
| Project remediation window | Up to 21 calendar days |
| Diff/fix review starts | Within 3 business days of submitted remediation materials |
| Diff/fix report delivered | Within 5 business days of review start |
| Final ecosystem report | Within 14 days of final wave close |
Delivery Waves
| Wave | Projects | Timing | Output |
|---|
| Wave 1 | 10 | Weeks 1-4 | Intake, initial scans, reports, and first fix-review availability |
| Wave 2 | 10 | Weeks 5-8 | Intake, initial scans, reports, and first fix-review availability |
| Wave 3 | 10 | Weeks 9-12 | Intake, initial scans, reports, and first fix-review availability |
| Closeout | All | Weeks 12-14 | Final anonymized ecosystem report and closeout memo |
If a project does not submit fixes during its remediation window, its allocated fix-review slot will be marked as made available, and the project will receive a residual-risk status reflecting that no fix materials were submitted within the program window.
11. Budget and Milestones
Total requested funding is $60,000 USD-equivalent in Canton Coin. The final Canton Coin amount should be calculated using the applicable Development Fund conversion methodology at approval.
Budget
| Item | Quantity | Unit cost | Total |
|---|
| Initial vulnerability scans | 30 | $850 | $25,500 |
| Diff/fix review scans | 30 | $850 | $25,500 |
| Program operations, intake, reporting, and ecosystem synthesis | Fixed | — | $9,000 |
| Total | 60 scan events + program operations | $850 direct scan unit cost / $1,000 all-in equivalent per scan event | $60,000 |
Milestones
| Milestone | Deliverables | Funding |
|---|
| M1 — Program Launch + Wave 1 | Intake framework, scan rubric, Wave 1 onboarding, first 10 initial scans, Wave 1 reports, and program operating cadence established. | $17,000 |
| M2 — Wave 1 Fix Reviews + Wave 2 Initial Scans | Up to 10 Wave 1 fix-review scans, next 10 initial scans, Wave 2 reports, and interim delivery metrics. | $17,000 |
| M3 — Wave 2 Fix Reviews + Wave 3 Initial Scans | Up to 10 Wave 2 fix-review scans, final 10 initial scans, Wave 3 reports, and interim delivery metrics. | $17,000 |
| M4 — Wave 3 Fix Reviews + Ecosystem Closeout | Up to 10 Wave 3 fix-review scans, final anonymized ecosystem report, reviewer-facing closeout memo, and final KPI summary. | $9,000 |
| Total | 60 scan events plus reporting and closeout | $60,000 |
12. KPIs and Acceptance Criteria
Delivery KPIs
| KPI | Target |
|---|
| Projects onboarded | 30 |
| Initial scans completed | 30 |
| Diff/fix review scan slots completed or made available | 30 |
| Total scan events completed or made available | 60 |
| Initial report turnaround | 90% within 5 business days of scan start |
| Diff/fix review turnaround | 90% within 5 business days of remediation submission |
| Critical/High notification | Within 24 hours of validation |
| Final ecosystem report | Within 14 days of final wave close |
Quality KPIs
| KPI | Target |
|---|
| Findings manually triaged before delivery | 100% |
| Reports include severity, affected component, and remediation guidance | 100% |
| Critical/High findings include reproduction or validation notes where safe | 100% |
| Public reporting excludes unresolved sensitive vulnerability details | 100% |
| Projects receive residual-risk status after fix review or non-submission | 100% |
| Final report includes aggregate vulnerability classes and remediation trends | 100% |
Acceptance should be based on delivery of the defined reports, scan counts, fix-review availability, turnaround metrics, and final anonymized ecosystem output. The program should not be judged by the number of vulnerabilities found, because that depends on project maturity, scope, and implementation quality.
13. Alignment with Canton Priorities
This proposal aligns with Canton ecosystem priorities in three concrete ways.
Security and Resilience
The program funds security reviews, vulnerability discovery, remediation guidance, and fix verification across multiple ecosystem teams. It directly supports ecosystem hardening and gives reviewers a safer view of recurring risk.
App Building and Developer Experience
The program reduces the security friction that early application, wallet, tooling, and integration teams face before production readiness. Participating teams receive actionable reports and a defined next step instead of a vague recommendation to “get an audit later.”
Public Good and Adoption-Driven Delivery
The value is not limited to one vendor or one project. Thirty projects receive coverage, and Canton receives aggregate security learnings that can inform future guidance, reviewer expectations, and security support for subsequent grant applicants.
14. Sustainability After the Grant Period
This proposal does not create a permanent operational burden for Canton Foundation.
After closeout, Canton will have:
- private per-project outputs for participating teams;
- aggregate ecosystem findings;
- recurring vulnerability classes;
- evidence of which project categories benefited most from early scans;
- a suggested next tranche size if continued coverage is useful;
- a repeatable intake and reporting model that can be reused, modified, or discontinued based on measured value.
If the program proves effective, a future tranche could be scoped around a narrower target set, such as wallets, financial workflow applications, developer tooling, or projects approaching production deployment.
15. Risk Management
| Risk | Mitigation |
|---|
| Project teams delay intake or fixes | Require complete intake before scan start; define a 21-day remediation window; mark fix-review slots as made available if no remediation is submitted. |
| Scope creep | Bound each scan during intake; exclude full formal audit certification and unrelated live-system testing. |
| Sensitive findings create disclosure risk | Use private project-level reports and anonymized public reporting only. |
| Heterogeneous project stacks | Use a scope-based review rubric and apply Canton-specific review only where relevant. |
| Reviewers need measurable proof of delivery | Track scan counts, report delivery, fix-review status, turnaround metrics, and final aggregate reporting. |
16. Out of Scope
The following are explicitly out of scope:
- full formal audit certification;
- core Canton protocol audit;
- economic or incentive-model audit;
- production incident response;
- penetration testing against live systems without explicit written authorization;
- custody/HSM review;
- legal or compliance certification;
- continuous monitoring subscription;
- long-term managed security retainer;
- bug bounty administration;
17. Why Octane
Octane is a strong fit for this program because the proposal requires fast, bounded, measurable security coverage across many projects rather than one long-form audit engagement.
| Requirement | Octane fit |
|---|
| Bounded execution | 30 projects, 60 scan events, defined timeline, fixed closeout. |
| Measurable delivery | Scan counts, reports, fix-review status, turnaround metrics, and final ecosystem report. |
| Practical remediation | Findings are manually triaged and paired with remediation guidance. |
| Ecosystem-level value | Outputs include project-level reports and an anonymized ecosystem-level security analysis. |
| Cost control | $60,000 total ask; $850 direct scan unit cost; $1,000 all-in program equivalent per scan event. |
| Complementary role | Does not replace formal audits, core protocol reviews, bug bounties, or long-term retainers. |
18. Suggested PR Description
## Development Fund Proposal Submission
Proposal file: `/proposals/octane-canton-vulnerability-scan-program.md`
---
## Summary
Octane proposes a 30-project Canton Ecosystem Vulnerability Scan Program. Each selected project receives one initial vulnerability scan and one diff/fix review scan, for 60 total scan events.
The program gives Canton ecosystem teams practical security coverage before production deployment, material user adoption, or deeper grant milestones while providing Canton reviewers with anonymized ecosystem-level visibility into recurring vulnerability classes and remediation trends. The total request is $60,000 USD-equivalent in Canton Coin.
---
## Checklist
- [x] Proposal file added under `/proposals/`
- [x] Milestones and funding amounts defined
- [x] Acceptance criteria included
- [x] Alignment with Canton priorities described
---
## Notes for Reviewers
This proposal is intentionally bounded. It does not request funding for a permanent retainer, formal audit certification, production incident response, or public disclosure of unresolved vulnerabilities. The program funds practical vulnerability discovery, remediation guidance, and fix verification for 30 selected ecosystem projects, with an anonymized closeout report for ecosystem-level learning.
19. References
