Proposals/canton-foundation/canton-dev-fund/#300GitHub ↗

Ready for Vote#300 Pull requestQasaraRFP 20, Indexers (rfp-20: indexers-observability), node-local. Also serves RFP 14, Wallet and dApp Integration tooling. Category: Developer Experience, Tooling & Education.

Proposal: Canton Event Stream — real-time ledger events via WebSocket…

Opened 05-05-2026 by anand-qasara, last activity 4d ago

Incoming29 days05-05-2026
In Review4.7 days03-06-2026
Ready for Vote23 days08-06-2026
Needs Revision14 days01-07-2026
Ready for Vote8.9 days15-07-2026
Needs Revision11 days24-07-2026
Ready for Vote29 days04-08-2026
Needs Revision1 day02-09-2026
Ready for Vote48 days so far03-09-2026
Voting Livenot reached
Approvednot reached

Waiting on: In a vote; idle 4.7 days
Funding request: 300,000 CC
Duration: up to ~8.5 months (14-week build, then an external-adoption window of up to 6 months after the Milestone 2 release)
Organization: Qasara
RFP or roadmap area: RFP 20, Indexers (rfp-20: indexers-observability), node-local. Also serves RFP 14, Wallet and dApp Integration tooling. Category: Developer Experience, Tooling & Education.
Discussion: 57 messages; 10 people

Proposal file: /proposals/canton-event-stream.md

Summary Canton Event Stream is a self-hostable, MIT-licensed Node.js service that connects to any Canton participant node and delivers classified, party-routed ledger events to application clients over WebSocket and SSE. It solves the missing push layer in the Canton ecosystem — the infrastructure between the raw JSON Ledger API stream and live UIs, deposit detectors, and reactive backends. The core implementation exists today inside Qasara's commercial Canton Gateway; this proposal extracts and open-sources it as a standalone package in 3 milestones over 6 weeks, funded at 300,000 CC.

Checklist

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

Notes for Reviewers

The core ingester (Splice interface subscription, Redis pub/sub fanout, WebSocket + SSE endpoints) is already running in Qasara's DevNet environment — this is an extraction + open-sourcing grant, not a greenfield build.
This proposal complements PQS (CIP-0100, approved 2026-04-23) rather than competing with it. PQS is the pull layer (SQL ODS); Canton Event Stream is the push layer (WebSocket/SSE). The Rationale section explains the coexistence design.
Champion: Parth (parth@canton.foundation), Canton Foundation.
Funding request: 300,000 CC across 3 milestones (120k / 100k / 80k).

Milestones 6

Standalone Package + Edge Authorization + RecordTime OrderingWeek 6
Configurable Subscriptions + Session Lifecycle + Integration Tests + AsyncAPI SpecWeek 11
Production Release + CIP Draft + External MainNet Adoptionproduction release by Week 14; the external-adoption window runs up to 6 months
A usable, privacy-correct, correctly-ordered event layer exists
General-purpose and adoptable
It runs in production, is externally adopted, and proposes a standard

Discussion23 comments, 0 reviews, 34 inline comments

Showing automated messages too. Hide bot messages

Showing 1 to 59 of 59, oldest first.

Denendcontributorcommented06-06-2026 · 4mo agoGitHub ↗

Quick question - how does canton event stream position itself relative to Cantons native push layer (json ledger api v2 ws channels via AsyncAPI, plus grpc UpdateService.GetUpdates server-streaming)? Would help to see the delta laid out

Refs:

Denendcontributorcommented07-06-2026 · 4mo agoGitHub ↗

@anand-qasara

anand-qasaracommented08-06-2026 · 4mo agoGitHub ↗

Quick question - how does canton event stream position itself relative to Cantons native push layer (json ledger api v2 ws channels via AsyncAPI, plus grpc UpdateService.GetUpdates server-streaming)? Would help to see the delta laid out

Refs:

https://github.com/digital-asset/canton/blob/main/community/ledger/ledger-json-api/src/test/resources/json-api-docs/asyncapi.yaml

https://github.com/digital-asset/canton/blob/main/docs-open/src/sphinx/sdk/tutorials/json-api/canton_and_the_json_ledger_api_ts_websocket.rst

@anand-qasara

Good question — and an important distinction. Let me lay out the delta precisely.

Canton's native push layer — gRPC UpdateService.GetUpdates and the AsyncAPI-documented JSON Ledger API WebSocket channels (/v2/updates et al.) — is the transport, and it's complete: multi-party filtering (filtersByParty), offset/checkpoint resume, and LEDGER_EFFECTS choice data are all first-class. Canton Event Stream is not an alternative transport. It consumes the native JSON WS upstream and sits above it as the application-edge layer.

The delta is the part the transport intentionally doesn't provide, and the core of it is privacy:

When a client talks to the participant directly, the node enforces per-party authorization — the token's read-rights bound which parties it can put in filtersByParty, so a consumer physically cannot subscribe to a party it isn't entitled to. That's exactly right, but it's a per-client model: every browser/microservice opens its own node subscription, holds a Ledger API token, and receives raw Created/Archived/Exercised primitives it has to classify itself.

The moment you add a fan-out tier to serve many clients from one upstream subscription — which you must, to avoid exposing the participant to every client and handing every client a ledger token — the node's per-party authorization boundary is removed from the downstream path. Something has to re-establish it, or one party's events leak to another. A generic WebSocket fan-out (Centrifugo, socket.io + Redis) can't: it has no concept of a Canton party or of who is entitled to see whose events. Re-enforcing per-party authorization at the streaming edge is the Canton-specific, security-critical work that makes a purpose-built event gateway necessary rather than off-the-shelf pub/sub — and it's the central deliverable of this proposal (M1), not an afterthought.

So the three deltas over the native transport are:

Per-party authorization at the edge — preserving Canton's privacy guarantee across the client-decoupling boundary (the hard part; generic infra gets this wrong). Fan-in/fan-out — one upstream node subscription serving many clients, so the participant isn't exposed to or loaded by every client, and clients never hold a ledger token. CIP-0056 event classification — mapping raw Created/Exercised(choice, consuming) into the stable token-standard vocabulary (transfer.executed, …) so every team doesn't re-implement and re-maintain the same Splice-interface→event mapping. It composes with the native layer rather than replacing it — the same relationship the proposal draws with PQS on the pull side (native primitive below, shared application-layer infrastructure above). It also only ever delivers events for parties an operator is authorized to read; by Canton's authorization model it can't expose third-party private events.

I've updated the proposal to make this explicit: see the new "Relationship to Canton's native push layer (JSON WS and gRPC streaming)" section under Rationale, the per-party authorization deliverable in Milestone 1, and the reframed Abstract/Objective. Thanks for pushing on this — it sharpened the positioning.

hrischuk-dacontributorinline comment on rfps/developer-experience-tooling-education/canton-event-stream.md:1716-06-2026 · 4mo agoGitHub ↗

I have reviewed the proposal. I think the approach has merit but I find this proposal is lacking and needs more updates. I could see this as being useful for scaling up the LAPI event stream to more clients but there are remaining questions.

The larger gaps to close are:

It does not support multi-hosted parties and party based HA (future) whereby it can switch to a different validator LAPI if the one it is connected to fails. Multi-hosted support should be the default.
The ordering mechanism is not sufficient. It would need to use RecordTime as its ordering metric. This would also allow a subscriber to say from when it wants to receive events.
It is not clear what the fan-in-fan-out scaling benefit is because each user/part would make a subscription for itself using its own JWT authorized to its own party. Naively, this looks to me like a 1-1 passthrough authorization which will not benefit scalability but I may be missing something.
There is a very narrow focus on what it subscribes to and there is no explanation for this. The list is too narrow for a general purpose solution and it should be able to be added to which brings me to ...
Creating a CIP to standardize the ledger event to subscribe event would be appropriate.
Needs to support 'unassign' and 'reassign' events for multi-synchronizer apps.

Happy to discuss more.

anand-qasarainline comment on rfps/developer-experience-tooling-education/canton-event-stream.md:1716-06-2026 · 4mo agoGitHub ↗

Thanks — sharp review, and it genuinely improves the design. We agree with most of it, want to restructure into two phases, and would value a quick call to align before we revise.

RecordTime ordering + "from when" resume (2): agreed — we'll make RecordTime the ordering/resume key, with an offset-checkpoint index to translate a requested time into a resume point.
Configurable subscriptions (4): agreed — the token-interface default reflects the code's origin, not a design limit; we'll make the subscribed interfaces/templates configurable with pluggable classification.
Unassign/assign events (6): agreed — we'll classify reassignment so multi-synchronizer apps don't misread a contract moving synchronizers as archive+create.
CIP (5): strong yes — we'll author a CIP for the event-selection and classified-event model, with this service as the reference implementation; we'd welcome your steer on the right SIG and path.
Multi-hosted + party HA (1): agreed on posture — RecordTime is the enabler (participant-independent key, failover, dedup). It can only be exercised on a multi-participant network, so we'd scope it (with reassignment) as a second phase on a multi-synchronizer/multi-participant testbed.
On fan-in/fan-out (3) — fair challenge. You're right that a per-user party self-subscribing with its own JWT is 1-1, with no subscription-dedup benefit. The benefit is in the operator-hosted model: one credential authorized for many parties opens one (or a few) multi-party subscriptions, fanned out to that operator's many downstream consumers — so downstream client connections decouple from upstream node subscriptions, and the participant is shielded from per-client connections each holding a ledger token. In the per-user-owned-party model the value is connection multiplexing, classification, and resumable ordering — not subscription dedup. We'll state that deployment model explicitly.

Net: Phase 1 (demonstrable now) — RecordTime resume, configurable subscriptions, classification, per-party authorization, CIP draft. Phase 2 (needs a multi-participant/multi-synchronizer testbed) — multi-hosted failover and reassignment. Could we grab 30 minutes to align on the CIP path and the phase boundary before we push the revision?

Thanks again.

Denendcontributorcommented01-07-2026 · 3mo agoGitHub ↗

The M1 acceptance criterion requires demonstrating that a client requesting an unauthorized party is rejected at subscribe time. How does the Event Stream Server validate downstream client credentials - who issues stream tokens, what party claims do they encode, and how does the server verify a client's party entitlement at subscribe time?

anand-qasaracommented01-07-2026 · 3mo agoGitHub ↗

The M1 acceptance criterion requires demonstrating that a client requesting an unauthorized party is rejected at subscribe time. How does the Event Stream Server validate downstream client credentials - who issues stream tokens, what party claims do they encode, and how does the server verify a client's party entitlement at subscribe time?

@Denend

Good question — this is the exact mechanism Milestone 1 builds. Here's how it works.

Who issues the stream tokens. Whoever already knows which user maps to which Canton party — the operator running the service (e.g. an exchange that knows "this logged-in user = party alice"). The Event Stream Server doesn't decide who owns which party; it only trusts tokens signed by an issuer it's configured to accept (via a shared key or a JWKS URL). This is the same trust model the participant already uses — it trusts the actAs claims in an IdP-signed JWT — just applied one hop further out, at the streaming edge.

Two deployment shapes: (a) the service issues the token itself after authenticating the client and looking up its parties from an operator-supplied mapping, or (b) the operator's existing identity system issues the token and the service just verifies it. Making that verify step pluggable — so any operator can use their own identity system — is the net-new open-source work. (In our commercial gateway today it's shape (a), tied to our API-key system.)

What's in the token. An explicit list of the party IDs the holder is allowed to stream, plus standard iss/aud/exp and a single-use id. The allowed parties are written into the signed token by the issuer — the server never guesses them. Tokens are short-lived (~60s) and single-use.

How the server checks, at subscribe time. When a client connects and asks to stream a set of parties, the server before opening any channel:

Verifies the token (signature, audience, not expired, not already used).
Reads the allowed-party list from the token.
Checks every requested party is on that list. If any isn't, the subscribe is rejected and no channel opens.

So the per-party boundary the node enforces on a direct subscription is re-created at the edge: the token's party list bounds what a client can stream. That's exactly what the M1 acceptance test shows — ask for a party your token doesn't include, and you're rejected.

Optionally (configurable), the service can also double-check with the participant that the token's issuer really holds read rights for that party — so even a mis-issued token can't grant more than the node itself would allow. I can add this as an "Authorization model" subsection in the proposal so it's written down explicitly.

Denendcontributorcommented15-07-2026 · 3mo agoGitHub ↗

@anand-qasara thanks, that covers it

Erlannn7commented16-07-2026 · 3mo agoGitHub ↗

This is a practical addition to the Canton ecosystem. Having an open-source event streaming layer for WebSocket and SSE could make it much easier to build responsive dApps and real-time user experiences. I also appreciate the clear positioning as a complement to PQS rather than a replacement.

Noosphere-314commented20-07-2026 · 3mo agoGitHub ↗

We're Woof (woof-software) - currently prepping two Dev Fund proposals (write-up): an EVM-side compliance SDK for Zenith and open-source risk primitives. Flagging interest because both would otherwise have to build this exact layer ourselves - our TS middleware needs live per-party compliance and settlement events for frontends, and our risk dashboard rebuilds state from classified events. If this lands we'd look at consuming it instead of rolling our own.

And we're not the only ones rolling our own, which is really the argument for funding it once. Hacken (#302) promises alerts "within 60 seconds of a triggering event," Zpoken (#138) is bolting pg_notify + GraphQL subscriptions onto their indexer for "within 2s" push, and #51 (Participant Event Gateway) solves the same participant-local, party-scoped delivery problem over webhooks. The 2026 DevEx survey lists real-time streaming as a gap people patch individually. Worth linking #51 from here - same problem, different transport, so it reads as demand rather than overlap.

On the native-vs-this question from earlier: we went through the JSON Ledger API v2 AsyncAPI spec and gRPC UpdateService ourselves, and the delta holds. Native gives you per-party-filtered streams with offset resume and stakeholder auth, but every client connects with the participant's own JWT and minds its own offsets - and the docs themselves say to keep long-lived streams to a minimum (WS caps around 2h). Once you fan one upstream subscription out to many clients, so they aren't each holding a ledger token, the participant's per-party check leaves the path, and a plain WS broker has no notion of a Canton party to put it back. Re-doing party auth at the edge, classifying raw Created/Exercised into transfer.executed, and offering SSE at all (native is WS/gRPC only) is a genuine layer. Push-here vs pull-from-PQS is the right split.

Three things we'd want pinned down before building on it, coming at it as a compliance/settlement consumer:

Version the taxonomy against the token-standard interfaces. The default profile maps HoldingV1 / TransferInstructionV1, and the event JSON has no schema-version field - only the package is semver'd. splice is shipping v1 and v2 interfaces in parallel right now (there's a weekly-reset V2 DevNet), so anything wired to today's shapes breaks quietly when instruments move to v2. A schemaVersion on the event, plus a stated policy for mapping across interface versions, saves every consumer from patching that later.
Say what the delivery guarantee is, and what happens at the resume edge. You've got RecordTime ordering and resume-within-a-window, but not the guarantee class (at-least-once? exactly-once?), how a client dedupes across a reconnect, or what a resume request older than the window returns. For deposit detection and compliance state that's not academic - a silent gap is a missed deposit, a dup is a double count. Simplest fix: declare at-least-once, give consumers a stable idempotency key (eventId?), and make an out-of-window resume a hard error so they fall back to PQS instead of assuming continuity.
Spell out how the token rides on the wire, especially for SSE. The short-lived single-use party token is a good design, but browser EventSource can't set headers, which tends to push the SSE token onto the query string - where it lands in proxy and access logs. Worth documenting the transport, and for SSE using something that keeps it out of the URL (short-lived cookie, or a POST to establish the stream).

Overall - real gap, the positioning against native/PQS checks out, and the thread's already sharpened it a lot. The above is hardening, not objection. Glad to dig into the compliance-event side of the taxonomy later if it's useful.

anand-qasaracommented21-07-2026 · 3mo agoGitHub ↗

@Noosphere-314 Thank you for the great feedback. It's a real demand signal and a proper hardening pass in one, and all three points are going straight into the design

Versioning the taxonomy — agreed. There's no schema-version field today and there should be. I'll put a schemaVersion on the event plus a clear policy for mapping across interface versions. V2: CIP-0112 adds a first-class EventLog_HoldingsChange event, so the right move is to version the taxonomy against the interface — infer-from-choice on V1, read-the-EventLog on V2 — and let schemaVersion tell the consumer which they've got. Then an instrument moving to v2 flips a field instead of silently breaking you.

Delivery guarantee — agreed, and you're right this can't stay implicit; for deposit/compliance state a silent gap is a missed deposit and a dup is a double count. So: at-least-once, a stable idempotency key, and an out-of-window resume that fails hard so you fall back to PQS instead of assuming continuity. Today's eventId has a random UUID in it, so it isn't stable across a re-ingest; it needs to be deterministic (updateId + event position). That would've bitten everyone.

Token on the wire — yep, the SSE-token-in-the-query-string thing is a genuine footgun (EventSource can't set headers, so it ends up in proxy logs). We'll document transport properly: WS in the Sec-WebSocket-Protocol subprotocol like the native API, and SSE via a short-lived cookie or a POST to open the stream — out of the URL either way.

Thanks again

anand-qasaracommented21-07-2026 · 3mo agoGitHub ↗

@Freakzyyy45 Thanks, really appreciate it.

Jatinp26membercommented23-07-2026 · 3mo agoGitHub ↗

@anand-qasara it states that Qasara operates a hosted version as part of their commercial Canton Gateway. The OSS version excludes API key management, rate limiting, and billing remain commercial. As dev fund is to fund public good opensource products, I am not sure how that fits in with Qasara and how much of this money is dedicated to your commercial offering and what would OSS would offer if it doesn't have API Key management, need more transparency in it.

anand-qasaracommented23-07-2026 · 2mo agoGitHub ↗

@Jatinp26

Thanks Jatin, this is the right thing to push on.

To be clear on the money: the whole grant goes into the public MIT repo. None of it funds the hosted service — we just run the same open-source package ourselves. There's no private fork of the actual streaming engine.

On what you get without our API-key system: it's a full self-hostable service, not a stripped one. The ingester, the event classification, the per-party privacy enforcement at the edge (which is the part that's easy to get wrong, and is squarely OSS), fanout, WebSocket/SSE, reconnect, Helm charts — all public. It authenticates connections too; it validates a client's JWT/token, and it's decoupled from our own auth and DB so you plug in your own IdP. What's not in it is the SaaS billing layer — issuing and metering keys for paying customers. That's the Grafana OSS vs Grafana Cloud line, and it's where our commercial side actually sits.

On rate limiting — you're right, that's a wording error. Basic connection/backpressure limits belong in the OSS and I'll move them there explicitly; only per-plan tiered limits are commercial.

We run this in production ourselves, which is what keeps it maintained past the grant. And the incentive runs the same way: the more teams building live Canton apps, the bigger the market for our hosted API — keeping the engine closed would work against us.

I'll push a corrected version with an explicit OSS-vs-hosted table so none of this is left to interpretation.

hrischuk-dacontributorinline comment on proposals/canton-event-stream.md:1923-07-2026 · 2mo agoGitHub ↗

Can we change this to Apache 2?

hrischuk-dacontributorinline comment on proposals/canton-event-stream.md:1923-07-2026 · 2mo agoGitHub ↗

Can you add that your commercial offering is an infrastructure offering that will run the same OSS code as is developed here?

hrischuk-dacontributorinline comment on proposals/canton-event-stream.md:2923-07-2026 · 2mo agoGitHub ↗

This is a pretty strong claim. Are you willing to bet all of the funding on that claim? If not, I suggest weakening it to what can be achieved.

hrischuk-dacontributorinline comment on rfps/developer-experience-tooling-education/canton-event-stream.md:6423-07-2026 · 2mo agoGitHub ↗

You will also need to deal with deduplicating the same event from multiple participants because of multi-hosting of parties.

hrischuk-dacontributorinline comment on rfps/developer-experience-tooling-education/canton-event-stream.md:7923-07-2026 · 2mo agoGitHub ↗

doesn't htis figure needs to show one or two clients that adjust their subscriptions?

hrischuk-dacontributorinline comment on proposals/canton-event-stream.md:7823-07-2026 · 2mo agoGitHub ↗

Probably need to include Token Standard v2 since it is running live in DevNet.

hrischuk-dacontributorinline comment on proposals/canton-event-stream.md:8923-07-2026 · 2mo agoGitHub ↗

Isn't this missing important information from the token standard v1 and v2? Is that buried somewhere in these fields?

hrischuk-dacontributorinline comment on proposals/canton-event-stream.md:12123-07-2026 · 2mo agoGitHub ↗

Please explain what a 'default profile' looks like and what is in it.

hrischuk-dacontributorinline comment on rfps/developer-experience-tooling-education/canton-event-stream.md:25923-07-2026 · 2mo agoGitHub ↗

Can you provide a block diagram that explains what this solution will look like for an end-to-end solution?

hrischuk-dacontributorinline comment on rfps/developer-experience-tooling-education/canton-event-stream.md:30223-07-2026 · 2mo agoGitHub ↗

Please explain the mechanism for "Per-subscriber party authorization"?

hrischuk-dacontributorinline comment on proposals/canton-event-stream.md:20623-07-2026 · 2mo agoGitHub ↗

This doesn't sufficiently demonstrate value to the community. I would think that this solution needs to be adopted by at least 3 external community members and deployed to MainNet. This will increase your delivery time but it will demonstrate value.

hrischuk-dacontributorinline comment on proposals/canton-event-stream.md:22223-07-2026 · 2mo agoGitHub ↗

The last milestone needs to be at least 50% of the funding because it is when the ecosystem value can be best demonstrated.

anand-qasarainline comment on rfps/developer-experience-tooling-education/canton-event-stream.md:7924-07-2026 · 2mo agoGitHub ↗

Updated the figure to show the subscribe/unsubscribe back-channel: a WebSocket client picks its parties and can change that set live (subscribe [alice], later add [bob], drop [alice]). SSE clients set their parties at connect, since SSE is one-way. Per-party authorization runs on each subscribe.

anand-qasarainline comment on rfps/developer-experience-tooling-education/canton-event-stream.md:6424-07-2026 · 2mo agoGitHub ↗

Yes: with a party on multiple participants, each participant emits the same update, so Phase 2 dedups on the participant-independent identity. The same update carries the same updateId and RecordTime on every participant, so the ingester keeps a seen-set of updateIds within the RecordTime window and drops repeats. Updated in the phasing section

anand-qasarainline comment on proposals/canton-event-stream.md:1924-07-2026 · 2mo agoGitHub ↗

Added in the document. Qasara's commercial offering is a hosted infrastructure service that runs this same open-source code: the grant funds the OSS package, and the hosted product consumes it as-is rather than maintaining a private fork,

anand-qasarainline comment on proposals/canton-event-stream.md:7824-07-2026 · 2mo agoGitHub ↗

Added Token Standard V2 (CIP-0112) to the default profile alongside V1. V2 is especially relevant here because it ships a dedicated transfer-events surface (holdings-change events), so the ingester can read transfer events directly rather than inferring them from exercised choices.

anand-qasarainline comment on proposals/canton-event-stream.md:8924-07-2026 · 2mo agoGitHub ↗

You are right, and it was not buried anywhere, it was missing. I added a payload block that carries the Token Standard semantic fields a consumer needs: instrument, amount, sender, receiver, holding. It is populated from CIP-0056 (V1) holdings/transfer-instruction data or CIP-0112 (V2) holdings-change events, so a dApp reads "Alice sent Bob 100 Amulet" directly rather than decoding the contract. The data block keeps the raw ledger metadata for anyone who needs to go deeper, and non-token event types carry their own typed payload under the same envelope.

anand-qasarainline comment on proposals/canton-event-stream.md:12124-07-2026 · 2mo agoGitHub ↗

A profile is the configurable unit, and it has three parts: the subscribe set (interfaces/templates to pull), the classification mapping (raw event to named type), and the payload mapping (token fields to event.payload). I added a concrete default profile showing all three, covering CIP-0056 V1 (Holding, TransferInstruction) and CIP-0112 V2 (holdings-change transfer-events). Operators can extend it or ship additional profiles for non-token domains; the token-standard profile is default.

anand-qasarainline comment on rfps/developer-experience-tooling-education/canton-event-stream.md:25924-07-2026 · 2mo agoGitHub ↗

Added an end-to-end block diagram. It shows the full path: Canton participant node, then the Ledger Ingester (one upstream subscription, classify to named events, RecordTime ordering, Phase 2 multi-host dedup), then Redis (per-party channels and a short replay buffer), then the Event Stream Server (token auth, per-party authorization, WS and SSE, RecordTime resume), then application clients, which never touch the node and pick their parties over the connection. The operator profile config feeds the ingester, and the whole service is one Docker image with Redis as its only dependency.

anand-qasarainline comment on proposals/canton-event-stream.md:2924-07-2026 · 2mo agoGitHub ↗

I would not bet the funding on an ecosystem-adoption claim. I have reworded it to what the grant actually delivers: a team can get classified, party-authorized events by running one container, instead of building that plumbing themselves. Whether it becomes the default across the ecosystem is adoption, which I moved out of the outcome statement.

anand-qasarainline comment on rfps/developer-experience-tooling-education/canton-event-stream.md:30224-07-2026 · 2mo agoGitHub ↗

Added Authorization model section in the document -the server re-creates the node's per-party visibility boundary at the streaming edge using short-lived, party-scoped tokens: Who issues tokens. The operator running the service, or their existing identity system: whoever already knows which user maps to which Canton party (for example, an exchange that knows "this logged-in user = party alice"). The server does not decide party ownership; it only accepts tokens signed by an issuer it is configured to trust (a shared key or a JWKS URL). This is the same trust model the participant already uses for actAs claims in an IdP-signed JWT, applied one hop further out. Two deployment shapes. (a) the service authenticates the client, looks up its parties from an operator-supplied mapping, and issues the token itself; or (b) the operator's identity system issues the token and the service only verifies it. Making that verify step pluggable, so any operator can use their own identity system, is the net-new open-source work. (Qasara's commercial gateway uses shape (a) today, tied to its API-key system.) Token contents. An explicit list of the party IDs the holder may stream, plus standard iss/aud/exp and a single-use id. The allowed-party list is written into the signed token by the issuer; the server never infers it. Tokens are short-lived (around 60 seconds) and single-use. Subscribe-time check. Before opening any channel, the server (1) verifies the token (signature, audience, not expired, not already used), (2) reads the allowed-party list, and (3) confirms every requested party is on that list. If any requested party is not, the subscribe is rejected and no channel opens. This is exactly what the Milestone 1 acceptance test demonstrates: request a party the token does not include, and the subscribe is rejected. Optional node-side check. Configurably, the service can also confirm with the participant that the token's issuer actually holds read rights for the party, so even a mis-issued token cannot grant more than the node itself would allow.

anand-qasarainline comment on proposals/canton-event-stream.md:20624-07-2026 · 2mo agoGitHub ↗

I have made external MainNet adoption the primary Milestone 3 gate: at least 3 independent community members deploying the service alongside their own validator on MainNet, evidenced by their live deployment. Qasara's own gateway and validator now serve only as the reference integration and deployment, not as the value proof. This does extend the timeline as you expected: the build stays about 12 weeks, and the adoption window runs up to 6 months.

anand-qasarainline comment on proposals/canton-event-stream.md:22224-07-2026 · 2mo agoGitHub ↗

Done. Milestone 3 is now 50% of the grant (150,000 of 300,000), released as a single payment when the full M3 criteria are met, including the external MainNet adoption above.

sunstrike228commented26-07-2026 · 2mo agoGitHub ↗

Read it end to end. The fanout argument is what convinced me. The moment you put a tier in front of the participant, the node's per-party visibility drops out of the downstream path, and generic pub/sub can't restore it because it has no idea what a Canton party is. Better solved once than separately by five teams.

You also state where the fan-in benefit doesn't apply instead of skipping past it, which made the rest of the numbers easier to trust.

Complementary to us on the mobile side. A phone can't hold a ledger token or keep a participant connection open, so a party-scoped edge that classifies events is what a mobile client needs. We would use this.

Two things I'd want pinned down as a consumer. Tokens are around 60 seconds and single use, but a WebSocket stays open for hours, so what happens on the live channel when a token expires or an entitlement is revoked? And RecordTime isn't unique per event, so "everything since T" needs a tiebreaker plus an inclusive or exclusive rule, or people get duplicates or a gap across reconnects.

anand-qasaracommented27-07-2026 · 2mo agoGitHub ↗

@sunstrike228 Thanks, and you're right: a phone can't hold a ledger token or keep a live connection open, so it needs something in front that does that and only ever shows each user their own events. That's exactly what CES will handle.

On your two points:

The 60s token authorizes the handshake, not the whole session. The approach we'll pin down: give the session a bounded life with silent in-band re-auth, so a normal expiry stays invisible to the user, and handle revocation actively, so when a key or entitlement is revoked the edge closes the matching streams within seconds with a distinct close code, rather than letting a revoked client ride an open socket.

You're right that RecordTime isn't unique on its own, so we won't key resume on it alone. The plan is a composite cursor, (synchronizerId, recordTime, updateId, nodeIndex), ordered per synchronizer, resumed exclusive of the last event you processed: recordTime picks the instant, updateId the transaction in it, nodeIndex the event in the transaction. That removes the tie, so no duplicates and no gap across reconnects. We're moving to RecordTime as the key on purpose, since it's participant-independent, so a client that fails over to another host still resumes at the right spot.

mziolekdacontributorinline comment on proposals/canton-event-stream.md:12927-07-2026 · 2mo agoGitHub ↗

This can be hard to implement in the IAM systems. The mapping from user to parties is often only stored in the participant's user database and the token issuer does not have that information.

anand-qasaracommented27-07-2026 · 2mo agoGitHub ↗

@mziolekda

You're right, most IAMs only know people, not Canton party IDs. Making the token carry them means every operator has to sync that mapping in and keep it there. So the token just says who the user is and we look up the parties. When each user has their own ledger user we read their grants straight from the participant, so there's nothing to sync. That doesn't cover an operator running one service account across many customer parties, where the participant can't tell those users apart. So we'll make party lookup pluggable: the participant's user rights, an operator-supplied mapping, or a list in the token for issuers that already have it.

mjuchli-dacommented28-07-2026 · 2mo agoGitHub ↗

I think this proposal addresses a gap in the Canton ecosystem, and I can see the need for an event stream service that is optimized for end-user applications (dApps). To me, the primary consumers of such a service are dApp developers, and as such I review it from a dApp architecture point of view.

Some things I particularly like:

Keeping this as a separate Node.js component rather than embedding it into Canton (although I would consider merging once this is mature)
Reusing/relying on the Ledger API authorization model (but I let @mziolekda and others point out the particular concerns)
Building it using the Wallet SDK, which keeps the developer experience aligned with the rest of the ecosystem and demonstrates the intended approach for ecosystem builders.

One aspect I think is currently missing, however, is how this integrates with the dApp architecture. This is probably the most important architectural question from my perspective.

The dApp API is only aware of the Ledger API endpoint. At the same time, exposing the Ledger API is optional; some wallet providers intentionally keep it private and instead require dApps to proxy ledgerApi requests via the dApp API. I suspect the same considerations will apply to a Canton Event Stream service.

That raises a few questions:

How does a dApp discover the Canton Event Stream endpoint (host/port) of the connected validator?
Does this require an amendment to CIP-103 so that wallet providers can advertise the availability and location of a Canton Event Stream service (host/port)?
Alternatively, should wallet providers be responsible for optionally proxying the event stream through the dApp API (e.g. dAppApi.on('CES:transfer.pending')) so that dApps never need to know where the underlying service is hosted?

If the latter approach is preferred, I think it would also be important to consider the different wallet deployment models (browser extension, desktop, remote wallet, etc.), as they each have different networking assumptions and trust boundaries.

Overall, I like the direction of the proposal. I think clarifying how a dApp discovers and consumes the event stream within the existing wallet architecture would make it much easier to see how this fits into the broader ecosystem.

hrischuk-dacontributorcommented28-07-2026 · 2mo agoGitHub ↗

Our engineering team has provided the following feedback which requires a response, as well as Marc's excellent review above.

Why is it simpler to re-implement authorization at the edge using JWTs instead of permissioning users on the LAPI?
For supporting sub-party fan-out, they'd need to re-implement the privacy projection logic for stream events that we already have in the LAPI. There is significant complexity with re-implementing home-grown party projections. Can you provide details about this in the proposal?
What is the backwards compatibility guarantee / compatibility model?

mziolekdacontributorinline comment on proposals/canton-event-stream.md:12028-07-2026 · 2mo agoGitHub ↗

Which stream types do you intend to distribute: ledger effects or ACS-delta? Please note that the event set returned to the requester is different in these two cases. Ledger-effects stream is richer and contains all events present in ACS-delta plus more. However, reconstructing ACS-delta cannot be done as a stateless pass-through stage on the ledger-effects stream.

anand-qasaracommented28-07-2026 · 2mo agoGitHub ↗

Our engineering team has provided the following feedback which requires a response, as well as Marc's excellent review above.

Why is it simpler to re-implement authorization at the edge using JWTs instead of permissioning users on the LAPI?

For supporting sub-party fan-out, they'd need to re-implement the privacy projection logic for stream events that we already have in the LAPI. There is significant complexity with re-implementing home-grown party projections. Can you provide details about this in the proposal?

What is the backwards compatibility guarantee / compatibility model?

@hrischuk-da

Thanks, and we'll provide detail in the proposal.

On authorization: this isn't a replacement for LAPI permissioning, it's the same permissioning enforced one hop out. The default resolver reads the user's CanReadAs and CanActAs grants from the participant's own user management, so the party set is the node's answer rather than ours. The edge check exists because any fanout tier removes the node's enforcement from the downstream path, so whatever sits there has to re-check. The alternative is every end-user session holding its own LAPI connection and a token with real ledger authority, which is what the tier is there to avoid. We also see operators running a single shared service account rather than a ledger user per person, and there the LAPI has no per-user grants at all, so the operator's own mapping is the only source; we support both.

On projection: we don't re-implement it, we consume it. The ingester subscribes with a multi-party filter, the participant computes visibility per event, and that arrives as witnessParties on every event we handle, Created, Exercised and Archived alike. Routing is a set intersection of the event's witnessParties with the subscriber's authorized parties. No stakeholder or divulgence logic is recomputed anywhere. We also don't project below party granularity: users mapped onto one shared party all see that party's stream, because the party is Canton's unit of privacy and we keep it that way.

On compatibility, three surfaces. The client-facing event schema is versioned and additive within a major, with the AsyncAPI spec as the contract and the Phase-1 CIP draft as the change process. Upstream we consume JSON Ledger API v2 and publish a tested compatibility matrix, Canton 3.5+ and Splice 0.5.x/0.6.x, with a 12-month maintenance commitment. Subscriptions and classification key on package-name aliases and interface IDs rather than pinned package IDs, so token-standard upgrades don't break classification, and resume cursors are participant-independent so they survive restarts and failover

anand-qasaracommented28-07-2026 · 2mo agoGitHub ↗

Thanks @mjuchli-da , fair point, and we'll add a dApp-integration section covering it.

Providers keep the Ledger API private because it's the raw node. CES is meant to be the part you can expose: narrow, classified, authorized per party. So a provider who wants the node private gets that by running CES and exposing it, rather than hiding both. Same for hosted wallets, where one exposed CES serves all their users' sessions instead of the wallet backend building its own fanout.

Discovery is one optional field. The wallet already gives the dApp an endpoint and token through getActiveNetwork, so a provider running CES just adds the event-stream URL. No field means no CES. It's additive, so by CIP-0103's own versioning rule no amendment is needed.

The dApp needs no new credentials. It connects with the token it already has for ledger reads, and we check it against the same issuer the participant trusts. If the token names parties, we use those. If it names a ledger user, we look up that user's rights on the participant. Either way it's your authorization model reused, not a new one.

Direct connection is the default, for the reason CIP-0103 already avoids proxying reads. Your CES:transfer.pending shape stays available for fully closed setups, and since the event schema is standard, both paths deliver identical events, so dApps write one handler. For extensions, the page holds the WebSocket, not the background worker, so suspension isn't an issue.

anand-qasarainline comment on proposals/canton-event-stream.md:12028-07-2026 · 2mo agoGitHub ↗

@mziolekda

We consume ledger-effects upstream, and both versions of the token standard need it. In V1 the transfer outcomes are consuming choices on the same TransferInstruction, so under ACS-delta you'd be inferring the outcome from the create/archive pattern instead of reading the choice name. In V2, EventLog_HoldingsChange is nonconsuming, so it produces neither a create nor an archive and doesn't appear in ACS-delta at all. Downstream we distribute neither shape. Subscribers get classified events like transfer.accepted, so converting between shapes never comes up. You're right that ACS-delta isn't a stateless transform, and we're not attempting it. Consumers needing a per-party ACS view should use PQS or their own Ledger API subscription.

shaul-dacommented02-09-2026 · 1mo agoGitHub ↗

@hrischuk-da @mziolekda we discussed this one in the voting meeting and need your input if your comments are resolved to your satisfaction and whether this is a priority. In the meantime, we're moving it to "Needs Revision" until further notice.

hrischuk-dacontributorinline comment on rfps/developer-experience-tooling-education/canton-event-stream.md:1702-09-2026 · 1mo agoGitHub ↗