Workflow

This section will go through the main workflow process to execute a transaction. In just a few steps, you will be able to understand how the Ternoa SDK works.

API initialization

It's optional, but it's good practice to initialize the API as soon as possible. If this call is omitted, the first SDK call will return an exception. The default chain endpoint is wss://alphanet.ternoa.com. It can be modified by passing a new endpoint as the first argument to the initializeApi() function.

Find more information & examples here about how to connect to the Ternoa chain and access specific or custom data.

How to execute a transaction​?

Now that we know how to init our SDK API, let's get into a feature example. The Ternoa-js provides the most friendly way to build on the chain and execute transactions.

To know what transaction to do with the Ternoa SDK, please look at our primitives/features list or the full events list.

It is expected three steps to execute every transaction (also called "tx" or "extrinsic").

1. Create an unsigned transaction

2. Sign the transaction hash returned when creating the unsigned transaction

3. Submit the transaction to the Ternoa chain.

To build applications within the Ternoa SDK, we provide two approaches for each primitive/extrinsic:

• An automated & user-friendly single-ligne function manages this three-step process seamlessly. It is the recommended method for executing transactions when you can access the transaction signer's account seed. With this approach, you should be able to generate a keyring from your seed. To prevent public exposure and theft, the seed must be kept in an environment variable. The following helper creates an NFT directly on the chain. It returns a blockchain event specifying the information registered on the chain.

  createNft(Offchain data, royalty, collectionId, soulbound, keyring, WaitUntil.BlockInclusion)

• A customizable function that provides an unsigned transaction hash from the extrinsic execution. It is the recommended method for executing transactions when you need a user to sign the transaction. According to your needs and the platform you are building, you will ask the user to sign the transaction with a wallet or an extension like the Polkadot extension. Instead of signing the transaction with a keyring as you do in the first approach, you will provide an injector that connects to your wallet or extension. The following helper creates an unsigned NFT. It returns a blockchain hash you will ask the user to sign to confirm the transaction and submit to the chain.

  createNftTx(Offchain data, royalty, collection id, souldbound)

When unsure about which function to select, consider whether you have access to the seed for signing the transaction. Looking at the SDK code repository will clarify this distinction. Each extrinsic function in the repository has a variant ending with "Tx". For instance, createSecretNftTx() versus createSecretNft(), burnNft() versus burnNftTx(), and so on.

Opting for the unsigned version, denoted by the Tx() suffix, demands to handle more pieces of code, but unlocks additional flexibility and functionalities like batching transactions. This is particularly beneficial for creating and managing a large volume of NFTs without the need to sign and send each one separately. You can find more details about transactions, signing, keyring, injectors and submitting a tx, in the Build section of this documentation.