The idea of this issue is to implement a support of meta transactions on the mediators contract as so bridged tokens (or native tokens permit()) could be triggered for the transfer without the necessity in the direct interaction with the contracts from the user side.

For example, the interaction flow could be like the following:

• the user is requested to sign a message which could be used to approve a particular account to use transferFrom functionality of the token contract
• the message and the signature are incorporated into a call of an extended version of relayTokens/relayTokensAndCall
• some agent sends a transaction with the extended version of relayTokens/relayTokensAndCall to the mediator contract
• the mediator contract uses the message to get the approval for itself to use transferFrom
• the mediator contract picks the token and proceeds with the action to complete the token transfer

Consider to support fungible tokens implemented with the EIP-1155 standard.

Several notes:

1. Both single mode and batch mode must be supported.
2. Consider to have more than one minter allowed for the bridged token (e.g. through an intermediate minter contract). The main idea is to allow FT OB and NFT OB mint tokens on the same EIP1155 token contract.
3. Consider the following implementation of meta-transactions

The set of changes could be shared with omni/omnibridge-nft#24.

Since now the Fee Manager is a separate module, the public methods provided by the mediator before (like calculateFee) are accessible in different way -- through the fee manager contract. It means that the compatibility with the previous version of the mediator contracts is broken. That's why the major value must be increased in the getBridgeInterfacesVersion method.

https://github.com/poanetwork/omnibridge/blob/ea0ffa6f015da024306d80f61bd271c4268b1f7a/contracts/upgradeable_contracts/components/common/OmnibridgeInfo.sol#L34

There is a set of modules which were extracted from the OmniBridge contracts to reduce the deployed bytecode as so OB uses them as external contracts:

• TokenFactory
• MultiTokenForwardingRulesManager
• OmnibridgeFeeManager
• SelectorTokenGasLimitManager

There is also a module which is deployed by the token factory: TokenProxy

Currently it is hard to discover a difference between the previous version of a deployed version of a module and the module in the repo. It could be used, for example, to identify if the module needs to be redeployed.

Consider to introduce versioning for the modules listed above. So, when the code of a module is changed, the version is updated also. That's why the next step to identify whether the module needs to be re-deployed is trivial.

Initially, when the permit() functionality was integrated in the bridged token contract the EIP-2612 standard did not exist. That's why the permit() method was copied from the MakerDAO DAI token.

Currently, EIP-2612 looks finished. So, it makes sense to port the implementation of the permit() method from the standard to the bridged token contract. But the current implementation of permit() must be preserved moreover its selectors differs from the standard's selector.

https://github.com/WETH10/WETH10/blob/main/contracts/WETH10.sol can be used a referenced implementation.

Currently the suffix added to the token name is hardcoded in the contracts:

https://github.com/poanetwork/omnibridge/blob/ea0ffa6f015da024306d80f61bd271c4268b1f7a/contracts/upgradeable_contracts/ForeignOmnibridge.sol#L149-L151

https://github.com/poanetwork/omnibridge/blob/ea0ffa6f015da024306d80f61bd271c4268b1f7a/contracts/upgradeable_contracts/HomeOmnibridge.sol#L199-L201

Consider research a way how to support more suffixes "from xDai", "from Mainnet", "from BSC".

The functionality of the fixMediatorBalance method was designed to allow for the extension admins to correct the issue with the token balances if the tokens were sent to the mediator improperly.

But the current implementation only works if the token was bridged to another side of the bridge and then returned back.

https://github.com/poanetwork/omnibridge/blob/ea0ffa6f015da024306d80f61bd271c4268b1f7a/contracts/upgradeable_contracts/BasicOmnibridge.sol#L224

Address the issue by removing this check and using the same method to generate the message call on the opposite side of the bridge how it is done in the _prepareMessage method:

https://github.com/poanetwork/omnibridge/blob/ea0ffa6f015da024306d80f61bd271c4268b1f7a/contracts/upgradeable_contracts/BasicOmnibridge.sol#L316-L327

Consider to add a task for the GitHub action similar to https://github.com/poanetwork/tokenbridge-contracts/blob/cdef2c6d696e46677a9125a064ab6c8c514bfc9d/.github/workflows/main.yml#L74-L92 to publish the docker image with the scripts and compiled contracts to simplify the deployment process.

Consider to use the configuration admin (owner) of the mediator contract to allow to modify parameters in the following external modules instead of initializing their own admins:

• MultiTokenForwardingRulesManager
• OmnibridgeFeeManager
• SelectorTokenGasLimitManager

It will simplify the migration to new owner if it is required.

Currently there are three modules serving some aspects of the bridge contracts configuration:

• the fee manager
• the gas limit manager
• the forwarding rules manager

These modules are implemented as a separate contracts and the bridge contract calls the modules' methods to get/store some information.

During the bridge usage the modules could collect lots of configuration data. But if an issue is found in the code of the modules they need to be updated. Since current contracts of the modules do not support the upgradable pattern, it means that the bridge admins could be required to perform lots of transactions to migrate the state from the old version of the module to the new one.