Add section on ACCOUNT_ALLOWANCE_HOOK call ordering

Signed-off-by: Michael Tinker <michael.tinker@swirldslabs.com>

Author: tinker-michaelj

HIP/hip-1195.md

@@ -12,7 +12,7 @@ status: Approved
 last-call-date-time: 2025-06-06T07:00:00Z
 created: 2025-02-19
 discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/discussions/1172
-updated: 2025-09-02
+updated: 2025-09-17
 ---
 
 ## Abstract
@@ -22,8 +22,8 @@ In principle, hooks could be programmed in any language, but we begin with **EVM
 writing contracts in a language like Solidity that compiles to EVM bytecode. EVM hooks may have optimized variants in
 the future, but we propose first a full-featured **lambda** EVM hook. The name is chosen to evoke event-driven code
 running in the cloud or call other external services. For any given entity, its user can create many hooks for that
-entity with different 64-bit **hook ids**. There is no limit on the number of hook ids than an entity can use; bu
-tits storage footprint, and hence rent, will increase proportionally.
+entity with different 64-bit **hook ids**. There is no limit on the number of hook ids than an entity can use; but
+its storage footprint, and hence rent, will increase proportionally.
 
 As a first Hiero extension point, we propose **account allowance hooks**. Users can create these hooks on their
 accounts, and a Hiero API (HAPI) `CryptoTransfer` transaction can then reference an allowance hook just as it does an
@@ -819,7 +819,7 @@ message NftTransfer {
 Note that `NftTransfer` supports both sender and receiver transfer allowance hooks, since the transaction may
 need to use the receiver hook to satisfy a `receiver_sig_required=true` setting.
 
-### The transfer allowance ABI
+### The account allowance ABI
 
 The account allowance EVM hook ABI is as follows,
 
@@ -923,6 +923,29 @@ interface IHieroAccountAllowancePrePostHook {
 }
 ```
 
+### Call order of `ACCOUNT_ALLOWANCE_HOOK`s
+
+A `CryptoTransferTransactionBody` can execute multiple hooks, subject only to the global limit on the number of child
+records for a single transaction,
+```
+consensus.handle.maxFollowingRecords=50
+```
+The `CryptoTransfer` handler will execute hook calls in the following order:
+1. All `pre_tx_allowance_hook` and `pre_post_tx_allowance_hook` calls in the HBAR `TransferList`, in the order they
+appear in the `CryptoTransferTransactionBody`.
+2. All `pre_tx_allowance_hook` and `pre_post_tx_allowance_hook` calls in the fungible `transfers` of the `tokenTransfers`
+list, in the order they appear in the `CryptoTransferTransactionBody`.
+3. All `pre_tx_sender_allowance_hook`, `pre_post_sender_tx_allowance_hook`, `pre_tx_receiver_allowance_hook`, and
+`pre_post_tx_receiver_allowance_hook` calls in the non-fungible `nftTransfers` of the `tokenTransfers` list, in the
+order they appear in the `CryptoTransferTransactionBody`. (_Note:_ if both sender and receiver hooks are present, then
+the sender hook is executed first.)
+4. All `pre_post` hooks previously executed in steps (1) to (3), _in the same order they were previously executed_;
+while the first call will be to the `allowPre(HookContext, ProposedTransfers)` method signature, the second call will
+be to the `allowPost(HookContext, ProposedTransfers)` signature.
+
+A block stream or legacy record stream client can use this well-known ordering to identify which child `ContractCall`
+to `0x16d` corresponds to which `HookCall` in a `CryptoTransferTransactionBody`.
+
 ### Examples
 
 Next we provide two examples of account allowance EVM hooks.