Intro

Connext is not a mint-and-burn bridge: we rely on liquidity pools on the different chains with native assets. This means we don’t wrap tokens when moving them from one chain to another one, but operate using existing tokens already present on the chains - for example asset created by the canonical bridge.

If there is no canonical bridge, we strongly recommend working with Nomad . Nomad is a generalized crosschain communication protocol that uses an optimistic security model (similar to rollups) to send messages between chains with minimal trust and moderate latency (~30 mins).

We're partnered super closely with Nomad because there's really no other trust-minimized option to do the above, and because nomad and Connext complement each other to create one seamless solution for crosschain comms (Nomad provides the slow/generalized messages, and Connext enables the fast transfers/contract calls that can happen in a few mins).

(Also note that with the new version of our protocol that we're releasing in the next 6-8 weeks, utilizing Nomad-flavored assets as the "canonical" assets on the receiving chain means that users will be able to transfer without slippage to that chain).

Time frame

We can be live on a new chain within a week if the following requirements are met.

What infra we need to be in place:

[ ] Being an EVM compatible chain. Being non EVM-compatible requires more R&D to convert our smart contracts.
[ ] Explorer
[ ] High quality RPCs - we would need your recs for these
[ ] Subgraphs - If the Graph Hosted service does not support the chain we have partners who can run subgraphs on behalf of the network. The chain needs to cover the fees for these.
[ ] Gelato relayer support - nice-to-have. We can go live using our own relayers as an interim at the cost of slightly slower txs.
[ ] If Nomad is going to be used, then we need Nomad deployment to be completed so we can get token addresses + bridge liquidity.

Liquidity

This is the most important dependency.

Our network is made up of router operators who run infra and provide liquidity. We can find ways to incentivize existing router operators to support your new chain through token grants/liquidity mining. This might take time, especially if it’s a new chain.

The best and quickest way is for you to find potential LPs native to a given chain ecosystem that can run a router, so if you can think of anyone in your ecosystem that can help provide initial bootstrap liquidity, that would speed things up greatly.

We have worked in the past with the chain foundations for example. If you’re interested in running a router, see this document.