[Proposal] Deprecate Seigniorage Reward Policy and Increase Gas Fees by 5x

By all means, you are welcome to scrape all transactions and match each to the spot price it was actioned at the time.
If you wait a bit longer I’ll give you the scraped transactions for the period to save you time so you don’t start from scratch :slight_smile:
I am looking for the ballpark population of the CP to ascertain if x5 (as the proposal says) is enough or maybe should be higher.

The calculations he did last month? US timezone format?


@wrapped_dday would really appreciate it if you could clarify and give us some inputs here.

when you withdraw rewards fee is in ustc. also when you stake the default is in ustc. Same when you swap a token to another.
What gas fees you mean? The equivalent in lunc or something else?
So if it is the equivalent, say
for delegate is 0.179122 USTC
for withdrawing rewards is 1.12066 USTC
for swaping is 0.10819 USTC (+tax)

Hi @terraki, I am looking to track down the portion of the fees that make it into the community pool based on the community_tax parameter of 50%. There are all sorts of fees collected LUNC/USTC etc. I am focusing on LUNC so I limit the search field.

I am still scratching my head about it tbh. The below seems to be inaccurate as well, I cannot cross-reference some transactions so I have to assume it’s wrong:

Back to the drawing board…


yeah the questions is what is the ratio lunc/ustc in the original post? meaning how did they calculate the lunc

1 Like

That’s a very good question, we tend to focus only on the LUNC wallet in our CP, not the others.

The check and this proposal are only taking into account the LUNC wallet in the CP; I will check the USTC allocation as well once I have the chain data and figure out how the allocation works.

1 Like

Please leave all political squabble and hate talk out of the post.

  1. What does the exchanges have to do with it? Exchanges will face the fact that there is a sales tax. And everything. Then traders will decide whether to trade these assets or not. I believe intraday rapid shooters will go away, but medium- and long-termers will come. And a lot of. The price will rise. The money supply is shrinking. Exchanges will be glad to
  2. As for legality. Are there laws prohibiting the introduction of a commission for trading?
  3. The tax should be on any sales of LUNC, not only on exchanges.
  4. If the goal is really to reduce the money supply to 10 billion, there is simply no other solution. Let the gas fee go to the developers’ rewards, and the sales tax to the incineration address. And no reproduction of coins

I wonder why we cannot remove burn tax and include in tax fee like other L2 chains ETH, polygon etc…

Some fresh analysis to show CP growth in the last epoch (excluding the recent mint):

CP balance as on:

  • 2nd Jan - 975,974,001 LUNC
  • 3rd Jan - 980,174,504 LUNC
  • 4th Jan - 982,452,683 LUNC
  • 5th Jan - 984,144,592 LUNC
  • 6th Jan - 985,845,537 LUNC

This indicates an average increase of ~2.5M LUNC per day. At 5x, this would generate ~375M LUNC per month in the CP - enough to cover dev costs, while still keeping gas prices competitive and offering higher rewards to delegates.


@dfunk Sounds great, awesome work! The vote is looking good so far.

1 Like

Hello all,

Upon further investigation into on-chain data and gas fees, an unusual bug has been found. This bug seems to be coming from TrustWallet.

For reference, please consider the following transaction: https://finder.terra.money/classic/tx/124EE244991EFB3E1154E2EA378D556D1447648971DCACE3F7F5AB21F8B9C5A8

The tx fee charged on this transaction is: 3,000,006.870568 Lunc

However, if we calculate the gas fees using the formula, fees = gas limit * gas prices, we get 1,212,810 * 5.665uluna = 6.87 Lunc

This discrepancy does not just happen with this transaction, but across multiple transactions from TrustWallet. TrustWallet is currently being informed of this issue.

In light of this bug, please consider revising your vote on Proposal 11242, until this bug has been resolved and a more informed decision can be made.

Proposal 11243 is not impacted by this bug, and can be continued to vote on as usual.

Apologies for the inconvenience and thank you for your understanding.


Apart from the fact that it’s gonna pass in a day, can you please give us some more details?

  1. You are saying that fees being charged, is less for TW? How is this happening exactly? The tracker isn’t tracking it properly? Is there a calculation mistake in the code?

  2. Is the L1 team looking into this for a possible fix? Have you informed them?

  3. How exactly is 11242 impacted by this? You mean to say that if we stop reminting this problem will persist?

What seems to be happening is that TrustWallet is charging an additional 0.2% of the transaction value, half of which is going to the CP. But this would be best answered by TrustWallet.

Yes, @ek826 has been informed.

There is no impact as such if you voted to stop re-minting. However, the increase in gas fee alone may not fully substitute the dev funding in light of this bug. However, it should still help.


Thanks for the clarification and transparency. 5x is still more than we have now!


We had taken down ‘Total Fees Accrued’ chart after @dfunk notified us about the discrepancy with community pool data.

After multiple rounds of debugging with @dfunk, we have figured out the issue. The tx fees that we query for every transaction from the lcd also includes the burn tax amount. The data you see in our chart is this total amount. But, the 50% that goes to community pool is excluding the burn tax. Hence the mismatch

‘Total Fees Accrued’ chart is back with a disclaimer - StakeBin | Terra Classic
We have a new chart to track community pool - StakeBin | Terra Classic

Sorry for the confusion!


Thanks for the clarification @StakeBin - that really helps! And also for the new Community Pool dashboard.

I believe this is the biggest hinderance in estimating transaction fees from gas. @ek826 could you look into separating the transaction fees from burn tax and the transaction fees from gas at the lcd api level? This would help get the much needed transparency.


Are you saying that if

  1. I wanted to vote YES , because I feel 5x is not too high that I voted right.
  2. I wanted to vote NO, because I feel it’s too high, that I need to reconsider?

In any event I have already voted.

The gas fee will/may not be sufficient to fund the CP , so a vote of YES on proposal 11243 will definitely affect the funding of the CP. There will be $0.00 going to the CP from the 0.2% on-chain tax. Funding of the CP was the original intent of proposal 11111. If the vote is NO on proposal 11243, then proposal 11111 will still be the law of the LUNC land and 10% of the 0.2% burn tax will go to the CP. There will be no minting as explained in an @ek826 article on the split ratio using a hot-fix.

Am I correct?

Hi all,

The analysis data used to uncover the bug and was used to prove the case at hand is available in the database file chainsql6.db - Google Drive

The database is sqlite3 so you can use any number of freeware GUIs or CLI to interact with it. I would recommend SQLiteStudio (also freeware).

There are two views created (scrape_uluna_fees, scrape_uusd_fees) from the data which append three additional (calculated) columns used for the analysis and I believe come in handy when trying to search certain conditions in the data.

Again, the ultimate outcome of the analysis comes does to what @dfunk said earlier

If I can put this in one line would be: “TrustWallet users are the most hardcore Tax BURN initiative supporters amongst us”

Happy hunting!

1 Like

If your reason for voting was purely to stop lunc re-mint (as is the case for most), then there is nothing to re-consider. If however, your reason for voting was to fully substitute the mint with gas fee, then you may want to re-consider, since the gas fee may not completely substitute the mint due to the data discrepancy issues highlighted earlier.

I believe that most people have voted to stop lunc re-minting so there would be nothing to re-consider for most.

This is inconclusive due to the aforementioned data issues.

Like Ed mentioned here, we will need to do a post-analysis to see what actually happens due to the data discrepancies.