In this diagram we observe two domains, "origin" and "destination", representing the chains that a cross-chain message will originate from and travel to.
We also see a differentiation between "fast path" and "slow path".
For a cross-chain message to travel through the fast path, it must abide by BOTH of these requirements:
- The transaction is bridging tokens only (no calldata) OR the calldata included is unauthenticated (anyone is allowed to call the function on the target contract).
- Routers are providing sufficient liquidity of the bridged token on the destination domain. We sometimes refer to this as the availability of "fast liquidity". If fast liquidity is not available, then the message will go through the slow path.
- A simple token bridge (like the
- Send funds from origin to destination and then execute a Uniswap
How it works
Connext is able to shortcut the normal AMB messaging delay (sometimes hours or days of latency!) by allowing its network of routers to front the capital to the user on the destination domain. Routers wait out the AMB latency in the user's stead, allowing the user to receive funds almost immediately. In exchange for taking on the risk of this temporary liquidity lockup, routers are compensated with a small fee. Note that at the end of the waiting window, routers always get reimbursed.
Essentially the inverse of fast path; if ANY of these apply to the cross-chain message, it will travel through the slow path:
- The transaction includes authenticated calldata (the destination function checks the originating caller from the origin domain).
- There is insufficient router liquidity of the bridged token on the destination domain.
- Execute DAO votes across chains
- Change protocol settings from any chain
- Generally, do anything that has an
How it works
The message takes on the full AMB delay, allowing the AMB verification process to complete. This is why slow path messages can trust that the origin caller is correct since data integrity is maintained.