Bridges Don't Support Multiple Native Tokens, Which May Lead to Incorrect Bridging
Currently, the system design does not support the scenarios where native tokens with the same addresses (which is possible with the same deployer and nonce) on different layers can be bridged.\\nFor instance, Let's consider, there is a native token `A` on `L1` which has already been bridged on `L2`. If anyone tries to bridge native token `B` on `L2` with the same address as token `A` , instead of creating a new bridge on `L1` and minting new tokens, the token bridge will transfer native token `A` on `L1` to the `_recipient` which is incorrect.\\nThe reason is the mappings don't differentiate between the native tokens on two different Layers.\\n```\\n  mapping(address => address) public nativeToBridgedToken;\\n  mapping(address => address) public bridgedToNativeToken;\\n```\\n\\n```\\nfunction completeBridging(\\n address \\_nativeToken,\\n uint256 \\_amount,\\n address \\_recipient,\\n bytes calldata \\_tokenMetadata\\n) external onlyMessagingService fromRemoteTokenBridge {\\n address nativeMappingValue = nativeToBridgedToken[\\_nativeToken];\\n address bridgedToken;\\n\\n if (nativeMappingValue == NATIVE\\_STATUS) {\\n // Token is native on the local chain\\n IERC20(\\_nativeToken).safeTransfer(\\_recipient, \\_amount);\\n } else {\\n```\\n
Redesign the approach to handle the same native tokens on different layers. One possible approach could be to define the set of mappings for each layer.
```\\n  mapping(address => address) public nativeToBridgedToken;\\n  mapping(address => address) public bridgedToNativeToken;\\n```\\n