Proposal: PartyLayer — Open-Source Wallet Abstraction Layer for Canton

Review Feedback — PartyLayer (Application-Layer Interoperability Infrastructure)

Thank you for the submission and for contributing a proposal focused on standardizing wallet integration and application-layer interoperability on Canton.

This is a strong proposal with clear traction and ecosystem alignment. The fact that the SDK is already live, CIP-0103 compliant, and integrated with multiple wallets is a significant strength.

That said, a few areas would benefit from clarification:

1. Positioning vs existing and parallel efforts

Given multiple proposals in the ecosystem targeting wallet integration and SDK layers, it would help to clarify:

• how PartyLayer differentiates from or complements other SDK efforts
• whether there is alignment to avoid fragmentation

2. Evidence of sustained adoption

Early traction is strong, but it would help to clarify:

• which teams are actively using PartyLayer in production or development
• whether there are committed integrations beyond initial adoption

3. Scope vs. ecosystem standardization

The proposal positions PartyLayer as a shared layer. It would help to clarify:

• whether this is intended to become a de facto standard
• how neutrality and long-term governance will be maintained

4. Observability and additional layers

The proposal includes observability, error taxonomy, and traffic utilities.

It would help to:

• clarify which components are essential for ecosystem value
• ensure core wallet interoperability remains the primary focus

5. Long-term maintenance

Given its role as a potential shared layer, it would help to clarify:

• how ongoing maintenance and compatibility with evolving CIPs will be handled

Overall, this is a high-quality and well-advanced proposal with strong ecosystem relevance. Clarifying positioning, alignment, and long-term ownership would strengthen confidence in its role as shared infrastructure.

I see PartyLayer as a useful addition at the CIP-0103 and WalletConnect connection layer. As wallet connectivity becomes more important for app distribution and user access, giving developers a practical way to support multiple connection paths is valuable, and the documentation here already gives this proposal a credible foundation as dApp-to-wallet tooling.

To be transparent, we have not yet had the capacity to test an integration from our own wallet side, so I cannot comment on implementation quality from direct experience. But I want to encourage the already integrated wallet teams such as Console Wallet, 5N Loop, Cantor8, Nightly, and Bron to share their experience publicly, as that would help validate the proposal further.

Compared to approved proposal best practices, I think three concrete things are still missing:

1. Add a clearer effort and cost rationale per milestone

• Right now all three milestones are structured as 3 weeks / 100,000 CC, but the proposal does not explain whether that reflects similar implementation effort, similar staffing, or a value-based funding split.
• In approved proposals, this is usually made explicit so reviewers can understand why the milestone split is shaped the way it is. Here that rationale is missing.

2. Make the acceptance criteria milestone-specific

• The proposal currently has one generic acceptance section for the whole grant.
• Approved proposals usually make this easier to review by putting deliverables, value metrics, and acceptance criteria directly under each milestone, so external reviewers know exactly what should be verifiable at Milestone 1, 2, and 3.
• That would improve reviewability here.

3. Add a concrete maintenance path after the funded work ends

• The proposal explains the maintenance philosophy, but it does not yet give the same level of operational specificity that approved proposals usually include after delivery, such as where maintenance will live, how it will be funded or handled, and what ongoing burden is expected.
• For shared ecosystem infrastructure, that post-grant maintenance path should be stated much more explicitly.

I would encourage the PartyLayer team to adapt the proposal along these lines, as I think those additions would strengthen an already mature submission. With that understood, I would still be comfortable moving the proposal forward to the voting round.

Thanks @LucasnFCS for the thorough review and the very concrete structure suggestions here, they were genuinely helpful in improving the proposal.

We’ve now pushed an update addressing all three points raised in the review.

For the per-milestone effort rationale, each milestone now includes a dedicated breakdown of how the 3-week timeline and 100,000 CC allocation distribute across implementation, testing, documentation, and integration validation. The equal CC structure reflects comparable engineering depth across milestones, with M1 focused on developer tooling, M2 on framework expansion and CIP-0104 observability utilities, and M3 on production hardening and MainNet readiness.

For acceptance criteria, the previous generic section has been replaced with milestone-specific and publicly verifiable criteria under each milestone. These now include concrete validation points such as npm publication, conformance runner validation, public deployments, integration tests, and reproducible build instructions.

For post-grant maintenance, we added a dedicated sustainability section covering long-term maintenance ownership, funding model, expected operational burden, repository health commitments, and continuity planning to ensure PartyLayer remains maintainable as shared ecosystem infrastructure.

On the wallet feedback side, we’d also genuinely welcome public input from Console, 5N Loop, Cantor8, Nightly, Bron, or other ecosystem wallet teams as suggested. Additional ecosystem-level validation would be very valuable for the proposal.

Thanks again to you and the reviewers for the thoughtful engagement throughout the process.

Appreciate your open communications and changes to your proposal @cayvox. I checked the updated proposal against my earlier feedback, and from my perspective the three requested points have now been addressed in a substantive way: the milestone funding split now has an explicit rationale, acceptance criteria are milestone-specific and externally verifiable, and the proposal now includes a concrete post-grant maintenance section with ownership, horizon, funding model, and expected ongoing burden. At this point, I would consider my earlier structural concerns resolved.

The remaining question around overlap with other ecosystem efforts feels more like a committee prioritization question than a proposal-quality issue.

Latest ecosystem update from the PartyLayer side:

We recently completed and deployed Send Wallet support on partylayer.xyz. The integration process was carried out in direct coordination with the Send team, and we are continuing end-to-end testing and refinement processes around wallet interoperability flows.

Our focus continues to be building an open and interoperable wallet coordination layer aligned with CIP-0103 and the broader Canton wallet ecosystem.

The proposal addresses real ecosystem needs, and the product looks good, also code-wise. However, much of the proposed functionality overlaps with the dApp SDK grant proposal, particularly around wallet discovery, abstraction, and CIP-103 compliance tooling. The main difference is the broader framework support (React Native, Vue.js), which could be beneficial to mobile wallet providers. At the same time, the proposal introduces an adapter-centric approach that risks encouraging wallet-specific integrations over the adoption of the CIP-103 standard. As a result, I would not recommend the proposal in its current form. A more focused proposal centered on framework expansion or mobile integrations, ideally by extending the existing dApp SDK, or other complementary areas not already covered by the dApp SDK roadmap could provide clearer ecosystem value.

The proposal addresses real ecosystem needs, and the product looks good, also code-wise. However, much of the proposed functionality overlaps with the dApp SDK grant proposal, particularly around wallet discovery, abstraction, and CIP-103 compliance tooling. The main difference is the broader framework support (React Native, Vue.js), which could be beneficial to mobile wallet providers. At the same time, the proposal introduces an adapter-centric approach that risks encouraging wallet-specific integrations over the adoption of the CIP-103 standard. As a result, I would not recommend the proposal in its current form. A more focused proposal centered on framework expansion or mobile integrations, ideally by extending the existing dApp SDK, or other complementary areas not already covered by the dApp SDK roadmap could provide clearer ecosystem value.

Thanks Marc, really appreciate the thoughtful feedback and review.

We fully agree that CIP-0103 should remain the canonical standard for wallet connectivity on Canton. PartyLayer is not intended to replace or compete with CIP-0103 or the dApp SDK, but rather to provide application layer developer tooling on top of them.

Our focus is improving developer experience around multi wallet flows, framework integrations (React/Vue/React Native), session management, wallet coordination tooling, and composable wallet UI primitives. These are areas that complement the transport layer responsibilities of CIP-0103 and the dApp SDK rather than duplicating them.

We see PartyLayer much closer to a wagmi/RainbowKit style application framework built on top of the Canton dApp SDK than an alternative transport or protocol implementation.

Recent work with wallets like Console and Send has been centered around native CIP-0103 alignment and standard based integrations. As more wallets adopt CIP-0103 natively, PartyLayer increasingly operates through fully native wallet connectivity flows across the ecosystem.

We also intentionally prioritize and surface native CIP-0103 wallets within PartyLayer while encouraging wallet teams across the ecosystem to move toward native support over time.

We definitely understand the concern around fragmentation. Long term, our goal is for PartyLayer to operate around fully native CIP-0103 wallet connectivity across the ecosystem, helping application teams support multiple wallets through a unified developer experience built around the standard itself.

We believe PartyLayer’s strongest differentiation lies around framework native developer experience, mobile integrations, multi wallet coordination, and composable wallet tooling. These are areas where we believe PartyLayer provides complementary ecosystem value alongside the existing dApp SDK roadmap while helping application teams build richer wallet experiences on Canton.

Appreciate the feedback again. This perspective is genuinely very helpful for refining the proposal direction further.

The proposal addresses real ecosystem needs, and the product looks good, also code-wise. However, much of the proposed functionality overlaps with the dApp SDK grant proposal, particularly around wallet discovery, abstraction, and CIP-103 compliance tooling. The main difference is the broader framework support (React Native, Vue.js), which could be beneficial to mobile wallet providers. At the same time, the proposal introduces an adapter-centric approach that risks encouraging wallet-specific integrations over the adoption of the CIP-103 standard. As a result, I would not recommend the proposal in its current form. A more focused proposal centered on framework expansion or mobile integrations, ideally by extending the existing dApp SDK, or other complementary areas not already covered by the dApp SDK roadmap could provide clearer ecosystem value.

I really have to disagree with this outlook.

The fact of the matter is, there are several competing wallet APIs and SDKs in Canton today. And if you look at actual adoption in terms of the top Canton apps today as measured by number of users, transaction volume, or featured app rewards, to my knowledge none of them are based on CIP-103 or the dApp SDK. So if someone wants build an app or some other tool that works with the state of the network today, then what PartyLayer is doing is the way to do it.

CIP-103 and its surrounding tools in splice-wallet-kernel represent a good possible future direction, but as of today they are not winning in the marketplace and I don't see them as end-to-end ready yet.

The CIP-103 proposal was not, as far as I could tell, something that had an overwhelming consensus behind it at the time it was adopted. I personally had some serious reservations about its design, about its vision, and about its overall approach. However, I felt that it would be good to let it play out because I see this is as community and ecosystem in its early stages, where we are still trying to figure things out and experiment with different ideas, designs, and approaches. I did not anticipate that it would be brought up in this fashion to attempt to freeze out other ideas or be used as a cudgel to beat people into adopting it into their own designs, even at the expense of practicality or utility. I am wholeheartedly against that.

Thanks for the responses.

I appreciate the concern regarding the CIP-103. However, it’s currently being actively adopted and everyone is more than welcome to suggest improvement proposals. (I’m personally interested in learning the details about your concerns and would be happy to set up meeting for this with you).

Personally, I would like to see many more Rainbowkit-like alternatives. My concern is not that “adapters” exist – they are likely necessary as transitional compatibility layers. The issue arises when: “integrate every wallet individually” becomes the primary abstraction; instead of pushing toward a shared interface / protocol – like it happens on all the other networks.

Thanks for the responses.

I appreciate the concern regarding the CIP-103. However, it’s currently being actively adopted and everyone is more than welcome to suggest improvement proposals. (I’m personally interested in learning the details about your concerns and would be happy to set up meeting for this with you).

Personally, I would like to see many more Rainbowkit-like alternatives. My concern is not that “adapters” exist – they are likely necessary as transitional compatibility layers. The issue arises when: “integrate every wallet individually” becomes the primary abstraction; instead of pushing toward a shared interface / protocol – like it happens on all the other networks.

Thanks Marc, appreciate the openness and the meeting offer.

On the concern around “integrate every wallet individually” becoming the primary abstraction, we completely agree that this should not be the long term direction.

A big inspiration for us here is actually the RainbowKit v2 architecture. On Ethereum today, the transport layer is mostly a generic EIP-1193 + EIP-6963 connector, while wallet specific entries are increasingly just metadata, branding, install URLs, and optional UX flows rather than custom transport logic. New EIP-6963 wallets can work with effectively zero per-wallet transport code.

We see PartyLayer evolving in a very similar direction on Canton around native CIP-0103 connectivity. The goal is for the shared standard itself to become the primary abstraction, with PartyLayer focusing more on framework native developer experience, wallet coordination, UI primitives, and multi wallet application flows on top of that layer.

Compatibility layers only exist to help bridge the current ecosystem state and naturally shrink as wallets move toward native CIP-0103 support. Our recent Send integration already moved heavily in this direction.

One interesting thing we’ve been thinking about during recent wallet integration work is how wallet discovery and namespace coordination may evolve as more CIP-0103 wallets enter the ecosystem. It reminded us a lot of the motivation behind Ethereum’s EIP-6963 announce-event discovery model, and we’d genuinely be interested in discussing whether Canton may eventually benefit from something similar as adoption grows.

Appreciate the discussion and thoughtful feedback here as well.

[image: image]

Adoption update:

OneSwap has been using PartyLayer as its wallet abstraction layer, and we recently shared a public announcement around this integration.

Announcement: https://x.com/oneswapcc/status/2056692726905610557

This is an early example of PartyLayer being used at the application layer within the Canton ecosystem, particularly for wallet connectivity and user experience.

There have been some more changes around CIP-104, which you might not yet be aware of.

As of 0.6, the traffic cost is exposed on the transaction itself: https://github.com/digital-asset/canton/blob/main/community/ledger-api-proto/src/main/protobuf/com/daml/ledger/api/v2/transaction.proto#L87-L97

And the cost estimation is part of the submission workflow: https://github.com/digital-asset/canton/blob/main/community/ledger-api-proto/src/main/protobuf/com/daml/ledger/api/v2/interactive/interactive_submission_service.proto#L97-L116

Where do you see the need for reward attribution in an end-user wallet connectivity framework?

We've met to discuss this proposal. To recap the discussion from our perspective:

• The party layer proposal has some overlapping elements with the existing CIP-103 and dApp SDK proposal (https://github.com/canton-foundation/canton-dev-fund/blob/main/proposals/development-fund-proposal-canton-network-dapp-sdk-and-tooling.md). We suggest that you review them in order to reformulate your proposal in an additive sense. This applies mainly to milestone 1 & 3.
• The traffic observability milestone 2 might be based on insufficient information, as the problem as stated should be mostly remediated by the fact that the traffic cost is included in the completion and transaction stream (since 0.6 / canton 3.5; pointers given below).
• You additionally expressed in the proposal the desire to expose an SDK for reward attribution. Here, we do not really understand how this fits into an end-user wallet connectivity framework.
• One key additive element seems to be the specific React support to target mobile devices. This is indeed additive to the existing standard, but right now, we are not aware of an actual, widespread demand in the Canton Network.

Please let us know if you have any questions or would like to discuss further.

Thanks for catching this and for sharing the proto references. This is very helpful.

You’re right that this section should be updated based on the post-0.6 changes. Traffic cost is now exposed directly on the transaction object, and cost estimation is already part of the interactive submission workflow, so this should not be framed as a missing SDK surface or a separate observability layer.

On the reward attribution point, we agree that PartyLayer should not be positioned as a reward attribution layer. That logic belongs closer to the validator / SV-app side. For PartyLayer, the relevant scope is cost visibility at the application layer: helping dApps surface transaction and traffic cost information in the UI, so developers and users can better understand execution cost, UX impact.

We’ll re-scope the CIP-0104 section around that narrower piece only, framed as a lightweight UX/developer-experience helper around existing transaction and submission cost fields, not as a reward attribution or observability component.

Thanks again for the precise pointers. We’ll revise this section to reflect the current state.

Thanks for the recap and for the clear feedback.

One important timeline point we’d like to clarify: the PartyLayer proposal was originally opened on February 20, before some of the later dApp SDK proposal discussions and scope details were available to us. So any similarity in wording was not intended as overlap, and we’re happy to clarify the proposal text now that the related SDK scope is more visible.

Our view is that PartyLayer and the Canton dApp SDK sit at different layers of the developer stack. PartyLayer is not intended to duplicate the canonical transport, discovery, compliance, or wallet connectivity layer. We see the Canton dApp SDK and CIP-0103 as the lower-level foundation that PartyLayer can build on top of.

The way we think about the intended layering is roughly:

Canton dApp stack:

┌──────────────────────────────────────────┐
│ dApp                                     │  ← built by app teams
├──────────────────────────────────────────┤
│ PartyLayer UI / DX layer                 │  ← RainbowKit-like primitives
├──────────────────────────────────────────┤
│ PartyLayer data / state layer            │  ← wagmi-like hooks and state
├──────────────────────────────────────────┤
│ Canton dApp SDK                          │  ← transport, discovery, base SDK
├──────────────────────────────────────────┤
│ CIP-0103                                 │  ← wallet connectivity standard - EIP1193-like
└──────────────────────────────────────────┘

This is the layer boundary we want to make clearer in the proposal text.

PartyLayer is focused on the application-layer developer experience: framework-native hooks, wallet UI primitives, session orchestration, multi-wallet UX, state management, and Canton-specific dApp patterns. In Ethereum terms, the closest analogy would be a wagmi / RainbowKit style layer built above the underlying wallet connectivity standard, not a competing transport or protocol implementation.

The key distinction is that the dApp SDK exposes the base connectivity layer, while PartyLayer focuses on application-level patterns, framework-native state, UI composition, and end-user wallet UX built on top of that foundation.

To make the distinction more concrete, these are the areas where PartyLayer would focus above the basic SDK surface:

1. Application-layer data patterns

PartyLayer can compose on top of lower-level SDK primitives with a reactive data layer designed for real dApp usage. This includes caching, refetching, optimistic transaction states, query invalidation, SSR / Next.js support, and session-aware state handling.

For example, instead of only exposing a primitive request or connection method, PartyLayer can provide higher-level hooks and patterns such as:

• useTransactionCost for pre-submission cost estimation and post-execution cost visibility using existing ledger API fields
• useDamlContract for typed contract reads using generated Daml / DAR types
• useExternalSigning for external party signing flows and topology-aware signing UX
• ACS snapshot helpers and update stream subscriptions with reconnect handling
• choice exercise lifecycle helpers for preparing, submitting, tracking, and finalizing user actions
• wallet-switch-safe state management so app state does not break when a user changes wallet or reconnects

This is closer to a wagmi-style data layer than a thin wrapper around a wallet request interface.

2. UI components and wallet UX primitives

PartyLayer can provide themed, accessible, composable UI primitives that help apps build richer wallet experiences without every team rebuilding the same flows from scratch.

Examples include:

• wallet connection components that can be themed and embedded into different app designs
• transaction lifecycle UI such as preparing, submitted, confirmed, finalized, or failed states
• transaction cost preview components
• party identity display and metadata resolution
• synchronizer selection or status UI where relevant
• wallet status components for connected, disconnected, wrong network, or unsupported wallet states
• user-friendly error display for cases like rejected signature, insufficient traffic, unsupported method, or synchronizer errors

The goal is not to replace the dApp SDK’s wallet picker or base connection layer, but to give application teams reusable UX building blocks around it.

3. Canton-specific developer patterns

Canton has application patterns that do not map cleanly to generic wallet connectivity alone. PartyLayer can package higher-level patterns around these Canton-specific flows so every dApp team does not need to rediscover them independently.

Examples include:

• privacy-aware query patterns
• witness filtering and selective disclosure UX patterns
• multi-party transaction flows
• DvP-style settlement flows
• beneficiary / confirmer patterns
• disclosed contract handling where relevant
• synchronizer-aware operations
• external signing UX patterns
• Canton-specific error taxonomy with user-friendly message mapping

These are not transport-layer responsibilities. They are application-layer patterns that help teams build production-grade Canton dApps faster and with more consistent UX.

4. Multi-framework support

The dApp SDK naturally focuses on the core SDK surface and React support. PartyLayer can extend the application-layer experience into additional frontend environments.

The current practical focus would be React and Vue, especially because Vue / Nuxt is relevant for some institutional frontend teams. React Native and other frameworks can remain longer-term roadmap items depending on ecosystem demand, instead of being overstated as immediate committed demand.

The key idea is to keep a shared framework-agnostic core while offering idiomatic bindings for each frontend environment:

• React hooks and providers
• Vue composables
• framework-specific reactive state bindings
• shared core logic underneath

This lets PartyLayer support application teams where they actually build, while still consuming the same lower-level Canton SDK foundation.

5. Vertical-specific dApp templates

Instead of only providing one generic reference dApp, PartyLayer can provide application-level templates for common Canton use cases. These would not be reference implementations of the base SDK. They would be production-oriented examples of how to compose wallet UX, state management, transaction flows, and Canton-specific patterns in real applications.

Examples could include:

• tokenization template for issuance, transfer, and restricted-asset flows
• trading template for order book, AMM, or settlement flows
• lending template for borrow, repay, collateral, and position monitoring
• RWA settlement template for DvP and multi-party confirmation flows
• identity / credentials template for KYC, attestations, and permissioned access patterns

These templates would help application developers move faster while demonstrating how the underlying dApp SDK and CIP-0103 foundation can be used in real products.

This is why we see PartyLayer as complementary to the dApp SDK. The dApp SDK provides the canonical foundation, while PartyLayer focuses on the higher-level developer experience, state management, UI primitives, and application patterns that sit above it.

Concretely, we plan to clarify the proposal text around:

1. PartyLayer as an application-layer DX framework built on top of the Canton dApp SDK / CIP-0103 foundation
2. The distinction between base SDK responsibilities and application-layer UI / state / orchestration responsibilities
3. Framework-native developer experience, wallet UI, session orchestration, multi-wallet UX, and Canton-specific dApp patterns
4. Lightweight cost visibility helpers using existing ledger API fields, where relevant, without positioning PartyLayer as a reward attribution or observ

Thanks @daravep, @joel-da, @mjuchli-da for the meetings and detailed review feedback. It was very helpful for clarifying the scope.

Since this proposal was originally written in February, a lot has evolved across the Canton ecosystem, especially around the dApp SDK, CIP-0103, CIP-0104, and wallet standards. We updated the proposal to better reflect the current direction and to make PartyLayer’s role clearer.

The main changes are:

1. Repositioned PartyLayer as an application-layer developer experience framework on top of the Canton dApp SDK and CIP-0103, focused on framework-native state, UI primitives, multi-wallet UX, and reusable dApp patterns.

2. Added clearer modular adoption paths, so teams can use the dApp SDK directly, use only PartyLayer’s data layer, use only the UI layer, or adopt the full stack depending on their needs.

3. Clarified that the current wallet adapters are transitional bridges for pre-CIP-0103 wallets and will be sunset within two months after proposal approval as wallets move to native CIP-0103 support through the canonical dApp SDK path.

4. Narrowed the CIP-0104 scope to lightweight application-layer cost visibility using existing ledger API fields.

5. Restructured the milestones around application-layer tooling, framework expansion, CIP-0104 cost UX, production hardening, Canton-specific patterns, and production-oriented dApp templates.

Overall, the updated version keeps PartyLayer focused on its strongest contribution: helping Canton application teams build better end-user wallet experiences without duplicating the lower-level connectivity work of the dApp SDK.

Quick ecosystem update from our side:

PartyLayer has now been listed on both Canton News and CCTools:

https://cantonnews.org/projects/partylayer

https://cctools.network/ecosystem/partylayer

We’re continuing to work on ecosystem visibility, wallet integrations, and dApp adoption around PartyLayer.

Milestone 1 — Application-Layer Developer Tooling

Estimated Delivery: 3 weeks | Funding: 100,000 CC

Effort Rationale: Approximately 3 weeks of full-team engineering effort distributed across @partylayer/session lifecycle and resilience layer (~25%), multi-framework CLI scaffolding (~20%), @partylayer/testing mock provider and harness implementation (~20%), PartyLayer Studio interactive workbench (~20%), and Pattern Cookbook authoring (~15%). The funding allocation reflects implementation effort weighted toward developer-facing artifacts that establish a reliable onboarding baseline for the application-layer surface, anchored by the session resilience foundation that subsequent milestones build upon.

Deliverables:

@partylayer/session — Session Lifecycle & Resilience Layer

A production-grade session management layer that sits above the Canton dApp SDK's transport primitives, handling the stateful concerns every Canton dApp currently rebuilds independently:

• Persistent session restore across page reloads via encrypted storage (Web Crypto API AES-GCM, localStorage and IndexedDB backends)
• Multi-tab synchronization via BroadcastChannel — disconnect in one tab propagates to all open tabs of the same dApp
• Party-switch detection — when the user changes the primary party in their wallet, dApp state is invalidated and re-fetched automatically
• Network and synchronizer change handling with cache invalidation and reconnect orchestration
• Automatic reconnect with exponential backoff and configurable retry policies for transient network failures
• Session expiry detection and graceful re-authentication flows that preserve in-flight transaction state
• useSession, useAccount, useAccountEffect hooks for React and equivalent composables for Vue, providing reactive access to session, primary account, and lifecycle events
• Session schema migration helpers for backward-compatible storage upgrades across SDK versions
• Origin-bound session isolation preventing cross-site session leakage

This layer operates strictly above @canton-network/dapp-sdk, consuming its connect, disconnect, status, and statusChanged primitives and adding the stateful resilience patterns that wallet-side transport does not provide.

npx create-partylayer-app — Multi-Framework Application Scaffolder

Four framework-aware boilerplates, each pre-wired with PartyLayer's application-layer patterns:

• React + Vite template — PartyLayer Provider, TanStack Query Client, pre-configured hooks, themed components wired
• Next.js App Router template — Server Components hydration via cookieStorage SSR pattern, route-level wallet gates, server-side party fetching
• Vue 3 + Nuxt 3 template — composables with API parity to React hooks, Pinia store integration, SSR hydration
• Vanilla JS template — framework-agnostic core for legacy frontends or progressive enhancement

Each template ships with a working transaction lifecycle UI, mock wallet setup from @partylayer/testing, session resilience pre-configured via @partylayer/session, and CIP-0103 conformance test integration.

@partylayer/testing v1.0 — Application-Layer Testing Harness

• Mock CIP-0103 wallet provider with configurable response scenarios (connect rejection, insufficient traffic, synchronizer error, transaction timeout)
• Simulated transaction lifecycle with controllable phase transitions for testing isPreparing → isSubmitting → isConfirming → isFinalized states
• Session lifecycle simulation utilities (forced session expiry, party-switch events, multi-tab disconnect propagation, reconnect scenarios)
• TanStack Query test utilities for asserting cache state, query invalidation, and optimistic update rollback
• Offline integration test utilities — no DevNet dependency required for unit tests

PartyLayer Studio — Interactive Pattern Workbench

An in-browser sandbox built on Sandpack that runs PartyLayer code without local installation:

• Live code editor with PartyLayer types pre-loaded — IntelliSense for all hooks, composables, and components
• Mock wallet driver integrated — simulate any CIP-0103 method response without a real wallet
• Embedded React Query DevTools showing live cache state, query keys, invalidations, and refetch triggers
• Transaction lifecycle stepper with pause/resume controls for walking through state transitions and rollback simulation
• Session resilience scenarios — multi-tab sync demonstration, party-switch invalidation walkthrough, reconnect-after-expiry replay
• Framework toggle — switch the same example between React, Vue, and Vanilla JS variants
• Scenario library — pre-built scenarios for multi-wallet switching, optimistic update rollback, CIP-0104 cost preview, synchronizer failover

PartyLayer Pattern Cookbook

Pattern-oriented cookbook of runnable patterns for common application-layer problems:

• Persistent session restore on page reload via @partylayer/session
• Multi-tab synchronization via BroadcastChannel
• Wallet-switch-safe state with useAccountEffect-style flow
• Automatic reconnect with exponential backoff after network interruption
• Optimistic transaction states with rollback (useChoice + onMutate snapshot/restore)
• Query invalidation tied to update stream events
• SSR hydration in Next.js App Router via cookieStorage
• CIP-0104 cost preview before signing
• Multi-party transaction composition with typed actAs/readAs accessors
• Suspense-driven loading boundaries via useSuspenseQuery

Each entry includes a runnable Studio scenario, code snippet, and "when not to use this pattern" guidance.

Updated npm releases and documentation publishing.

Acceptance Criteria:

• @partylayer/session v1.0 published to npm with encrypted persistent storage, multi-tab BroadcastChannel synchronization, party-switch detection, automatic reconnect with exponential backoff, session expiry handling, and useSession/useAccount/useAccountEffect hooks for React and equivalent composables for Vue, validated through integration tests covering at least eight session lifecycle scenarios
• npx create-partylayer-app CLI published to npm with semantic versioning, supporting React + Vite, Next.js App Router, Vue 3 + Nuxt 3, and Vanilla JS templates
• All four scaffolded templates produce a working PartyLayer integration that passes the CIP-0103 conformance runner and ships with pre-wired TanStack Query Client, Pinia integration where applicable, SSR cookieStorage configuration, and @partylayer/session resilience layer
• @partylayer/testing v1.0 published to npm with mock wallet provider supporting configurable failure scenarios, simulated transaction lifecycle, session lifecycle simulation utilities, and TanStack Query test utilities
• PartyLayer Studio deployed publicly with Sandpack-based code editor, embedded React Query DevTools, transaction lifecycle stepper, framework toggle, and a minimum of six pre-built scenarios including at least two session resilience walkthroughs
• Pattern Cookbook published in the documentation site with at least eight runnable pattern entries linked to corresponding Studio scenarios
• All deliverables open-source on GitHub under the MIT license, with versioned releases and reproducible build instructions

Milestone 2 — Framework Expansion & CIP-0104 Cost Helper

Estimated Delivery: 3 weeks Funding: 100,000 CC

Effort Rationale: Approximately 3 weeks of full-team engineering effort distributed across Vue.js framework parity implementation (~40%), @partylayer/react v2.0 modernization to a TanStack Query–based architecture (~30%), CIP-0104 cost visibility helper (~15%), and CIP-0104 Live Reference (~15%). The primary focus is framework expansion — Vue parity together with React modernization establishing a consistent reactive cache model across frameworks — with the CIP-0104 helper included as a narrow application-layer UX utility.

Deliverables:

• @partylayer/vue v1.0 — Vue 3 Composables with React Parity

  • Vue 3 composables with API parity to React bindings (useWallet, usePartyState, useTransactionCost, useDamlContract, useChoice)
  • Component bindings for <TransactionToast />, <CostPreview />, <PartyAvatar />, <SynchronizerSwitcher />
  • Nuxt 3 SSR compatibility with server-side party fetching and hydration
  • Pinia store integration option for centralized state management
  • Suspense-ready composables for declarative loading boundaries
  • Validated against the same CIP-0103 conformance runner as React bindings

• @partylayer/react v2.0 — Modernized React Bindings

  Modernization of the existing React integration layer to align with current frontend ecosystem standards and establish a consistent reactive cache model that Vue composables and future framework bindings mirror:

  • TanStack Query v5 integration as a peer dependency, replacing the current context-based state model
  • useQuery/useMutation standard adopted across all hooks (useWallet, usePartyState, useDamlContract, useChoice, useTransactionCost)
  • useSuspenseQuery support via a dedicated @partylayer/react/query entrypoint for declarative loading boundaries
  • Server Components compatibility for Next.js App Router (RSC-safe imports, server-side party prefetching)
  • cookieStorage SSR pattern support for hydrating wallet and party state across server and client boundaries
  • onMutate snapshot/restore patterns baked into mutation hooks for optimistic transaction states with automatic rollback on error
  • Documented v1.x → v2.0 migration guide with codemod-friendly mappings
  • Validated against the same CIP-0103 conformance runner; backward-compatible exports preserved for one minor cycle

• CIP-0104 Cost Visibility Helper

  • useTransactionCost React hook and Vue composable
  • Pre-submission CostEstimation reading (confirmation_request_traffic_cost_estimation, confirmation_response_traffic_cost_estimation, total_traffic_cost_estimation)
  • Post-execution paid_traffic_cost reading from the transaction object
  • <CostPreview /> UI component for displaying expected cost before signing and actual cost after execution
  • Documentation on integrating cost visibility into production dApp UI

  Lightweight UX layer around existing ledger API fields (paid_traffic_cost on transaction.proto, CostEstimation on interactive_submission_service.proto). No reward attribution, no observability pipeline, no traffic accounting modification.

• CIP-0104 Cost Visibility Live Reference

  Minimal, single-page, embeddable demonstration of the CIP-0104 cost helper running against DevNet:

  • Shows exact protobuf field reading (paid_traffic_cost, confirmation_request_traffic_cost_estimation, total_traffic_cost_estimation) in a working dApp
  • Provides a pattern reference wallet teams can point users to when explaining transaction costs
  • Serves as a regression target for CIP-0104 changes

Acceptance Criteria:

• @partylayer/vue v1.0 published to npm with API parity to React bindings, Nuxt 3 SSR support, Pinia integration, and validation against the same CIP-0103 conformance runner
• @partylayer/react v2.0 published to npm with TanStack Query v5 integration, useSuspenseQuery support via @partylayer/react/query, Server Components compatibility, cookieStorage SSR pattern, and a documented v1.x → v2.0 migration guide
• CIP-0104 Cost Visibility Helper published to npm with useTransactionCost hook/composable reading existing protobuf fields, accompanied by <CostPreview /> UI component for React and Vue
• CIP-0104 Live Reference deployed publicly demonstrating pre-submission CostEstimation and post-execution paid_traffic_cost reading in a working DevNet dApp
• All Milestone 2 packages tagged on GitHub with versioned releases and reproducible build instructions

Milestone 3 — Production Hardening, Canton-Specific Patterns, Observability & Mobile

Estimated Delivery: 3 weeks Funding: 100,000 CC

Effort Rationale: Approximately 3 weeks of full-team engineering effort distributed across vertical-specific dApp templates (~25%), Canton-specific developer patterns (~20%), application-layer UI primitives and theme system (~15%), production observability layer and structured logging (~15%), React Native bindings (~10%), error taxonomy design and integration (~10%), and PartyLayer Production Migration Checklist with performance optimization (~5%). The vertical templates serve as integration vehicles that exercise and validate the application-layer patterns, UI primitives, and Canton-specific helpers established in earlier deliverables, reducing redundant implementation work. This milestone carries the highest production-readiness burden, balanced by reusing patterns and primitives established in earlier milestones.

Deliverables:

• Canton-Specific Developer Patterns

  • Privacy-aware query helpers (view decomposition handling, witness filtering)
  • Multi-party transaction flow patterns (multi-confirmer workflows, atomic settlement coordination)
  • CIP-0056 token standard interaction helpers (holdings queries, transfer instruction submission, allocation flows for FoP and DvP-style workflows)
  • Explicit contract disclosure helpers (auto-attach disclosed_contracts on Ledger API commands, leveraging Daml's explicit disclosure feature)
  • Synchronizer-aware operation utilities (multi-synchronizer party operations)

• Vertical-Specific dApp Templates

  Reference dApp templates that compose PartyLayer's application-layer surface — framework-native hooks, UI primitives, Canton-specific patterns, and CIP-0104 cost visibility — in production-oriented examples of real Canton use cases. These are not reference implementations of the base Canton dApp SDK; they are application-layer references that demonstrate how teams can build production-grade Canton dApps on top of the canonical SDK foundation.

  • Tokenization Template — issuance, transfer, and holdings management flows built on the CIP-0056 token standard

    • Issuer dashboard with mint, freeze, and supply management UI
    • User-facing holdings view via useHoldings and <PartyAvatar />
    • Transfer flow using CIP-0056 transfer instructions with <TransactionToast /> lifecycle UI
    • CIP-0104 cost preview before signing via <CostPreview />
    • Multi-party demonstration (issuer party + user party) with wallet-switch-safe state
    • Typed Daml contract reads via useDamlContract with generated DAR types

  • DvP Settlement Template — atomic delivery-versus-payment flows between two parties, exercising the deepest set of Canton-specific patterns

    • Two-party UI (buyer + seller) with multi-confirmer transaction workflow
    • Atomic settlement coordination via CIP-0056 allocation flow (proposed → counter-signed → executed → settled lifecycle states)
    • Explicit contract disclosure auto-attach for cross-party visibility
    • Privacy-aware queries demonstrating per-party witness filtering
    • Synchronizer-aware operations with <SynchronizerSwitcher /> for multi-synchronizer settlements
    • CIP-0104 cost preview per settlement leg

  Each template ships as an open-source GitHub repository with a working DevNet deployment, README with documented user flows, and deployment instructions. Templates are reference quality — they demonstrate composition patterns and exercise PartyLayer's stack end-to-end — and are explicitly not production-audited integrations.

• Application-Layer UI Primitives

  • <TransactionToast /> — transaction lifecycle UI (preparing → submitted → confirmed → finalized → failed states)
  • <CostPreview /> — CIP-0104 cost visualization component (built in M2, extended here with theme integration)
  • <PartyAvatar /> — party identity display with metadata resolution
  • <SynchronizerSwitcher /> — multi-synchronizer selection modal
  • Theme system (light / dark / Canton variants with configurable accent color, border radius, font stack)

• Production Observability Layer

  • Application-level event emission across integration lifecycle phases (connect, authorize, prepare, submit, confirm, error)
  • Vendor-neutral adapter interfaces for optional integration with external monitoring tools (OpenTelemetry, Sentry, Datadog)
  • No network-level telemetry, no centralized tracking, no user-identifying data collection

• Structured Logging Hooks

  • Standardized, machine-readable log events for each application-layer interaction phase
  • Configurable verbosity levels (debug, info, warn, error)
  • Correlation identifiers for tracing multi-step wallet operations

• Standardized Error Taxonomy

  • Canonical error classification aligned with CIP-0103 response categories
  • Stable, documented error codes for programmatic handling
  • User-friendly error message mapping for common cases (rejected signature, insufficient traffic, unsupported method, synchronizer errors)
  • Additive normalization layer — no modification of underlying CIP-0103 semantics

• @partylayer/react-native v1.0

  • Mobile wallet connectivity for React Native applications
  • React Native compatibility layer that consumes the same shared framework-agnostic core as React and Vue
  • Demonstration on at least one mobile-compatible wallet adapter

• PartyLayer Production Migration Checklist

  PartyLayer-specific operational checklist for moving applications from DevNet to TestNet to MainNet:

  • Bundle size regression checklist with per-framework targets (React, Vue, React Native), tree-shaking validation, lazy loading boundaries
  • Cache configuration for production — TanStack Query staleTime, gcTime, refetchOnWindowFocus tuning per data type (ACS snapshots vs party state vs cost estimates)
  • Production error boundary setup with Sentry/Datadog adapter configuration
  • Observability event schema with production sampling rates and PII filtering verification
  • Synchronizer failover patterns — <SynchronizerSwitcher /> production configuration, retry policies
  • CIP-0104 cost preview accuracy monitoring — CostEstimation vs paid_traffic_cost drift tracking
  • SSR/Server Components production setup — cookieStorage configuration, edge runtime compatibility, cache headers
  • Multi-framework consistency tests ensuring React, Vue, and React Native behave identically in production scenarios

• Performance Optimization

  • Bundle size analysis and reduction
  • Caching strategies and lazy loading

Acceptance Criteria:

• Canton-specific developer patterns published with documented hooks/utilities for privacy-aware queries, multi-party flows, CIP-0056 token standard interactions (holdings, transfer instructions, allocations), explicit contract disclosure helpers, and synchronizer-aware operations
• Two vertical-specific dApp templates (Tokenization Template, DvP Settlement Template) published as open-source GitHub repositories, each deployed to a live DevNet demo URL, accompanied by a README documenting at least five user flows per template and exercising the full application-layer surface (hooks, UI primitives, Canton-specific patterns, CIP-0104 cost visibility)
• Application-layer UI primitives (<TransactionToast />, <CostPreview />, <PartyAvatar />, <SynchronizerSwitcher />) published with theme system supporting light, dark, and Canton variants
• Production observability layer published with documented event schema across connect, authorize, prepare, submit, confirm, and error lifecycle phases
• Vendor-neutral adapter interfaces shipped with at least one working reference adapter for external monitoring tools (OpenTelemetry, Sentry, or Datadog)
• Structured logging h

Congratulations on getting this approved. I like that PartyLayer focuses on improving wallet interoperability without changing the underlying protocol rules. That should make adoption much easier across the ecosystem. Looking forward to following its progress.