Token Allowance for Hedera Token Service (HTS) Precompile #1332
walter-hernandez
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
hip: xx
title: Token Allowance for Hedera Token Service (HTS) Precompile
author: Walter Hernandez walter.hernandez.18@ucl.ac.uk, Paolo Tasca p.tasca@exp.science, Nikhil Vadgama nikhil.vadgama@exp.science, Colin Fausnaught c.fausnaught@exp.science, Marco Javarone m.javarone@exp.science, Jiahua Xu jiahua.xu@ucl.ac.uk
type: Service
category: Service
needs-council-approval: Yes
status: Draft
created: 2025-10-05
discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/XX
link-to-pr: https://github.com/hiero-ledger/hiero-improvement-proposals/pull/xx
Abstract
Proposal for a precompiled contract to enable token allowance functionality for Hedera Token Service (HTS) tokens precompiled (HIP-206). This allows developers to enable functionality in their contracts that allows token holders to approve third-party contracts or accounts to transfer tokens on their behalf within specified limits, following the standards ERC-20 and ERC-721's allowance.
Motivation
The precompiled approach allows smart contracts to query and modify allowances without requiring token holders to sign each transfer, while maintaining strict security boundaries through explicit approval limits.
Rationale
The ERC-20 and ERC-721 token standard's
approveandtransferFrompatterns have become the standard mechanism for controlled token delegation in EVM compatible chains. Implementing this as a precompiled contract achieves gas efficiency through native implementation, provides standardization across all HTS tokens, and enhances developer experience by reducing complexity. This approach aligns with existing practices in the Ethereum ecosystem, facilitating easier migration of dApps to Hedera while reaping the benefits of HTS (e.g., low fees, high throughput, gas efficiency).User stories
As a dApp developer, I want users to approve my contract to access their tokens once during onboarding, so that my application can execute token transfers as part of its core functionality without repeated authorization prompts.
As a marketplace operator, I want users to grant my contract permission to transfer their NFTs, so that sales can execute atomically when buyers and sellers are matched without requiring the seller to be online.
As a subscription service provider, I want approved access to users' stablecoin balances, so that I can process recurring payments automatically while respecting predefined spending limits.
As a payment processor, I want to execute batch payments on behalf of users who have granted allowances, so that multiple transfers can be processed efficiently in a single transaction.
Specification
It will follow the ERC-20 standard's and ERC-721 standard's
approveandtransferFromlogic from OpenZeppelin's implementation, adapted for HTS tokens: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol and https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.solBackwards Compatibility
This HIP introduces new functionality without breaking existing behaviors. Existing HTS tokens function normally without any allowance configuration. Tokens can opt into allowance functionality without requiring updates to token configuration. All HIP-206 precompile functions remain unchanged and fully compatible.
Security Implications
Users may approve unlimited allowances for convenience, exposing their entire token balance to potentially compromised contracts. Mitigation includes emphasizing principle of least privilege in documentation, dApp UIs clearly displaying requested allowance amounts, warning users when approving amounts larger than immediately necessary, and implementing allowance expiration in application logic.
If a contract with approved allowances is compromised, attackers can drain all tokens for which allowances were granted. Mitigation includes users revoking allowances for contracts they no longer use, dApps providing clear allowance management interfaces, implementing emergency revocation mechanisms, and smart contracts implementing circuit breakers and pausability.
Following HIP-206 security patterns, clear documentation is needed of which keys authorize allowance operations. Allowances granted by token holders should not require admin key authorization. Admin key requirements apply only when transfers themselves require such authorization.
How to Teach This
Open Issues
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)
All reactions