Proposal: Canton Payment Streams

[deepthi-2531]

Development Fund Proposal Submission

Proposal file:
/proposals/canton-payment-streams.md

Summary

This proposal requests funding for Canton Payment Streams, an open-source reference implementation for privacy-preserving continuous payment streaming, vesting, and programmable payment flows on Canton.

It provides Daml smart contract templates, a TypeScript SDK, a reproducible demo environment, and a thin web dashboard for creating, monitoring, and withdrawing from prefunded streams. The goal is to deliver shared ecosystem infrastructure for payroll, vesting, and recurring payment use cases that benefits multiple Canton builders.

Checklist

• Proposal file added under /proposals/
• Milestones and funding amounts defined
• Acceptance criteria included
• Alignment with Canton priorities described

Notes for Reviewers

This proposal is scoped as shared ecosystem infrastructure, not a billing platform or proprietary product.

It addresses a clear ecosystem gap: payment streaming is a well-known primitive on other networks, but Canton does not yet have an open-source, reusable streaming reference implementation for teams that need payroll, vesting, contributor compensation, or subscription-style payment flows.

The proposal is intentionally scoped as a phase 1 reference implementation for prefunded, single-domain streams so the initial milestone set remains verifiable and realistic.

The main differentiators are:

• privacy-preserving streaming using Canton and Daml visibility rules, so stream terms and balances are visible only to authorized parties
• on-ledger enforcement of stream lifecycle logic through Daml templates, rather than off-chain automation or proprietary backend services
• prefunded escrow-based settlement model aligned with Canton Coin and a reference CIP-56-compatible token path
• reusable developer-facing deliverables including Daml packages, SDK, demo environment, integration examples, and deployment documentation
• milestone-based delivery with clear acceptance criteria, ecosystem validation, and public release under Apache 2.0

Policy-based delegated automation is listed only as a future roadmap item and is not part of the requested phase 1 milestone scope.

[hellenstans97]

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.

[deepthi-2531]

@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.

[hellenstans97]

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.