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
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
@@ -61,7 +61,7 @@ While development for BOB Gateway is advancing rapidly, there are still some tra
- Liquidity providers (LPs) receive BTC directly from users on Bitcoin mainnet. As a result, the off-chain relayer cannot interfere with funds received by the LPs.
- The relayer is currently necessary to complete the user's intent (e.g. by submitting a Merkle proof of the BTC transaction to the on-chain light client, unlocking the LP's wrapped BTC). Since users cannot submit the proofs themselves yet, user funds are "stuck" whenever the relayer is offline. Users will be able to submit their own BTC proofs after we transition Gateway use a full Bitcoin light client and add functionality to protect LPs from potentially malicious strategy contracts.
- Another reason the relayer does not currently accept proof submissions directly from users is to prevent "liquidity sniping." The relayer will reject order requests from users if all available liquidity is reserved for outstanding orders; as a result, it is possible to reserve all available liquidity by submitting proofs, blocking Gateway's operation. We will address this vulnerability when we make it possible for anyone to submit a proof.
- Another reason that Gateway does not currently accept proof submissions directly from users is to prevent "liquidity sniping." If there were no relayer (i.e. users could reserve liquidity directly from the Gateway LPs for free before the user sends their BTC), it would be possible to reserve all available liquidity, blocking Gateway's operation.
- At the moment there is only one relayer. In addition to its other functionality, this relayer pays gas on the user's behalf so that the user doesn't need to make a transaction on BOB to complete the bridging process. Since a malicious actor could create a strategy designed to take advantage of the relayer (e.g. spend all of the funds available for gas fees), the process of adding new strategies to Gateway as well as decentralizing the relayer role are restricted by the BOB team until Gateway is upgraded as described above.
