Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove optional app tx fee #176

Open
fbwoolf opened this issue Nov 1, 2021 · 6 comments
Open

Remove optional app tx fee #176

fbwoolf opened this issue Nov 1, 2021 · 6 comments
Labels

Comments

@fbwoolf
Copy link
Contributor

fbwoolf commented Nov 1, 2021

We are currently implementing the new estimation fees into the web wallet, with this effort we are removing the ability for apps to set a custom fee for transactions. We need to remove it from the options here in conjunction with the work on:
leather-wallet/extension#1857

@unclemantis
Copy link

Negative 1.

I reject this feature as not an enhancement but as a restriction that further cripples dApp development and not allowing ease of functionality for users new to the stacks ecosystem. If a dApp developer is aware of a functioning fee rate for their contract call then why not allow the developer to set the fee instead of gambling on the fee estimation of stacks web wallet? During times of high mempool volume such as NFT mint / claim releases wouldn't it make sense to allow the dApp developer to set a fee for their contract call at a rate a la carte based on miner transaction execution fee requirements at the time of the contract call instead of the web wallet setting a fee rate that is below the current mempool traffic load and requiring the user to increase the fee after initial broadcast of the transaction? This causes bottlenecks and an increase in TX Support requests throughout the ecosystem in multiple Discord channels and guilds.

I am currently working on a discord bot and dApp to help end users to pinpoint the reasons why their transactions are pending for over an hour during high mempool activity periods.

One of the suggested solutions that I have been developing was to allow a dApp to pull in the sender's mempool transactions and comparing the fee rate to a suggested fee rate that has been calculated and determine if the transaction's fee rate needs to be increased to meet the demands of the miners.

Unfortunately after countless hours spanning a number of weeks seeking a way for the dApp to deserialize a pending transaction that the connected wallet has broadcast,, edit the fee to a larger value and then opening the wallet for user confirmation, signing and submission using the same nonce as the existing pending transaction, I have failed miserably at finding a solution for this.

Please add an interface to the connect library which allows the passing of an edited stacks transaction. Suggested function name could be openUpdateContractCall / doUpdateContractCall, or perhaps openIncreaseFee / doIncreaseFee.

Also please allow open and do methods to set a custom fee rate through stxTransfer / contractCall / deployContract to reduce the amount of pending transactions with no chance in heck to be executed by the miners during high mempool volume rallies and do reduce the rate of duplicate contractCalls from impatient users.

Please take my suggestions to heart. Stacks is my home and has been for a year and a half. I have been through thick and thin and have contributed countless hours to stacks support channels, one on one DM support and also one on one onboard training for new developers who want to set up their rigs and get to building clarity contracts and node apps.

Thank you for your consideration.

unclemantis.btc

@kyranjamie
Copy link
Contributor

Thanks for sharing your thoughts @unclemantis

The use case you describe is legitimate and definitely to be considered. One of the motivations for killing this feature, though, is that it does introduce a scope for abuse, or unintended error.

What happens when an a dev sets the fee to 1,000 STX? The wallet needs to handle some "too high" case. Perhaps, instead, dapps could suggest a fee, requiring explicit user opt-in to use that fee?

@unclemantis
Copy link

fee suggestion is what I am implying for initial broadcast. second would be like I described an IncreaseFee call with a payload of a pending tx that opens the Increase fee draw modal where the user would set the fee to the suggested fee rate displayed on the dApp dashboard next to the open button.

thoughts?

@unclemantis
Copy link

In the end I want increased ease of use as well as keep user control and safety intact.

@markmhendrickson
Copy link
Contributor

Thanks @unclemantis for these detailed requests.

I've created the following issue in the wallet repo to track it there for the custom fee setting request in particular: leather-wallet/extension#2566

If the wallet is suggesting unhelpfully low fees to users, that's a root problem that we ought to solve in the wallet itself. Though it's great to hear you're working on an app that helps with diagnostic information and assistance for transactions in any case, so we'd love to support it.

We'd also love to check out the app to see how it all works whenever you feel it's ready to share!

@unclemantis
Copy link

We'd also love to check out the app to see how it all works whenever you feel it's ready to share!

I am way over time vested and budget with this project due to the lack of support in existing Hiro products and middleware. It is not the fault of Hiro by any means. You guys have a lot going on with a lot of micro-issues to support multiple developers. I am just very good at creating solutions to problems that exist that others just push aside as inconveniences and just work around. I tend to go at the jugular. LOL.

Would love to add you to the DEMO group. Feel free to find me on Discord through Stacks guild and mention me if we have not already spoken. I believe we have though. I will check.

Let's continue this topic in the new issue you created.

Cheers!

unclemantis.btc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: 📋 Backlog
Development

No branches or pull requests

6 participants