As I see more projects embark on their multichain journey, I want to provide some tips learned and best practices;

Step 1: Use a CREATE2 deployer

A CREATE2 deployer will give you deterministic addresses on all EVM compatible blockchains. Create 1 new account and fund it with native tokens (ETH, FTM, BNB, HT, xDAI, MATIC, etc). Use this account to only deploy the CREATE2 deployer. An address that deploys code with the same nonce will always create the same address on any EVM blockchain.

You can either use our deployed CREATE2 deployer or you can deploy your own deployer (code below). Ensure this deployer has the same address on all chains you wish to support.

If the deployer addresses remains the same, then as long as your bytecode and salt remain the same you will create the same deterministic address on all supported blockchains. This will already help you dapp and your users as they only need to support 1 set of addresses across all chains.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.2;contract AnyswapCreate2Deployer {
  event Deployed(address addr, uint256 salt);function deploy(bytes memory code, uint256 salt) public {
    address addr;
    assembly {
      addr := create2(0, add(code, 0x20), mload(code), salt)
      if iszero(extcodesize(addr)) {
        revert(0, 0)
      }
    }emit Deployed(addr, salt);
  }
}

Step 2: multichain tokens

There are 4 options to support multichain tokens;

• Balance float
• Mint/Burn
• Liquidity swap (combination of balance float and mint/burn)
• Wrapped + Mint/Burn

• 2.1 Balance Float

Lets say your token is natively on Ethereum, and you would like to bridge to Fantom. Your token is capped on Ethereum and you cant mint/burn any new tokens. You deploy your token on Fantom (please refer to step 1 to keep the address deterministic). On Fantom, you mint your full circulating (or total, whichever is greater) supply, and you provide this as a balance float to whatever bridge mechanism you use (more on bridges later). When 1 token is locked on Ethereum, the bridge is notified and transfers 1 token on Fantom to the recipient.

If using the above method, please be incredibly careful with what bridge technology you use (more on this later). If its a centralized service, consider if that wallet is compromised.

• 2.2 Mint/Burn

As above, but when 1 token is burned on Ethereum, another is minted on Fantom. This can also work by mixing 2.1, where the bridge receives 1 token on Ethereum and mints 1 token on Fantom. And inversely burns from Fantom to Ethereum.

• 2.3 Liquidity Swap

This requires liquidity and an intermediary transfer token. Using anyswap.exchange as an example, you would transfer 1 USDC from Ethereum to 1 anyUSDC on Fantom, on Fantom, you would have a curve pool that provides USDC-anyUSDC. This allows users to swap USDC (Ethereum)> anyUSDC > USDC (Fantom). It does not require custody, simply liquidity (this is my second best recommended approach and is supported in the v3 router of multichain.xyz).

• 2.4 Wrapped + Mint/Burn

This is a combination of 2.3 and 2.2, you would mint anyUSDC by depositing 1 USDC into anyUSDC, you would then burn anyUSDC (Ethereum) to trigger a mint for anyUSDC (Fantom), you can then trade anyUSDC (Fantom) to USDC (Fantom). This is my best recommended approach and is supported in the v3 router of multichain.xyz. With this mechanism the bridge has no custody over USDC on Ethereum or Fantom.

Step 3: Bridges

Probably the most important aspect is the bridge themselves.

• Custodial + Centralized (Binance, Wrapped BTC)
• Custodial + PoA (Proof of Authority)
• Custodial + PoS (Proof of Stake) (Matic, xDAI, REN)
• Custodial + MPC (Multi Party Computation) (Thorchain, Anyswap)
• Non-custodial + MPC (Multichain ~ yes, I’m shilling Multichain)

If you do liquidity based with wrapped mint/burn, it doesn’t really matter too much which bridge you use, since the bridge is just telling the other chain to mint/burn, it doesn’t actually keep custody of funds, it could cause infinite mint/burn attacks though, so try to have as much decentralization as possible.

Conclusion

This template is what I recommend to use as the base template and standard. With tether and frapped we have started to push these multichain standards for projects. The template will allow you to support any of the above discussed mechanisms, and any of the above discussed bridges without friction. It will also allow you to switch between bridge providers if you ever need to do so.