SDK: Support for depositor proxies #776
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Refs: #749
Pull request #760 introduced a possibility to embed 32-byte extra data within the deposit script. This simple change opens multiple possibilities. Notably, third-party smart contracts can now act as depositor proxies and reveal deposits on depositors' behalf. This way, proxy contracts receive minted TBTC and can provide extra services without requiring additional actions from the depositor (e.g., deposit it to a yield protocol or bridge it to an L2 chain). This, in turn, empowers third-party protocols to use tBTC as a foundation and propose additional value on top of it. The goal of this pull request is to facilitate the integration of such third-party protocols through tBTC SDK.
The
DepositorProxyinterfaceFirst of all, we are introducing the
DepositorProxyinterface that represents a third-party depositor proxy contract in a chain-agnostic way. A third-party integrator willing to relay deposits is expected to provide an implementation of this interface and inject it into the tBTC SDK.The SDK uses the instance of the
DepositorProxyto prepare the right deposit script (thus deposit BTC address) and notifies that instance once the deposit is funded and ready for minting. How minting is initialized depends on the proxy implementation thus this logic is abstracted as therevealDepositfunction exposed by theDepositorProxyinterface. This way, the SDK is responsible for the heavy lifting around deposit construction while the depositor proxy must only finalize the process by doing their own logic and, reveal the deposit to theBridgecontract.To facilitate the job for Ethereum-based proxies, we are also exposing the
EthereumDepositorProxyabstract class. This component can serve as a base for classes interacting with Ethereum depositor proxy contracts that relay deposit data to the EthereumBridge. TheEthereumDepositorProxyaims to make that part easier.The
initiateDepositWithProxyfunctionTo provide a single point of entrance to the depositor proxy flow, we are exposing the
initiateDepositWithProxyfunction. This function is available from the top-level SDK interface, alongside the regularinitiateDepositfunction triggering the non-proxy deposit flow. The signature of theinitiateDepositWithProxyfunction is similar toinitiateDeposit. The difference is that it expects an instance of theDepositProxyinterface. It also accepts optional 32-byteextraDatathat can be used to embed additional data within the deposit script (e.g. data allowing to attribute the deposit to the original depositor). TheinitiateDepositWithProxyreturns aDepositobject that represents the initiated deposit process.Usage
Here is a brief example illustrating what a third-party integrator should do to use their contract as a deposit intermediary.
Let's suppose the integrator implemented an
ExampleDepositorcontract that exposes arevealDepositOnBehalffunction which takes a deposit and reveals it to theBridgeon behalf of the original depositor:In that case, the off-chain part leveraging tBTC SDK can be as follows: