Skip to main content

High-level Signing Process

The basic steps of preparing and signing a transaction using an external party are as follows:
  1. Creating a command - You start by simply creating a command.
  2. Preparing the transaction - You send the command to the blockchain RPC, offered by your node, to prepare the transaction.
  3. Validating the transaction - You inspect the transaction and decide whether to sign it.
  4. Signing the transaction - Once validated, you sign the transaction hash using your private key (typically with ECDSA/EdDSA).
  5. Submitting the transaction - You submit the signed transaction to be executed.
  6. Observing the transaction - You observe the blockchain until the transaction is committed.
In the examples below, the SDK examples use the Ping app which comes pre-installed with the validator and the cURL examples show the underlying HTTP requests using Canton Coin following a token standard transfer.

How do I quickly perform a transfer between two parties?

The below performs a two-step transfer between Alice and Bob and expose their holdings:

Creating a Command

Commands are the intents of an user on the validator, there are two kinds of commands: CreateCommand and ExerciseCommand. The CreateCommand is used to create a new implementation of a template with the given arguments and can result in one or more new contracts being created. The ExerciseCommand takes an existing contract and exercises a choice on it, which also can result in new contracts being created. In the Canton Network, it is often necessary to need to include input data when creating commands which needs to be read from the ledger. For example, which UTXOs to include in a transfer. This is private data which you read from your own node. It’s also often necessary to include contextual information in a transfer. For example, information about a particular asset which you don’t get from your own node - you get from an API provided by the asset issuer. See here for more information. The general process for forming a transaction is:
  1. Call your own node’s RPC to get the current ledger end (think “latest block”)
  2. Call your own node’s RPC to get relevant private data at ledger end (e.g. wallet’s holdings)
  3. Call app/token specific APIs to get context information (e.g. mining round contracts)
  4. Assemble the data into the full command using the OpenAPI/JSON or gRPC schemas.
In the examples below, the SDK example uses the Token Standards inside the a validator to create a simple transfer command. The transfer command is sent to a recipient party who can then exercise accept or reject on the created contract (thereby archiving it). In the cURL example, we show the steps above gaining information from a validator and context information from the Canton Coin scan API. The Wallet SDK allow us to build such a command easily:

UTXO management and locked funds

The default script for creating a transfer above uses automated utxo selection, the automatic being to simply select all utxo’s. In a more professional way, you would want to carefully pick which utxo’s you would like to use as input for your transfers, for more information on that, see the next section UTXO Selection and Management. Alongside, you might also want to define a custom expiration time for when the transaction should automatically expire.
if we call sdk.token.utxos.list({partyId}) or sdk.token.utxos.list({partyId, includeLocked: false}) then it will show 1 utxo of 50 (then one we excluded). This defaults to filtering out the locked utxos. if we call sdk.token.utxos.list({partyId, includeLocked: true}) then it will show all 3 utxos (100 and 25 both will have a lock).

UTXO Selection and Management

If you opt to choose your own UTXOs, it’s advised that you read the other documentation sections on Holding UTXO Management and UTXO Model and Dust Expiry

Preparing the Transaction

Now that we have a command we need to prepare the transaction by calling a node’s RPC API which will return an unsigned transaction. It must be a validator which hosts the party initiating the transaction as private information is needed to construct the transaction. This is unlike other chains where you construct the transaction fully offline using an SDK. A transaction is a collection of commands that are atomic, meaning that either all commands succeed or none of them do. Note: contractId’s are pinned as part of prepare step, the execution of the transfer will only go succeed if the contractId’s haven’t been archived between preparation and execution steps. To prepare a transaction we need to send the commands to the ledger.
The return type is an unsigned transaction if the combination of the commands are possible, otherwise an error is returned. The transaction can then be visualised and signed by the party.

Validating the Transaction

The result from the prepare step is an encoded protobuf message and easily decoded and inspected to go through a policy engine, for example. The transaction is returned alongside with the hash that needs to be signed. If the validator is not controlled by you, then it might be a good idea to validate that the transaction is what you expect it to be. You can use the Wallet SDK to visualize the transaction as described in the Visualizing a transaction section. On top of visualizing the transaction, it’s also important to compute the transaction hash yourself and confirm that it matches the hash of the transaction provided by the validator from the prepare step. The hash can be computed using the Wallet SDK:
You can then compare the hash with the transaction.preparedTransactionHash to ensure they match.

Visualizing a Transaction

The Wallet SDK uses a transaction parsing transform a fully fledged transaction tree into human recognizable transaction view. The full code for the transaction parsing can be found at parser typescript class. The Wallet SDK uses this parser to transform all transaction tree interacted with into PrettyTransactions. for instance on the getTransactionById or listHoldingTransactions (Detailed here). The Transactions will have format:
A single transaction can contain multiple events (deposits and withdrawals are considered events). In order to figure out the on chain transaction it is required to iterate over all the events. The events have the format:
below you can have a look at different event types and how to potentially visualize the transaction for a client
Here is an example on how a “tap” event looks like (Performing tap):
The tap gives a nice and simple view some key values to look at. Using the label we can quickly gage what is happening:
For a “tap” event we don’t have any locked holding changes, however we do have an unlocked create event:

Signing the Transaction

Once the transaction is validated, the hash retrieved from the prepare step can be signed using the private key of the party. Below shows an example in the Wallet SDK and using cURL commands:

Sign a transaction in an offline environment

The SDK exposes functionality that can be used in an offline environment to sign and validate transactions the below script shows an entire interaction between Alice and Bob with signing happening in an offline environment and online environment that performs the prepare and submit.

Submitting the Transaction

Once the transaction is signed, it can be executed on the validator. You can observe completions by seeing the committed transactions. If they don’t appear on your ledger, you are guaranteed some response, and you can keep retrying; signed transactions are idempotent. Finality usually takes 3-10s.

Observing the Transaction

The execute method in the ledger`` namespace will execute the submission and wait for a response. THs returns an \updateIdandcompletionOffset`. Additionally, you can continuously monitor holdings changes using token standard history parser.