Discussion: Adjust account permission update and multi-sign execution cost

[simbadMarino]

Summary

Since the Multi-sign feature was implemented on TRON (2019-03-21) no fees adjustments has been done to cope with increasing TRX price appreciation, I'd like to initiate a discussion on the matter and if approved by consensus adjust both:

getUpdateAccountPermissionFee from 100 TRX to 8 TRX
getMultiSignFee from 1 TRX to 0.1 TRX

(fees can be adjusted depending on discussion and feedback from community)

Motivation

Encourage TRON users to use the multi-sign feature to increase their accounts flexibility without compromising security.

Additionally, agentic commerce users might choose TRON over other blockchains if we provide their agents with cost effective solutions to enhance their EOA security, unlocked applications include the following:

• Configure multi-sign threshold > 1 for high value / semi-automated wallet transactions flows
• Limit agents automated actions to specific application like staking / delegation / vote
• Prevent agents to execute non-desired operations like TRX transfer or Triggering Smart Contracts depending on use case.

Background

Considering initial dollar cost of multisign update was $2.2 USD (100 TRX * $0.022 USD = $2.2) and based on current TRX price now its $31 USD ( 100 TRX * $0.31 USD = $31 USD)

TRX growth factor = 14

I'd recommend to adjust multi-sign parameters so it is economically viable for users to enhance their TRON EOAs security.

TRON EOA Multi-sign feature is proven as an effective way to keep TRON accounts safe and flexible to use across different use cases like:

• Institutional grade accounting security
• TRON resources marketplaces (Delegation / Un-delegation / Vote automation)
• Wallet as a Service
• Large holders & Exchanges
• Retail users willing to harden their accounts security

However, due to TRX price increases over time, the inherited cost of executing multisign transactions ($0.3 USD) as well as updating account permissions ($28.3 USD) is now considerably high, pushing users away from enhancing their accounts security and / or deterring their user experience while interacting with the TRON blockchain.

Analysis

While the current proposal improves user and dev experience there's also some potential security considerations we have to review.

Positive Impacts

• Lower the economic barrier to strengthen TRON users accounts
• Encourage users and developers to use multi-sign feature, enhancing security and security

Negative Impacts

Malicious actors can target unexperienced users to approve Ownership Account Permission , by reducing the cost the chances of users "blindly" signing a txn can increase.

Mitigations

• Improve UI warning mechanisms on wallets like recently adopted by Tronlink and others.
• Release education content amongst the community to increase awareness
• Currently, most scammers automatically fund victim accounts with 100 TRX to execute an ownership permission attack, thus, reducing the fee most likely won't make a difference on it.

I thereby invite anyone to discuss on this matter. Thanks!

[yanghang8612]

Given your proposal to reduce fees related to multi-sig transactions, should we analyze multi-sig transactions over the past period to illustrate the impact of this proposal on the average daily TRX burn rate and protocol revenue?

[simbadMarino]

I agree @yanghang8612 , good idea. I'm supporting with some stats by txn type in #834 so I can utilize the same for this one.
Thanks

[lopeed]

I fully support this proposal. The current multisig fees have become prohibitive for retail users, especially when considering the overall cost structure of the TRON resource model.

As highlighted, updating account permissions now costs around $31 USD, that's a massive barrier to adopting basic security features. For comparison, equivalent security mechanisms on other chains are either built-in at no extra activation cost or are significantly cheaper:

• Bitcoin: native multisig (P2SH or Taproot) with no fee beyond the standard transaction cost.
• Cosmos ecosystem (e.g., Osmosis, Juno): native multisig accounts with zero additional setup fees.
• Solana: native multisig programs that require only a minimal one-time rent (often < $0.01) and no separate "enable" fee.
• EVM chains with account abstraction (e.g., Starknet, zkSync): enable flexible security models without upfront costs.

In contrast, TRON charges a flat 100 TRX (≈$31) just to enable multisig permissions, plus an additional 1 TRX per approval a pricing model that hasn’t been updated since 2019 and now punishes retail users and developers alike.

Reducing the update fee to 8 TRX and the execution fee to 0.1 TRX would align these costs with the original intent of multisig: enabling everyone from retail users to agentic applications to secure their accounts without being penalized by TRX price appreciation.

Thanks for pushing this forward.

[halibobo1205]

They've been unchanged for 7 years while the TRX price has risen significantly, so an adjustment seems overdue.
One question, though: where does the 8 TRX number come from? Without a clear anchoring logic, we might end up revisiting this the next time TRX appreciates.
Also agree with @yanghang8612 that on-chain data analysis is necessary — better to finalize the numbers after reviewing historical transaction volume.

[abn2357]

100 TRX * $0.022 USD = $1.8
The calculation in the issue appears to be a clerical error.

[waynercheung]

Thanks for raising this topic. It may be helpful to clarify two implementation details first, so we make sure we are discussing the right pricing model.

From the current java-tron implementation, my understanding is:

1. UpdateAccountPermissionFee applies to AccountPermissionUpdateContract in general, so it seems broader than only “enabling multisig”.
2. MultiSignFee seems to be charged when an executed transaction has more than one signature, so it may be closer to a per-multisigned-transaction surcharge than strictly “per approval”.

If so, it may make sense to evaluate these two parameters separately, since one is a permission-update cost and the other is a recurring execution cost.

[simbadMarino]

They've been unchanged for 7 years while the TRX price has risen significantly, so an adjustment seems overdue. One question, though: where does the 8 TRX number come from? Without a clear anchoring logic, we might end up revisiting this the next time TRX appreciates. Also agree with @yanghang8612 that on-chain data analysis is necessary — better to finalize the numbers after reviewing historical transaction volume.

The suggested cost reduction comes from simply dividing cost by growth factor, which comes from: 31 / 2.2 = 14 . As we do not have any dynamic-non-TRX-price-independant algorithm to adjust fees on TRON so far this is the most straightforward way I could think of to adjust the fees.

Thanks for pointing out the error @abn2357 , fixed!

My thought process is a bit different on this @waynercheung , you are right in the sense that each seem to serve a different purpose, however, both parameters are intrinsically related by the defined threshold while updating the permission, but we could eventually split this into separate TIPs if community prefer this way. I will edit the title for clarity, thanks!

I will work on providing statistical data so we can take the best decision. Thanks all for your comments!

[waynercheung]

@simbadMarino

Thanks for clarifying the rationale, and for preparing the statistical data.

When the stats are ready, it may be especially helpful to break them out separately for:

• AccountPermissionUpdateContract usage / unique accounts
• transactions executed with more than one signature
• threshold distribution, if available
• the current TRX burn impact attributable to each parameter

That may help the discussion better assess whether the same scaling factor should apply to both parameters in practice, or whether they may eventually need to be tuned separately.

[abn2357]

Hello, @simbadMarino
Given the current reality that TRX is already inflationary, I believe it is more reasonable to adjust only the fees for account permission update transactions.
First, the frequency of such transactions is relatively low, so reducing their fees will not cause a significant drop in TRX burn; on the contrary, it may even attract more users to update their account permissions, thereby increasing TRX burn.
Second, it can encourage more users to use multi-signature transactions for security purposes, which will further increase TRX burn in this category.