-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SDK: Support for depositor proxies #776
Merged
Merged
Conversation
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
Here we introduce the concept of a `DepositorProxy` contract. A `DepositProxy` can reveal deposits to the Bridge, on behalf of the user (i.e. original depositor). Once minting is completed, the `DepositProxy` receives minted TBTC and can provide additional services to the user, such as routing the minted TBTC tokens to another protocols, in an automated way. To expose this feature to the SDK users, we are adding a new `initiateDepositWithProxy` function. This function triggers the deposit flow with support of the given `DepositProxy`.
If extra data is set, the deposit should be revealed using the `revealDepositWithExtraData` function of the Ethereum `Bridge`. Otherwise, the regular `revealDeposit` should be used.
The `EthereumDepositorProxy` is a base class meant to facilitate integration with Ethereum depositor proxies.
tomaszslabon
approved these changes
Jan 19, 2024
nkuba
approved these changes
Jan 19, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
DepositorProxy
interfaceFirst of all, we are introducing the
DepositorProxy
interface 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
DepositorProxy
to 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 therevealDeposit
function exposed by theDepositorProxy
interface. 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 theBridge
contract.To facilitate the job for Ethereum-based proxies, we are also exposing the
EthereumDepositorProxy
abstract class. This component can serve as a base for classes interacting with Ethereum depositor proxy contracts that relay deposit data to the EthereumBridge
. TheEthereumDepositorProxy
aims to make that part easier.The
initiateDepositWithProxy
functionTo provide a single point of entrance to the depositor proxy flow, we are exposing the
initiateDepositWithProxy
function. This function is available from the top-level SDK interface, alongside the regularinitiateDeposit
function triggering the non-proxy deposit flow. The signature of theinitiateDepositWithProxy
function is similar toinitiateDeposit
. The difference is that it expects an instance of theDepositProxy
interface. It also accepts optional 32-byteextraData
that can be used to embed additional data within the deposit script (e.g. data allowing to attribute the deposit to the original depositor). TheinitiateDepositWithProxy
returns aDeposit
object 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
ExampleDepositor
contract that exposes arevealDepositOnBehalf
function which takes a deposit and reveals it to theBridge
on behalf of the original depositor:In that case, the off-chain part leveraging tBTC SDK can be as follows: