Fees understated on ShapeShift vs Coinbase

[MBMaria]

Overview

When doing the same transaction on shapeshift and coinbase, the fee stated on shapeshift is less than what is actually charged

References and additional details

Coinbase eth to usdc transaction:

ShapeShift eth to usd transaction:

Acceptance Criteria

Fees should be accurately stated and charged

Need By Date

No response

Screenshots/Mockups

No response

Ownership

• If my bounty needs engineering or needs product I have added the respective labels on the right
• As the sponsor of this bounty I will review the changes in a preview environment (ops/product) or review the PR (engineering)

Estimated effort

No response

Sponsor / Stakeholder

No response

Bounty Hunters

• Join our discord
• Include an expected timeline for you to complete work in the work plan when you apply for this bounty!
• Please refer to this link for some basic info
• Please do not start work on this issue until you are approved in Gitcoin.

[0xean]

Do we know what wallet was used for this tx? Has operations been able to reproduce this?

[MBMaria]

i was able to reproduce twice yesterday using native wallet and it was @tolltalcrypto who brought it to our attention, also noticing the variation in fee. Let me know if you need any other info @0xean

[kaladinlight]

This situation is a bit chicken and egg and has been the cause for constant issues surrounding accuracy. The problem being the network fees we show are based on rough estimations at quote time provided by the upstream apis and not necessarily actual estimations from the node itself due to potential native asset balance and/or approval constraints. I see two options here that we can discuss:

1. Show the rough estimation at quote time, and then add logic to update and/or poll gas estimation at the confirm step until the transaction is broadcast in which it will freeze the final broadcast network fee state and stop updating. This would probably result in the closest to accurate we can hope for at the cost of potentially a big change between the quoted network fee and initial confirm step network fee, and constantly updating UI. This may also be a decent undertaking given the nature and setup of the swapper.

2. Leverage the network fee estimated range similar to coinbase in the above example. We use the returned gasLimit from the quote as the low end, and show a 2x (or some agreed upon multiplier) buffer for the high end assuming the final network fee will hopefully fall somewhere in that range. Then it would just be a question of what value to use for the native balance check to ensure the user has enough fees to pay for gas (high end? middle?)

[0xean]

@kaladinlight - would love to chat on this for a few today during the call.

[0xean]

tabled for further discussion with product on the best outcome here.

Concerns are technical complexity vs JIT updates with final display to the user so that they only pay exactly what they see (at worse) vs signing a payload they don't have complete visibility into.

[gomesalexandre]

@MBMaria Can you give this a retest when testing #8432 in release? We now have JIT updates which is as accurate as it gets!