Skip to content
Tenzro
Documentation menu
Execution and interoperability

DAML

DAML smart contracts on Network 1: multi-party workflows with per-party privacy, a TNZO holding view and commands from the CLI or SDK.

DAML is the third runtime on Tenzro Network 1, next to the EVM and the SVM. It is built for agreements between several parties, where each party should see only the parts of a workflow it takes part in. DAML contracts run on Canton participants (Canton 3.5 and later, through the JSON Ledger API v2) that node operators connect to the network; see Canton for how access, parties and tenancy work.

When to use DAML

Use DAML when a workflow has several independent parties with different rights and different views, and the rules of who may do what are the point of the contract. Machine Economy examples:

  • Compute contracts. A buyer, a GPU provider and an auditor agree on a job. The buyer sees delivery and price, the provider sees the job spec and payment, the auditor sees the attestation and SLA result.
  • Data licensing. A data owner grants a model developer a time-bound licence; a separate party certifies the dataset. Each sees only its own obligations.
  • Multi-counterparty escrow. Funds release when every named party has confirmed its step.
  • Supply chains for hardware. Provenance records for machines and accelerators that several operators hand on to one another.

If a workflow has one owner or needs public state, the EVM is usually the simpler choice.

Privacy model

DAML contracts declare signatories and observers. A party sees a contract only if it is a signatory or observer of it, and sees a transaction only for the sub-transactions it is entitled to. Tenzro inherits this model as-is from Canton: shared facts are agreed by the parties that share them, and nobody else learns them.

Templates and commands

A DAML application is a set of templates packaged as a DAR. Two commands act on them:

  • create instantiates a template with arguments.
  • exercise runs a choice on an existing contract, which may archive it and create new ones.

Create a contract:

bash
tenzro canton submit \
  --command-type create \
  --template ComputeJob:Job \
  --create-arguments '{"buyer":"Buyer::1220ab...","provider":"Provider::1220cd...","gpuHours":"12.0","priceTnzo":"40.0"}' \
  --api-key "$TENZRO_API_KEY" \
  --rpc https://rpc.tenzro.xyz

Exercise a choice on it:

bash
tenzro canton submit \
  --command-type exercise \
  --template ComputeJob:Job \
  --contract-id <CONTRACT_ID> \
  --choice ConfirmDelivery \
  --choice-argument '{"attestationHash":"0x9f2c..."}' \
  --api-key "$TENZRO_API_KEY" \
  --rpc https://rpc.tenzro.xyz

The JSON-RPC methods behind these are tenzro_submitDamlCommand and tenzro_listDamlContracts. Commands run as the party bound to your API key; pass --act-as to act as another party your key is authorised for.

List active contracts for your party:

bash
tenzro canton contracts --api-key "$TENZRO_API_KEY" --rpc https://rpc.tenzro.xyz

Upload your own templates with tenzro canton upload-dar, then list installed packages with tenzro canton packages.

TNZO in DAML

TNZO appears in DAML as a CIP-56 holding. It is a view of the account's native balance, the same balance the EVM sees as wTNZO and the SVM as an SPL mint. A DAML workflow that pays in TNZO therefore moves the native balance itself; there is no wrapped copy to redeem. CIP-56 transfers are two-step: the sender creates a transfer offer and the receiver accepts or rejects it. tenzro_getTokenBalance returns the DAML view alongside the others.

Workflows that span runtimes

A workflow can start on one runtime and settle on another. For example, a buyer agent opens a job on the EVM and pays through a settlement escrow, while the multi-party approvals run as a DAML contract visible only to buyer, provider and auditor. Operators can anchor Tenzro workflows and their obligations into a Canton synchronizer so the parties there see a record of each step.

Access

DAML runs on Canton participants that operators run and connect. Every DAML call needs an API key with the canton scope, issued by the operator of the node you use, sent as the X-Tenzro-Api-Key header or --api-key. Keys bind to your own Canton party; see Canton for tenancy, network selection and rate tiers.