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
The bridge seems to only send tokens to the same address as the sender address, only on the opposite network. For example if the user is sending USDT from 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 on Ethereum then the bridge will send RUSDT to 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 on the RSK network.
However, some RSK wallets (such as Liquality) do not generate the same RSK address as the Ethereum address. This results in difficulty for users of these wallets when using the bridge, who must then figure out a series of complicated steps to export their seed, import in another wallet, find the correct derivation path the addresses were generated on, etc.
Solution
Allow users to input a custom receiving address for the transaction they are sending across the bridge.
The text was updated successfully, but these errors were encountered:
Hi John we are aware of this issue, we are working to allow sending funds to other addresses on version 2, this will be released in this quarter. It's taking us a while as there are security concerns in case you send the funds to a contract on the other network, we are in the process of auditing the code.
Thanks for contributing! :)
Problem
The bridge seems to only send tokens to the same address as the sender address, only on the opposite network. For example if the user is sending USDT from
0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045
on Ethereum then the bridge will send RUSDT to0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045
on the RSK network.However, some RSK wallets (such as Liquality) do not generate the same RSK address as the Ethereum address. This results in difficulty for users of these wallets when using the bridge, who must then figure out a series of complicated steps to export their seed, import in another wallet, find the correct derivation path the addresses were generated on, etc.
Solution
Allow users to input a custom receiving address for the transaction they are sending across the bridge.
The text was updated successfully, but these errors were encountered: