Smooth experience when using bridged tokens (`PermittableToken` implementation upgrade)

General Gnosis Chain
1

Problem

PermittableToken, the contract implementing all token logic for bridge tokens from the OmniBridge causes some pain points with development experience.

Notably, there are multiple code-paths within PermittableToken that revert with no reason string, or custom error. This creates user-experience problems where a transfer (as an example), may Fail, and subsequently provides no input to the user as to what the actual problem is.

As an example, if Alice wants to send Bob 10 XYZ but only has a balance of 9 XYZ, her transfer will Fail. When Alice, being diligent, checks Gnosis Scan, her transaction just shows Fail - no error message.

While the above is trivially identifiable where the error is, the issue becomes more nuanced when a user may subsequently be importing CSVs and making transactions, where the CSV actually contains errors associated with rounding precision. While not an issue of Gnosis Chain’s specific making, debugging arbitrary Fail transactions requires non-trivial knowledge of stepping through the transaction with a debugger to see the failure point. A user shouldn’t be expected to do this.

Normally, token contracts are immutable, however due to the critical nature of the Omnibridge, the PermittableToken contract is perceived as somewhat of a “core” contract. To upgrade such a contract requires a hardfork of Gnosis Chain.

Solution

Ensure that all failure paths provide a reason (such as ERC20: Insufficient Balance etc).

Risks

Upgrading PermittableToken carries heavy risk as it affects all bridged tokens. Extreme care needs to be taken on keeping the code base auditable.

Enhancements

If it were decided to smooth the user experience, there are a couple of other features that could also be simultaneously implemented in order to greatly improve the Gnosis Ecosystem interoperability, notably:

  1. PermittableToken does not support ERC-1271 smart contract signatures for permit. While not required by EIP-2612 Permittable Tokens, enabling this support greatly improves the user experience for Safe users.
  2. A perhaps more controversial / less-implemented extension to be considered as well to implement is ERC-3009: Transfer With Authorization, such as that deployed in USDC’s FiatToken_V2_1 proxy implementation on mainnet. If this were to be implemented as part of this proposal, in addition to (1) above, it would be suggested to allow EIP-1271 authorization as well here. The advantage in this case is that a Safe could authorize multiple payments, (via signing a SafeMessage) and these payments could be pulled in various order, eliminating the nonce binding for transactions otherwise. The alternative here is to enable a Safe module.

The above 2 enhancements would greatly smooth the user experience for dealing with bridge tokens on Gnosis Chain.

3 Likes
2

Thanks for the proposal @mfw78 . As you mention, the risks with a hardfork affecting all bridged tokens is quite high. Therefore need to understand better the benefits.

  1. Better error handling
  2. Better user experience for Safe users

Are there any additional benefits to making this changes?

1 Like
3

The first is a bit difficult to understate. At the moment any transfer of an ERC20 token that doesn’t meet a balance or approval condition will just fail with no message. A quick search on the discord found this user within the last week suffering from this issue. This is one case, but it is not isolated.

To the following point, it would provide better user experience not only for Safe users, but also for any contracts implementing ERC-1271.

While I understand the risks associated with a hardfork, given that hardforks are already occurring on a basis of approximately twice per year, I think it is reasonable to integrate this work into an existing / low tech debt hardfork (ie. it should be considered for inclusion). The additional work for inserting sane error handling / messages is low, and the audit risk / debt is additionally low risk.

Most risk would potentially come from permit being made ERC-1271 capable, and potential use of ERC-3006 (and therefore time would be needed for downstream consumers of bridged tokens to provide feedback / assessment for potential security risks). Therefore, if a timeline were to be suggested, I think it would be reasonable for this to be a CFI for the next merge after Dancun.

Additionally, I think to inform the value of this proposal, a poll may be suitable?

4

Thanks for the additional context. I think it’s reasonable to prepare this change and have it ready for the next planned hardfork indeed.

Poll might be a good idea as well.