Page Comparison

• The user has access to his/her account in the Iroha network
• The user's account has permissions to provide grantable permissions

Use case flow

1. The user prepares the instruction to grant one or more permissions to another account
2. The user sends the instruction transaction with the prepared instruction to the Iroha peer (<<includes>> FR0100)
3. The Iroha peer returns the result of the instruction to the user

• The permission was granted to another account

• The user has permissions to execute requested instruction

Use case flow

1. The user prepares the instruction parameters according to his/her needs
2. The user sends the transaction with the instruction into instruction into the Iroha peer (<<includes>> FR0100)
3. The user uses the same connection for obtaining the status of the instruction finalization
4. The Iroha peer sends updates about the instruction finalization status to the user
5. The user receives the "successfully finalized" status about the instruction

• The instruction is accepted and finalized in the block-storage
• The user did not spend additional resources for redundant network connections and requests

• At step 4 if the instruction cannot pass the validation, the user would not get the "successfully finalized" status; instead, he/she will get the "invalid instruction" status.
• At step 4 if the network is in "bad" condition, the user would get the "successfully finalized" status eventually, when the network will return in a "good" state.

• The user has permissions to change the list of signatories to the required account
• The user has key pair for adding/deleting a signatory to/from the selected account

Use case flow

1. The user prepares the instruction of adding/deleting signatories for sending
2. The user sends the transaction with the instruction to instruction to the Iroha peer (<<include>> FR0100)
3. The user receives the response from the Iroha peer

• List of signatories for the selected account was changed correspondingly

• On step 2, if the signatory with the current key pair exists in the list of signatories in the target account, the Iroha peer will return "already added" error status; use case flow stops.

• There is a multi-signature account in the Iroha network
• The user has access to the one or many key pairs for the multi-signature account
• The current amount of signatures to the multi-signature transaction is lower than a current quorum value

Use case flow

• Amount of signatures in the signed instruction increased by 1 signature
• Signed instruction disappears from the list of pending instructions for the current user's account

• On step 2 the user can select more than one instructiontransactions, all of them can be sent on step 4 as a separate requests
• On step 3 the user can sign the instruction transaction by more than one signature, and all of them can be sent as a single request per single instruction transaction on step 4

• The user has permissions to change the conditions for the target multi-signature account

Use case flow

1. The user requests the list of currently configured conditions for the target multi-signature account
2. The user prepared the instruction with the list of conditions to be added/removed
3. The user sends the prepared instruction to the transaction with the instruction to the Iroha peer (<<include>> FR0100)
4. The Iroha peer sends the response to the user

• The list of conditions for the target multi-signature account was changed correspondingly

• The user has permissions to request the list of pending instructionstransactions

Use case flow

• The user have the list of currently pending instructions

• On step 3, if there are no currently pending instructiontransactions, the Iroha peer will return "empty response" status