Submits a single composite command and waits for its result. Propagates the gRPC error of failed submissions including Daml interpretation errors.
Documentation Index
Fetch the complete documentation index at: https://docs.canton.network/llms.txt
Use this file to discover all available pages before exploring further.
Ledger API standard JWT token
A composite command that groups multiple commands together.
Individual elements of this atomic command. Must be non-empty.
Required: must be non-empty
A command can either create a new contract or exercise a choice on an existing contract.
Uniquely identifies the command.
The triple (user_id, act_as, command_id) constitutes the change ID for the intended ledger change,
where act_as is interpreted as a set of party names.
The change ID can be used for matching the intended ledger changes with all their completions.
Must be a valid LedgerString (as described in value.proto).
Required
Set of parties on whose behalf the command should be executed.
If ledger API authorization is enabled, then the authorization metadata must authorize the sender of the request
to act on behalf of each of the given parties.
Each element must be a valid PartyIdString (as described in value.proto).
Required: must be non-empty
Uniquely identifies the participant user that issued the command.
Must be a valid UserIdString (as described in value.proto).
Required unless authentication is used with a user token.
In that case, the token's user-id will be used for the request's user_id.
Optional
Set of parties on whose behalf (in addition to all parties listed in act_as) contracts can be retrieved.
This affects Daml operations such as fetch, fetchByKey, lookupByKey, exercise, and exerciseByKey.
Note: A participant node of a Daml network can host multiple parties. Each contract present on the participant
node is only visible to a subset of these parties. A command can only use contracts that are visible to at least
one of the parties in act_as or read_as. This visibility check is independent from the Daml authorization
rules for fetch operations.
If ledger API authorization is enabled, then the authorization metadata must authorize the sender of the request
to read contract data on behalf of each of the given parties.
Optional: can be empty
Identifier of the on-ledger workflow that this command is a part of.
Must be a valid LedgerString (as described in value.proto).
Optional
Specifies the deduplication period for the change ID. If omitted, the participant will assume the configured maximum deduplication time.
Optional
Lower bound for the ledger time assigned to the resulting transaction. Note: The ledger time of a transaction is assigned as part of command interpretation. Use this property if you expect that command interpretation will take a considerate amount of time, such that by the time the resulting transaction is sequenced, its assigned ledger time is not valid anymore. Must not be set at the same time as min_ledger_time_rel.
Optional
Same as min_ledger_time_abs, but specified as a duration, starting from the time the command is received by the server. Must not be set at the same time as min_ledger_time_abs.
Optional
A unique identifier to distinguish completions for different submissions with the same change ID.
Typically a random UUID. Applications are expected to use a different UUID for each retry of a submission
with the same change ID.
Must be a valid LedgerString (as described in value.proto).
If omitted, the participant or the committer may set a value of their choice.
Optional
Additional contracts used to resolve contract & contract key lookups.
Optional: can be empty
Must be a valid synchronizer id
Optional
The package-id selection preference of the client for resolving package names and interface instances in command submission and interpretation
Optional: can be empty
Fetches the contract keys into the caches to speed up the command processing. Should only contain contract keys that are expected to be resolved during interpretation of the commands. Keys of disclosed contracts do not need prefetching.
Optional: can be empty
The maximum number of passes for the Topology-Aware Package Selection (TAPS). Higher values can increase the chance of successful package selection for routing of interpreted transactions. If unset, this defaults to the value defined in the participant configuration. The provided value must not exceed the limit specified in the participant configuration.
Optional