Hey guys, as you might know, launching in multiple L2s is one of the main priorities of the team to reduce the gas friction for some users while making Cryptex protocol more accessible. One of the issues of just deploying the same contracts on every protocol is that we will end with different TCAP tokens with different prices depending on secondary market liquidity, for example, pTCAP - $200, arbTCAP $210, oTCAP $250, and mainnet TCAP $230.
A fix for this is making the whole protocol interoperable, meaning that you can mint/burn in one layer and mint/burn in another, this opens the possibility for arbitrage opportunities multichain helping to reduce the prices distinctions.
We are discussing with the team several implementations of this and wanted to open it for discussion with the community to see what approach makes more sense:
Wrapper Vault Strategy
Users can use the bridges on mainnet to send their TCAP to L2 (minting a bTCAP token). User then can use an special vault to turn their bTCAP into l2 TCAP on a 1:1 with no additional fees.
Users can mint and burn tcap directly from mainnet calling the bridges. An issue with this is that the burn on Optimistic Rollups can take up to 7 days.
This strategy involves updating the TCAP token contracts in order to reflect the same mapping as the bridged version, keeping the vaults as the same. The issue is that there needs to be a migration strategy from TCAP v1 to TCAP v2, resulting in the same issue of having two tokens. same as SAI and DAI from maker.
I think it’s important to minimize TCAP secondary market price variance between mainnet & L2s.
If we can mitigate the risk of running out of liquidity with the Wrapper Vault Strategy option either with a market maker or the Hop/another protocol, that may be the best option.
The only issue I see with something like hop protocol is that it’s a single point of failure, I think bridges will be attacked because they are like one big honey pot. We’ve seen this with the wormhole bridge hack… I would rather wait 7 days than use a bridge.
I like the last model the most (upgrading to a tcap v2 version), as the tcap supply is not that high and we are in an early stage I think it won’t be a big issue for people to migrate. The SAI to DAI migrated proved this already and the supply was higher back then.
Plus i’m sure you can add some other features that you didn’t think about when you released v1.
We discussed it on discord but will put it here so other can see it. Doesn’t matter which approach we take we would need some kind of bridge to move assets from one chain to another. So multi chain arbitrage require some kind of bridging.
I agree with you that we shouldn’t rely on 3rd party solutions for bridging TCAP. I personally am inclined towards building a standard bridge which we can call the official solution supported by Cryptex.
Also, AMMs like hop are useful for transferring assets to the mainnet without the 7-day waiting period.
So IMO, both solutions need to co-exist for a better user experience.
I want to add a few more details regarding the wrapper vault strategy. The wrapper vault will mainly be a proxy that allows the L2 bridge to mint and burn TCAP. We need this especially in the case of optimism because TCAP on optimism has already been deployed and we cannot make changes to a deployed contract. However, we can add new vaults. So we can add a Fake Vault A.K.A proxy that lets the bridge mint and burn TCAP.
I also wanted to clarify that this strategy won’t involve moving your collateral from L1 to L2. The vault mentioned here is a fake vault whose primary job is to serve as a proxy.
What’s the difference for example between the official Optimism bridge and Hop Protocol? Hop is speedier, but is it worth in terms of security? I guess to enable arbitrage we need the faster solution but are we sacrificing security?
Optimism bridge only allows you to send eth. We can use their standard contracts to create a bridge, so we can move tcap from mainnet to optimism in minutes or from optimism to mainnet in 7 days.
Using default bridges mean that if we want to move from optimism to arbitrum, we have to do opt > mainnet > arb which includes gas plus waiting period. Hop is an amm, You put mainnet, opt and arb tcap as liquidity ,which enable users to trade from arb to opt with no waiting period.
I see, thanks for clarifyng. So it makes more sense to use a bridge like Hop Protocol but we or Hop Protocol will have to incentivise users to add TCAP liquidity to their pool. Could be an issue as it might be more lucrative to add liquidity to the bridge than to a trading pool (Sushi/Uni) and this will cause more fragmentation.
Looks like the interopability between L2 is a problem not just for us but for the whole ecosystem, I wonder if other projects are working on connecting L2 in more effective ways.
