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
{{ message }}
This repository has been archived by the owner on Dec 5, 2021. It is now read-only.
https://github.com/enyalabs/OMGX_wallet/issues/22
Someone willing to swap on/off needs to ensure there is enough in the pool on the other side, otherwise they end up losing funds to the LP. This process has to be manual. There should be an external service which confirms this fact before someone can use the contracts.
Possible solutions
Some solutions to remove the external service and make it trustless could be-
Reserve tx - A ticket/reserve mechanism can be used where a tx is first sent to the LP on the withdrawal chain, this is to reserve the amount from the pool for a certain period of time, so that someone else couldn’t race out and clear funds from the pool before it can be withdrawn
A circular cross-domain tx - After supplying to L2 pool, a cross-domain tx is sent to withdraw from the L1 pool. An unsuccessful transfer on L1 ( i.e. if the L1 pool doesn’t have enough funds) could trigger another cross-domain tx back to the L2 pool, and allowing to take back the funds for a failed swap. There could be a chance to break this up into two separate tx considering the gas. Note, this could be a process to save funds for a rare case, and higher gas should be okay
The text was updated successfully, but these errors were encountered:
Issue
https://github.com/enyalabs/OMGX_wallet/issues/22
Someone willing to swap on/off needs to ensure there is enough in the pool on the other side, otherwise they end up losing funds to the LP. This process has to be manual. There should be an external service which confirms this fact before someone can use the contracts.
Possible solutions
Some solutions to remove the external service and make it trustless could be-
Reserve tx - A ticket/reserve mechanism can be used where a tx is first sent to the LP on the withdrawal chain, this is to reserve the amount from the pool for a certain period of time, so that someone else couldn’t race out and clear funds from the pool before it can be withdrawn
A circular cross-domain tx - After supplying to L2 pool, a cross-domain tx is sent to withdraw from the L1 pool. An unsuccessful transfer on L1 ( i.e. if the L1 pool doesn’t have enough funds) could trigger another cross-domain tx back to the L2 pool, and allowing to take back the funds for a failed swap. There could be a chance to break this up into two separate tx considering the gas. Note, this could be a process to save funds for a rare case, and higher gas should be okay
The text was updated successfully, but these errors were encountered: