Wallet Gateway Reference Implementation #109 Milestone 1: Early Trading MVP Support

OPENIssue
by pedrodneves21-05-2026
References:CIP-0103
View on GitHub ↗← All Proposals

Milestone 1: Early Trading MVP Support

Establishing the foundational API architecture, containerized deployment, and initial institutional connectivity required for MVP trading flows.

  • Reusable User API: Delivery of reusable core wallet API.

Acceptance:* Demonstrable network separation between the User API (powering the trusted UI) and the dApp API.

  • dapp API-Server (CIP-0103): Delivery of the server-side CIP-0103 dApp API. API endpoints supporting inbound pre-prepared LAPI transaction payloads and outbound signed-transaction submission hand-offs.

Acceptance:* Successful end-to-end execution of a JsPrepareSubmission flow initiated by the current dapp-sdk, resulting in a valid LAPI-prepared transaction payload ready for KeyStore signing.

  • Authentication (Centralized IDP): Implementation of standard Ledger API authentication. To rapidly unblock the MVP, this initial release will rely on traditional, centralized Web2 Identity Providers to manage user authorization and Ledger API connectivity.

Acceptance:* Successful authentication and connection to the Ledger API using a standard JWT issued by a centralized IDP.

  • Party Support (Internal/External Parties): The infrastructure automated routing of transaction hashes to Keystore API (external) or local Validator (internal) signing modules based on party metadata. To adhere to zero-trust security models, internal parties (where keys are held directly by the Validator Node) are supported strictly for development and rapid testing environments. Production deployments benefit from the use of external parties, ensuring cryptographic assets remain fully isolated within the user's chosen KeyStore.

Acceptance:* Verified via automated tests, successfully allocating and listing both party types on a local validator.

  • Containerized Deployment: Delivery of the "Remote Wallet Gateway" as a Docker image.

Acceptance:* Delivery of the "Remote Wallet Gateway" as a containerized NodeJS server (Docker image) capable of co-location with a Validator Node.

  • Battle-Testing: Proving the Gateway can handle production-level traffic and providing a live, visible example of the implementation.

Acceptance (Public Good): Production of verifiable Ledger submission logs for 10 consecutive, unique transaction types via a fully open-source dApp UI example, providing a verifiable reference implementation for the Canton developer community. Voluntary Bonus Acceptance (Enterprise Scale): While the funding requested in this grant strictly covers the Gateway development and the open-source reference integration. It does not subsidize the integration work into DA's non-OSS commercial code). Still we commit to voluntary validation not covered by grant funding via integration into Digital Asset's commercial registry frontend (utilities.digitalasset.com) to serve as the production-grade "Battle Test".

  • Initial Institutional Adapter: Delivery of the first institutional KeyStore driver designed to plug-and-play with external institutional wallets.

Acceptance:* Demonstrated compatibility with an institutional 'Clear Signing' engine via the KeyStore API.

  • Developer Documentation: Publication of technical integration documentation.

Acceptance:* API schema and integration markdown files published to the repository (User manuals excluded).

  • Internal Security Architecture Review / Internal Audit: Documented sign-off from DA Core Engineering.

Acceptance:* Documented sign-off from DA Core Engineering confirming the MVP API architecture and container network boundaries meet initial Canton security standards.

  • Code Quality (MVP): CI/CD pipelines must report:

At least 80% Unit Test coverage. At least 50% E2E test coverage specifically mapped to critical transaction routing flows. Provision of comprehensive E2E Integration Logs.

  • Basic clear signing: write-review during the transaction submission process.

Acceptance:* The user is presented with the transaction payload prior to signing the transaction hash.

| Milestone | Target deadline | Funding Request | | :--- | :--- | :--- | | Milestone 1: Early Trading MVP Support | June 30th 2026 | 800.000 CC |

_Originally posted by @pedrodneves in https://github.com/canton-foundation/canton-dev-fund/issues/109#issuecomment-4512190033_