Skip to content

Commit 5953d4e

Browse files
littletarzanlittletarzan
committed
first draft custom fee
1 parent 407ad0e commit 5953d4e

1 file changed

Lines changed: 45 additions & 41 deletions

File tree

‎hip-0000.md‎

Lines changed: 45 additions & 41 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
---
22
hip:
3-
title: Generalized Schedule Contract Call
3+
title: HTS Custom Fee Schedule Detector Precompile
44
author: Matthew DeLorenzo (@littletarzan), Michael Tinker (@tinker-michaelj)
55
working-group:
66
requested-by:
@@ -11,7 +11,7 @@ hedera-review-date:
1111
hedera-approval-status:
1212
needs-hiero-approval: Yes
1313
status: Draft
14-
created: 2025-04-09
14+
created: 2025-08-22
1515
discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/discussions/1096
1616
updated:
1717
requires:
@@ -20,71 +20,75 @@ superseded-by:
2020
---
2121

2222
## Abstract
23-
This HIP extends HIP-756 by allowing smart contracts to utilize the Hedera
24-
Schedule Service (HSS) for any possible smart contract call.
23+
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.
2524

2625
## Motivation
27-
HIP-755 extended the ability to schedule transactions to the Hedera Smart
28-
Contract Service. While this is very useful for smart contract calls by
29-
externally owned accounts (EOAs), it requires off-chain coordination and
30-
it does not extend to smart contracts calling other smart contracts as the
31-
origin of the transaction. Furthermore, HIP-755 does not fully support
32-
regularly scheduled transactions, as the off-chain signatures and message
33-
submission must be repeated for each transaction.
34-
35-
Extending HIP-756 to call contracts in the future would enable recursive
36-
execution and rescheduling of contract calls, resulting in a 'set it and forget
37-
it' system by which contract calls can be made at regularly scheduled intervals
38-
as long as the transaction payer has enough hbar to cover the gas and scheduled
39-
contract call fee.
26+
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.
27+
28+
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.
29+
30+
This HIP enables developers to **proactively reject token associations** that present this threat by allowing contracts to detect `customFeeSchedules` and non-empty `customFeeScheduleKeys`.
4031

4132
## Rationale
42-
This HIP provides the possiblility to have fully on-chain 'cron jobs' regularly
43-
call smart contracts that to this point have been done manually or through a web
44-
server.
33+
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.
34+
The precompile would return the following:
35+
36+
- Whether the token has a non-empty `customFeeSchedule`
37+
- Whether the token has a non-zero `customFeeScheduleKey`
4538

46-
## User stories
47-
1. As a smart contract developer, I want to reduce my technical overhead through
48-
having a contract call itself or other contracts
39+
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.
4940

50-
Useful examples for this upgrade could include: rebalancing DeFi positions,
51-
claiming tokens from vesting contracts at regular intervals, and changing token
52-
statuses at a predetermined epoch time in the future.
41+
## User Stories
42+
1. As a dApp developer, I want to prevent tokens with malicious fee schedules from being deposited into my contract.
43+
2. As a protocol admin, I want to audit the fee characteristics of incoming tokens.
44+
3. As a security engineer, I want on-chain detection of potentially exploitable token configurations.
5345

5446
## Specification
55-
The ledger HSCS will utilize the existing HSS but with more generality via
56-
`IHederaScheduleService.sol`.
5747

58-
### HSS System Contract
59-
The `IHederaScheduleService.sol` interface must be updated to support everything
60-
needed to run any smart contract call.
48+
### System Contract Interface
49+
This HIP introduces a new precompile interface:
50+
51+
```solidity
52+
interface IHederaTokenService {
53+
function detectCustomFees(address token) external view returns (
54+
bool hasCustomFeeSchedule,
55+
bool hasCustomFeeScheduleKey
56+
);
57+
}
58+
```
59+
60+
61+
### Selector Table
6162

6263
| Hash | Selector |
6364
|---------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------|
64-
| `0xb278e9be` | `scheduleNative(address targetContract, address payer, uint256 epochTimeToCall, uint256 gas, uint256 msgvalue, bytes memory args) returns (int64 responseCode)` |
65+
| `0xabcdefg` | `detectCustomFees(address token) returns (bool hasCustomFeeSchedule, bool hasCustomFeeScheduleKey)` |
66+
6567

6668
## Backwards Compatibility
67-
No existing features are modified as this only exposes HAPI functionality to smart
68-
contracts.
69+
This HIP introduces new functionality via precompile and does not change any existing behavior.
6970

7071
## Security Implications
71-
No additional security concerns
72+
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.
7273

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

7680
## Reference Implementation
77-
81+
TBD. A sample contract using IHederaTokenService.detectCustomFees() can be provided to show how a contract rejects a token if either boolean is true.
7882

7983
## Rejected Ideas
80-
84+
• Using off-chain detection (not trustless)
85+
• Whitelisting tokens (not scalable or dynamic)
8186

8287
## Open Issues
83-
88+
• Should this precompile expose full fee schedule data?
89+
• Should fallback fee info be included for royalty fees?
8490

8591
## References
86-
1. [HIP-755](https://hips.hedera.com/hip/hip-755)
87-
2. [HIP-756](https://hips.hedera.com/hip/hip-756)
8892

8993
## Copyright/license
9094
This document is licensed under the Apache License, Version 2.0 —

0 commit comments

Comments
 (0)