Vaultemore

The same code is deployed on several supported chains. There is a crossChainTotalSupply minted only on the originChain. An authority (owner, DAO, …) can add a new supported chain. It can support n chains, not only 2. One user can transfer his tokens from supported chain A to supported chain B. From a Connext perspective, the ERC20 contract plays both roles of Source and Target contract, using authenticated calls and callbacks. How it works? A user selects on chain 1 how many tokens to transfer and the destination chain 2. Tokens are locked on chain 1. A mint request is recorded on chain 2. Callback to chain 1. Cross-chain call from that callback function to chain 2. Tokens are minted on chain 2. Locked tokens are burnt on chain 1. Local totalSupply attribute is not broken because we use _mint() and _burn(). If Connext becomes unavailable, tokens locked on chain 1 and a mint request on chain 2 have a lock timeout of 24 hours, unlockable by the mint requestor. On the UX part, we've used Wagmi ui components to interact with the erc20 cross chain contract. Also, we've built a restful api with Rust using forge bind for RPC data access.

From a Connext perspective, the ERC20 contract plays both roles of Source and Target contract, using authenticated calls and callbacks. It was good to externalize the cross-chain network and the callbacks mechanisms are very useful, as well as the way parameters are encoded in the value msg.data. Finally, the starter pack available on their website was very useful to start our hack.