What is this cross-chain stuff?

For those that follow me on twitter, you would have noticed I have been posting some cross-chain stuff, today we hit a rather big product milestone that we will be rolling out over the next few weeks, so I wanted to finally take a pause, and take some time to explain what this stuff actually is.

Lets start with wrapped BTC (wBTC). wBTC is cross-chain BTC. You deposit BTC on Bitcoin to a wBTC custodian, once the wBTC custodian receives your funds, they can mint wBTC and send it to you. That simple. Send BTC on Bitcoin to party A. Party A mints wBTC on Ethereum. This can be considered a centralized custodian solution, but it is still cross-chain.

Let’s look at the key points of the above;

• BTC was transferred to a designated wallet on Bitcoin.
• Party A has some mechanism of being made aware of the previous transaction, and has some mechanism to confirm that the transaction is valid. Normally this involves querying a Bitcoin fullnode.
• Party A minted wBTC on Ethereum after confirmation of step 2.

What happens if party A gets compromised? They could infinitely mint wBTC on Ethereum, or they could drain all the deposited BTC on Bitcoin. A straight forward next step, lets make it a multisig wallet, and lets assume 5 total participants, and at least 3 need to sign for a transaction to be valid. The process flow is still exactly the same, you send BTC on Bitcoin to the multisig address. When 3/5 multisig participants agree on the receipt of the BTC, they mint wBTC.

With the above design, the multisig address still becomes a honeypot, since it owns quite a lot of BTC.

To understand the next bit, lets quickly look at how AMM’s like Sushiswap work. In a AMM like Sushiswap you have 2 tokens in a pair, lets say ETH/BTC. If you add ETH, you can withdraw BTC and vice versa. Why does this not create the same honeypot as the above multisig? Because the pair owner, has no control over the assets.

So how can we use the above for cross-chain? An AMM pair is comprised of three parts, token A, token B, and a quoted price based on the relationship of token A to token B. So for an AMM to be valid, it needs to know the quantity of token A and the quantity of token B. This however means, that token A and token B don’t necessarily have to live on the same chain.

So an LP could provide liquidity in the form of ETH on Ethereum and FTM on Fantom. The pair on Ethereum holds ETH, and no FTM, but is aware of how much FTM is being held on Fantom. The pair on Fantom holds FTM, and no ETH, but is aware of how much ETH is being held on Ethereum.

How does the pair on Fantom know, how much ETH is on Ethereum? At its core, this is an oracle problem. So that being said, any oracle can solve this problem, whether that be existing oracle solutions or new solutions. The problem statement here is; how does chain B know that an event occurred on chain A. In an ideal world, chain A and chain B speak the same “language” or p2p protocol, while I do think that this will become more standardized, and we will see more interchain lightclients, for now, this is normally achieved via some third party network.

The current most simplistic solution, is to have multiple nodes/servers/participants all listen for contract events on Ethereum/Fantom/BSC/etc. When a super majority of nodes/servers/participants all agree they have seen the event, they can trigger the next event in the sequence. The key thing to note here, is that how this consensus is reached, doesn’t actually matter much for the protocol execution. This can be proof of authority, proof of stake, custodial, multisig, etc. At its core, this is a consensus problem (which is a subset of the oracle problem).

Putting it all together;

We deploy a new cross-chain cross-asset AMM for token A on chain A and token B on chain B, for purposes of illustration, lets assume ETH on Ethereum and FTM on Fantom. The pool is seeded with 100 ETH and 200,000 FTM. Anyone can add liquidity and anyone that added liquidity can redeem liquidity.

Alice comes along and adds 1 ETH to the pool, and withdraws 2,000 virtual FTM (vFTM). Lets assume our oracle network is running ~10 nodes, with 2n/3 consensus requirement. Each of these nodes either run their own full nodes, or subscribe to infura/alchemy/pokt APIs. When 7 (2n/3) nodes are aware that Alice added 1 ETH, they create a new event that updates the AMM on Fantom to add 1 virtual ETH (vETH) and send 2,000 FTM to Alice.

Note the above is a fairly large over simplification of how all these components interact, but it should give a decent indication of how a cross-chain cross-asset swap looks like. One large part I omitted as part of this article is the economic guarantees for the oracle network, aka, what do those 10 nodes have at stake so if they misbehave they would get slashed. In the above design, they could “steal” all 100 ETH and 200,000 FTM by colluding with each other to drain the system. These economic guarantees are critical for the safety and security of a system such as this, more details on this in a later article, we have something interesting coming out with regards to that in the future.