Proposal: Canton Token Standard Local API Compatibility & CI Harness

Development Fund Proposal Submission

Proposal file: /proposals/proposal-canton-token-standard-local-api-compatibility-harness.md

Summary

This proposal requests funding for Canton Token Standard Local API Compatibility & CI Harness, a focused open-source developer infrastructure project for local Token Standard / CIP-56-style workflow testing in Canton applications.

The proposal targets an application-facing layer for backend, wallet, SDK, QA, and DevRel teams that need to test Token Standard workflows locally and in CI before depending on DevNet/TestNet Utility infrastructure.

The Splice repository already includes token-standard/splice-token-standard-test, which provides a Daml-level Token Standard test harness with AmuletRegistry, Token Standard package dependencies, Daml scripts, transfer/DvP scenarios, and disclosure handling inside Daml tests.

This proposal does not build another Daml-level Token Standard test harness. It builds the layer above that foundation: a local CIP-56-compatible API/CI harness that application teams can consume directly.

In short:

• splice-token-standard-test provides the Daml/package-level foundation.
• This proposal provides the application-facing local API, CI workflows, examples, and compatibility documentation around that foundation.

The intended high-level local developer experience is expected to be similar to:

docker compose up -d
ctsu fixture seed --profile basic-token
ctsu scenario run first-transfer --from Alice --to Bob --symbol tUSD --amount 100
ctsu assert holdings --party Bob --symbol tUSD --amount 100
ctsu fixture reset

These commands are illustrative examples of the intended local developer ergonomics, not a finalized CLI contract.

What this delivers beyond splice-token-standard-test

This proposal adds a layer that application teams can consume directly:

• reuse or wrap existing Splice Token Standard test assets where possible;
• expose a supported local CIP-56 OpenAPI-compatible profile for selected workflows;
• return required disclosedContracts for supported flows;
• handle ledger-derived createdEventBlob rather than manually constructing or faking it;
• provide deterministic CI scenarios: fixture seed → first transfer → holdings assertion → reset;
• ship Java/Spring and TypeScript/NestJS examples;
• publish a supported / simulated / deferred compatibility matrix.

Disclosed Contracts and createdEventBlob Handling

The service will not fake or manually serialize createdEventBlob.

The design uses ledger-derived createdEventBlob values, retrieved from the local ledger / participant through supported ledger access paths such as JSON Ledger API active-contract queries with includeCreatedEventBlob=true or equivalent gRPC access.

Those blobs are cached by contract id and returned in disclosedContracts where required by the supported CIP-56-style local profile.

Workflows outside the supported v1 local profile are explicitly documented as deferred or out of scope rather than presented as spec-compliant.

Checklist

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

Notes for Reviewers

This proposal is intentionally narrow and scoped to avoid overlap with broader SDK, DevKit, CLI, wallet, registry, indexer, auth, verification, and rewards efforts.

It does not replace splice-token-standard-test. It builds an application-facing local compatibility layer around existing Splice Token Standard test assets where possible.

The main differentiators are:

• focused on local application development and CI testing, not production Utility Registry behavior;
• centered on a supported local CIP-56-compatible profile for selected workflows, not a custom token API;
• includes explicit disclosedContracts / createdEventBlob handling for supported flows;
• designed as a shared local test target for SDKs, wallets, applications, QA suites, examples, and DevRel workflows;
• useful without changing protocol behavior or requiring privileged MainNet/TestNet/DevNet access for v1 acceptance;
• scoped and priced as a focused public-good developer infrastructure tool.

The proposal includes a dedicated existing-work section, a non-overlap section, and a supported / simulated / deferred compatibility matrix to make clear what is reused, what is added, and what is out of scope.