You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
The PR to introduce versioned transaction support #777, introduces a UX bug for 99% of WalletConnect users. dApps are no longer able to read the supportedTransactionVersions field to reliably drop into a "legacy" transaction mode. This leads to a broken flow as users are left to find and manually toggle, when available, that setting.
To Reproduce
Take a wallet implementing WalletConnect but not Ottr
Expected behavior
Providing the appropriate supportedTransactionVersions given the underlying wallet. Can this be a dynamic feature check on the remote wallet?
supportedTransactionVersions should at least be reverted until the dust settles with supporting a potential proper interface to sign transaction #806
The text was updated successfully, but these errors were encountered:
idea: The wallets implement the CAIP-25 standard. As such they can signal to the dapp in the CAIP-25 response whether they support supportedTransactionVersions. Possibly it can also signal the value for this.
Describe the bug
The PR to introduce versioned transaction support #777, introduces a UX bug for 99% of WalletConnect users. dApps are no longer able to read the
supportedTransactionVersions
field to reliably drop into a "legacy" transaction mode. This leads to a broken flow as users are left to find and manually toggle, when available, that setting.To Reproduce
Take a wallet implementing WalletConnect but not Ottr
Expected behavior
Providing the appropriate supportedTransactionVersions given the underlying wallet. Can this be a dynamic feature check on the remote wallet?
supportedTransactionVersions
should at least be reverted until the dust settles with supporting a potential proper interface to sign transaction #806The text was updated successfully, but these errors were encountered: