Could a governance instruction travel without transferring tokens?

A data-only xcall could send an instruction with a zero token amount. For zero-amount calls, the native-fee overload allowed either address(0) or a registered asset address in the asset field. This branch suited instructions that required no accompanying funds; the zero amount did not remove authentication requirements for a privileged receiving function.

How were relayer fees paid for an application call?

The initiator supplied a relayer fee with xcall to incentivize destination execution. Legacy interfaces supported paying this fee in the origin chain’s native asset or the transacting asset, depending on the chosen overload. The fee funded relaying; it did not replace the destination application’s asset requirements.

Were nested xcalls suitable for sending a result back to another chain?

Nested xcalls could carry a follow-up message from a destination receiver. That receiver became the source of a new xcall, allowing asynchronous callback-like behavior or distribution to additional domains. A returned message remained another crosschain operation; it did not turn the original request into a synchronous contract call.

Did a custom integration require the hosted bridge interface?

A custom integration could expose bridging inside its own website or application. The legacy setup supported direct integration alongside the hosted bridge interface. Embedding the operation changed its access point, while destination asset support and the application’s receiving logic continued to determine which tasks it could perform.

Why could sender-based fund recovery require the slow path?

Recovery logic that relied on a validated originSender required authentication and therefore the slow path. That design could change the latency of an otherwise public application call. Applications could instead authorize specified rescue addresses, with recovery rights enforced by the receiver. Either approach needed implementation within the receiving application.

What happened if a required destination swap exceeded its slippage tolerance?

Excessive slippage on a required destination swap could prevent execution after the origin operation had succeeded. Relayers could retry when conditions improved, or the designated delegate could raise the destination tolerance. A higher tolerance permitted more price movement; it did not fix an incompatible receiving contract.

Connext

Connext suited apps that needed asynchronous crosschain contract calls

Connext suited asynchronous apps that combined crosschain asset delivery with destination contract calls. Its xcall interface fit deposits and governance actions whose destination work could complete later. Suitability depended on the receiving function’s permissions, available liquidity and application-controlled recovery. The project announced its rebrand to Everclear in June 2024 and introduced a liquidity-clearing focus. Application execution and liquidity rebalancing were distinct tasks within that shared project history.

Updated · 2026-10-19

An open destination function could use fast liquidity, while a privileged governance instruction required authenticated origin information.

Which application tasks fit xcall?

Crosschain deposits, remote governance actions and token transfers fit different branches of xcall, depending on whether the destination needed funds, instructions or both. The intended destination effect determined the required integration: recipient asset delivery, an application position or an authorized configuration change.

Connext xcall code parameters beside connected network icons

Open full-size image

A token-only transfer aimed to deliver an asset to a recipient. Adding encoded instructions, called calldata, let the receiving contract attempt application work alongside the transfer. A destination adapter could convert the bridged asset when necessary, then forward the deposit call. The destination protocol’s accepted asset and callable function determined the adapter logic. For an integration using adapters, each supported destination needed an adapter deployment that handled its target protocol. That made compatibility with the target application a separate requirement from compatibility with the bridge.

A governance integration had a different intended effect. A decision originating on one chain needed to authorize an action elsewhere. Its inputs included the permitted source of that decision and the encoded instruction. Generalized messaging supplied the crosschain connection, while the destination’s access rules determined whether the instruction could run. Delivery of a message alone could not grant permission to change protocol settings.

Vault interactions, crosschain swaps and lending were further potential uses. NFT and storage integrations also needed application-specific logic beyond message transport.

Destination contracts and application responsibilities

The integrator connected transport to application behavior by implementing xReceive directly or deploying an adapter that forwarded calls to an existing target contract. The receiver processed incoming assets and calldata. Its responsibilities included adapting asset inputs, enforcing application permissions and defining behavior when downstream logic failed. The ForwarderXReceiver base supported unauthenticated calls and separated preparation from forwarding. AuthForwarderXReceiver added checks against registered source domains and source contracts. These receiver designs gave integrators different starting points for public actions and permissioned operations.

The originating request identified the destination domain and receiver, plus the asset, amount and encoded instructions when relevant. ERC-20 transfers also required allowance for the protocol contract. The receiver needed to match the target application’s asset and function requirements. A compatible bridge route did not supply missing adapter logic or grant application permissions.

A successful deposit required the destination protocol to record the position. The ExternalCalldataExecuted event reported whether external calldata succeeded, while a transfer identifier alone established no such success. The destination position supplied application-level confirmation beyond the transport record.

A receiver call that reverted after Connext verified the crosschain message could leave transferred funds on the receiver contract. Recovery then depended on logic that the application supplied, such as protected withdrawal accounting or an authorized rescue role. Integrators needed to define access to those funds before relying on the receiving contract for application deposits.

When did origin authentication change the choice?

Origin authentication changed the choice whenever a receiving function depended on who sent the instruction, as with governance execution or restricted protocol settings. The destination needed to validate the expected origin domain, the source contract and the local Connext contract as caller. Checking a source address without its domain omitted part of that authorization boundary.

Authenticated calls used the slow path so that crosschain message verification could complete. Token-carrying calls to public functions could use the fast path when destination routers supplied sufficient liquidity. Removing source checks to obtain that speed would change who could invoke a restricted action.

The application’s permission model determined this trade-off. An operation that accepted public, funded calls could use an unauthenticated receiving function. An owner-only change required authorization despite the additional latency. An application that required the destination outcome within the originating transaction needed a different execution design.

Token control and liquidity commitments

Token issuance and liquidity provision were separate jobs. An issuer using xERC20 (ERC-7281) could retain control and set minting and burning limits per bridge on each chain. Enabling a bridge did not itself supply destination liquidity. Routers supplied fast-path capital, making liquidity availability relevant to the intended transfer size. A project controlling its token therefore had different responsibilities from an operator supplying liquidity. Neither role replaced the receiver logic that an application call required.

Open full-size image

A different job after the Everclear rebrand

Connext announced its rebrand to Everclear on June 3, 2024. The announcement introduced a clearing-layer direction centered on coordinating liquidity settlement between chains. Its focus included the inventory problem that solvers faced after fulfilling crosschain intents. Solvers could accumulate funds away from the chains where they needed working capital.

The clearing design coordinated netting and settlement of opposing liquidity flows. The legacy application interface connected funds or messages to destination contract behavior. A need to rebalance inventory therefore pointed toward the clearing-layer role. Compatibility depended on the contracts and interface of the selected architecture; an existing xcall receiver did not establish compatibility with the clearing system.

Diagram: A different job after the Everclear rebrand (Connext)

Open full-size image

When was a token transfer enough?

A token transfer was enough when success meant recipient asset delivery, with no additional contract action required on the destination chain. The destination outcome determined which parts of an integration were necessary:

Empty calldata suited recipient asset delivery without additional application instructions.
A deposit or swap needed a compatible receiver or adapter and the asset that its target function accepted.
A restricted governance action required authenticated origin information, even when message verification added latency.
An operation that had to finish within its origin transaction ruled out an asynchronous destination dependency.
A solver inventory-rebalancing requirement pointed toward liquidity clearing, with its own settlement interface.

An integration that added a privileged destination action also added an authentication requirement, even if its earlier version only transferred tokens.

Before you start with Connext

Could a governance instruction travel without transferring tokens?: A data-only xcall could send an instruction with a zero token amount. For zero-amount calls, the native-fee overload allowed either address(0) or a registered asset address in the asset field. This branch suited instructions that required no accompanying funds; the zero amount did not remove authentication requirements for a privileged receiving function.
How were relayer fees paid for an application call?: The initiator supplied a relayer fee with xcall to incentivize destination execution. Legacy interfaces supported paying this fee in the origin chain’s native asset or the transacting asset, depending on the chosen overload. The fee funded relaying; it did not replace the destination application’s asset requirements.
Were nested xcalls suitable for sending a result back to another chain?: Nested xcalls could carry a follow-up message from a destination receiver. That receiver became the source of a new xcall, allowing asynchronous callback-like behavior or distribution to additional domains. A returned message remained another crosschain operation; it did not turn the original request into a synchronous contract call.
Did a custom integration require the hosted bridge interface?: A custom integration could expose bridging inside its own website or application. The legacy setup supported direct integration alongside the hosted bridge interface. Embedding the operation changed its access point, while destination asset support and the application’s receiving logic continued to determine which tasks it could perform.
Why could sender-based fund recovery require the slow path?: Recovery logic that relied on a validated originSender required authentication and therefore the slow path. That design could change the latency of an otherwise public application call. Applications could instead authorize specified rescue addresses, with recovery rights enforced by the receiver. Either approach needed implementation within the receiving application.
What happened if a required destination swap exceeded its slippage tolerance?: Excessive slippage on a required destination swap could prevent execution after the origin operation had succeeded. Relayers could retry when conditions improved, or the designated delegate could raise the destination tolerance. A higher tolerance permitted more price movement; it did not fix an incompatible receiving contract.