Proposal: Canton Payment Streams

This is a useful tool with a clear use case, and it’s good to see something like this being proposed for Canton.

My main question is around the immediate impact on the Canton ecosystem. On its own, this feels like infrastructure that still needs a team or product layer on top to actively adopt it, source users, and turn it into something that drives real usage on the network.

It reminds me of Superfluid, a streaming payments protocol, where early traction for the project came from actively partnering with DAOs like ENS and Optimism to stream payouts for grantees, and later through their own incentive programs to drive usage.

Without a similar adoption path here, there is a risk this becomes a well-built tool but with limited short term impact, even if it is reusable in theory.

@hellenstans97 You’re absolutely right to highlight the risk of “infrastructure waiting for a product.” This proposal is deliberately designed to bridge that gap by delivering both a public‑good primitive and the adoption layer around it: an opinionated TypeScript SDK, a React dashboard, and end‑to‑end integration guides so that teams can move from theory to utility on day one.

In line with the Canton Development Fund (CIP‑0100) mandate, this is framed as a reference implementation intended as a shared benefit for the ecosystem rather than a proprietary product. We have intentionally avoided building a closed product layer so that these rails remain neutral, open‑source (Apache 2.0), and reusable by any participant without vendor lock‑in.

Concretely, we see three high‑impact early adopter groups that move this beyond “scaffolding” and into real usage:

1. Institutional payroll & vesting (privacy USP): While streaming exists on public chains, those protocols expose sensitive compensation data. By leveraging Canton’s sub‑transaction privacy, this tooling allows institutions to move payroll and vesting on‑ledger while still meeting GDPR and trade‑secret requirements that have been blockers for public‑chain streaming.
2. Ecosystem platforms (the “streaming backend”): Rather than building a siloed app, we are providing an SDK that existing wallets, billing platforms (such as Cantara), and operator consoles can plug in as their streaming backend. This mirrors the Superfluid playbook: we supply robust protocol logic so those teams can focus on UX and user acquisition.
3. Capital markets workflows (streaming repo interest): Canton already underpins large‑scale tokenized collateral and repo activity, where a major pain point is unremunerated or under‑remunerated collateral. Streaming payments make it straightforward to express “interest accruing every second” on top of existing collateral and repo flows, directly improving liquidity efficiency for participants.

I fully agree that Superfluid’s traction came from deep integration with specific partners like ENS and Optimism rather than just publishing contracts. Our validation phase mirrors that approach by including reference integrations with existing Canton workflows and publishing those as case studies, so we end up with concrete “this is how it’s used in practice” examples rather than just a code library. In that sense, this proposal funds the essential public‑good rails; once those common‑good building blocks are live and their institutional value is demonstrated, a dedicated product layer or incentive program can be developed as a natural follow‑on, rather than being bundled into this initial infrastructure grant.

To solve the exact visibility issue for new builders, I've also created a companion proposal: Canton Builder Navigator — an ecosystem catalog + AI-assisted discovery layer that indexes all grant-funded projects (including this streaming primitive). A new dev searching "payroll streaming" or "vesting schedules" would immediately surface this exact tool with explainable recommendations, starter paths, and direct repo links. Our validation phase delivers reference integrations/case studies; Navigator ensures developers can find them.

That makes sense, and I see the intention to lower the barrier with the SDK, dashboard, and integration guides being open-sourced to the community.

My question is more around whether there is already clear demand from developer teams who would adopt this infrastructure and actively drive usage and impact.

I agree this use case aligns well with Canton’s privacy advantage. It will be interesting to see what gets built on top of it and how quickly that translates into real usage on the Canton ecosystem.

Review Feedback — Canton Payment Streams

Thank you for the submission and for contributing a proposal focused on payment streaming, vesting, and programmable payment flows on Canton.

That said, a few areas would benefit from clarification:

1. Evidence of ecosystem demand

The proposal makes a strong conceptual case, but it is not yet clear:

• which teams are planning to adopt this in the near term
• whether there are committed integrations or active users

2. Adoption beyond the reference implementation

The proposal includes SDK, dashboard, and demos, which is positive. It would help to clarify:

• how this translates into real usage on Canton
• whether there are target early adopters or integration partners

Overall, this is a strong and thoughtful proposal. Clarifying demand and adoption pathways would strengthen confidence in ecosystem impact.

Thanks for the thoughtful review. This was helpful feedback @hythloda

I’ve updated the proposal to address the two main areas you called out:

1. Evidence of ecosystem demand

   • clarified that the proposal targets recurring Canton-native workflows that already exist across payroll-style payouts, vesting schedules, milestone-based service payments, and recurring treasury / contributor disbursements
   • made the case more explicit that the problem is not hypothetical product design, but repeated payment-flow logic that teams would otherwise implement independently

2. Adoption beyond the reference implementation

   • strengthened the adoption section to identify the most likely early adopters more clearly
   • added a more explicit success model beyond initial release, including external evaluation / pilot-style usage, reusable integration examples, and downstream adoption of the Daml package or SDK as a building block

I also tightened the proposal so the adoption story is framed not just as “SDK + dashboard + demo,” but as a path toward real reuse in payroll, vesting, treasury, and milestone-payment workflows on Canton.

Happy to keep refining further if there are specific adopter signals or validation expectations the committee would like to see.

This looks valuable to us.

From a Zynk perspective, payment streaming is the kind of reusable primitive we can see us wanting for vesting, recurring payouts, and other time-based payment flows. It feels more useful to have one open-source reference implementation than to have each team build its own version of the same logic privately.

We especially like that the proposal is scoped as shared infrastructure and a reference implementation, rather than trying to be a full end-user billing platform from day one. We would want to use this especially USDC path and CC for our subscriptions.

We at BitDynamics would like to use Canton Payment Streams once it is implemented.

Payment streaming already solves a real need on public chains like Ethereum, and we think having a similar primitive on Canton would be valuable, especially because of Canton’s privacy features. We can see this being useful for subscription and payment flows at BitDynamics, and we would be interested in integrating it for those use cases.

We’d be interested in evaluating this as well

We'd like to contribute to this initiative because we were building a service like this inhouse for our Neobank. Would like to connect

We would be interested in using this, and this is one of the core use cases from uETH that adds value to Canton.

We'd be willing to test milestone deliverables as they land and provide feedback from an application-side perspective.

@deepthi-2531 this looks interesting, a few observations:

1. What factors influenced the decision to pre-fund the payment stream? What is the intended use case? It may be capital inefficient depending on how it's structured
2. A smart contract audit is not included in the grant. I think meaningful adoption will be difficult without one. I'd recommend adding audit scope to the request and allocating budget for it. Otherwise, this risks becoming an open-source reference implementation that never reaches production use
3. There is no maintenance budget requested. How do you ensure continuity after delivery? A few features are also marked as out of scope for future iterations, but without ongoing support they may never be completed
4. Several projects have expressed interest in using it, which is great to see. Given that early interest, it may be worth tying part of the funding request to an adoption milestone as a signal of validation and real demand

@joel-da

On pre-funding: v1 is intentionally designed as an escrow-backed, prefunded stream because the initial goal is guaranteed settlement across apps and supported assets, without introducing credit risk, insolvency handling, liquidation mechanics, or continuous top-up dependencies. The main target use cases are bounded-term flows such as milestone escrow, vesting, grants, prepaid subscriptions, recurring service agreements, and fixed-duration payroll cycles. I agree this is less capital-efficient for long-dated or open-ended streams, so I will make that tradeoff explicit and position more capital-efficient models like rolling buffer / top-up streams as future work.

On audit and maintenance: I had initially left both out because I felt the ask would go materially higher if I bundled core implementation, audit, and longer-term support into the first request, and I thought those could be handled in a follow-on proposal once adoption started to materialize. Need your help here if those should be included here or in follow up request once implementation is done and community starts to test , I can quickly get this audited and create a maintenance support

On adoption: agreed. I will tie the last milestone to external validation, so the final phase includes audit, remediation, maintenance, and adoption validation together.

What do you think? Or do you want me to include Audit and short term maintenance in this proposal? and Longer-term support and future feature expansion can still be handled as a follow-on request if the project sees meaningful adoption.

Thanks for the proposal — this is an interesting area to explore.

The main concern right now is the lack of clear demand or confirmed users for this approach. The use cases (like payroll) are compelling in theory, but we would need to see stronger evidence that institutions or ecosystem participants plan to adopt a prefunded streaming model.

To strengthen this, it would help to include:

Concrete adoption signals (teams planning to use it) Milestones tied to real usage, not just implementation Examples or data showing success of similar models elsewhere

Happy to revisit with that additional context.

Thanks @hythloda — this is genuinely helpful feedback, and I want to address it directly.

The biggest correction I want to make is on demand: this is not just theoretical. We already have named ecosystem teams asking for this in concrete workflow terms. BitDynamics and Lumens.fi have raised LP incentive streaming as a real need, where prefunding is actually valuable because it gives LPs and market makers confidence that committed rewards are already reserved. Gateway has raised validator and infrastructure billing as a concrete recurring-payment use case — specifically real-time, trust-minimized metered accrual, which is a more natural fit than invoice-and-settle cycles. . I will make these design-partner signals much more explicit in the revised proposal and tie milestones to external validation and usage, not just implementation.

I also agree that payroll was the wrong lead example. The stronger Canton-native use cases are:

• LP incentives and market-maker retainers
• Validator and infrastructure service billing (real-time metered accrual)
• Vesting, grants, and private-round unlock schedules
• Institutional custody / servicing / financing fee accrual

These fit Canton particularly well because the commercial terms, balances, and counterparties are often sensitive, while the assets themselves increasingly need to be interoperable across applications.

On prefunding: the original rationale was to guarantee settlement in v1 and avoid credit risk, insolvency handling, liquidation mechanics, or top-up dependencies. I still think that is the right starting point for the partner use cases above. Treasury-budgeted LP incentives, vesting, and fixed-term retainers all benefit from reserved capital because it makes the commitment credible to the counterparty. That said, I agree prefunding is capital-inefficient for open-ended flows, so I will make that tradeoff explicit and position non-prefunded / rolling top-up models as a planned second path in the broader project design.

I will also strengthen the proposal with clearer precedent from other ecosystems especially ETH. Sablier Lockup shows that prefunded streams can reach product-market fit for bounded-term use cases, with Sablier reporting over $1B in cumulative payment volume (reached before the V2 launch in September 2024). Superfluid shows that non-prefunded / buffer-based streams can also scale meaningfully, with public figures of over $750M in streamed volume across 350K+ wallets and 850+ projects built on the protocol. Sablier's later Flow model is also useful evidence that open-ended recurring payments often need a more capital-efficient design than pure lockup, and Sablier themselves position Flow specifically for payroll, grants, subscriptions, and rent. I think the right lesson is that both models are valid; the important thing is matching each model to the right Canton use case.

Finally, I agree on audit and maintenance. I initially left them out to keep the first request contained, but I agree adoption is unrealistic without both security validation and continuity. I will revise the final milestone so it includes independent audit/review, remediation of material findings, a defined maintenance/support window, and adoption validation tied to the named partner use cases above.

Overall, I think the revised proposal will be materially stronger by foregrounding named partner demand, tying milestones to real usage, leading with Canton-native institutional use cases, and making the security and continuity path explicit.

Please open it back to voting as this clarifies the raised issues and also I will update the Proposal accordingly.

On audit and maintenance: I had initially left both out because I felt the ask would go materially higher if I bundled core implementation, audit, and longer-term support into the first request, and I thought those could be handled in a follow-on proposal once adoption started to materialize. Need your help here if those should be included here or in follow up request once implementation is done and community starts to test , I can quickly get this audited and create a maintenance support

@srikanth-bitdynamics building on my earlier point, without an audit, adoption will likely be limited. This creates a risk of ending up with a codebase that functions as a reference, rather than a production ready product

@deepthi-2531 Really strong revised framing —, he institutional use cases land much better than payroll as a lead. On the audit point: worth flagging that Canton contract security is genuinely its own discipline. The privacy model, sub-transaction architecture, and Daml execution environment introduce attack surfaces that don't map cleanly from EVM or Solana audit methodology. We've quietly completed three Canton contract audits over the past year , all under NDA with ecosystem teams. If this proposal moves forward and the team wants independent review, we'd be happy to offer a discounted rate given the public-goods nature of the work. The goal would be making sure something at this layer gets done right, not just done. Happy to connect off-thread if useful. -BlockApex Security

@joel-da Noted Joel . Added Audit in the Milestones.

@MujSensei Definitely can you send your email will get in touch once this is approved.

What do you mean by this feature? Specifically, what are you proxying and what makes it browser-safe?

Why choose Testnet here as opposed to Mainnet?

Why not target any CIP-056 asset? Especially as the V2 of the token standard is being developed it would be serious short coming of a Canton payment streams library if it did not target the token standard.

While these are sensible choices on an existing payment stream, one thing that this platform should address is are the workflows (the request, accept) necessary to aggregate necessary authority for the payment stream.

This project would make a great addition to the network, it is certainly something we have discussed internally and we are happy to see someone taking up the mantle to build this. From the proposal three things stood out:

1. While onledger payment stream state is the right approach, and the SDK is nice, everyone will then have to write automation for the most common cases. That automation will also need authorization and common logic, and its design will influence the payment streams. Specifically, I think to design one well you have to design/build the other part at the same time. I think this proposal can benefit from committing to it as well.
2. This proposal did not make any requests for funding?
3. Can you describe your experience developing on Canton and your qualifications?

Note you might want to build this using the dApp architecture: https://github.com/canton-network/wallet-gateway/tree/main/docs/dapp-building (based on CIP-103)

We already have most of it using this but I'll make sure we align to this while developing. Thanks for this @daravep

browser-safe is meant in the specific sense of: credentials and topology that shouldn't be in the browser aren't, and each browser-reachable action is bound to a role and a party check. It's a reference pattern, not a hardened gateway

I want to launch this as production grade but launching the app on mainnet would make this a service which I'm mindful of as this is intended to be OSS . That said code will always be ready as mainnet. But if you think otherwise happy to discuss and change it

We do support all CIP56 Assets but as an example of how this works I added support for CC & USDC . We will also support V2 Tokenstandard

The repo I' building has propose → accept → finalize chains per settlement mode. Will make sure this is taken into consideration thanks

Thanks.

Committing to live use on MainNet would be a stronger commitment, that I encourage.

Would be great if your proposal and the SDK targeted token standard assets specifically.

Following our discussion in the voting committee, I haven't personally seen much commercial demand for payment streams in Canton. That said, if the milestones are stated in a way that completely tie the payment to adoption metrics, e.g. amount of burn driven by this app, I'd be happy to vote "yes." That way, regardless of my opinion on whether this gets adopted, the developer takes the risk, and the upside is completely tied to aligned incentives.

@shaul-da Updated Proposal to keep >80% of funding after Milestone 4 which is

• at least 10 featured apps integrating Canton Payment Streams in production on Mainnet
• a minimum of 100 active streams running on Mainnet across these integrations over a rolling 30-day window

Hope this is ok now as majority is tied to adoption metrics.

Following our discussion in the voting committee, I haven't personally seen much commercial demand for payment streams in Canton. That said, if the milestones are stated in a way that completely tie the payment to adoption metrics, e.g. amount of burn driven by this app, I'd be happy to vote "yes." That way, regardless of my opinion on whether this gets adopted, the developer takes the risk, and the upside is completely tied to aligned incentives.

@shaul-da @daravep @hythloda @srikanth-bitdynamics — We want to show you something.

We are not connected to this proposal at all. We built Canton payment streaming on our own, no grant, no approval, no CC asked yet, just because we believed it was the right primitive for this network.

Here's where we are today:

Live repo, full working product: https://github.com/BlockX-AI/Canton_Streams_RewardApp/tree/canton_native 800+ real users already on it via CCTools: https://www.cctools.network/earn/growstreams-x-cctools 1,500+ community members following the build: https://x.com/GrowwStreams 66/66 on chain tests passing on Canton. CIP-0103 wallet integration. Built and shipped. Feel free to check these out and let us know your valuable feedbacks

We had a conversation with Melvis about this. He said "Per second is probably too aggressive. Hourly or even daily payment streams already move the needle compared to the status ". He was right. We've already reframed around that. The per-second precision is the protocol floor, not the pitch.

His other point was that demand has to come first, or the bulk of any funding should be tied to adoption milestones. We're already past that problem — the demand is real and visible above.

We would like to raise a PR from our side, structured exactly the way Melvis suggested — adoption-gated, no upfront payout, everything tied to active streams on Mainnet. Would the committee be open to that?

Not competing with @deepthi-2531 here, genuinely open to joining forces if that's useful. Just want to make sure the committee has the full picture on where demand actually stands.

@shaul-da Author Updated metrics for adoption so moved it back to ready to vote again based on your comment.

@BlockXAI Good to see community demand

@shaul-da Author Updated metrics for adoption so moved it back to ready to vote again based on your comment.

@BlockXAI Good to see community demand

@shaul-da We're also happy to raise a PR as we already have the user demand... Got 1500 users in 8 hours of our launch to canton https://x.com/cantontools/status/2054905080160112680?s=20 We don't need to wait to build or don't even need CC To build or show demand... We also have the users also the demand over community We just need to reward this community and bring more and more growth to this community on Canton 1500+ on chain users 3000+ followers on x 1000+ community

Collaboration wity canton projects 3-4 already

Happy to take this idea more forward

@BlockXAI Please create a PR and let us know we will review the Proposal and send it to voting post review

@BlockXAI Please create a PR and let us know we will review the Proposal and send it to voting post review

Sure Will Do ASAP

@BlockXAI Please create a PR and let us know we will review the Proposal and send it to voting post review

Here you go! Could you please give a label of financial-workflows-composability to this proposal and help us get you as champion @srikanth-bitdynamics As you been providing valuable expertise to this use case from last few months. Happy to have your review and go ahead to voting. We kept most with adoption as just needed the grants supports for deployments and maintenance. PR Link: https://github.com/canton-foundation/canton-dev-fund/pull/344

- Grantee is excluded from the qualifying burn count
- Traffic counted toward this milestone must originate from real usage by users/companies not affiliated with the FTP team.

To move to approved needs to have this clause.

@deepthi-2531 you good with this addition?

@hythloda Updated the proposal to match this

I wonder how you build this on top of CIP-56. You are likely going to have an easier time using committed V2 allocations with iterated settlement, which lands as part of token standard V2: https://lists.sync.global/g/cip-discuss/message/743

Happy to do take a look at your Daml models to learn how the standards are being used; and if I can provide some input based on the experience I gathered as part of my work on splice and the token standards.

@meiersi-da We worked on V2 only as this will be the default going forward. I shared you access to the working repo https://github.com/deepthi-2531/Payment-Streams can you have a look and add your review when you have time. Thanks again for helping out.

Ah using V2 I can see how you can make this work. Consider adding your voice to https://lists.sync.global/g/cip-discuss/message/770 so that SV rights owners get this extra datapoint that you are fully depending on the V2 token standard being voted-in in a timely fashion.

It looks like you've been using AI to generate a large amount of the code. I've thus time boxed my review time. Some notes:

• CIP-0047 is going to be phased out as soon as CIP-104 goes live. Current ETA is around end of July. The economics will likely also change. Assuming that you always get $1.50 for $0.50 of traffic burn is fragile.

• someone has to drive Allocation_ExecuteTransfer

  This choice no longer exists in CIP-112.

The whole repo looks like a massive wall of text to me as a human. Consider how to enable humans to answer the following questions:

1. Should I use this?
2. How do I best use this?

Then focus on what's the minimal amount of code to deliver on the answers you want them to make.

@meiersi-da Thanks this is still WIP so nothing is ready shared repo with you for DAML review. I will tag you once final version is ready so your questions on Should I use this and How do I best use this will be answered in README itself.

Hi @deepthi-2531, 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 Canton Payment Streams, would a participant-local event gateway be useful for stream-created / withdrawn / archived lifecycle notifications, app backend updates, and replaying missed events after downtime?

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 maps to real app workflows.

Milestone 1: Public OSS Repo, Threat Model, and Prefunded CC Reference Flow

A new evaluator can clone the repository, run the sandbox, create streams, and validate the base lifecycle from documentation alone.

Deliverables

• public GitHub repo under Apache 2.0
• architecture note and initial threat model
• Daml templates for the base prefunded stream lifecycle
• Canton Coin reference flow implemented end to end
• reproducible local sandbox demo
• initial SDK surface for create/query/withdraw/cancel
• initial integrator documentation

Milestone 2: USDCx Reference Integration, Rolling Top-Up Path, and External Validation

An external builder should be able to test LP incentives, vesting, or recurring billing workflows using the SDK and examples.

Deliverables

• named USDCx reference integration
• documented generic adapter boundary for downstream tokens
• non-prefunded / rolling top-up reference path
• expanded TypeScript SDK and event/query surfaces
• integration examples for LP incentives, vesting, and recurring billing
• onboarding guide for new tokens and host-wallet integrations

Milestone 3: Hardening, Audit/Review, Maintenance Window, and Adoption Validation

The full reference stack is published as a release candidate another team can evaluate without one-off setup help.

Deliverables

• React reference dashboard and proxy
• documented prefunded and non-prefunded reference flows
• independent smart contract audit or experienced Daml/Canton review
• remediation of material findings
• production-oriented runbooks and deployment documentation
• defined maintenance/support window
• adoption validation tied to named design-partner workflows
• public release candidate suitable for real ecosystem evaluation

Milestone 4: Adoption on Mainnet

Canton Payment Streams transitions from a release candidate to a production-validated primitive demonstrably in use across the ecosystem, with measurable adoption, audit certification, and a public maintenance commitment.

Deliverables

• at least 5 featured apps integrating Canton Payment Streams in production on Mainnet
• a minimum of 50 active streams running on Mainnet across these integrations over a rolling 30-day window
• external security audit certification with all Critical and High findings remediated and the audit report published
• Apache 2.0 release of the full reference stack including Daml packages, TypeScript SDK, React dashboard, and reference proxy
• final adoption report submitted to the Canton Dev Fund Committee summarizing usage metrics, integrator feedback, and lessons learned

Milestone 5: Performance-Based Adoption Bonus

A metric-triggered tranche running for 12 months from grant delivery. Disbursed in 100,000 CC increments as on-chain CC burn through Canton Payment Streams crosses each 200,000 CC threshold.

Acceptance test (per tranche)

• Cumulative CC burn on transactions exercising Canton Payment Streams template ids exceeds the next 200,000 CC threshold
• Grantee is excluded from the qualifying burn count
• Traffic counted toward this milestone must originate from real usage by users/companies not affiliated with Grantee's Featured App.
• The 12-month window from grant delivery of milestone 4 has not yet elapsed
• Cap of 1,000,000 CC total bonus has not been reached

Deliverables

• canonical template-id manifest pinned at Milestone 1 (binding artifact for bonus computation)
• public adoption-metric report at each tranche claim

Breakdown by Milestone