Proposal: C# / .NET SDK for Canton Network

Review Feedback — C# / .NET SDK for Canton Network

Thank you for the submission and for contributing a proposal focused on expanding Canton’s developer ecosystem through a C# / .NET SDK.

This proposal clearly aligns with Development Fund priorities around developer tooling and ecosystem expansion. The scope is well-defined, the deliverables are concrete, and the focus on open-source distribution via NuGet is appropriate for the target developer audience.

That said, there are a few areas that would benefit from additional clarification:

1. Evidence of ecosystem demand

The proposal makes a strong case for the size and importance of the .NET ecosystem. However, it does not yet demonstrate specific demand from Canton ecosystem participants.

Please clarify:

• Whether any teams are currently blocked by the lack of a C# SDK
• Any known projects or institutions that would adopt this SDK
• Whether there has been direct feedback or requests from developers in the ecosystem

2. Adoption expectations and success criteria

The proposal includes adoption metrics (e.g., NuGet downloads, GitHub engagement), which is positive. However, these are primarily package-level indicators, not necessarily ecosystem-level impact.

Consider clarifying:

• How this SDK will translate into real applications or integrations on Canton
• What success looks like in terms of actual usage within the ecosystem (e.g., apps built, integrations completed)
• Whether there are target use cases or early adopters identified

3. Cost relative to scope

The proposal includes a substantial funding request, particularly for:

• full API coverage across two protocols (gRPC + JSON)
• documentation and adoption efforts
• ongoing quarterly maintenance

While the scope is comprehensive, it would be helpful to:

• Clarify which components are already partially implemented vs. net-new
• Provide additional context on effort allocation across milestones
• Explain how the scope justifies the total funding level relative to expected adoption

4. Maintenance model and long-term ownership

The proposal includes a structured maintenance plan, which is a strength. However, additional clarity would help ensure long-term sustainability:

• Whether maintenance responsibility remains with a single entity or transitions to the community
• How governance of the SDK evolves if adoption grows
• What happens if maintenance funding is not renewed

Overall, this is a well-structured proposal with clear technical scope. Strengthening the areas above would improve clarity around ecosystem demand, expected impact, and long-term sustainability.

The parenthetical in the gRPC client bullet is confusing: a “gRPC Ledger API Client” generally targets the Ledger API over gRPC, while “JSON API v2” is a separate HTTP surface. Consider rewording to avoid implying the gRPC client also covers JSON (since the next bullet already introduces a dedicated JSON API v2 client).

2. **gRPC Ledger API Client** – A native C# client for the Canton Participant Node's Ledger API over gRPC.

Q1 - Command Deduplication

Per Canton Ledger API:
https://github.com/digital-asset/canton/blob/main/community/ledger-api-proto/src/main/protobuf/com/daml/ledger/api/v2/commands.proto

"The triple (user_id, act_as, command_id) constitutes the change ID for the intended ledger change."

The CommandsSubmission builder in A.5 exposes WithWorkflowId but no WithCommandId or WithDeduplicationPeriod

The proposal states the SDK will "handle connection failures... gracefully" - but without caller-controlled command_id, a retry after a network failure generates a new change ID and submits a duplicate command.

Question:
How does the SDK manage command_id on retry?

Q2 - PQS Filter Translation

Filter.Field(x => x.Property, value) in A.9 implies C# expression tree compilation to PostgreSQL JSONB path queries

The proposal shows no detail on how this translation works - specifically:

• How are nested records, Optional, List, and Map fields handled?
• What is the mapping between codegen-emitted C# property names and JSONB keys in PQS storage?

Question:
What is the internal mechanism for expression tree -> JSONB translation?

Thanks for taking the time to review @Denend 🙏 — both questions are well-targeted. A framing note first: the snippets in §A.5 / §A.9 illustrate the intended developer ergonomics, not the full API surface — they're abbreviated for proposal readability rather than meant as a spec extract. Here's where things stand in the working code today and where the funded scope closes the remaining gaps.

Q1 - Command Deduplication

Per Canton Ledger API: https://github.com/digital-asset/canton/blob/main/community/ledger-api-proto/src/main/protobuf/com/daml/ledger/api/v2/commands.proto

"The triple (user_id, act_as, command_id) constitutes the change ID for the intended ledger change."

The CommandsSubmission builder in A.5 exposes WithWorkflowId but no WithCommandId or WithDeduplicationPeriod

The proposal states the SDK will "handle connection failures... gracefully" - but without caller-controlled command_id, a retry after a network failure generates a new change ID and submits a duplicate command.

Question: How does the SDK manage command_id on retry?

Q1 — command deduplication & retry

• CommandsSubmission already exposes WithCommandId alongside WithWorkflowId, WithActAs, WithReadAs. When the caller omits command_id, the SDK defaults it to Guid.NewGuid().ToString() in LedgerClient.BuildCommands, so the change ID is always populated.
• Retry semantics today are caller-owned: the SDK does not run an internal retry pipeline, only configurable gRPC deadlines. An opt-in Polly-based resilience pipeline is part of the funded scope. The contract we'll wire in: command_id is generated once at the logical-submission boundary and preserved unchanged across every retry attempt, so the ledger sees the same change ID and dedup behaves as designed. Anything that mutated command_id per attempt would defeat dedup, which is precisely the failure mode you're highlighting.
• WithDeduplicationPeriod is not yet exposed — also funded scope. The plan is caller-settable with a sensible default, sized to cover the Polly retry horizon so the dedup window stays meaningful end-to-end.

Q2 - PQS Filter Translation

Filter.Field(x => x.Property, value) in A.9 implies C# expression tree compilation to PostgreSQL JSONB path queries

The proposal shows no detail on how this translation works - specifically:

• How are nested records, Optional, List, and Map fields handled?
• What is the mapping between codegen-emitted C# property names and JSONB keys in PQS storage?

Question: What is the internal mechanism for expression tree -> JSONB translation?

Q2 — PQS filter translation

A working baseline exists today, scope-limited:

• Filter.Field<T>(x => x.Property, value) is implemented end-to-end for top-level scalar properties. An expression-tree walk extracts the MemberExpression, applies a PascalCase → camelCase rule to match PQS's emitted JSONB keys, and produces parameterised SQL like payload->>'fieldName' = @p via Npgsql (injection-safe). Filter.And / Filter.Or compose recursively.
• Nested records, Optional, List, Map, and Variants are deliberately out of scope at this stage — the resolver throws on nested member access today, on purpose, to keep semantics explicit until the deeper translation is properly designed. The direction we're considering is to extend the visitor to walk member chains and emit payload->'a'->'b'->>'c'-style paths, with type-aware handling: Optional mapping to IS NULL / value branch, List / Map to JSONB containment or key-existence operators, Variants to tag-discriminated branches. The codegen-property-name ↔ JSONB-key mapping for the parameterised types would likely read codegen-emitted schema metadata directly rather than rely on a string transform, so the mapping stays aligned with the underlying Daml package. That said, this part is exactly the kind of design that deserves dedicated study before final commitments — and is precisely the work the funding is intended to support. Happy to iterate on the approach with reviewers as it takes shape; thanks again for surfacing it.

This is a big claim: "cannot be consumed from .NET without a multi-week reverse-engineering effort per integration". You should hint at what is missing.

Why isn't a C# OpenAPI generator good enough? What else is added? (I assume there is a C# generator)

What is this adding or what problem is it solving? Adding types where strings are auto-converted to numbers?

I think developer documentation is sufficient.
AI assist is based on that.

This is too weak a reason. Suggest adding something like: "TradFi institutions are Microsfoft only or major users. Providing this toolchain will speed the movement of TradFi institutions to the Canton Network."

- Build dApps that use Daml where the clients are applications entirely in C#

It should integrate with dpm as another component. See https://docs.digitalasset.com/build/3.4/dpm/dpm-components.html

Is this using OpenAPI generators?

Will the Sample Applications have a web front end as an example?

I don't think the admin api is necessary. In the future the LAPI will be able to do topology transactions.

Shouldn't be part of this proposal unless there is some C# benefit or it is an example app. This is another proposal.

Where do you document mapping the DAML LF types to C# types?

Codegen should use the • lib daml-lf-archive for reading the LF. This library will be maintained as new Daml / LF language additions are made.

You also need to take into account Smart Contract Upgrade to understand how versioning is used.

The code is here: https://github.com/digital-asset/canton/tree/main/community/daml-lf/archive/src/main/scala/com/digitalasset/daml/lf/archive

More specifically we use this method: https://github.com/digital-asset/canton/blob/1379ecc9f2d6b673630a4bc649416e27ea8c8[…]ve/src/main/scala/com/digitalasset/daml/lf/archive/Decode.scala

Windows is the important platform for the TradFi institutions.

Why include gRPC? It is redundant since JSON API is there. We recommend gRPC for performance sensitive applications or better type safety. You may want to justify this.

Can this be reduced to: windows + x64 Linux + Arm64

Why all the others?

Isn't layer 2 more broad? Isn't the requirement As a dApp developer I want to be able to convert any DAR into a C# object representation so that I can easily write a C# application while keeping the application stack in place, using my IDE better (e.g., intellisense), and have type safety.

This is too narrow. Anyone should be able to codegen a C# object model from their DARs. You can demo it on the Splice-* DARs though.

Yes!

Nice!

Reassignment is actually two events: unassign and assign. Please adjust this in the proposal

Please point out that A.6 is described below. This would be helpful.

why include the 12 weeks?

For now it is Out of Scope,

• A basic Asp.Net API Server with an autogenerated Scalar or Swagger web page should be enough to prove the point and demonstrate a good architecture.
• Not many people write C# frontend (Blazor)
• This project would not add much value adding a TypeScript frontend.

That being said, it can easily be added if required, and could arguably show a more complete picture how a full dApp should be built.

OK no worries, it stays in the Out of Scope section or I can simply remove the mention entirely.

Agreed, it is currently in the Out of Scope section

Removed — the M4 NuGet-adoption gate no longer carries the 12-week qualifier, and the Acceptance Criteria line was updated in lockstep (M4). The milestone now closes when the ecosystem gates are reached rather than at a calendar deadline.

Hinted concretely — the Abstract now lists the specific defects (Empty1–Empty10, three independent HashingSchemeVersion enums, object-typed DAML payload fields, broken required semantics) and points at Appendix B, which catalogues all five structural defects in full.

Full answer with evidence in Appendix B: we audited the published JSON spec (8,707 lines, version 3.5.1-SNAPSHOT) and catalogued five structural defects that any faithful OpenAPI generator reproduces verbatim. The SDK therefore takes the protos as the source of truth for the gRPC client and hand-writes thin wrappers for the handful of JSON-only admin / health endpoints — see §2 — Client architecture.

Yes, exactly that — and a bit more. PQS itself is Digital Asset's denormalised PostgreSQL projection of ledger state, with contract payloads stored as JSONB. Without a typed wrapper, application code reaches in via stringly-typed JSONB navigation (payload->>'amount' cast to numeric — no compile-time check that amount is even a field on the template, no IDE help, no rename safety). The C# PQS client consumes the codegen-emitted record types and translates Filter.Field<Iou>(x => x.Amount, value)-style expression trees into parameterised JSONB path queries that preserve Postgres types — same wire path as DA's PQS, typed end-to-end.

Mechanism: new "What the PQS client adds" paragraph in §2 — Client architecture. Worked example: §A.9.

Agreed and removed throughout — item 6 is gone from the SDK list, the M3 deliverable is dropped, the cost rationale that name-checked it has been removed, and the Comparison-with-existing-SDKs row is gone. Documentation now lands as XML docs + a DocFX site, no separate "AI-optimised reference" component.

Adopted — the Abstract now opens with the Microsoft-first framing, and a rewritten § Why C# / .NET makes the TradFi-Microsoft case explicitly (Visual Studio / MSBuild / NuGet / Entra ID / SQL Server / .NET on Windows Server, .NET on Linux containers as the cost-efficient deployment target). The proposal now treats Windows x64 as the primary production target throughout — see Quality Assurance and the Risk Mitigation table.

Applied — the §1 bullet now reads "Build dApps on Daml whose client applications are written entirely in C#".

Adopted — new §2 — Integration with dpm subsection. The codegen ships both as a standalone daml-cs codegen CLI (so the SDK is usable independently of dpm's availability and release cadence) and as a dpm codegen csharp plugin invoking the same pipeline. Coordination with the dpm maintainers is part of Milestone 1; the plugin lands under M1 if dpm's plugin surface is ready, otherwise under M2.

No — see §2 — Client architecture and Appendix B. The gRPC client is generated directly from the Canton Ledger API .proto files via Grpc.Tools + Google.Protobuf. The HTTP / JSON path is a hand-written thin wrapper for the few admin / health endpoints with no gRPC equivalent — pointing a generic OpenAPI generator (NSwag, Kiota, openapi-generator-cli) at the published JSON spec produces a client riddled with structural defects (numbered duplicate schemas, single-key oneOf wrappers without discriminators, inline-duplicated enums, untyped DAML payload fields, broken required semantics), all catalogued in Appendix B.

Added — full mapping table now in §2 — Daml LF → C# type mapping. Covers record (sealed record), variant (sealed record hierarchy), enum, all primitives (Text, Int, Decimal / Numeric N, Date, Time, Bool, Unit), Party, ContractId T, List, TextMap, GenMap, Optional, Daml interface, and explicitly the package versioning / Smart Contract Upgrade story (assembly-level [assembly: DamlPackageVersion(...)] metadata, SCU compatibility reported by daml-lf-archive at codegen time).

Good point! Thanks a lot for flagging it 🙏 Smart Contract Upgrade had not been taken into consideration yet and that changes the game.

Adopted as the largest single architectural change in the revision. The codegen architecture in §2 now wraps daml-lf-archive via a small JVM helper that emits an intermediate AST, consumed by the C# Roslyn emitter. LF version dispatch, package-hash handling, and Smart Contract Upgrade compatibility are inherited from the upstream library Canton itself uses — not reimplemented in C# — so an LF change becomes a JVM-helper update rather than an SDK rewrite (see the updated Risk Mitigation row).

End-user runtimes stay pure .NET — only the codegen toolchain itself touches the JVM, in CI when a Canton / Splice release tag appears or when a developer regenerates locally.

The PoC's direct LF-protobuf parsing path is acknowledged honestly as not yet wrapping daml-lf-archive; the migration is bundled into Milestone 1 / Milestone 2 and gets its own deliverable line ("JVM codegen helper (daml-lf-archive integration)") in M1.

Adopted — Windows x64 is now the primary production target across the PoC-not-covered list, Quality Assurance, the Risk Mitigation table, and § Why C# / .NET. Linux Arm64 sits alongside it as the cost-efficient cloud-runtime target; macOS Arm64 stays in CI as a developer-experience target only, not production.

Justified explicitly in § Why This Approach and detailed in Appendix B. The Canton Ledger API is defined in .proto files; the JSON spec is a downstream tapir-generated artefact with five catalogued structural defects. The gRPC client is therefore the primary path; the HTTP path is not a redundant second client surface but a thin hand-written wrapper for the small set of admin / health endpoints that exist only in the JSON spec. So the two transports are scoped asymmetrically — gRPC is the full surface, JSON is the gap-filler.

Done exactly as suggested — production targets are now Windows x64 and Linux Arm64. macOS Arm64 stays in CI as a developer-experience target only (Peaceful Studio's own toolchain runs there), not as a production support target. Updated in § Quality Assurance and the Risk Mitigation table.

Adopted — §3 is retitled "Extending Daml / Canton into the .NET Ecosystem", and Layer 2 now opens with your user-story verbatim:

As a dApp developer I want to be able to convert any DAR into a C# object representation so that I can easily write a C# application while keeping the application stack in place, using my IDE better (e.g., intellisense), and have type safety.

Splice DARs are reframed as published reference implementations / proof points that demonstrate the codegen pipeline produces a clean object model from real-world protocol DARs at scale. Splice NuGet maintenance stays part of M5+; user DARs stay user-maintained, on the same model as daml codegen java.

Same change as the comment on Layer 2 above — the headline user-story is now any-DAR (not Splice-specific), and Splice serves as the demonstration that the pipeline works on real-world protocol DARs at scale. See the rewritten §3 Layer 2 — the dotnet add package <YourCompany>.<YourDaml>.<Component> example now leads, with the Canton.Splice.* packages following as the published reference implementations.

Adjusted everywhere it appears — §3 multi-synchronizer readiness, the Risk Mitigation table, and §A.7 — Typed subscription streams now describe Unassigned (source synchronizer) and Assigned (target synchronizer) as distinct typed cases on ContractEvent<T>. §A.7 has a worked code example covering both branches.

Done — the bullet now reads "shown in §A.6 below" with a navigable anchor link, and the leading reference earlier in the same bullet is also linked. While I was at it, I went through the document and converted other cross-section prose references (§2 ↔ §3, §A.x outside Appendix A, Appendix B) into anchor links for navigability — should make re-reviewing the diff a lot easier than it was.

🙏

🙏

Thanks a lot for the thorough review @hrischuk-da 🙏 — genuinely useful across the board.

A couple of your comments shifted the architecture rather than just polishing the prose:

• the daml-lf-archive / SCU pointer reshaped the codegen path
• the broader Layer-2 framing turned the proposal from Splice-specific into any-DAR with Splice as the published reference implementation.

I've revised the file at b470a3c and posted a reply on each of your threads with anchor links to the relevant updated sections. Hope this addresses your concerns — happy to iterate on anything that still needs sharpening.

Thank you.

Thank you

Ok.

One of the Canton Foundation’s core principles is ensuring that grants provide ecosystem-wide value and that payouts are proportional to adoption. Currently, your adoption milestone represents 600k CC (~24% of the total grant), whereas the average for other grants is ~40%. To better align with the Canton Foundation Development Fund standards for ecosystem impact, I suggest rebalancing the payment schedule to weight the final adoption milestones more heavily.

The adoption milestone mentions 3 organizations and 2 applications leveraging the SDK. To drive real adoption with high impact, I would recommend specifying that 2 of those 3 organizations should be banks.

Thanks @guillaumedejenlis-da 🙏 — your point on proportionality reshaped the payment structure. The 2026-05-12 revision:

• M4 base up to 32% (800,000 CC) — paid per-event, not binary: 100k CC per TradFi institution (up to 3), 100k CC per external mainnet app (up to 2), 300k CC on completion gates. Partial adoption → partial payout.
• +20% acceleration bonus (160k CC) if all M4 gates close within 15 months — lifts M4 to ≈38% of the 2,660,000 CC max, matching the dev-fund convention (Token Standard V2, ISS-BFT, LSU, PQS).
• 18-month deadline as explicit exception to the 9-month default — TradFi cycles routinely run 9–18 months for a first conversation; a 9-month gate forfeits the very tranche the proportionality principle rewards.

Detail in §M4 and §Payment Breakdown.

Thanks @guillaumedejenlis-da 🙏 — §M4 now credits any regulated TradFi institution (bank, custodian, exchange operator, asset manager — not just banks) at 100k CC per institution, up to 3 institutions. I hope that is OK.

Great approach with the event-based pay. Suggestion for Tech & Ops: Front-load the compatibility testing and bug fixes into M3. This allows M4 to stand alone as a pure adoption-based milestone

Thanks for the suggestion @guillaumedejenlis-da , it does make more sense now:

• M3 has compatibility, bugs, and audit fixing
• M4 is purely adoption focused, cn-quickstart equivalent, docFx website, TradFi adoption.

@hrischuk-da are you OK with that 🙏 ?

**[Champion](https://github.com/canton-foundation/canton-dev-fund/blob/main/sig-directory.md):** Curtis Hrischuk @hrischuk-da

Exciting to see .NET support coming to Canton, it is used in enterprise setting where developers may not be as engaged in the DeFI space. The proposal is ambitious, comprehensive and reasonable.

👍

We have a generic scals (jvm) library that reads dars and converts them to an abstract in-memory representation. Writing a codegen is then just a case of writing a custom back-end. We have example codegens for java, scala and typescript based on that.

I would suggest to make c# codegen part of the same family. This will have a couple of benefits

• standard AST representation shared with all other DAML tools
• any bug fixed upstream will be fixed in the tool
• any change to Daml-LF will be immediately absorbed

DA plans to publish an existing library that already builds this AST. Writing a C# codegen will then be just down to writing a custom back-end

I now see what you intend to do. Being able to use Roslyn for codegen is indeed an enticing prospect. I think this is a technical detail which can be hashed-out as we go. I see two possibilities

• either as you have suggested: jvm codegen .dar -> .ast followed by C# codegen .ast -> .cs or
• just one jvm codegen .dar -> .cs

When you look at the other codegens you will be able to judge how much you gain from Roslyn and whether it is worth it.

No, this is the migration steps when you are moving from the previous spec, where these fields were marked as required to the new spec, where they are correctly marked as optional

I suggest that support for opentelemetry tracing should also be considered here. Ledger api supports it and so should be the case with the client libraries.

Clients of the Ledger API can be written at different abstraction levels

• The lowest level client simply wraps around the gRPC/JSON
• At a higher level the client code can provide error handling and retry logic
• At a yet higher abstraction level it can provide the notions of in-memory active-contract-set and pending-set etc

Could you specify which level you are intending to target in this grant?

Thanks a lot for the careful read @mziolekda 🙏. Three of your six comments converge on the §2 codegen architecture we shipped after Curtis' review in b470a3c, so I believe we are on the same line. But please let me know if I missed anything.

I believe 28b06d1 addresses your comments:

• Appendix B defect 5 dropped — you're right, the line-6 note was a migration warning, not a current breakage. This was removed; the other four defects stay unchanged.
• OpenTelemetry instrumentation added to M2 — end-to-end across all three transports (gRPC via Grpc.Net.Client, HTTP/JSON via HttpClient + traceparent, PQS via Npgsql's OTel integration), inside the existing engineering envelope.
• Abstraction-level target stated in §2 — "thin client + ergonomics + opt-in resilience", with PQS as the Canton-native answer for ACS materialisation rather than an SDK-side cache.

Inline replies on each thread.

Side note: I opened digital-asset/canton#527 yesterday proposing what I think is a good upstream change to improve the openApi spec generation — adding google.api.http annotations on the v2 protos and generate the spec from the protos directly. If it can't be accepted, we'll do things downstream another way, no worries.

Agreed on common AST generation using the JVM libraries — see the other comment on the way AST → C# is planned to work. Happy to discuss further as you mentioned.

That would be perfect 🙏 — we'd switch the planned JVM step to consume the published library directly rather than maintain our own daml-lf-archive wrapper. Is possible to track the progress from a public issue or something like that? Do you have a rough idea of when it could be released?

Agreed it's a detail to come back to later. §2 commits to option (a) for now — emitting C# from C# via Roslyn keeps the emit decisions (records, primary constructors, nullable annotations, keyword hygiene, IDE-friendly output) inside the .NET ecosystem, where the .NET maintainers and tooling live. Will review the Java/Scala/TS emitters as you suggest to re-evaluate that decision.

You are right, I misread it, apologies => Defect 5 dropped in 28b06d1; I believe the other four defects are still relevant.

Agreed — added as an M2 deliverable in 28b06d1 covering all three transports. The gRPC path stitches client-side spans to the Ledger API's existing server-side OTel emission as one distributed trace; HTTP/JSON propagates traceparent for whatever server-side instrumentation picks it up; PQS emits client-side DB semantic-convention spans via Npgsql (no participant-node counterpart on the PostgreSQL side). Inside the existing engineering envelope 🤞 .

Targeting middle layer + PQS:

• typed wrappers with error handling, opt-in Polly retry, OTel instrumentation, and command_id-preserving retries for ledger-side dedup.
• Deliberately no in-process ACS or pending-set: the participant node owns authoritative state and PQS exposes it queryably; an SDK-side cache is out of scope.

I added an explicit §2 — Abstraction level paragraph in 28b06d1. Happy to discuss that later, hopefully some day adoption warrants it 😉 .

so the SDK is usable independently of dpm's availability and release cadence

Dpm works like a package manager: it does not have prior knowledge of the components. Any new component can be published and resolved independently of dpm itself.

sdk-version: 3.5.0
components:
  codegen-cs:
    version: 1.0.0

This configuration will add support for dpm codegen-cs command.

and the one-time cost — a small JVM build step in CI — is paid by Peaceful Studio once rather than by every consumer.

The codegen-cs can be used on any custom DAR, in addition to Splice DARs. The JVM build step is going to be paid by all user of codegen-cs.

Technically this (try each branch) is more a shortcoming of (some?) openapi generators. (but it is the most common implementation).

I am unsure what is the real impact on the runtime performance, very likely it is negligible in most cases, as we are anyhow mostly constrained by IO (while processing json).

daml-lf-archive reports SCU upgrade-compatibility at codegen time

I don't think that daml-lf-archive performs any upgrade-compatibility checks. Could you clarify this?

The two big upgrade checks (DAR comparison) are performed at compile time and upload time.

DA is working right now with several entities that are Windows shops and will benefit from this proposal. They primarily development platform is Windows and C#/.Net. This includes: a post trade market infrastructure org, multiple global banks, and others.

That is correct, for the common DARs, only the Nuget publisher has to do the JVM step, however for custom DARs, the user of codegen-cs will have to go through the JVM build step.

The "why not reimplement `Decode.scala` in C#" decision is deliberate: the SCU rules and version dispatch are non-trivial, change with LF, and have authoritative implementations in `daml-lf-archive`. Wrapping the existing implementation is materially less risky than translating it, and in the case of common Splice DARs, the one-time cost — a small JVM build step in CI — is paid by Peaceful Studio once rather than by every consumer.

OK thanks for that precision, I believe it removes the need for a standalone CLI tool => amending the proposal to only plan the addition of a dpm component.

Agreed on both counts @jarekr-da 🙏 — Reframed it around the kind of C# type the consumer ends up writing against (OneOf<A,B,C> envelopes or custom JsonConverters). Runtime cost acknowledged as negligible against IO.

Thanks @adrien-piquerez-da 🙏 — I think I misunderstood how SCU was working and overstated daml-lf-archive's role. Removed the SCU-at-codegen claim everywhere (diagram, §2 prose, mapping-table row, M1 deliverable row).

🙏 thanks @hrischuk-da, that's good news and IMO in line with the kind of institutions Canton is targeting. If the grant is approved, we'll be happy to coordinate early with any of those orgs to ensure adoption is not too slow.

🙏 Thanks for the review @adrien-piquerez-da, @jarekr-da — I made some revisions:

• tightened the daml-lf-archive scope so the SCU and PackageMap claims match what the library actually does
• consolidated distribution on dpm codegen-cs (dropping the standalone CLI from M1, I don't think it is needed anymore).
• remove the irrelevant perf claim about C# Json Serialisation of OneOf<A,B,C> records
• unrelated to reviews but, also fixed three type-mapping bugs (Numeric N, GenMap, Time) I hope this is now more accurate!

Hi @monsieurleberre, targeted design-partner question from #51, not a request to change this approved proposal.

I revised #51 from an indexer/PQS-adjacent proposal into Canton Participant Event Gateway: direct Ledger API ingestion, interface-aware event subscriptions, REST replay/event history, reliable webhooks, delivery audit, and party-scoped auth.

For the C# / .NET SDK audience, would a participant-local event gateway like this be useful as the recommended backend event-delivery pattern for .NET app developers, so they do not each need to build Ledger API ingestion, checkpointing, replay, and webhook plumbing themselves?

If you have a quick yes/no, or a concrete gap that would make it useful/not useful, a comment on #51 would help validate whether the revised scope is solving a real developer workflow.

Milestone 1: Open-Source Release & First Reference NuGets

• Estimated Delivery: 8 weeks from funding approval
• Focus: Open-source existing code, CI/CD, NuGet publishing, codegen MVP (any DAR → C# NuGet) on the new JVM-helper / daml-lf-archive architecture (§2), dpm codegen-cs component publication, quickstart, and the first two Splice reference NuGets (Canton.Splice.Amulet, Canton.Splice.Wallet) as proof points that the pipeline produces a clean object model from real-world protocol DARs. Most of the runtime and API-client code already exists; the codegen toolchain itself is being migrated from the PoC's direct-LF-protobuf path to the JVM helper, and the milestone bundles that migration with the packaging and publishing work. The 8-week estimate (vs. the 6 weeks initially scoped) reflects that the codegen architecture migration to daml-lf-archive is materially larger than the open-source-release work it ships alongside.
• Deliverables / Value Metrics:

Verification: Tech & Ops committee or delegate confirms code compiles, tests pass, packages installable from NuGet (including the two Splice packages), and quickstart feedback collected.

Milestone 2: Full Ledger API Coverage, PQS Client, JSON API & Remaining Splice Packages

• Estimated Delivery: 10 weeks after M1 acceptance
• Focus: Complete gRPC and HTTP API surface (~40 endpoints across two transports), PQS client, async streaming, integration testing against LocalNet, remaining Splice NuGet packages
• Deliverables / Value Metrics:

Verification: Demonstrate end-to-end flow: codegen → submit command → observe transaction → query ACS, on both gRPC and HTTP paths. Community integration attempt documented.

Milestone 3: Stabilisation, Audit & Compatibility Verification

• Estimated Delivery: 7 weeks after M2 acceptance (covers the Cure53 audit window, remediation of critical/high findings landed in parallel with the audit, and cross-version compatibility verification)
• Focus: Pre-launch hardening, cross-version compatibility verification, and hosting the Cure53 security audit window
• Deliverables / Value Metrics:

The Cure53 security audit window sits in M3 between M2 acceptance and M3 acceptance — the fee is held outside the M1–M4 engineering envelope as a pass-through line (Appendix C) and remediation engineering is absorbed within the M1–M3 envelope per the severity-tiered turnaround commitments in the same appendix. The audit is therefore a milestone event, not a billable deliverable.

Verification: Cross-version compatibility matrix passing in CI against every Canton release live at M3 acceptance; Cure53 audit completed with findings remediated or documented per Appendix C.

Milestone 4: Adoption & Ecosystem Integration

• Opens: on M3 acceptance.
• Deadline: 18 months from grant approval — explicit exception to the standard 9-month default. See Deadline rationale below.
• Focus: Adoption-enabling deliverables (DocFX API reference site, ASP.NET Core sample, coordinated public launch) plus structured engagement with regulated TradFi adopters and active community engagement. The deliverables are built and shipped under M4 because they exist to enable adoption events — for the adopter, not for the SDK to be functionally complete. The SDK itself is feature-complete at M2 acceptance and stabilised, audited, and cross-version-verified through M3.
• Payment structure: decomposed into deliverable tranches and per-event tranches at a fixed 100,000 CC per adoption event, plus a conditional +20% acceleration bonus on early full completion (see Acceleration bonus below). Partial adoption success translates into partial payout rather than a binary forfeit of the whole milestone. Full breakdown in Payment Breakdown by Milestone below.
• Deliverables / Value Metrics:

Acceleration bonus. A +20% bonus of 150,000 CC is added to the M4 payout if all M4 gates above — adoption-enabling deliverables, per-event tranches, and the milestone-completion criteria — are paid in full within 15 months of grant approval. That is three months ahead of the 18-month deadline, leaving roughly nine months of M4 runtime after M3 acceptance (~6 months in, per §Volatility Stipulation) to close adoption events. This follows the convention in merged dev-fund grants (Token Standard V2 +20%, ISS-BFT +20%, LSU +10/20%, PQS +20%, Traffic-Based App Rewards +15%), most of which attach the acceleration clause to a final or adoption milestone rather than to the engineering delivery phase. The bonus pays only if the full base M4 tranche is paid in full — partial M4 completion does not produce a partial bonus. Maximum M4 with acceleration: 900,000 CC. Maximum M1–M4 total (engineering + Cure53 audit + acceleration): 2,855,000 CC — see §Funding for the breakdown.

Deadline rationale. The dev-fund standard is ≤9 months from grant approval. M4 here targets adoption among regulated TradFi institutions whose procurement and integration cycles routinely run 9–18 months for the first conversation alone — a structurally slower adopter set than the developer-tooling adopters typical of other dev-fund grants. A 9-month M4 deadline against this adopter profile is near-certain to forfeit the adoption tranche the proportionality-of-payout-to-adoption principle (raised in PR review) was designed to reward. The 18-month deadline is the shortest window in which multiple TradFi institutions can realistically be expected to close integration, and is requested as an explicit exception to the 9-month default with this rationale.

Foundation collaboration. Peaceful Studio leads all engineering and integration work and does not condition M4 acceptance on Foundation action. Realistic TradFi adoption against an 18-month deadline does, however, depend on relationship-building that materially benefits from Foundation cooperation. Peaceful Studio requests:

• Direct introductions to Canton-member institutions with .NET-heavy engineering stacks
• Inclusion of the SDK in SIG and Foundation-member communications and developer announcements
• Joint outreach where the Foundation runs institutional-developer programmes

This is a good-faith collaboration ask, not a precondition.

Verification. Adopter institutions are evidenced either publicly (named in a roster with their consent, corroborated by repo/press references) or privately (attestation to the Canton Foundation under confidentiality; Foundation confirms to the committee). The private path accommodates TradFi adopters that cannot publicly disclose their stack. Mainnet applications are evidenced by party IDs and on-chain submission. Adoption-enabling deliverables (DocFX site, ASP.NET Core sample, public launch) are evidenced by their public artefacts (deployed docs site, sample repo, dated launch announcement). Completion tranche: NuGet stats, GitHub insights, triaged-issue links.

Milestone 5+ (Ongoing): Quarterly Maintenance

• Estimated Delivery: Ongoing, quarterly renewal
• Focus: Protocol compatibility, security patches, community support
• Deliverables / Value Metrics:

Verification: Release tags demonstrating compatibility with latest Canton version; issue response times auditable via GitHub; quarterly adoption report submitted.

Acceptance Criteria

Per the template framework introduced in PR #258, acceptance is based on demonstrated ecosystem value, not artifact delivery alone. Each milestone above is bound to a measurable adoption gate (external developer feedback, NuGet downloads, named external integrations, GitHub engagement) — not a CI-passing or feature-complete checkbox.

The Tech & Ops Committee will evaluate completion based on:

• Ecosystem-value gates met for each milestone (see per-milestone deliverables — each ties funding to measurable adoption)
• Deliverables completed as specified for each milestone
• Demonstrated functionality and operational readiness
• Documentation and knowledge transfer provided

Project-specific ecosystem-value conditions:

• All code published as open source under Apache 2.0 license
• NuGet packages published and installable from the public NuGet feed — including the codegen tooling itself and pre-built Canton.Splice.* reference bindings for the published Splice DARs
• Integration tests passing against Canton LocalNet
• API documentation site deployed and accessible
• M4 ecosystem gates — adoption among regulated TradFi institutions (banks, custodians, exchange operators, asset managers) and external Canton applications using the SDK on mainnet — assessed per the deliverable + per-event tranche structure in M4 above