website logo
ConnextBlogBridgeAcademy
⌘K
🚀CONNEXT WIKI
What is Connext?
Connext Bridge
NEXT Token
Supported Chains
Connextscan
FAQs
💢CONNEXT ECOSYSTEM
Connext Team
Backers
🤖ECOSYSTEM ROLES
Community Leaders
Ecosystem
Router Operator
Subgraph Provider
Testers
Connextooor
Bridgooor
Developer
Contributors
Quarantine
Status
🏅ROUTERS
What is a Router?
Router Requirements
Revenue Streams of Routers
Slashing Mechanism
Staking Mechanism
✨TECHNICAL DOCUMENTATION
Introduction
🧁PROTOCOL UPDATES
Amarok
💥CONNEXT DAO
💫RESOURCES
Important Links
Brand Kit
Events
Telegram Groups
Newsletter
Docs powered by
Archbee
PROTOCOL UPDATES
Amarok

Transaction Flow

10min



Document image


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".

Fast Path​

Requirements​

For a cross-chain message to travel through the fast path, it must abide by BOTH of these requirements:

  1. 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).
  2. 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.

Examples​

  • 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.

Slow Path​

Requirements​

Essentially the inverse of fast path; if ANY of these apply to the cross-chain message, it will travel through the slow path:

  1. The transaction includes authenticated calldata (the destination function checks the originating caller from the origin domain).
  2. There is insufficient router liquidity of the bridged token on the destination domain.

Examples​

  • 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.



🔗Key Benefits

Key benefits of Amarok



Updated 13 Jul 2023
Did this page help you?
PREVIOUS
Amarok
NEXT
Key Benefits
Docs powered by
Archbee
TABLE OF CONTENTS
Fast Path​
Requirements​
Examples​
How it works​
Slow Path​
Requirements​
Examples​
How it works​
🔗Key Benefits
Docs powered by
Archbee