Update bsip-0040.md

bsip-0040.md

@@ -39,11 +39,11 @@ The above list of named keys is nothing that is known to the backend as the back
 
 # Rational
 
-Custom active permission is a list of `custom active authorities`. A `custom active authority` contains an `operation_id`, an `authority` (just like with active permission) and `asserts` than can be used to restrict arguments and is only valid a certain time period (`valid_from` and `valid_to`). When handling incoming signed transactions, the backend checks for each operation if there is a `custom active authority` for any of its required accounts. Check for every required account of the transaction if all its belonging operations have at least one positively matched `custom active authority` (match means same `operationid`, now is within `valid_to` and `valid_from` and all `asserts` pass), and if so grant the active authority of the corresponding account. 
+Custom active permission is a list of `custom active authorities`. A `custom active authority` contains an `operation_id`, an `authority` (just like with active permission) and `asserts` than can be used to restrict arguments and is only valid a certain time period (`valid_from` and `valid_to`). When handling incoming signed transactions, the backend checks for each operation if there is a `custom active authority` for any of its required accounts. Check for every required account of the transaction if all its belonging operations have at least one positively matched `custom active authority` (match means its `authority` is granted through present signatures, same `operationid`, now is within `valid_to` and `valid_from` and all `asserts` pass), and if so grant the active authority of the corresponding account. 
 
 # Specification
 
-All descriptions in this section are on a pseudo/prosa level and no recommendation how it can best be implemented or serialized. They are meant to facilitate the understanding.
+All descriptions in this section are on a pseudo/prosa level and no recommendation how it can best be implemented or serialized. They are meant to facilitate the understanding. If anything in the looping process or order of evaluation is unsuitable for actual implementation, changes can be made accordingly as long the same functionality is achieved.
 
 ### Custom active permission and custom active authority
 
@@ -145,7 +145,7 @@ Note: This is just an illustration of a possible serialization, not a specificat
 When a signed transaction arrives and before the backend evaluates if all necessary authorities are present through the signatures, do the following:
 - iterate over required accounts and for each account, iterate over all operations within the transactions that require the active authority of this account
 - iterate the `custom_active_authorities` of said account
-- if a `custom_active_authority` is found that matches (same `operationid`,  now is within `valid_to` and `valid_from` and passes all `asserts`), remember that and stop iterating the authorities and continue until all operations are checked
+- if a `custom_active_authority` is found that matches (match means its `authority` is granted through present signatures, same `operationid`,  now is within `valid_to` and `valid_from` and passes all `asserts`), remember that and stop iterating the authorities and continue until all operations are checked
 - if the account has a `custom active authority` match for every operation in the transaction that requires it, then grant the `active authority` of said account. If no match is found, treat as if no authority was given
 
 Note: