Hiero logo

HIP-1195: Hiero Hooks and an Application to Allowances

6 min read•May 26, 2026

by Anshul Kushwaha

Hiero

The Technical Steering Committee has approved HIP-1195, which introduces hooks to Hiero — programmable extension points that let users attach custom logic to their native entities. Rather than requiring a dedicated protocol change for each new behavior, hooks allow that behavior to be written in Solidity and attached directly.

This post outlines the proposal, its technical details, and what it means for the Hiero ecosystem.

Introduction and Background

Hiero users frequently need to customize native entities to fit specific business or regulatory requirements. Historically, each such customization required a dedicated HIP and protocol-level changes. Examples include:

  • HIP-18: Custom fee payments for HTS transfers
  • HIP-904: More permissive token association policies for frictionless airdrops
  • HIP-991: Fee-based access control for topic message submissions

While effective individually, this approach does not scale. Each new customization adds complexity to the protocol and requires a full design review cycle. Users who need custom business logic are often left choosing between waiting for protocol changes or migrating entirely to EVM smart contracts, losing the performance and simplicity of native APIs.

HIP-1195 addresses this by introducing a general-purpose mechanism for extending native entity behavior.

What is HIP-1195?

HIP-1195 defines hooks as programmable Hiero extension points. Users program hooks by writing contracts in a language like Solidity that compiles to EVM bytecode. Each entity can have multiple hooks, identified by unique 64-bit hook ids.

The first extension point introduced is account allowance hooks. These hooks can be created on accounts and referenced in a CryptoTransfer transaction, similar to how ERC-style allowances defined in HIP-376 work today. When a transfer references an allowance hook, the network calls the hook's EVM bytecode with the context of the triggering transaction. If the hook returns true, the transfer proceeds; otherwise it is rejected.

Unlike smart contracts, which encapsulate trust guarantees for multiple parties, EVM hooks belong to a single owner. The owner can directly update hook storage using the new HookStore transaction introduced by this HIP, enabling fast adjustments to hook behavior with significantly less overhead than a ContractCall.

Motivation and Goals

HIP-1195 aims to give users a general-purpose way to add custom business logic to their entities. Specific goals include:

  • Flexibility without protocol changes – Users can implement custom rules (regulatory compliance, conditional transfers, automated policies) without proposing a new HIP for each use case
  • Reduced protocol complexity – Instead of adding one-off features to the protocol, hooks provide a reusable extension mechanism
  • Developer empowerment – Token issuers, account operators, and dApp developers can enforce business rules natively while preserving the performance of Hiero APIs
  • Preserving native API performance – Unlike migrating everything to custom ERC-20 contracts, hooks keep the simplicity and throughput of native services

Together, these goals reduce the need for protocol-level changes while keeping the benefits of native services.

Technical Implementation

Hook Execution Model

The EVM execution environment for hooks has two key differences from a standard contract call:

  • Special address 0x16d – Throughout a hook's EVM transaction, the hook bytecode executes at the system contract address 0x16d. Conceptually, the initial EVM message frame is a DELEGATECALL from 0x16d to the hook's implementing contract. If another contract calls back to 0x16d, control returns to the hook's bytecode.
  • Entity privileges – A hook is an extension of its owning entity. When the hook calls Hiero system contracts, they execute on behalf of the entity. If the entity has a balance, the hook can use it to transfer value, such as refunding gas fees.

Restricted operations in hook execution include:

  • CALLCODE always fails
  • DELEGATECALL fails unless done in the facade contract of a native entity
  • SELFDESTRUCT fails if executed in the frame with address 0x16d

Hook executions are not supported in batch or scheduled transactions, though hook creations are supported in both.

Hook Creation and Management

Hook registration is handled through existing HAPI protobuf transactions — no new transaction types are needed for creation or lifecycle management (the new HookStore transaction mentioned above is used only for direct storage updates):

  • CryptoCreate / CryptoUpdate – Create or update hooks on accounts
  • ContractCreate / ContractUpdate – Create or update hooks on contracts

Each hook has an admin key controlled by the owner, ensuring only authorized parties can modify or delete hook registrations.

Allowance Hook ABI

Account allowance hooks implement a specific interface with three entrypoints:

  • allow(...) – The primary function called during a CryptoTransfer to determine whether the transfer should proceed
  • allowPre(...) – Called before the transfer executes, enabling pre-validation logic
  • allowPost(...) – Called after the transfer, supporting post-execution checks and cleanup

Each entrypoint receives an IHieroHook.HookContext struct containing the owner address, transaction fee, gas cost, memo, and any extra call data.

Gas and Throttling Model

  • Upfront gas payment – The payer of the triggering transaction pays for hook gas upfront
  • Refund capability – The hook API includes the gas fee as a parameter, allowing hooks to refund some or all of the cost
  • Gas limit – The payer is never charged more gas than the limit they set at the hook reference point
  • Reduced intrinsic gas – Hook executions use a lower intrinsic gas cost (hooks.evm.intrinsicGasCost=1000) since they are already gated by the triggering transaction fee
  • Throttling – Hooks share the same gas throttle as top-level contract calls. If the network is at gas capacity, hook execution is throttled and the triggering transaction fails with CONSENSUS_GAS_EXHAUSTED

Impact on the Ecosystem

For developers and dApp builders:

  • Implement custom transfer logic (compliance checks, spending limits, conditional approvals) without full smart contract migrations
  • Build valuable metaprotocols using hooks that can be published as application HIPs and adopted broadly by the community

For token issuers and account operators:

  • Enforce regulatory or business rules on every transaction involving their assets natively
  • Maintain full control with admin keys while benefiting from EVM programmability

For the network:

  • Reduce protocol complexity by channeling customization needs through a general-purpose mechanism
  • Hooks that gain broad adoption will be extensively reviewed, audited, and given special treatment by ecosystem wallets and block explorers

For Hiero network operators:

  • Hook creation rates are throttled using the same buckets as contract creation, with configurable pricing
  • Rent scales linearly with the number of hooks and storage slots, supporting sustainable state growth

How to Learn More

To explore HIP-1195 in detail:

Conclusion

HIP-1195 adds a general extension mechanism to Hiero. Instead of encoding each customization into the protocol, hooks let users define their own logic in EVM bytecode and attach it to their entities. Account allowance hooks are the first application, and the architecture supports adding more extension points in the future.

Recent Hiero Posts