> For the complete documentation index, see [llms.txt](https://docs.hiveauth.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hiveauth.com/developer-documentation/protocol-description/transactions.md).
# Transactions
## Broadcasting transactions
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
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:
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 %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.hiveauth.com/developer-documentation/protocol-description/transactions.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.