POST /v2/interactive-submission/prepare
Requires readAs scope for the submitting party when LAPI User authorization is enabled
Request body
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
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 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
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
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
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
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
Response
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
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
Changes
No recorded changes to this endpoint across all 1 revision of this API.