Connext routers fronted funds for fast transfers

When did router funding shorten the wait?

Router funding shortened the recipient’s wait when a transfer had usable destination liquidity and could execute without authenticated origin information. Token-only transfers and calls to destination functions that accepted unauthenticated input could qualify. A receiver that checked the original caller’s identity needed the slow path’s verification before that check could succeed.

The ordinary prefunded route needed enough usable liquidity for the transfer at execution. Insufficient funding could send a transfer through the slow path, although some contract versions also included a conditional credit alternative.

Destination inventory and conditional credit

Router inventory used the local asset on each supported chain. That asset was the canonical token on its home domain and a representation elsewhere. A network-wide liquidity total did not reveal the usable balance for a particular destination asset.

Funding branches

BridgeFacet distinguished ordinary router balances from an optional Aave Portals branch that could attempt credit-funded execution when a single router lacked liquidity.

Prefunded balances

Router deposits credited a specific router and local asset in that chain’s contract. Operators supplied liquidity for the chains and assets they supported. This accounting made the destination asset balance relevant to execution, even when the operator held additional capital elsewhere.

Open full-size image

Configured Aave Portals credit

The Aave Portals branch required a configured pool, one Portal-approved router and a transfer expecting the adopted asset, meaning the token normally delivered to the recipient. A request to receive the local asset bypassed this credit branch. The contract recorded debt for Portal-funded execution; the existence of that code did not establish availability on every deployment.

How did transfer records distinguish delivery from repayment?

Destination records distinguished delivery from repayment through the order of execution and reconciliation, revealing whether router funds arrived before bridge settlement. An origin transaction or an XCalled entry established initiation only.

Executed before Reconciled identified fast execution. The CompletedFast status recorded that execution and subsequent reconciliation had both occurred.

The slow path reconciled before execution; its combined status was CompletedSlow . A token-only transfer’s destination execution record and delivered amount addressed the recipient’s receipt. Reconciliation addressed repayment to the router when it had advanced the funds. These records answered different timing questions without establishing a fixed delivery deadline.

After reconciliation, a receiving contract could reject its application call without reverting the entire destination execution. The ExternalCalldataExecuted event’s success flag distinguished that failure. The receiver retained any transferred tokens, and recovery depended on its implementation. Bridge completion alone did not establish that a deposit or other application action succeeded.

Bids between routers and relayers

A router bid contained a signed proposal for destination execution, separating the liquidity commitment from the transaction that eventually reached the chain. Routers monitored supported chains, simulated applicable destination calls and submitted bids to the sequencer. The sequencer collected bids, selected routers and forwarded winning batches to a relayer network.

Relayers submitted destination transactions. A simulation or selected bid did not establish delivery; the destination transaction still needed to execute. An insufficient relayer fee could leave destination execution pending even when a router had offered liquidity.

Reimbursement and matching parameters

A router’s reimbursement depended on its execution matching the original xcall parameters. An incorrect amount or different calldata could prevent repayment because the resulting transferId would differ from the one in the settlement message. This condition gave operators a financial reason to deliver the requested funds and instructions accurately.

Open full-size image

For the ordinary inventory-funded route, reconciliation restored local-asset liquidity on the destination chain. That design avoided a separate manual rebalancing transfer after each fulfillment. Capital awaiting reconciliation remained committed, however, which limited the balance available for further prefunded transfers.

Legacy fees and payment conditions

The legacy fee schedule separated payment for liquidity from payment for destination transaction execution. The router percentage compensated a capital commitment; the relayer charge funded another service. Neither charge established how quickly an individual transfer would finish.

Connext Routers Fronted Funds for Fast Transfers

• Bids between routers and relayers
• Reimbursement and matching parameters
• Legacy fees and payment conditions
• Operator exposure beyond the fee

Open full-size image

Required asset conversions introduced slippage separately from the liquidity fee. The router percentage alone therefore could not predict the final adopted-token receipt. A destination swap also had to satisfy the transfer’s applicable slippage tolerance.

Operator exposure beyond the fee

Router operators carried hot-wallet, API-exposure and protocol-implementation risks alongside the opportunity to earn liquidity fees. The signing key could spend the operator’s funds within the protocol. A compromised router host therefore threatened capital as well as bidding availability.

The legacy configuration supported Web3Signer to avoid keeping an unencrypted mnemonic directly on the router host. Network isolation also helped protect sensitive services. An administration token authenticated API requests; exposing both the API and its token could allow unauthorized operations.

The bridge sunset and Everclear boundary

Connext announced its rebrand to Everclear on June 3, 2024, introducing a clearing direction centered on netting and settlement between chains. Clearing addressed capital rebalancing for participants such as solvers. Legacy routers had advanced funds against individual transfers, making that earlier liquidity commitment a distinct mechanism.

The hosted Connext Bridge announced a sunset and encouraged users to remove pool funds and return nextAssets to their canonical domains. Its notice explicitly excluded xERC20 tokens from the sunset’s impact. The assets that the notice named as disabled in the hosted interface were USDC, USDT and DAI.