Requires readAs scope for the submitting party when LAPI User authorization is enabled
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
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
Individual elements of this atomic command. Must be non-empty. Limitation: Only single command transaction are currently supported by the API. The field is marked as repeated in preparation for future support of multiple commands.
Required: must be non-empty
A command can either create a new contract or exercise a choice on an existing contract.
Set of parties on whose behalf the command should be executed, if submitted.
If ledger API authorization is enabled, then the authorization metadata must authorize the sender of the request
to read (not act) on behalf of each of the given parties. This is because this RPC merely prepares a transaction
and does not execute it. Therefore read authorization is sufficient even for actAs parties.
Note: This may change, and more specific authorization scope may be introduced in the future.
Each element must be a valid PartyIdString (as described in value.proto).
Required: must be non-empty
Uniquely identifies the participant user that prepares the transaction.
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
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 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
Additional contracts used to resolve contract & contract key lookups.
Optional: can be empty
Must be a valid synchronizer id If not set, a suitable synchronizer that this node is connected to will be chosen
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
When true, the response will contain additional details on how the transaction was encoded and hashed This can be useful for troubleshooting of hash mismatches. Should only be used for debugging. Defaults to false
Optional
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
Maximum timestamp at which the transaction can be recorded onto the ledger via the synchronizer specified in the PrepareSubmissionResponse.
If submitted after it will be rejected even if otherwise valid, in which case it needs to be prepared and signed again
with a new valid max_record_time.
Use this to limit the time-to-life of a prepared transaction,
which is useful to know when it can definitely not be accepted
anymore and resorting to preparing another transaction for the same
intent is safe again.
Optional
Hints to improve the accuracy of traffic cost estimation. The estimation logic assumes that this node will be used for the execution of the transaction If another node is used instead, the estimation may be less precise. Request amplification is not accounted for in the estimation: each amplified request will result in the cost of the confirmation request to be charged additionally.
Traffic cost estimation is enabled by default if this field is not set To turn off cost estimation, set the CostEstimationHints#disabled field to true
Optional
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
The hashing scheme version to be used when building the hash. Defaults to HASHING_SCHEME_VERSION_V2.
Optional
HASHING_SCHEME_VERSION_UNSPECIFIED, HASHING_SCHEME_VERSION_V2, HASHING_SCHEME_VERSION_V3 [docs-entry-end: HashingSchemeVersion]
The interpreted transaction, it represents the ledger changes necessary to execute the commands specified in the request. Clients MUST display the content of the transaction to the user for them to validate before signing the hash if the preparing participant is not trusted.
Required
Hash of the transaction, this is what needs to be signed by the party to authorize the transaction. Only provided for convenience, clients MUST recompute the hash from the raw transaction if the preparing participant is not trusted. May be removed in future versions
Required: must be non-empty
The hashing scheme version used when building the hash
Required
HASHING_SCHEME_VERSION_UNSPECIFIED, HASHING_SCHEME_VERSION_V2, HASHING_SCHEME_VERSION_V3 Optional additional details on how the transaction was encoded and hashed. Only set if verbose_hashing = true in the request Note that there are no guarantees on the stability of the format or content of this field. Its content should NOT be parsed and should only be used for troubleshooting purposes.
Optional
Traffic cost estimation of the prepared transaction
Optional