Feedback / champion sought — Canton App Readiness Doctor (RFP #19 /

1. #1Pelpa33303-10-2026source ↗

   Hello Canton grants community,

   I’m looking for technical feedback and a potential Champion for a small open-source Development Fund proposal that grew out of integrating FlowLedger with the current Canton stack.

   Working title: Canton App Readiness Doctor
   Primary alignment: RFP #19 — DPM Components and Extension Ecosystem
   Secondary: RFP #18 — Integration into SDLCs; RFP #15 — Canton 3.x onboarding/troubleshooting material

   Scope: a read-only-first DPM/CLI component for application teams that checks Daml/DPM build compatibility, Ledger API reachability, OAuth/JWT configuration, application Party/user rights, Token Standard registry/asset readiness, use of unstable internal Validator APIs, and CI-friendly readiness output. A separate explicit DevNet smoke command would submit a minimal supported test and return a real Update ID.

   This is deliberately not a validator lifecycle/deployment tool. Existing RFP #7 proposals such as BlockSmith already address validator onboarding and node operations; this proposal focuses on the application-to-validator integration boundary, including hosted/NaaS environments.

   Evidence already exists publicly in FlowLedger:
   https://github.com/enstest1/FlowLedger

   Relevant commits:

   • 26e5e04 — read-only Canton readiness doctor
   • 93a78e8 — Wallet SDK + Token Standard integration and Daml 3.5.2 AP DAR

   I’d appreciate feedback on whether RFP #19 is the right primary category and whether a Tech & Ops / DevRel member is interested in championing a tightly scoped version.

   Thank you,
   Christopher Tomich
   PelpaLabs
   Cflash18@...
   https://flowledger.cc

2. #2Pelpa33305-10-2026source ↗

   Hello Canton grants community,

   Following guidance from Dr. Amanda Martin at the Canton Foundation, I’m following up with a fuller proposal, including scope, milestones, requested amount, and the existing prototype evidence.

   Working title

   Canton App Readiness Doctor

   Problem

   Application teams integrating with Canton can reach a point where the application is built and the validator exists, but the final application-to-validator boundary is still difficult to diagnose. Common issues include Daml/DPM compatibility, Ledger API reachability, OAuth/JWT configuration, Party/user rights, Token Standard readiness, and accidental dependence on unstable/internal validator APIs.

   This proposal is deliberately not a validator lifecycle or node-deployment product. It focuses on application readiness against a validator, including hosted/NaaS environments, and is intended to complement rather than duplicate validator-onboarding work.

   Proposed solution

   An open-source, read-only-first CLI/DPM component that produces both human-readable and machine-readable readiness results for:

   • Daml/DPM build and SDK compatibility
   • Ledger API reachability and supported connectivity
   • OAuth/OIDC/JWT configuration
   • application Party and user rights
   • Token Standard registry/asset readiness
   • detection of unsupported/unstable internal Validator API dependencies
   • CI-friendly JSON output and exit codes
   • an explicit, opt-in DevNet smoke command that runs only after read-only checks pass and returns a real Update ID

   Current prototype / evidence

   The work grew directly out of connecting FlowLedger to the current Canton stack.

   FlowLedger: https://github.com/enstest1/FlowLedger

   Live application: https://flowledger.cc

   Relevant existing work:

   • 26e5e04 — read-only Canton readiness doctor
   • 93a78e8 — Wallet SDK + Token Standard integration and Daml 3.5.2 AP DAR

   GitHub account: https://github.com/enstest1

   The reusable component will be released under Apache-2.0.

   Proposed 12-week milestones

   Milestone 1 — Core readiness framework and specification (Weeks 1–4) — 75,000 CC

   • extract the existing readiness logic into a standalone reusable tool
   • formalize checks, result schema, exit codes, and configuration model
   • DPM/Daml compatibility, Ledger API, OAuth/JWT, and Party/user-rights checks
   • human-readable and JSON output
   • unit tests and initial documentation

   Milestone 2 — Canton application integration checks and CI support (Weeks 5–8) — 100,000 CC

   • Token Standard registry/asset readiness checks
   • detection/reporting of unsupported internal Validator API dependencies
   • CI examples and machine-readable integration
   • hosted/NaaS-compatible configuration path
   • integration tests against supported Canton interfaces
   • troubleshooting guidance mapped to failed checks

   Milestone 3 — DevNet smoke verification, packaging, and public release (Weeks 9–12) — 125,000 CC

   • explicit opt-in DevNet smoke command gated behind successful read-only checks
   • submit a minimal supported test and return a verified Update ID
   • end-to-end examples using FlowLedger as a reference integration
   • packaging/release workflow, documentation, migration notes, and contributor guide
   • public Apache-2.0 release and final demonstration

   Total requested: 300,000 CC, milestone-based.

   Alignment

   My current view is:

   • Primary: RFP #19 — DPM Components and Extension Ecosystem
   • Secondary: RFP #18 — Integration into SDLCs
   • Supporting: RFP #15 — Canton 3.x onboarding/troubleshooting material

   I initially considered RFP #7 because the underlying problems surfaced during validator onboarding. After reviewing the scope more carefully, I believe the application-to-validator boundary is a cleaner fit and avoids duplicating existing validator lifecycle/onboarding work.

   I’d appreciate technical feedback on the scope and alignment, and I’m looking for a Tech & Ops / DevRel Champion who would be willing to review and sponsor a tightly scoped formal proposal.

   I’m happy to adjust milestone boundaries, requested amount, or the RFP alignment based on community feedback.

   Thank you,

   Christopher Tomich
   PelpaLabs
   Cflash18@...