Cross-chain

The basic idea of our cross chain implementation is that on each chain and layer 2 a vault is deployed. These vaults all have a cross chain exposure determined by our game. For the end user it doesn’t matter on which chain or layer 2 it enters one of our vaults, the user will always get the same exposure. This basic idea is shown in the schema below.

The cross chain implementation depends on a number of external triggers which make sure all chains and layer 2s are synchronized. These triggers, 8 for the cross chain synchronization and 1 for the vaults rebalancing, are shown in the schema below.

Here, our game will be deployed on a layer 2 to save for gas. The xChainController is deployed to do all the book keeping of vaults underlyings and allocations from the game players during the rebalancing period. The xChainController also rebalances the funds between vaults, it's therefore deployed on Ethereum mainnet for maximum safety. As mentioned before, the vaults are deployed on all supported chains and layer 2s.

In the picture above, all cross chain messages and fund bridging makes use of external bridging technologies. At the time of writing we only use Connext for both cross-chain bridging of funds and authenticated messaging. Each of the arrows in the schema above (except for arrow 8) represents one of these cross-chain messages or fund bridges. To remain flexible on which set of technologies we will use for all cross-chain messages and bridges each of these arrows is implemented as is shown in the schema below.

A XProvider is deployed on each chain and layer 2 and functions as translation between our contracts and the contracts of Connext. If we would like to change the cross-chain technology, we only have to write a new XProvider.