Canton Infrastructure

RWA issuance, transfer, wallet architecture, and secure signing

Canton Network engineering at TEKHQS for an RWA platform, covering Daml contracts, non-custodial wallet architecture, threshold signing, and secure remote signing infrastructure. Client and project details are withheld.

CantonRWATokenizationSigning

Context

Client delivery at TEKHQS on Canton Network. The public record names the architecture, not the client.

The challenge

Tokenizing real-world assets on a privacy-preserving ledger is not a single token contract. Issuance, transfer, and compliance have to survive explicit counterparties, multi-party authorization, and a signing model that is not a custodial hot wallet.

My role

Architecture owner and engineering lead for the RWA stack. Hands-on on the signing path and participant SDK — not a paper architecture.

What I owned

Architected

RWA contract flows: instrument creation, receiver enrollment, mint, and transfer.
The signing boundary between Canton transaction preparation and secure key authorization.
Wallet origin isolation so the host never sees secret key material, ciphertext, or the hash-to-sign.

Implemented

Remote signing service: enclave keygen/sign, sharded KMS custody.
Participant SDK: external-party onboarding, interactive submission, and RWA write routing.

Led

Canton node config, DAR upload, and environment topology.
Engineering delivery on the RWA stack at TEKHQS.

Architecture

Daml application layer for instruments, holdings, factories, and on-ledger pause/compliance controls. Operator and registrar as external parties using interactive submission. Host applications talk to a wallet origin over an iframe boundary — intents in, public results out. External-party keys are 2-of-3 threshold: a device share wrapped under a passkey, a recovery share, and an enclave co-signer. A remote signing service performs keygen and sign inside AWS Nitro; KMS decrypt is gated on enclave attestation. A TypeScript participant SDK owns party management, RWA flows, and per-leg submission routing.

Trust boundaries

Private keys: device share wrapped under WebAuthn; recovery share sealed under a client-held secret; enclave co-signer never ships to the browser.
Who can request a signature: the host sends intents only. The wallet origin is the authorization surface. The signing service authenticates callers with identity-scoped JWTs.
What is validated before signing: Canton hash recomputed from prepared bytes; mismatch discards; user approves the decoded transaction; anti-replay nonce; the enclave also recomputes the hash.
What the backend cannot access: wallet secret material, ciphertext, and the hash-to-sign. It prepares transactions and mints Cognito JWTs. It does not sign.
Signing boundary: isolated wallet origin; attested Nitro; KMS decrypt gated on attestation; the parent process does not carry shard decrypt keys over vsock.
Transaction integrity: prepared bytes pin the hash; interactive submission of single-authorizer legs.

System architecture

01
Host application
Intents in. Public results out.
02
Wallet origin
Isolated iframe. Hash recompute. Approval.
03
Signing service
Nitro enclave. KMS. Cognito JWT.
04
Canton participant
Interactive submission. Single-authorizer legs.
05
AWS infrastructure
Nitro, KMS, Cognito, DynamoDB, S3.

Host applications never hold signing keys. The wallet origin, attested signer, and ledger sit on opposite sides of that boundary.

Signing path

01
Intent
Host → wallet origin
02
Prepare
Canton prepared transaction
03
Verify hash
Recompute; discard on mismatch
04
Approve
Decoded tx; summary untrusted
05
Threshold sign
Passkey share + attested co-sign
06
Submit
Interactive, per-leg

Nothing is displayed, and nothing is signed, until the prepared bytes pin to an independently recomputed hash.

Signing flow

Host sends an intent into the isolated wallet origin. Secret material does not cross that boundary.
Backend prepares the Canton transaction and returns prepared bytes plus a claimed hash.
Wallet origin recomputes the Canton hash from the prepared bytes. A mismatch discards the request before anything is shown.
User approves the decoded transaction. The backend summary is an untrusted hint only.
Device share is released under a WebAuthn-gated wrap. The enclave co-signer runs only after attestation; KMS decrypt is gated on that attestation.
Signing requests carry a fresh anti-replay nonce. The enclave also recomputes the Canton hash from the prepared transaction.
Interactive submission of single-authorizer legs to Canton. Mixed actAs is not forced onto one submission.

Why this was hard

A custodial hot wallet or a browser-held seed cannot authorize Canton external parties under interactive submission.
Issuance, transfer, and compliance have to survive explicit counterparties and multi-party authorization — not a single-token shortcut.
The hash that will be signed must be independently recomputed from prepared bytes. Displaying an unpinned transaction is a trust failure.
Mixed external and internal authorization on one interactive submission is rejected by the ledger; the flow has to be decomposed into single-authorizer legs.

Engineering decisions

Isolated wallet origin instead of host-held keys, because the host must never see secret material, ciphertext, or the hash-to-sign.
Attested enclave co-sign instead of browser or unattested-backend signing.
Independently recomputed Canton hash instead of trusting a backend-claimed hash. A mismatch discards the request before anything is shown.
User approval of the decoded transaction instead of a backend summary. Summaries are untrusted hints.
Single-authorizer legs instead of mixed external and internal actAs on one interactive submission, because Canton rejects the mixed case.
Unpublished client identity and signing-ceremony internals instead of a public demo.

Constraints

Client confidentiality — names, endpoints, and signing-ceremony internals stay unpublished.
Canton interactive submission rejects mixed external and internal actAs on one write.
Production-shaped HA across local, stage, and production environments.
Cognito credentials stay in the backend. The SDK never holds them; the backend mints the JWT.

Infrastructure

Canton participant topology and DAR deployment across local, stage, and production-shaped HA. Signing path on AWS Nitro enclaves with per-shard KMS keys, DynamoDB for hot shard metadata, and S3 for cold shard storage. Callers authenticate to the signing service with identity-scoped JWTs (Cognito M2M); the SDK never holds Cognito credentials — the backend mints the token, the service verifies it against the identity-provider JWKS. Environment config, TLS, and JWT auth are part of the same delivery, not a later ops handoff.

Security model

Device keys wrapped under WebAuthn PRF; recovery key sealed under a client-held secret.
2-of-3 threshold for external parties. The enclave co-signer never ships to the browser.
KMS decrypt requires Nitro attestation. The parent process does not carry shard decrypt keys over vsock.
Identity-scoped JWTs for the signing service. Cognito credentials stay in the backend, not in the SDK.
Interactive submission for every external-party authorization.

Canton

External-party authorization and interactive submission. Participant SDK for party management, RWA writes, and per-leg Canton submission. Participant configuration, DAR deployment, and environment topology across local, stage, and production-shaped HA.

Outcome

Internal RWA issuance and transfer on Canton — mint, transfer, enrollment, and the signing path. Not a public product page, and not a claim about a live consumer demo.

Technology

Canton Network · Daml · TypeScript · AWS Nitro · KMS · Cognito · WebAuthn · DynamoDB · S3

Evidence / Availability

Professional engineering work at TEKHQS. Client and proprietary implementation details withheld.

Client/internal project — implementation details are intentionally limited.

← All engineering work