Page Comparison

• List of preconditions which must be satisfied before the use case can be applied
• Each precondition should be defined as the point in the list

Use case flow

1. The enumerated list of actions, which describes the interaction between actors step by step
2. Each step should involve a single actor as an object of the action
3. Each step can involve one or more actors as a subject of the action
4. Each use case can involve other use cases as dependencies by include or extend relationships

• List of post-conditions, one or more results of successfully finished use case

• List of alternative flows that can happen with the use case.
• Each entry should have the link to the step of the main use case flow when the alternative can occur
  • If needed, each entry can contain sub-entries
• Each entry should describe the consequences of the alternative flow

• List of exceptions that can happen during the use case flow, which can prevent it to be successfully finished
• Each entry should have the link to the step of the main use case flow when the exception can occur
  • If needed, each entry can contain sub-entries
• Each entry should describe the consequences of the exception

• The user has an account in the Iroha network
• The user has prepared the transaction for sending; transactions can consist of several instructions
• The user has permissions to execute all instruction included in the transaction
• The Iroha network is working in normal condition

Use case flow

1. The user sends the transaction to the Iroha peer through the API
2. The Iroha peer receives the transaction and validates its contents
3. The Iroha peer checks that the user's account have enough permissions to run all instructions included in the transaction
4. The Iroha peer executes the transaction by applying it to the current block
5. The Iroha peer returns the result of the operation to the user

• The transaction is successfully executed and applied to the network state

• On step 4, if the current user's account is multi-signature, the result of the transaction will be applied to the block-store only when the number of signatures will reach the current quorum value. In other cases, the Iroha peer will return "pending" status as a response on step 5.

• On step 2, one of the instructions has invalid structure, the Iroha peer returns an error message with description to the user and stops the flow
• On step 3, if the user's account does not have required permissions to execute one of the instructions, the Iroha peer returns information about that error and stops the flow
• On step 3, in case of a multi-signature transaction, if the instruction signed using the key pair, which was already used for signing that instruction, the Iroha peer will return "already signed" error status and stop the flow

• The administrator has configured environment for running Iroha executable
• The administrator has prepared the information for the network configuration (peer addresses and ports, consensus parameters, etc.)
• The administrator generated key pairs for all accounts, which should be created at the start of the network, including root administrator account if it is required by business requirements
• The administrator has prepared the genesis block configuration according to the network configuration and business requirements

Use case flow

1. The administrator launches the command to run Iroha peer and providing the path to the genesis block description
2. The Iroha peer read and validates the genesis block configuration
3. The Iroha peer starts the Iroha network according to the configuration in the genesis block
4. The Iroha peer provides "successfully started" report to the administrator

• The Iroha network is running
• The administrator has access to the root account of the network

N/A

• At step 2, in case of the invalid genesis block, the Iroha peer shows corresponding error messages to the administrator and halts the network creation process

• The user has permission to create other usersIroha network is running
• The administrator has access to the account with permissions of adding peers to the network

Use case flow

1. The user prepares information about the account that should be created, which includes name, domain, the public key and permissions list
2. The user prepares instruction to send to the Iroha network according to the prepared information
3. The user sends the transaction with the instruction to the administrator configures and starts the new peer
4. The administrator prepares the transaction with instruction to add the new peer
5. The administrator sends the prepared transaction to the existing Iroha peer (<<include>> FR0100)
6. Tha The existing Iroha peer returns the result of the instruction execution to the user

1. initiates connection with the new Iroha peer
2. The new Iroha peer synchronizes the block-storage with existing Iroha peers
3. The new Iroha peer start functioning as fully functional peer in the current Iroha network

• The new peer is added into the network

• On step 35, if the account with the provided name or public key already exists in the network, the Iroha peer will return "already exists" error status; user case flow will stop.synchronization cannot be finished for some reason, the new Iroha peer cannot join the network; use case stops

Use case flow

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

• The administrator has access to the account with permission of removing peers form the network

Use case flow

1. The useradministrator prepares the instruction to grant one or more permissions to another accountThe user remove the peer from the Iroha network
2. The administrator sends the transaction with the prepared instruction to the Iroha peer (<<includes>> FR0100)
3. The Iroha peer returns confirms the result execution of the instruction to the user

• The target peer is removed from the current Iroha network and all processes in consensus continues without it

• The Iroha network is just started

Use case flow

• The Iroha network is configured according to the requirements

• Sora 2 project

• The user administrator has access to account with permissions to execute requested change the network configuration by sending the corresponding instruction

Use case flow

• 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 instruction is accepted and finalized in the block-storage
• The user did not spend additional resources for redundant network connections and requests

• The network configuration is changed correspondingly

N/A

• The administrator has access to the maintenance endpoint of the target Iroha peer

Use case flow

Use case flow

1. The administrator connects to the maintenance endpoint of the target Iroha peer
2. The administrator performs requests to change required parameters of the target Iroha peer
3. The Iroha peer returns result of change operation to the administrator

• The configuration of the target Iroha peer was changed

• On step 3, if the value of changed configuration parameter is out of the limit, the Iroha peer will return "wrong parameter value" error status to the administrator; use case flow stops.

• The user has an account in the Iroha network
• The user has prepared the transaction for sending; transactions can consist of several instructions
• The user has permissions to execute all instruction included in the transaction
• The Iroha network is working in normal condition

Use case flow

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

• List of signatories for the selected account was changed correspondingly

1. transaction and validates its contents
2. The Iroha peer checks that the user's account have enough permissions to run all instructions included in the transaction
3. The Iroha peer executes the transaction by applying it to the current block
4. The Iroha peer returns the result of the operation to the user

• The transaction is successfully executed and applied to the network state

• On step 4, if the current user's account is multi-signature, the result of the transaction will be applied to the block-store only when the number of signatures will reach the current quorum value. In other cases, the Iroha peer will return "already addedpending" 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 transactions, all of them can be sent on step 4 as a separate requests
• On step 2 ideology of Iroha1 when creation of same transaction which already exists will result in addition of signature to this transation in pending state. This reduces need to perform queries and search for transactions needed to be signed. For bridge functionality that is a prefered flow, because all bridge instances will already know about how to form a transaction from the bridge consensus. And only malicious bridge peers will send wrongly formed transaction what is expected. Iurii Vinogradov
• On step 3 the user can sign the transaction by more than one signature, and all of them can be sent as a single request per single transaction on step 4. In bridge implementation scenario is: 1. Selected bridge get all bridge instances signatures from the block and calls an Iroha2 ISI with the transfer information, attaching all bridge nodes signatures. It can be implemented as in Iroha1 by sending multple ISI calls in one transaction or batch, or it can be implemented as One ISI call with multiple signatures. Iurii Vinogradov

• status as a response on step 5.

• On step 2, one of the instructions has invalid structure, the Iroha peer returns an error message with description to the user and stops the flow
• On step 3, if the user's account does not have required permissions to execute one of the instructions, the Iroha peer returns information about that error and stops the flow
• On step 3, in case of a multi-signature transaction, if the instruction signed using the key pair, which was already used for signing that instruction, the Iroha peer will return "already signed" error status and stop the flow

• The user has permission to create accounts

Use case flow

1. The user prepares information about the account that should be created, which includes name, domain, the public key and permissions list
2. The user prepares instruction to send to the Iroha network according to the prepared information
3. The user sends the transaction with the instruction to the Iroha peer (<<include>> FR0100)
4. The Iroha peer returns the result of the instruction execution to the user

• The new account in the Iroha network is created

• On step 3, if the account with the provided name or public key already exists in the network, the Iroha peer will return "already exists" error status; user case flow will stop.

• The user has access to the Iroha account with permissions to change permissions of the target account

Use case flow

1. The user prepares information about set of permissions, which should be enabled or disabled for the target account
2. The user prepares instruction to send to the Iroha network according to the prepared information
3. The user sends the transaction with the instruction to the Iroha peer (<<include>> FR0100)
4. The Iroha peer returns the result of the instruction execution to the user

• The permissions of the target account was changed correspondingly

• On step 4, if the user disables the permission which is not enables on the target account, the Iroha peer return "Permission is not enabled" error status; use case flow stops
• On step 4, if the user enables the permission which is already enabled on the target account, the Iroha peer return "Permission already enabled" error status; use case flow stops

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

• On step 3, if the user does not have permission to grant permissions to other accounts, the Iroha peer will return "Not permitted" error status; use case flow stops

• The user has permissions to send complex instructions with DSL sequence inside
• The user has permissions to execute each instruction inside the list of DSL sequence

Use case flow

1. The user builds the DSL sequence for the complex instruction
2. The user prepares the complex instruction to send to the Iroha peer
3. The user sends the complex instruction to the Iroha peer (<<include>> FR0100)
4. The Iroha peer returns the results of complex instruction execution to the user

• The complex instruction was executed and applied to the Iroha network

• On step 4, of there is not enough permissions to execute whole DSL sequence, the Iroha peer will return "not enough permissions" error status; use case flow stops.

• 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 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 eventually 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 5, if there is some problem with instruction or Iroha network the "successfully finalized" may never be obtained; in that case, the behavior of client depends on the project business rules and particular requirements.

• 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 have permission to create new MST accounts

Use case flow

1. The user prepares information about new account, including list of signatories and quorum of signatures
2. The user creates new account in the Iroha network (<<include>> FR0101)
3. The user receives result of new account creation from the Iroha peer

• The new MST account with defined list of signatories and quorum is created

• On step 3, if amount of signatories in the list is lower, than quorum, the Iroha peer returns "Not enough signatories" error; use case flow stops

• The user have access to the account with permissions to control the target MST account

Use case flow

1. The user prepares the instruction with needed parameters for changing the quorum value
2. The user sends the transaction to the Iroha peer (<<include>> FR0100)
3. The Iroha peer returns the results of instruction execution

• The quorum for the target MST account was changed

• If the new quorum is higher than amount of signatories, the Iroha peer will return "Not enough signatories" error message; use case flow stops.

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

• 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 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 change the conditions (or some other, to discuss) for the target multi-signature account

Use case flow

1. The user prepared the instruction with the map of public keys and weight correspondence (e.g. key1 → 50, i.e. key2 → 25, key3 → 25)
   and the target quorum (e.g. 50 so that it is needed either to sign upcoming transactions of the user with either key1 or both key2 and key3)
2. The user sends the transaction with the instruction to the Iroha peer (<<include>> FR0100)
3. The Iroha peer sends the response to the user

• The list of signatories weights and target quorum for the target multi-signature account was changed correspondingly

• The user has access to account with permissions to change data payload related to the target account

Use case flow

1. The user prepares the key and value of the data payload for forming the corresponding instruction
2. The user sends the transaction with prepared instruction to the Iroha peer (<<include>> FR0100)
3. The Iroha peer returns results of instruction to the user

• The data payload associated with the target account was changed correspondingly

• On step 1, the user can define the previous value of the selected key, so the Iroha peer will compare that value with the current value saved in the block storage on step 2. If values will be different, the Iroha peer will return error status on step 3.
• On step 2, if there was no such key associated with the target account, the key will be created
• On step 2, if some value is already associated with the provided key, the value will be overwritten

• On step 2, if the size of payload data exceeds limit, the Iroha peer will return the "Too large data" error message; use case flow stops.

• The user has access to account with permissions to perform required instruction

Use case flow

1. The user prepares the instruction for the required operation and attached the payload to the instruction
2. The user sends the transaction with prepared instruction to the Iroha peer (<<include>> FR0100)
3. The Iroha peer returns results of instruction execution to the user

• The instruction with attached payload successfully executed and payload saved in the block storage

• On step 2, there should be an option to verify the payload before applying the instruction ("compare and set" operation); in case if the comparison fails, the instruction should not be applied.

• On step 2, if the size of payload data exceeds limit, the Iroha peer will return the "Too large data" error message; use case flow stops.

• The sender has access to the account in the Iroha network
• There is at least one non-fungible asset type in the Iroha network
• There are at least one token of non-fungible token type on the sender account

Use case flow

1. The sender requests list of currently available non-fungible assets on the personal account by sending query to the Iroha network (<<include>> FR02016)
2. The sender prepares the information about non-fungible assets which should be sent
   1. Information must include IDs of assets which need to be sent
3. The sender sends the transaction with "send" instruction to the Iroha network (<<include>> FR0100)
4. The Iroha network returns results of the transaction to the sender

• The sender sent non-fungible token(s) to the recipient

• On step 1, the user can configure filtering, so the Iroha peer will return the list of all assets which are correspond to the filters.

• Iroha 2 whitepaper
• Generic functionality of Iroha

• User has access to the account with permissions, which allows to get results of target query

Use case flow

• User receives the response with the requested data

• On step 2, if the query was formed not correctly (for example, because of problems with the client library) the Iroha peer returns error with result of validation, use case execution stops.
• On step 3, if the user's account does not have enough permissions, the Iroha peer returns error with corresponding status, use case execution stops.

• Iroha 2 white paper

• The user has access to the account with permissions of getting information about the target account

Use case flow

1. The user prepares query for requesting information about the target account
2. The user sends the query to the Iroha peer (<<include>> FR0200)
3. The user receives the request with the list of parameters of the target account
   1. It should include: account name, domain, permissions, quorum, list of signatories, associated key-value dictionary with payload

• The user received the information about the selected account

• Iroha 2 white paper

• The user has access to the account with permissions of checking list of permissions of the target account

Use case flow

1. The user prepares query for requesting a list of permissions for the target account
2. The user sends the query to the Iroha peer (<<include>> FR0200)
3. The user receives the request with the list of permissions for the target account

• The user received the list of permissions for the target account

• Sora 2 project

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

Use case flow

• The user has the list of currently pending instructions according to provided parameters

• On step 1, the user can request all pending transactions
• On step 1, the user can request pending transactions, which waits his/her signature only (by account ID or by providing public key from the target key pair)

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

• Bakong project
• Sora 2 project

• The user has permissions to request a list of conditions to the target multi-signature account

Use case flow

1. The user prepares query for requesting a list of currently configured conditions of signing for the target multi-signature account
2. The user sends the query to the Iroha peer (<<include>> FR0200)
3. The user receives the list of currently configured conditions of signing for the target multi-signature account

• The user received the list of conditions for the target account

• On step 3, if there are no currently configured conditions, the Iroha peer will return "empty response" status
• On step 3, if the account is not multi-signature, the Iroha peer will return "not applicable" status

• The user has permissions to request the block by its number

Use case flow

• The user receives the requested block from the block-store

• On step 3, if there are no block specified, the Iroha peer will return "error/no such block" response

• The user has permissions to request blocks (subscription, can be separate permission or from <<include>> FR0205)

Use case flow

• The user has got stable channel for continuous block obtaining, which can be used for getting all new blocks on the current peer until the connection will be interrupted

N/A

• The user has permissions to request the list of pending transactions (subscription, can be separate permission or from <<include>> FR0203)

Use case flow

• The user has got stable pending transactions perception channel and newly arriving pending transactions

• The user has permissions to get results of the target query

Use case flow

1. The user prepares request data for the target query
2. The user establishes permanent connection to the Iroha peer and sends the query
3. The Iroha peer confirms the connection and start sending updates on the query results until the user closes the connection
4. The user receives the results and performs continuous analysis of the payload

• The user has continuous results of query execution

• The user has permissions to get results of the target query

Use case flow

1. The user prepares request data for the target query
2. The user sends the query to the Iroha peer (<<include>> FR0200)
3. The Iroha peer returns response containing result of the query as well as the Merkle proof of its validity and relation to the current block-store.
4. The user receives the response and validates the correctness of the data by comparing hashes in Merkle proof and hashes of obtained data.

• The user has result of the query request with Merkle proof of its validity

Use case flow

<<extends>> FR0200, substitutes step 4:

1. The Iroha peer collects data from the block storage at the moment, requested in the query

• The user received the requested information about the information in block store on the provided date

• The user has permissions to perform the query
• The user has list of conditions which need to be used for filtering accounts

Use case flow

1. The user prepares the query and adds the filtering setup to the query body
2. The user sends query to the Iroha peer (<<include>> FR0200)
3. The Iroha peer returns result of the query execution to the user

• The user has the list of accounts which satisfies entered filter

• On step 1, the user can include the query to the DSL sequence as a part of the complex instruction

• On step 3, if the user does not have enough permissions, the Iroha peer returns "not enough permission" error status; the use case flow stops.

• The user has access to account with permissions to retrieve data payload related to the target account

Use case flow

1. The user prepares the target account identifier for forming the corresponding query
2. The user sends the transaction with prepared query to the Iroha peer (<<include>> FR0200)
3. The Iroha peer returns results of query to the user, which contains the list of keys, associated with the target account

• The user acquired list of keys of data payload associated with the target account

N/A

• On step 2, if there is no keys associated with the target account, the Iroha peer will return "No data" status message; use case flow stops.

• The user has permissions to perform the target query
• The user has list of conditions which need to be used for filtering transactions (optionally)

Use case flow

1. The user prepares the query for getting list of transactions and adds the filtering data to the query body
   1. Filtering may filter out incoming or outgoing transactions
   2. Filtering may filter out transactions by receiver and/or sender account ID
   3. Filtering may filter out transactions by time frame
2. The user sends query to the Iroha peer (<<include>> FR0200)
3. The Iroha peer returns result of the query execution to the user

• The user has the list of transactions which satisfies the predefined filter with pagination

• On step 1, the filtering data can be optional; in that case the Iroha peer will return list of all transactions without any filtering
• On step 1, the user can also include paging-related request into the query, in that case the Iroha peer will return the data correspondingly

• On step 3, if the user does not have enough permissions, the Iroha peer returns "not enough permission" error status; the use case flow stops.
• On step 3, if the user provided setup of filtering, which results in empty response, the Iroha peer will return "Empty response" status message; use case stops,
• On step 3, if the user provided incorrect pagination-related request part, the Iroha peer will return "Incorrect pagination request" error message; use case stops.

• The user has permissions to perform the target query of getting list of incoming transactions
• The user has list of conditions which need to be used for filtering transactions

Use case flow

1. The user prepares the query for getting list of incoming transactions and adds the filtering data to get only incoming transactions
2. The user sends query to the Iroha peer and subscribes on the results (<<include>> FR0208)
3. The Iroha peer continuously returns result of the query execution to the user
4. The user processes the incoming results of the query
5. Eventually, the user interrupts the subscription with the Iroha peer, which stops the flow of data about incoming transactions

• The user has all incoming transactions during the period when the subscription was active

• On step 1, the user can configure list of accounts, which should be used as filter for the query

N/A

• The user has permissions to perform the target query of getting list of incoming transactions

Use case flow

1. The user prepares the query for getting list of non-fungible assets
2. The user sends query to the Iroha peer (<<include>> FR0200)
3. The Iroha peer responses with result of the query execution to the user, which contains list of all non-fungible assets with IDs and parameters

• The user has a list with IDs and parameters of all non-fungible assets attached to the account

• On step 1, the user can configure filtering for the request, so the resulting output on step 3 will contain only those assets, which are corresponds to the invariant

N/A

• The user has permissions to perform query using special language
• The user has permissions to all data inside block storage, which he/she wants to request by the query

Use case flow

1. The user prepares the complex query by building request on the provided query language
2. The user sends prepared query to the Iroha peer (<<include>> FR0200)
3. The Iroha peer responses with result of the query execution to the user

• The user requests all data according to the query language, which is available to his account according to permissions

N/A

• The user has permissions to setting up triggers in the Iroha network
• The user has permissions to execute all instructions and queries which are included into the trigger body

Use case flow

• The trigger was configured and ready to fire
• The user has ID o the created trigger to use it in future manipulations with it

• The trigger was created and configured as "manual" by the FR0300
• The user has permissions to fire the trigger
• The user has ID of the target trigger

Use case flow

1. The user prepares the instruction to fire the target trigger
2. The user sends the instruction to the Iroha peer (<<include>> FR0100)
3. The Iroha peer returns result of the target trigger execution

• All instructions from the trigger body was executed and applied to the block storage

• On step 3, if user does not have permissions to run all instructions in the Trigger, the Iroha peer returns "not enough permissions" status; use case flow stops.

• The trigger was created by the FR0300
• The user has permissions to remove the trigger
• The user has ID of the target trigger

Use case flow

1. The user prepares the instruction to remove the trigger
2. The user sends the instruction to the Iroha peer (<<include>> FR0100)
3. The Iroha peer returns results of the instruction to the user

• The target trigger was removed from the list of active triggers

• On step 3, if the user does not have enough permissions, the Iroha peer will return "not enough permissions" error status; use case flow stops

• The network administrator have access to the account with permissions to configure fees in the current Iroha network

Use case flow

1. The network administrator prepares the business-level description of the fee configuration
2. The network administrator sets up the fee configuration using the format (or DSL) used in Iroha
3. The network administrator prepares the instruction to change fee in the Iroha network
4. The network administrator sends the prepared instruction to the Iroha peer (<<include>> FR0100)
5. The Iroha peer returns results of the instruction to the user

• The fee configuration was changes according to the provided data

• On step 3, if the user does not have enough permissions, the Iroha peer will return "not enough permissions" error status; use case flow stops

• The user has access to the account with permissions to transfer assets to other account

Use case flow

1. The user prepares the information about needed transfer of assets
2. The user sends the query to the Iroha peer in the aim to get the needed structure of transaction, including all required fees (<<include>> FR0200)
   1. The response also contains the time frame until the provided information will be relevant.
3. The user creates the transaction with all required instructions included within the provided time frame
4. The user sends the prepared instruction to the Iroha peer (<<include>> FR0100)
5. The Iroha peer returns results of the instruction to the user

• The transfer instruction was successfully applied, together with all needed instructions for fees deduction.

• On step 3, if the time frame has passed, the user needs to request the information about fees again in the aim to create correct transaction

• On step 3, if user sends the transaction within the time frame, there is a chance that fees will be changed and the transaction will be rejected; use case flow stops.

• The user has need to delegate full or partial control over the account to another account
• (optionally) The user wants to limit the delegation period by time

Use case flow

1. The target user (which will get delegated rights on the account control) provides the account ID to the initial user
2. The initial user prepares the data for instruction for delegating control over the account
3. The initial user sends the transaction with instruction to the Iroha peer (<<include>> FR0100)
4. The Iroha peer executes the instruction and applies it to the block-store
5. The Iroha peer returns the response with the result of the instruction execution

• The control over the initial user's account was delegated to the target account

• On step 1, the initial user also can configure the time period for which the delegation will be actual. After the end of the period, the Iroha network removes the rights of sending transaction as behalf of initial user's account from the target user's account.

• The initial user has access to the target account in the Iroha network with permissions to configure inheritance
• The descendant user has access to another account in the Iroha network with permissions to accept the inheritance

Use case flow

1. The initial user prepares the instruction to configure inheritance rules
2. The initial user sends the transaction with the prepared instruction to the Iroha peer (<<include>> FR0100)
3. The Iroha peer responds with the result of the instruction to the initial user
4. Eventually, if the account of the initial user has no activity during the configured time period, the Iroha peer adds the key pair of the account of the descendant user to the list of signatories of the target account.
5. The descendant user receives rights to control the target account with its own key pair

• The descendant user receives the control over the target account

N/A

• The external system has access to the account with permissions to configure fees
• The fee distribution business rules are defined by the external systems

Use case flow

1. The external system configures the business rules of fee and distribution mechanism for the system (<<include>> FR0900)
2. Different users of the system performs operations, covered by the fee (<<include>> FR0901)
3. The Iroha network aggregates data about fee distribution by executing the DSL code, added to block storage on step 1.
4. Regularly, each predefined interval of time the Iroha network applies distribution of fees by executing code, added to block storage on step 1 .
5. The external system eventually requests information about collected fees and corresponding assets distribution during defined period (<<include>> FR0200)

• All fees are collected and distributed according to the business rules
• The external system has access to the information about distribution of assets from collected fees

• On step 4, the distribution mechanism can be triggered manually by the external system
• On step 5, the request can be done in keep-alive mode, using FR0208

N/A

• The user A has access to the account A in Iroha network with permissions to change its own list of signatories
• The user B has access to the account B in the Iroha network with permissions to be added as a signatory

Use case flow

1. The user A sends the transaction with instruction to add account of the user B to the list of signatories of the account A (<<include>> FR0100)
   1. This step is required to avoid flooding of list of pending transactions for account B in case in many users will add this account as a signatory without confirmation.
2. The user B requests the list of pending requests to be added as a signatory (<<include>> FR0200)
3. The user B sends the transaction with confirmation instruction for assigning account B to the list of signatories of account A (<<include>> FR0100)
4. The Iroha network adds key pair of account B to the list of signatories of account A
5. The user B receives possibility to sign the transaction on behalf of account A

• The user B has possibility to sign transactions on behalf of the account of user A

• On step 2, if the user B granted permission to user A to add account B as a signatory, the Iroha network will perform the operation without requesting confirmation from the user B.

• On step 3, if the user B did not confirmed the operation within the timeout (defined in the network configuration), the initial request created on step 1 will be dismissed. Use case flow stops.

• There are N user in the system, which accounts are selected to be a member of parliament
• All of these accounts are added as a signatory to the system central parliament account
• The system central parliament account has quorum which is required for making decisions by majority of parliament members
• The initiator of the decision has permissions to make the initial transaction with the proposal

Use case flow

1. The initiator of decision creates a transaction with the proposal body
   1. If the decision influences internal mechanics of the Iroha network, it should be represented in form of sequence of instructions, written using DSL
   2. If the decision influences external entities, it should be added as a document to the transaction payload
2. The initiator of the decision sends the transaction to the network (<<include>> FR0100)
3. All parliament members can get the list of pending transactions using their key pairs as a filter to get all pending decisions (<<include>> FR0203)
4. All parliament members makes their decision and sends corresponding transaction to the network
5. In case if majority of decisions reached, the Iroha network applies decision to the block store
   1. For sequence of instructions, they becomes executed and applied to the block store
   2. For the document, it becomes available as a immutable payload of the network

• The decision approved and saved forever in the block storage

• On step 5, if the majority of votes cannot be reached because of too much "contra" votes, the decision becomes rejected.
• On step 5, if the majority of votes cannot be reached because of timeout of voting, the decision becomes rejected.

N/A

• The user need to manage assets, which has unique characteristics for each entity

Use case flow

1. The user receives request to store and manipulate virtual assets with uniques characteristics at each entity
   1. It can be virtual representations of unique real objects, like cars, houses, arts, etc.
   2. It can be pure virtual representation of unique entities which can be summed up into the single class
2. The user creates the asset type by sending corresponding ISI in the transaction (<<include>> FR 0100) to the Iroha peer
3. The user configures types of characteristics for the created asset type by sending corresponding ISI in the transaction to the Iroha peer
4. The user configures permissions for all related entities in the Iroha network so they can manage created type of assets; the user sends corresponding ISI in the transaction to the Iroha peer
5. The user performs operations with assets of created asset type
   1. Creates new assets
   2. Changes characteristics of each asset

• There is a new type of non-fungible assets in the Iroha with predefined list of unique characteristics

• On step 3, characteristics can be mutable and immutable. Hence, on step 5, if all characteristics are immutable, there is no way to change them after minting new assets.

N/A

Use case flow

• The validator was nominated and selected successfully; the machine of validator joined as a validation node to the Iroha.

• There is a validator in the system which performed staking of assets and was nominated by the voting to take a validator role (see FR0908)
• Validator's node is connected to the Iroha network and works with not stable results

Use case flow

1. The government members in the project get information about the "bad behaviour" of the validator
2. The government member creates the proposal for slashing of validator's stake in terms of complex instruction written on DSL and sends it to the Iroha network (<<include>> FR0104)
3. The government members votes for the proposal (<<include FR0906)
4. In case if proposal gets majority of votes, the Iroha network executes slashing operation applies results to the storage

• The validator's stake was "slashed" in the favour of the overall budget of the "governance" structure

• On step 2, the decision about bad behavior can be made automatically if there is a possibility to operate with meta-parameters of the Iroha network from the DSL. Hence on step 3, the slashing proposal may be generated also automatically.

• There are more than one peer in the current Iroha network
• The user has access to the account with permission for receiving information about trusted peers

Use case flow

1. The user sends the query with request for list of trusted peers to the Iroha peer (<<include>> FR0100)
2. The Iroha peer returns result of the query to the user
3. The user can check the validity of the query by the Merkle proof attached to the result