Canton RWA

Problem

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.

Context

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

Role

Architecture owner and engineering lead for the RWA stack.

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.

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. Environment config, TLS, and JWT auth are part of the same delivery, not a later ops handoff.

Engineering

• Architect the RWA contract flows: instrument creation, receiver enrollment, mint, and transfer.
• Design and implement the remote signing service (enclave keygen/sign, sharded KMS custody).
• Design the wallet SDK split so the host never sees secret key material, ciphertext, or the hash-to-sign.
• Build the participant SDK: external-party onboarding, interactive submission, and RWA write routing.
• Own Canton node config, DAR upload, and environment topology.

Decisions

• Keep the wallet origin isolated from the host app. Secrets do not cross that boundary.
• Co-sign inside an attested enclave, not in the browser and not in an unattested backend.
• When Canton rejects mixed external and internal actAs on one interactive submission, decompose the flow into single-authorizer legs.
• Do not publish the client name, a public demo, or signing-ceremony internals.

Security

• 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.
• Interactive submission for every external-party authorization.

Result

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.

Stack

Canton Network · Daml · TypeScript · AWS Nitro · KMS · WebAuthn

Evidence

• TEKHQS engineering, 2025. Client name withheld.