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

High transaction fees when paying with Custodial wallet without metatransaction #4227

Open
olgapod opened this issue Feb 3, 2025 · 1 comment · May be fixed by #2448
Open

High transaction fees when paying with Custodial wallet without metatransaction #4227

olgapod opened this issue Feb 3, 2025 · 1 comment · May be fixed by #2448
Assignees
Labels
bug Something isn't working Priority: P1 (High)

Comments

@olgapod
Copy link
Contributor

olgapod commented Feb 3, 2025

Description:

When paying with a Custodial wallet (Google, Discord, or GitHub) with metatransactions disabled, the transaction fees are significantly higher compared to using non-custodial wallets like Metamask, Coinbase, or Rabby under the same conditions.

Steps to reproduce

  1. Log in with Google, Discord, or GitHub.
  2. Disable metatransaction (open manage account -> advanced -> disable "Colony pays my gas fees" toggle.)
  3. Go to colony and create simple payment with permission.
  4. Pay attention to the transaction fee.
  5. Log in with Metamask, Coinbase or Rabby wallets.
  6. Disable metatransaction (open manage account -> advanced -> disable "Colony pays my gas fees" toggle.)
  7. Go to colony and create simple payment with permission.
  8. Pay attention to the transaction fee.
  9. Try other motions.
Image Image Image Image

Expected behaviour

  • Transaction fees should be consistent and reasonable across both custodial and non-custodial wallets when metatransactions are disabled.
  • No significant fee difference between wallet types under the same conditions.

Actual behaviour

  • Transaction fees are much higher when paying with a Custodial wallet (Google, Discord, GitHub) compared to non-custodial wallets like Metamask, Coinbase, or Rabby.
@olgapod olgapod added bug Something isn't working Priority: P1 (High) labels Feb 3, 2025
@JoinColony JoinColony deleted a comment Feb 3, 2025
@JoinColony JoinColony deleted a comment Feb 3, 2025
@JoinColony JoinColony deleted a comment Feb 3, 2025
@rdig rdig self-assigned this Feb 3, 2025
@rdig rdig linked a pull request Feb 3, 2025 that will close this issue
@rdig
Copy link
Member

rdig commented Feb 3, 2025

So I took some time today and investigated this as it sounded as a quite problematic issue.

Turns out, that, while indeed it looks alarming, it's actually "just an UI issue"

So what happens is that the actual gasFee (maxPriorityFee in this case) that we send is the same, however, each wallet type uses their own internal "oracle" (service that provides an exchange rate for gas) to get the ETH value to multiply with the gas fee we provide in coming up with that "user-friendly" FIAT estimate amount.

Metamask

Image
Image

Custodial Wallet

Image

This can be seen better by using a network for which neither wallet type (metamask or embedded) can provide a native exchange rate for ETH, in which case, both will display just the ETH value that the transaction is sending, and not convert it to FIAT

Now, I can't really prove it definitely, since neither service provides much information in this regard, and how they fetch their exchange rate, but what I "think" happens here is that the custodial wallet (dynamic) is using the Mainnet ETH exchange rate vs. the ETH on Arbitrum Sepolia rate (which might very well be true, since Arbitrum Sepolia is an testnet)

I will not pursue this any further, as the actual gas price values are correct, it's just a user display issue, which we can't control anyway.

I will keep this issue open until we merge #2448 at which point it will be automatically closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Priority: P1 (High)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants