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.

For clarity, transaction refusal is not depicted in the above diagram. The flow would be the same but with a sign_nack message.

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. 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.

For clarity, transaction refusal is not depicted in the above diagram. The flow would be the same but with a sign_nack message.

Note: The default maximum delay to approve a transaction request is 60 seconds. The HAS will discard any pending request with a longer timeout.