Merge branch 'main' into 1259-acceptance

Signed-off-by: Michael Garber <michael.garber@hashgraph.com>

Author: mgarbs

.github/workflows/add-hip-number.yml

@@ -31,7 +31,7 @@ jobs:
 
       - name: Import GPG Key
         id: gpg_importer
-        uses: step-security/ghaction-import-gpg@c86c374c0659a6c2d1284bccf8af889e73ce8fe0 # v6.3.0
+        uses: step-security/ghaction-import-gpg@69c854a83c7f79463f8bdf46772ab09826c560cd # v6.3.1
         with:
           git_commit_gpgsign: true
           git_tag_gpgsign: true

.github/workflows/schedule-last-call-date-end.yml

@@ -31,7 +31,7 @@ jobs:
 
       - name: Import GPG Key
         id: gpg_importer
-        uses: step-security/ghaction-import-gpg@c86c374c0659a6c2d1284bccf8af889e73ce8fe0 # v6.3.0
+        uses: step-security/ghaction-import-gpg@69c854a83c7f79463f8bdf46772ab09826c560cd # v6.3.1
         with:
           git_commit_gpgsign: true
           git_tag_gpgsign: true

.github/workflows/send-discord-message.yml

@@ -31,6 +31,6 @@ jobs:
       - name: Discord notification
         env:
           DISCORD_WEBHOOK: ${{ secrets.DISCORD }}
-        uses: step-security/action-discord@b4bb54a2ec8218130ee588d2ca1fa358cf828735 # v0.1.2
+        uses: step-security/action-discord@25f3b8e2229f3a238679abdbcf82d84a075419bd # v0.1.3
         with:
           args:  "${{ github.event.inputs.filename }} moved into ${{ github.event.inputs.status }} status https://hips.hedera.com/hip/${{ github.event.inputs.filename }}"

.github/workflows/update-draft-hips.yml

@@ -29,7 +29,7 @@ jobs:
 
       - name: Import GPG Key
         id: gpg_importer
-        uses: step-security/ghaction-import-gpg@c86c374c0659a6c2d1284bccf8af889e73ce8fe0 # v6.3.0
+        uses: step-security/ghaction-import-gpg@69c854a83c7f79463f8bdf46772ab09826c560cd # v6.3.1
         with:
           git_commit_gpgsign: true
           git_tag_gpgsign: true

HIP/hip-1046.md

@@ -9,10 +9,11 @@ category: Core
 needs-hedera-review: Yes
 needs-hiero-approval: Yes
 discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/discussions/1059
-status: Accepted
+status: Final
+release: v0.64
 last-call-date-time: 2024-10-29T07:00:00Z
 created: 2024-09-18
-updated: 2025-05-21
+updated: 2025-10-15
 ---
 
 ## Abstract

HIP/hip-1064.md

@@ -8,11 +8,12 @@ type: Standards Track
 category: Core
 needs-hedera-review: Yes
 needs-hiero-approval: Yes
-status: Accepted
+status: Final
+release: v0.61
 last-call-date-time: 2024-12-11T07:00:00Z
 created: 2024-10-17
 discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/discussions/1063
-updated: 2025-03-27
+updated: 2025-10-15
 ---
 
 ## Abstract

HIP/hip-1127.md

@@ -10,12 +10,12 @@ needs-hiero-approval: Yes
 needs-hedera-review: Yes
 hedera-review-date: 2025-07-15
 hedera-acceptance-decision: Accepted
-status: Approved
-last-call-date-time: 2025-07-16T07:00:00Z
+status: Final
+release: v0.65.0
 created: 2025-02-17
-updated: 2025-07-30
+updated: 2025-09-25
 requires: 1056
-discussion-to: https://github.com/hiero-ledger/hiero-improvement-proposals/pull/1127
+discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/pull/1127
 ---
 
 ## Abstract

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-10-03
 ---
 
 ## 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
@@ -593,32 +593,27 @@ message EvmHookState {
    */
   proto.ContractID hook_contract_id = 4;
 
-  /**
-   * True if the hook has been deleted.
-   */
-  bool deleted = 5;
-
   /**
    * For a lambda, its first storage key.
    */
-  bytes first_contract_storage_key = 6;
+  bytes first_contract_storage_key = 5;
 
   /**
    * If set, the id of the hook preceding this one in the owner's
    * doubly-linked list of hooks.
    */
-  google.protobuf.Int64Value previous_hook_id = 7;
+  google.protobuf.Int64Value previous_hook_id = 6;
 
   /**
    * If set, the id of the hook following this one in the owner's
    * doubly-linked list of hooks.
    */
-  google.protobuf.Int64Value next_hook_id = 8;
+  google.protobuf.Int64Value next_hook_id = 7;
 
   /**
    * The number of storage slots a lambda is using.
    */
-  uint32 num_storage_slots = 9;
+  uint32 num_storage_slots = 8;
 }
 
 /**
@@ -718,7 +713,8 @@ If any transaction repeats a hook id in its `hook_creation_details` list, it wil
 to create a hook with an id that is already occupied, it will fail with status `INDEX_IN_USE`. Similarly, if either
 update transaction tries to delete a hook with an id not in use, it will fail with status `HOOK_NOT_FOUND`. Much as an
 account can only be deleted when it has zero HTS token balances, a hook can only be deleted when it has zero storage
-slots. Otherwise deletion will fail with `HOOK_DELETION_REQUIRES_EMPTY_STORAGE`.
+slots. Otherwise deletion will fail with `HOOK_DELETION_REQUIRES_EMPTY_STORAGE`. An account can only be deleted when it
+has zero hooks; otherwise deletion will fail with `TRANSACTION_REQUIRES_ZERO_HOOKS`.
 
 To support atomic hook updates for compliance reasons, we **do** support deleting and recreating a hook with the same
 id in a single update transaction. (That is, the `hook_ids_to_delete` list is processed first; then the
@@ -822,7 +818,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,
 
@@ -831,8 +827,6 @@ The account allowance EVM hook ABI is as follows,
 pragma solidity >=0.4.9 <0.9.0;
 pragma experimental ABIEncoderV2;
 
-import './IHederaTokenService.sol';
-
 /// The interface for a generic EVM hook.
 interface IHieroHook {
     /// The context the hook is executing in
@@ -850,46 +844,48 @@ interface IHieroHook {
     }
 }
 
+
+// SPDX-License-Identifier: Apache-2.0
+pragma solidity >=0.4.9 <0.9.0;
+pragma experimental ABIEncoderV2;
+
+import './IHieroHook.sol';
 /// The interface for an account allowance hook invoked once before a CryptoTransfer.
 interface IHieroAccountAllowanceHook {
-    /// Combines HBAR and HTS asset transfers.
-    struct Transfers {
-        /// The HBAR transfers
-        IHederaTokenService.TransferList hbar;
-        /// The HTS token transfers
-        IHederaTokenService.TokenTransferList[] tokens;
-    }
+   /// A single balance adjustment in the range of a Hiero native token
+   struct AccountAmount {
+      // The address of the account whose balance is changing
+      address account;
+      // The amount in atomic units of the change
+      int64 amount;
+   }
 
-    /// Combines the full proposed transfers for a Hiero transaction,
-    /// including both its direct transfers and the implied HIP-18
-    /// custom fee transfers.
-    struct ProposedTransfers {
-        /// The transaction's direct transfers
-        Transfers direct;
-        /// The transaction's assessed custom fees
-        Transfers customFee;
-    }
+   /// A single NFT ownership change
+   struct NftTransfer {
+      // The address of the sender
+      address sender;
+      // The address of the receiver
+      address receiver;
+      // The serial number being transferred
+      int64 serialNo;
+   }
 
-    /// Decides if the proposed transfers are allowed, optionally in
-    /// the presence of additional context encoded by the transaction
-    /// payer in the extra calldata.
-    /// @param context The context of the hook call
-    /// @param proposedTransfers The proposed transfers
-    /// @return true If the proposed transfers are allowed, false or revert otherwise
-    function allow(
-       IHieroHook.HookContext calldata context,
-       ProposedTransfers memory proposedTransfers
-    ) external payable returns (bool);
-}
+   /// A zero-sum list of balance adjustments for a Hiero-native token
+   struct TokenTransferList {
+      // The Hiero token address
+      address token;
+      // For a fungible token, the zero-sum balance adjustments
+      AccountAmount[] adjustments;
+      // For a non-fungible token, the NFT ownership changes
+      NftTransfer[] nftTransfers;
+   }
 
-/// The interface for an account allowance hook invoked both before and after a CryptoTransfer.
-interface IHieroAccountAllowancePrePostHook {
    /// Combines HBAR and HTS asset transfers.
    struct Transfers {
-      /// The HBAR transfers
-      IHederaTokenService.TransferList hbar;
+      /// A zero-sum list of balance adjustments for HBAR specifically
+      AccountAmount[] hbarAdjustments;
       /// The HTS token transfers
-      IHederaTokenService.TokenTransferList[] tokens;
+      TokenTransferList[] tokens;
    }
 
    /// Combines the full proposed transfers for a Hiero transaction,
@@ -902,6 +898,27 @@ interface IHieroAccountAllowancePrePostHook {
       Transfers customFee;
    }
 
+   /// Decides if the proposed transfers are allowed, optionally in
+   /// the presence of additional context encoded by the transaction
+   /// payer in the extra calldata.
+   /// @param context The context of the hook call
+   /// @param proposedTransfers The proposed transfers
+   /// @return true If the proposed transfers are allowed, false or revert otherwise
+   function allow(
+      IHieroHook.HookContext calldata context,
+      ProposedTransfers memory proposedTransfers
+   ) external payable returns (bool);
+}
+
+// SPDX-License-Identifier: Apache-2.0
+pragma solidity >=0.4.9 <0.9.0;
+pragma experimental ABIEncoderV2;
+
+import './IHieroHook.sol';
+import './IHieroAccountAllowanceHook.sol';
+
+/// The interface for an account allowance hook invoked both before and after a CryptoTransfer.
+interface IHieroAccountAllowancePrePostHook {
    /// Decides if the proposed transfers are allowed BEFORE the CryptoTransfer
    /// business logic is performed, optionally in the presence of additional
    /// context encoded by the transaction payer in the extra calldata.
@@ -910,9 +927,9 @@ interface IHieroAccountAllowancePrePostHook {
    /// @return true If the proposed transfers are allowed, false or revert otherwise
    function allowPre(
       IHieroHook.HookContext calldata context,
-      ProposedTransfers memory proposedTransfers
+      IHieroAccountAllowanceHook.ProposedTransfers memory proposedTransfers
    ) external payable returns (bool);
-   
+
    /// Decides if the proposed transfers are allowed AFTER the CryptoTransfer
    /// business logic is performed, optionally in the presence of additional
    /// context encoded by the transaction payer in the extra calldata.
@@ -921,11 +938,34 @@ interface IHieroAccountAllowancePrePostHook {
    /// @return true If the proposed transfers are allowed, false or revert otherwise
    function allowPost(
       IHieroHook.HookContext calldata context,
-      ProposedTransfers memory proposedTransfers
+      IHieroAccountAllowanceHook.ProposedTransfers memory proposedTransfers
    ) external payable returns (bool);
 }
 ```
 
+### 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.