You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

调用Solidity函数铸造HTS代币时遇INSUFFICIENT_TX_FEE错误求助

遇到INSUFFICIENT_TX_FEE错误的问题

背景说明

我有一个作为金库的合约,在安全模型更新前,它会调用HTS.createFungibleToken并将自身设为金库。更新后,我把所有HTS函数调用迁移到了继承HTS的「代理合约」,因为现在需要从金库合约委托调用代理合约,以此传递关联代币的EOA签名。

问题场景

尽管已经设置发送超1000 HBAR,但以下三种代币创建操作场景仍持续触发INSUFFICIENT_TX_FEE错误(HTSProxy为直接调用HTS的代理合约,LDCREToken为金库合约):

  • 可支付构造函数直接调用代理方法:我认为无需委托调用(合约自身作为金库,交易签名者应为金库合约),在构造函数中直接调用proxy.mintToken,同时为CreateContractTransaction设置setInitialBalance(new HBAR(1000))和setMaxTransactionFee(new Hbar(1000));
  • 在可支付构造函数中使用delegate call/call调用代理方法(与场景1操作一致,仅调用方式改为委托调用/call);
  • 在金库合约中新增方法,直接或通过delegate call/call调用代理的mintToken(将前两种场景的操作从构造函数移至单独方法),为ContractExecuteTransaction设置setPayableAmount(new HBAR(1000))和setMaxTransactionFee(new HBAR(1000))。

后续思考

我考虑通过Hashgraph SDK在部署两个合约后调用代理合约的mintToken并传入正确金库地址来规避问题,但不清楚当前方案失败的原因。

场景3的Solidity代码

function mintToken() external payable {
    (int responseCode, address _tokenAddress) = htsProxy.mintToken(
        "OraCRE",
        "OraCRE",
        address(this),
        1000000000,
        8
    );
}

内容的提问来源于stack exchange,提问作者Pathorn Teng

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.07.24 23:22:36