Transaction request

Guide

After explaining the sign in request concept, it is time to introduce transaction requests.

If you don't know what sign in request are or you haven't read the docs, we recommend to learn how they work in the previous section.

What is a transaction request?

To answer this question, first we need to clarify what a transaction is, which corresponds to a transaction made in the CKB blockchain. Therefore, a transaction request is the dApp's way of asking a CKBull Wallet user to sign a transaction.

The logic is quite simple. In order to create a transaction, you need someone responsible for signing it. So, you cannot generate a transaction request without a user who wants to sign it.

The responsible party to bring this information is a signed sign in request, which will contain the user's metadata to later provide the transaction request related to that user.

Here is the workflow of a transaction request generated by the dApp with a signed sign in request.

When an identified user triggers an event in your frontend app, a transaction request will be generated via API.

The user will then sign the transaction request received in CKBull Wallet, broadcast it to the blockchain, and return the transaction hash to the API for subsequent use by the dApp. To know how to check the status of a transaction request check the API docs.

Transaction request life cycle

As with sign in requests, transaction requests also have a certain life cycle depending on the actions taken by the user.

When a transaction request is generated, it gets a pending status that will not change unless it is signed, rejected or expired.

Once the dApp has generated a transaction request, the CKBull Wallet user will receive the request in the application, where he or she can sign or reject it. The transaction request will display information about the dApp, such as its name, description and logo, along with the transaction summary.

For transaction requests, no QR code must be generated to receive them. Once created, the user will be able to view them in the Activity > Pending tab.

PreviousSign in request NextIntroduction

Last updated 1 year ago

How do sign-in requests and transaction requests relate to each other?

The logic is quite simple. In order to create a transaction, you need someone responsible for signing it. So, you cannot generate a transaction request without a user who wants to sign it.

The responsible party to bring this information is a signed sign in request, which will contain the user's metadata to later provide the transaction request related to that user.

Here is the workflow of a transaction request generated by the dApp with a signed sign in request.

When an identified user triggers an event in your frontend app, a transaction request will be generated via API.

Transaction request life cycle

As with sign in requests, transaction requests also have a certain life cycle depending on the actions taken by the user.

When a transaction request is generated, it gets a pending status that will not change unless it is signed, rejected or expired.

For transaction requests, no QR code must be generated to receive them. Once created, the user will be able to view them in the Activity > Pending tab.