Mailing Lists/Asset issuance through canton networkSource on lists.sync.global ↗

Asset issuance through canton network

globalSyncForum10 messagesstarted 09-05-2025
Also mentions:CIP-0056CIP-0100
  1. #1Rahil Mansuri14-05-2025source ↗

    Thanks for the response.
    While checking the Canton Quickstart, I noticed that it requires a Daml Enterprise license, which makes it a paid product.

    I'm looking for a way to build this from scratch using only open-source tools—I don’t want to use any paid software.

    Is there a developer guide or step-by-step tutorial available to help with this?

  2. #2Curtis Hrischuk14-05-2025source ↗
    Hi Rahil.  The Canton Quickstart is not a paid product because you can use it under an evaluation license, free of charge.  

    It is the recommended way to get started with building your Canton Network application because it is designed as application scaffolding that gives you a jumpstart.  It  provides several guides (e.g., step-by-step tutorial), like you requested.  It does use open source tooling (e.g., gradle, etc.).

    It is published under the BSD Zero Clause License so you can experiment and adjust however you want.  For example, you can remove the parts that aren't OSS and still get that jumpstart.

    toggle quoted message Show quoted text

    On Wed, May 14, 2025 at 6:25 AM Rahil Mansuri via lists.sync.global <rahil=pointsville.com@...> wrote:

    Thanks for the response.
    While checking the Canton Quickstart, I noticed that it requires a Daml Enterprise license, which makes it a paid product.

    I'm looking for a way to build this from scratch using only open-source tools—I don’t want to use any paid software.

    Is there a developer guide or step-by-step tutorial available to help with this?



    --
    My best regards,
    Curtis Hrischuk, Ph.D.
    Principal Technical Product Manager / +1 919 414 2253
    Digital Asset, creators of Daml

    This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.
  3. #3Rahil Mansuri14-05-2025source ↗
    In  message #45
    Could you share the estimated release date for Splice 0.4.0, or let me know where I can check the release versions of Splice?
  4. #4Wayne Collier14-05-2025source ↗
    The GSF publishes the major upgrade dates on its calendar here:

    https://sync.global
     
    Splice 0.4.0 will be released to DevNet, TestNet and MainNet concurrently with Canton 3.3. 

    You can see all the versions of Splice on the release notes pages for each network at:

    https://sync.global/docs
  5. #5/ethen19-05-2025source ↗
  6. #6Simon Meier20-05-2025source ↗
    Thanks for sharing these links. Two comments:

    On Mon, May 19, 2025 at 9:48 PM /ethen via lists.sync.global <ethen=send.it@...> wrote:
    We are also starting to dive into this and wanted to share some links that we found valuable

    Daml: https://docs.daml.com/
    Splice: https://docs.dev.sync.global/app_dev/overview/index.html
    Onboard External Party: https://docs.digitalasset.com/build/3.3/tutorials/app-dev/external_signing_onboarding

    We are in the process of updating / porting all the 2.x docs to the 3.3 docs and this link might move due to that. In case of doubt just use the search functionality or browse the ToC to find the content on external party signing again. 
    _._,_._,_

     

     

    This link is outdated. The token standard has since been accepted https://github.com/global-synchronizer-foundation/cips/blob/main/cip-0056/cip-0056.md; and implemented as part of splice: https://github.com/hyperledger-labs/splice/tree/main/token-standard 
     
    --
    Dr. Simon Meier
    Principal Engineer, Architecture Team
    Digital Asset

    This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.
  7. #7Rahil Mansuri18-05-2026source ↗

    Hi all,

    Posted a revised version of the Cantool proposal reflecting feedback through various sources from the past several weeks. Summary of changes:

    • Descoped the original Milestone 4 (environment management) based on security concerns
    • Added a new Milestone 4 for OCI component delivery and dpm integration, addressing concerns about ecosystem fragmentation
    • Compressed timeline to 6 months
    • Reduced total ask to 1,000,000 CC base (1,100,000 CC max with early completion bonus)

    Full details on the PR: https://github.com/canton-foundation/canton-dev-fund/pull/77

    Happy to answer questions here or on the PR.


    ---
    Eric Mann
    Displace Technologies, LLC
    E: emann@...
  8. #8Rahil Mansuri22-05-2026source ↗

    Hi everyone,

    I'm Jatin Sahijwani. My co-founder Anirudh Singh and I run HackTour India (https://x.com/HackTourIND, 50+ events in 2025), and we've previously shipped grant-funded developer SDKs for the Arbitrum Foundation (a production-grade ZK SDK for Arbitrum : TypeScript, end-to-end Circom-to-verifier pipeline, single-call JS integration) and Avalanche Team1 (a ZK SDK for Avalanche subnets). We're EVM-native and exploring our first contribution to Canton.

    After studying the Q1 2026 Developer Experience and Tooling Survey and reading through the open canton-dev-fund PRs, we believe there's a coherent runtime-layer toolkit that no current proposal covers, and we're bringing it to this list first, ahead of opening a Dev Fund PR, on the encouragement of the Foundation's Tech & Ops side. 

    Working name: Canton Bindings.

    THE THREE PROBLEMS, FROM THE FOUNDATION'S OWN SURVEY:

    1. "Typed Client SDK & Code Generator: Developers currently spend days manually extracting hash strings from compiled files (.dar) and hardcoding them into their frontends." Only daml codegen js ships officially. Teams in Python, Java/Kotlin, Rust, or Go are on their own.
    2. "JWT authentication middleware ... a repeated friction point for 'Hybrid' and 'TradFi' teams", which is the 83% of survey respondents.
    3. "Pre-Flight Resource & Cost Profiler", devs "deploying blindly" and finding out about byte-size limits only after a failed submission.

    All three live in the same architectural layer (between the dev loop and the protocol) and we believe they're best scoped as a single coherent toolkit rather than three separate proposals.

    PROPOSED SCOPE:

    • Codegen + runtime SDK for TypeScript, Python, Java/Kotlin, Rust, and Go
    • Runtime Package ID Resolver (eliminates hardcoded .dar hashes via PackageManagementService introspection)
    • JWT/OIDC middleware with first-class Keycloak, Auth0, Azure AD, and Okta presets, with party-claim mapping
    • Pre-flight transaction byte-size and Canton Coin cost estimator (target ±5% accuracy)
    • Cantool plugin (cantool bindings gen <lang>) so Eric's CLI users get this as a first-class extension

    POSITIONING (DELIBERATELY COMPLEMENTARY, NOT COMPETITIVE):

    • Cantool (PR #77) handles the local dev loop. We sit on top of it for codegen and runtime.
    • CantonTrace (PR #185) handles runtime debugging. We sit alongside it as the typed client.
    • PartyLayer (PR #9) and Wallet Gateway (PR #109) handle end-user/wallet signing. We sit on the server/service side.
    • daml codegen js stays as-is for pure JS users. We add four more languages and the runtime resolver around it.

    PROPOSED FUNDING SHAPE:

    • 700,000 CC across 4 milestones, ~24 weeks
    • M1 175K (TypeScript + Resolver + Keycloak)
    • M2 200K (Python + Java/Kotlin + Auth0/AAD)
    • M3 175K (Rust + Go + Okta + Pre-Flight Profiler)
    • M4 150K (Cantool plugin + docs + tutorials + maintainer handoff)
    • Volatility stipulation per CIP-0100 on M3 and M4
    • License: Apache-2.0 (code), CC0-1.0 (proposal)

    Anchored between Axcess (~318K CC) and x402 (~1M CC) based on scope.

    FULL DESIGN DOCUMENT (architecture diagrams, milestone breakdown, alignment table, risk register, honest §7 on our Daml/Canton ramp-up): https://github.com/jatinsahijwani/canton-bindings/blob/main/README.md

    WHAT WE'D LOVE INPUT ON, BEFORE WE OPEN A PR:

    1. Language priority : we have TS → Python → Java/Kotlin → Rust → Go. Anyone blocked on a different order? Especially curious if Java should jump Python given the institutional/TradFi skew.
    2. IdP coverage : Keycloak / Auth0 / Azure AD / Okta covers the largest enterprise share. Anyone urgently needs Ping, OneLogin, or self-hosted OIDC first?
    3. Prior art we may have missed : if anything in scope is already being built (open-source or in flight), we'd much rather plug into it than rebuild.
    4. Cantool plugin shape : what's the right integration boundary? Eric, would love your view here.

    We'd particularly value input from folks active in the Daml Language & Developer Tooling, DAR Package Management & App Lifecycle, dApp Integration, and Canton APIs SIGs, and from anyone building TradFi/Hybrid apps who's hit the JWT pain firsthand.

    Happy to take this conversation deeper anywhere it's useful.

    Best,
    Jatin Sahijwani,
    Co-founder,
    HackTour India https://x.com/HackTourIND
    GitHub: https://github.com/jatinsahijwani

  9. #9frank.preiwuss@digitalasset.com26-05-2026source ↗
    Hello everyone,
    A few weeks ago, InfraSingularity submitted a proposal to the Canton Dev Fund for building a Canton-native Transaction Debugger, and we’re currently looking to gather reviews and feedback from the relevant contributors and ecosystem stakeholders.
    The proposal focuses on three primary deliverables:
    • A deterministic decoding engine for Canton/Daml transaction failures
    • Privacy-aware, shareable debug bundles
    • A debugger UI with scoped replay tooling
    The broader goal is to significantly reduce transaction debugging time — from hours to minutes — while improving the overall developer experience across the Canton ecosystem.
    Proposal Link:
    Canton Dev Fund Proposal #297
    We would greatly appreciate any feedback, technical review, or guidance from the community to help ensure the proposal aligns well with ecosystem needs and priorities. If there are any additional SIGs, contributors, or stakeholders we should directly reach out to for reviews, we would be grateful for the direction as well.
    Best regards,
    Jitin Jain
    CEO, InfraSingularity
  10. #10Simon Meier01-06-2026source ↗
    Hi all,

    I'm Irpan from Askardex. We run a Canton validator on MainNet, and over the past months we built an internal tool to handle the parts of bringing a validator up that are tedious and easy to get wrong. We've cleaned it up, open-sourced it, and submitted it as a Development Fund proposal.

    The tool is called NodePilot. In short, it takes a validator from a bare host or an empty Kubernetes cluster to a registered, healthy node: the participant, Postgres, Keycloak, ingress, TLS, and the one-time onboarding secret, all in one guided flow instead of a pile of shell scripts and hand-edited Helm values. It works two ways: Docker Compose over SSH for single-host operators, and Helm on Kubernetes for production. It already runs our own node, so the failure modes it guards against (the cold-start traffic deadlock, audience-mapper mismatches, onboarding-secret reuse, the topology delay on first registration) are ones we actually hit.

    The PR was auto-closed because it needs a Tech & Ops Committee or Core Contributors champion, which makes sense for an external team like ours. So I'm reaching out here: if anyone working in node deployment and operations would be open to championing it, or can point me to the right person, I'd really appreciate it. We're listed in the Node Deployment & Operations SIG, and I'm happy to give a short walkthrough or answer questions.

    Proposal (PR): [https://github.com/canton-foundation/canton-dev-fund/pull/402](https://github.com/canton-foundation/canton-dev-fund/pull/402)
    Proposal text: [https://github.com/askardex/canton-dev-fund/blob/proposal/nodepilot/proposals/nodepilot.md](https://github.com/askardex/canton-dev-fund/blob/proposal/nodepilot/proposals/nodepilot.md)
    Source code: [https://github.com/askardex/nodepilot](https://github.com/askardex/nodepilot)

    Thanks for reading,
    Irpan
    Askardex