RFC 8: Cross-chain Tokenized Threshold BTC #542
Conversation
pdyraga
requested review from
beaurancourt,
dimpar,
lukasz-zimnoch,
mhluongo,
michalinacienciala,
michalsmiarowski,
nkuba,
r-czajkowski,
sashatanase,
tomaszslabon and
eth-r
No changes to the content, just moved the "Minting on L1" section higher to be right after the "Overview". This should help to understand the process from the user's perspective better.
docs/rfc/rfc-8.adoc
Outdated
| For the sake of simplicity, we will implement the gateway using the Plain token | ||
| transfer approach. If the DAO decides to add another way of minting the token in | ||
| the future, we can implement another gateway contract based on the Custom | ||
| message gateway given the canonical token accepts multiple minting authorities. |
There was a problem hiding this comment.
We had a conversation with @conorpp and we decided this is not the optimal approach. The initial implementation would be simpler only in theory as the upgrade path to the custom-message approach would be really complicated. We decided to spend the time better on implementing the custom-message solution from the beginning and being able to support multiple minting authorities from day one.
I will rework this part of the RFC.
| bridges. Each of these token variants soaks up valuable liquidity that could be | ||
| better utilized elsehwere. | ||
|
|
||
| Because tBTC is minted "centrally" on Ethereum L1, we can do better. By |
There was a problem hiding this comment.
Does it mean that we could surpass L1 and mint directly from BTC to ETH L2? instead of BTC-->L1--->L2 just have BTC --->L2
There was a problem hiding this comment.
This proposal assumes TBTC is minted on L1 first, always.
There are ways to mint directly on L2 but this is something for the future as it is quite complex and requires remote mint and burn implementation for L1<>L2 bridging.
| we'll start as simply as possible. Every tBTC mint will continue to require | ||
| transactions on Ethereum from the user — first a deposit reveal, then a lock | ||
| to bridge to another network. | ||
|
|
There was a problem hiding this comment.
Does this mean that if I want to mint tBTC on say Optimism I need to first pay gas on Ethereum and also have Optimism ETH?
| A generic implementation of the token will be provided in the `solidity` smart | ||
| contracts directory. |
There was a problem hiding this comment.
Do you mean this repository https://github.com/keep-network/tbtc-v2/tree/main/solidity?
Could we consider placing it in a separate package, so we don't need to install all the dependencies of @keep-network/tbtc-v2?
Perhaps https://github.com/thesis/solidity-contracts would be the cleanest place to hold it? Or a dedicated subdirectory in tbtc-v2 repository with an independent NPM package?
There was a problem hiding this comment.
I would go with keep-network/tbtc-v2/solidity for simplicity. We would need to import this repository and all transitive dependencies for L1 TBTC token artifact anyway.
| └── PolygonTBTC.sol | ||
| ``` | ||
|
|
||
| `L2TBTC.sol` is an abstract contract doing all the heavy lifting: upgradeability, |
There was a problem hiding this comment.
Matching contract addresses on different chains and networks seems convenient but brings a risk of confusion. Unique addresses are another level of protection for users/devs to ensure they are interacting with the right chain/network. It protects against accidentally locking funds in a contract deployed on an undesired network.
Some of the implementation details will have to be revisited during the implementation. They are important for bridging to work but not essential for the RFC. This RFC focuses on a high-level details and code organization/architecture.
Let's not keep it Wormhole-specific and be explicit other cross-ecosystem bridges may be added as well in future.
A note for future-us!
| chain that require interoperability. These bridges are both the most important | ||
| and the trickiest to support. | ||
|
|
||
| Each native bridge has its own way mechanism to manage an Ethereum-to-chain |
There was a problem hiding this comment.
Probably
| Each native bridge has its own way mechanism to manage an Ethereum-to-chain | |
| Each native bridge has its own mechanism to manage an Ethereum-to-chain |
| └── PolygonTBTC.sol | ||
| ``` | ||
|
|
||
| `L2TBTC.sol` is an abstract contract doing all the heavy lifting: upgradeability, |
There was a problem hiding this comment.
I like zero-padded contract addresses across chains... It saves and gas and it's just nice. But I agree we can keep moving.
Part of #542 This PR is a continuation of tBTC expansion to L2s - BASE chain. Code was largely copied from the existing cross-chain/* modules with some naming modifications, addresses and chain ids. It creates a new cross-chain/base module to bring tBTC to BASE with the help of Wormhole. Here's a diagram to illustrate the flow ``` +----------------------------+ +-------------------------------------------------------------------+ | Ethereum | | Base | | | | | | +----------------------+ | | +----------------------+ +---------------------+ +----------+ | | | Wormhole TokenBridge |--|---------|--| Wormhole TokenBridge |--| BaseWormholeGateway |--| BaseTBTC | | | +----------------------+ | | +----------------------+ +---------------------+ +----------+ | | | | | +----------------------------+ +-------------------------------------------------------------------+ ``` - `Wormhole TokenBridge` on Ethereum - holds all `TBTC` bridged to BASE. This is an external contract created by the Wormhole team. - `Wormhole TokenBridge` on BASE - mints Wormhole wrapped `TBTC` ie. `wormholeTBTC`. This is an external contract created by the Wormhole team. - `BaseWormholeGateway` on BASE - acts as a vending machine that wraps and unwraps `wormholeTBTC` to the canonical `tBTC` token on BASE. This is an upgradable Gateway behind OZ transparent proxy. The Threshold team creates it. - `BaseTBTC` canonical `tBTC` token on BASE. It is upgradable behind OZ transparent proxy. The Threshold team creates it. All the ownership of Threshold-created contracts is transferred to the Threshold governance including a proxy admin ownership. A couple of things to pay closer attention at: - addresses under the `external/` dir - gateway address to a wormhole chain id: `30` - gateway addresses to other wormhole chains id: `23 - Arbitrum`, `24 - Optimism`, `5 - Polygon` - Goerli BASE and Mainnet BASE chain ids: `84531` and `8453` ## Deploy on BASE testnet / mainnet Create a `.envrc` file and include the following: ``` export L2_CHAIN_API_URL=<API_URL> // e.g. "https://goerli.base.org" export L2_ACCOUNTS_PRIVATE_KEYS=<0xOWNER_PRIV_KEY> export BASESCAN_API_KEY=<API_KEY> // needs to be created on [basescan](https://basescan.org/) ``` ```sh yarn deploy --network <network> ``` where `network` can be: - `baseGeorli` // testnet - `base` // mainnet ## Useful links: https://docs.base.org/network-information/ https://docs.wormhole.com/wormhole/supported-environments/evm#base TODO: - [ ] Register TBTC on BASE using Portal on [Testnet](https://testnet.portal-bridge-ui.pages.dev/18c38dbb6a/#/register) and [Mainnet](https://www.portalbridge.com/#/register). After that replace the address in `BaseWormholeTBTC.json` under `external/base` ~and `external/goerliBase`~ with a newly registered token.
The goal of this proposal is to enable efficient cross-chain tBTC liquidity.
In the Ethereum ecosystem, that means bringing Bitcoin to L2s and sidechains like Arbitrum, Optimism, Polygon, Avalanche, and Binance Smart Chain. In the Cosmos ecosystem, that means Bitcoin on IBC-enabled zones (chains) like Osmosis and Penumbra. And in newer ecosystems, that means chains like Solana, Aptos, and Sui.
Efficiency requires minimizing liquidity fragmentation by avoiding the need for tBTC wrapper tokens by each chain and bridge. This situation quickly leads to an
n*mproblem, where liquidity onnchains is divided betweenmbridges. Each of these token variants soaks up valuable liquidity that could be better utilized elsehwere.Because tBTC is minted "centrally" on Ethereum L1, we can do better. By deploying a canonical token on each chain, we can ensure the supply of tBTC remains sacrosanct, while enabling quick, interoperable cross-chain bridges and localizing ecosystem risk.