Skip to content

hip-1284.md

Latest commit

 

History

History
91 lines (68 loc) · 4.79 KB

hip-1284.md

File metadata and controls

91 lines (68 loc) · 4.79 KB
Raw
hip 1284
title HTS Custom Fee Schedule Detector Precompile
author Matthew DeLorenzo (@littletarzan), Michael Tinker (@tinker-michaelj)
requested-by Lambdaplex
type Standards Track
category Service
needs-hiero-approval true
needs-hedera-review true
hedera-review-date
hedera-approval-status
status Review
created 2025-09-15
discussions-to hiero-ledger#1271
updated 2025-09-17

Abstract

This HIP proposes a Hedera Smart Contract Service (HSCS) system contract function that allows a smart contract to determine whether a Hedera Token Service (HTS) token contains a customFeeSchedule and/or a non-empty customFeeScheduleKey. This information is critical for smart contracts to safely interact with tokens without risk of unintended token transfers caused by malicious fee schedules.

Motivation

While custom fee schedules are a powerful feature of HTS, they may be exploited maliciously in decentralized applications. If a smart contract accepts an HTS token with a complex or malicious fee schedule, and subsequently performs a token transfer via HAPI or precompile, it may unknowingly incur additional fee payments — including the unauthorized transfer of other unrelated tokens held by the contract.

This poses a serious threat to dApps and DeFi protocols which hold multiple tokens in their balance map. For example, if a smart contract accepts a token with a fee schedule that references an unrelated token or imposes a high collector fee, any token transfer operation might inadvertently transfer the unrelated token to a third-party address.

This HIP enables developers to proactively reject token associations that present this threat by allowing contracts to detect customFeeSchedules and non-empty customFeeScheduleKeys.

Rationale

This proposal adds support to a IHederaTokenService.sol that can be called from smart contracts to query the customFeeSchedule and customFeeScheduleKey of any HTS token. Any presence of a customFeeSchedule or non-empty customFeeScheduleKey should be detected and returned. The precompile would return the following:

  • Whether the token has a non-empty customFeeSchedule
  • Whether the token has a non-zero customFeeScheduleKey

By doing so, developers can build safer and more robust smart contracts that refuse to interact with unsafe tokens or alert administrators when unexpected configurations are found.

User Stories

  1. As a dApp developer, I want to prevent tokens with malicious fee schedules from being deposited into my contract.
  2. As a protocol admin, I want to audit the fee characteristics of incoming tokens.
  3. As a security engineer, I want on-chain detection of potentially exploitable token configurations.

Specification

System Contract Interface

This HIP introduces a new precompile interface:

interface IHederaTokenService {
    function detectCustomFees(address token) external view returns (
        bool hasCustomFeeSchedule,
        bool hasCustomFeeScheduleKey
    );
}

Selector Table

Hash Selector
0x2e0f2625 detectCustomFees(address token) returns (bool hasCustomFeeSchedule, bool hasCustomFeeScheduleKey)

Backwards Compatibility

This HIP introduces new functionality via precompile and does not change any existing behavior.

Security Implications

This precompile is intended to mitigate security risks by enabling better detection of malicious or risky tokens. It does not introduce new risks when implemented correctly.

How to Teach This

This HIP should be taught as a safety precompile for developers building DeFi and token-interactive smart contracts. Teaching materials should include: • Examples of malicious token configurations • Walkthrough of how to reject unsafe tokens using this precompile • Integration with existing token gating or access control systems

Reference Implementation

TBD. A sample contract using IHederaTokenService.detectCustomFees() can be provided to show how a contract rejects a token if either boolean is true.

Rejected Ideas

•	Using off-chain detection (not trustless)
•	Whitelisting tokens (not scalable or dynamic)

Open Issues

•	Should this precompile expose full fee schedule data?
•	Should fallback fee info be included for royalty fees?

References

Copyright/license

This document is licensed under the Apache License, Version 2.0 — see LICENSE or https://www.apache.org/licenses/LICENSE-2.0.