# Transactions

## Broadcasting transactions

![](https://1669603073-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFAr86K7oT03KsmxlrwVj%2Fuploads%2FKXjNHJIJSrQ9Ekg7Mh5R%2Fimage.png?alt=media\&token=6db25221-f05c-4d64-b824-ce4b57cc3d37)

1. the **App** sends a `sign_req` command with an encrypted payload to the **HAS**.
2. the **HAS** provides the **App** with a request identifier (`uuid`) and its expiration time (`sign_req_expire`) in a `sign_wait` message.
3. \[Optional] the **App** shows information about the pending request to the user. It may also ask them to (re)start their **PKSA** to approve the transaction within the allowed delay.\
   **Note:** the PKSA can be started before or after the transaction request is issued. It doesn't matter.
4. the **HAS** then forwards the `sign_req` command to the **PKSA**
5. the **PKSA** checks if it can decrypt the payload and prompts the **User** to approve or reject the transaction
6. the user approves or refuses the transaction.
7. If the **User** approves the transaction, the **PKSA** signs it and broadcasts it to the blockchain.
8. If the transaction broadcast is successful, the **PKSA** sends a `sign_ack` to the **HAS** with the blockchain transaction ID (`txID`)
9. the **HAS** forwards the `sign_ack` message with the blockchain transaction ID (`txID`) to the **App**.

{% hint style="info" %}
*For clarity, transaction refusal is not depicted in the above diagram.* The flow would be the same but with a `sign_nack` message.
{% endhint %}

## Signing Transactions <a href="#h3signingtransactions" id="h3signingtransactions"></a>

An **APP** may want to manage the sending of the transaction to the blockchain itself. In this case, it will ask **PKSA** to only sign the transaction without broadcasting it.

Here is the diagram describing the process:

![](https://images.hive.blog/0x0/https://i.imgur.com/la4XKuj.png)

1. the **App** sends a `sign_req` command with an encrypted payload to the **HAS**.
2. the **HAS** provides the **App** with a request identifier (`uuid`) and its expiration time (`sign_req_expire`) in a `sign_wait` message.
3. \[Optional] the **App** shows information about the pending request to the user. It may also ask them to (re)start their **PKSA** to approve the transaction within the allowed delay.\
   **Note:** the PKSA can be started before or after the transaction request is issued. It doesn't matter.
4. the **HAS** then forwards the `sign_req` command to the **PKSA**
5. the **PKSA** checks if it can decrypt the payload and  prompts the **User** to approve or reject the transaction
6. the **User** approves (or rejects) the transaction.\
   \&#xNAN;***Note:** For clarity, transaction refusal is not depicted in the above diagram.* The flow would be the same but with a `sign_nack` message.
7. the **PKSA** signs the transaction the **PKSA** sends a `sign_ack` to the **HAS** with the `signed_transaction`
8. the **HAS** sends a `sign_ack` command to the **App** with the `signed_transaction`.
9. It's now up to the **App** to broadcast the signed transaction to the blockchain.

{% hint style="info" %}
*For clarity, transaction refusal is not depicted in the above diagram.* The flow would be the same but with a `sign_nack` message.
{% endhint %}

{% hint style="danger" %}
**Note:** The default **maximum delay** to approve a transaction request is **60 seconds.** The **HAS** will discard any pending request with a longer timeout.
{% endhint %}