Cross-Chain Bridge

Connext Network (rebranding to Everclear) Review

connext.network7.4/10February 24, 2026

Objective review of Connext.Network, its Everclear rebrand, crosschain xcall messaging, router-based bridging model, security approach, supported chains, and tr

Connext Network (rebranding to Everclear) screenshot
Connext Network (rebranding to Everclear) screenshot

Background and history

Connext.Network is best understood in its Web3 context as a modular interoperability protocol: infrastructure intended to move funds and data between blockchains and rollups so applications can feel “multichain” without forcing users to manually manage networks. In Connext’s own documentation, the motivating problem is fragmentation. Scaling pushes activity to multiple parallel domains, which spreads liquidity and users across chains, and creates a user experience where people must continually think about what network they are on. Connext’s framing is that applications themselves should abstract this away by becoming crosschain applications, or “xApps.” [1]
A third-party deep dive published by LI.FI provides helpful historical anchoring. It states that Connext was started in 2017, then focused heavily on UX in 2018, and was launched as an interoperability protocol in January 2021 to enable fast, fully non-custodial transfers and crosschain contract calldata between EVM-compatible chains and rollups. [2]

One important “current state” detail is branding. The Connext.Network marketing site explicitly states, “Connext is now Everclear,” and links to everclear.org for rebrand updates, while still keeping Connext-branded pages and a “Bridge” entry point. For users doing diligence, this is material: brand transitions can temporarily complicate product discovery, documentation navigation, and social proof aggregation across review sites and explorers. [3]

Finally, there is a practical research hazard: name collision. “Connext” also refers to unrelated companies and products, including a Utah internet service provider with Yelp reviews and a cloud management platform listed on Gartner Peer Insights. Those sources are real, but they are not about the blockchain protocol at connext.network. Any serious evaluation should make sure it is referencing the correct Connext. [4] [5]

Key features and services

xApps and chain abstraction

Connext’s docs define it as a modular protocol for securely passing funds and data between chains, used to build xApps that interact with multiple domains simultaneously. The examples given are broad and application-oriented: crosschain execution of DAO vote outcomes, crosschain vault actions, crosschain lending and borrowing, DEX liquidity aggregation patterns, token bridging designs (lock-and-mint and burn-and-mint), NFT bridging and marketplaces, and even crosschain data patterns that reduce reliance on traditional oracle designs. [1]
This “chain abstraction” message also appears as a productized use case on the marketing site, which positions Connext as a way to build crosschain applications usable from any chain with any token. [3]

A developer-first primitive: xcall

A standout design choice in the documentation is Connext’s emphasis on a single core primitive, xcall. The docs describe xcall as a way for developers to asynchronously interact with contracts on another chain similarly to how they would call a contract on the same chain. This is a strong developer ergonomics story in a category that often becomes complex quickly, with multiple message types, verification modes, and execution environments. [1]

For platform evaluators, the important takeaway is not that crosschain is “simple,” it rarely is, but that Connext aims to constrain complexity at the interface level. If a team is building multi-domain application logic, a narrow, well-defined interface can reduce integration risk and long-term maintenance burden.

NXTP and router-based transfer mechanics

LI.FI’s deep dive describes NXTP as Connext’s base protocol for crosschain transfers. It states NXTP launched in September 2021 with the goal of becoming the “Internet Protocol (IP) of the Ethereum multi-chain ecosystem,” and it characterizes NXTP as trustless, low-cost, and extensible. [2]
The same deep dive outlines a router-based transaction lifecycle that resembles an auction and escrow process:
  • In the “route auction,” the user broadcasts the desired route and routers respond with sealed bids that commit to time and price ranges.
  • In “prepare,” the user accepts a bid and locks funds on the sending chain in a Transaction Manager contract; the router also locks its own liquidity on the receiving chain. The router’s reward is described as an auction fee taken from the sending amount.
  • In “fulfill,” the receiver-side completion is submitted, potentially via a relayer. A key UX point in LI.FI’s explanation is that relayers can help users execute transactions with arbitrary calldata without needing to worry about gas on the receiving chain.

This model matters because it clarifies who supplies liquidity and why transfers can complete quickly. Speed is not “free,” it is often achieved by letting routers front liquidity on the destination side and then settle back to the source side after conditions are met. [2]

Intents framing and productized use cases

The Connext marketing site describes the protocol as “powered by intents” and publishes performance targets for its intent layer, specifically “<20bps fees and <60 sec latency.” These should be read as targets rather than enforceable guarantees based on the provided sources, but they provide insight into the UX the protocol is aiming to deliver. [3]

The same site highlights three use case pillars:

  • Restaking, framed as “Restake From Anywhere,” with a claim that users can stake or restake tokens across supported chains in a single transaction.
  • xERC20 for deploying crosschain-native tokens with “zero slippage,” positioned as a security-forward token design.
  • Chain abstraction for building crosschain apps.

These categories suggest Connext is marketing not just a generic bridge or messaging layer, but a platform intended to be embedded into consumer-facing workflows. [3]

Security and trust

Security model: canonical bridges and Ethereum L1

Crosschain risk is not theoretical. Connext’s documentation explicitly notes that, in the past 18 months, almost $2B has been lost to bridge hacks. That context is important because Connext’s architecture is presented as a response to exactly this class of systemic risk. [1]

Connext describes a modular hub-and-spoke architecture that plugs into canonical messaging bridges for each connected domain and derives security from Ethereum L1. The docs describe messages being added to a Merkle root on each spoke domain and then being optimistically aggregated into a single root on Ethereum L1, with a fallback to canonical messaging bridges in the event of fraud. As a concrete example, the docs explain that a message between Polygon and Optimism is secured by a proof posted to Ethereum and verified by the Polygon PoS bridge and the Optimism rollup bridge. [1]

In other words, Connext’s “trust-minimized” argument is that it avoids inventing a wholly new security perimeter for crosschain messaging, and instead leans on established canonical bridges, with additional protocol-level safeguards.

Watchers and operational safety controls

The docs also describe Watchers, automated offchain actors that monitor the network and halt message passing if fraud or a hack is observed. This is a classic defense-in-depth concept: assume components can fail, then add detection and circuit-breaking to reduce blast radius. [1]

Additionally, Connext’s documentation references “rigorous external review for code changes” and collaboration with the security community to educate auditors and develop best practices. The dataset provided for this review does not include an audit list, incident timeline, or bug bounty terms, so a full trust assessment would require additional primary sources beyond what is available here. [1]

Trust takeaways and what to verify

Based on the supplied sources, Connext’s security posture is coherent and well-articulated, particularly in how it ties safety to canonical bridges and adds Watchers as a protective layer. However, for any production deployment, users and integrators should still validate items not present in this dataset, such as current audits, formal verification where applicable, bug bounty scope, and any historical incident reports.

User experience

For end users

Connext is not a consumer exchange, it is infrastructure. Most end users experience Connext indirectly through wallets, aggregators, or applications that integrate it.

That said, LI.FI’s description of relayers is an important UX detail. If a relayer submits the receiving-chain transaction, users may not need to source destination-chain gas to complete a crosschain action, which reduces friction for mainstream flows like bridging and crosschain contract calls. [2]

The marketing site also emphasizes intents and performance targets, pointing toward a user experience benchmark of sub-minute latency and sub-0.20% fees. Again, those are targets, but they show the direction: fewer steps, fewer manual chain switches, and more predictable outcomes. [3]

For developers

Developer experience is where Connext most clearly differentiates in the provided material. The xcall primitive is positioned as the main way to build crosschain behaviors while keeping the mental model similar to familiar contract-to-contract interactions. [1]

The docs also emphasize integrating into existing tooling and workflows, which matters for teams that already have CI pipelines, testing stacks, and deployment playbooks. However, the dataset does not include tutorial depth, SDK maturity benchmarks, or ecosystem integration counts, so “DX quality” should ultimately be validated by hands-on integration and community support responsiveness.

Pricing and fees

Connext does not present itself as a typical SaaS product with a posted pricing page. Instead, costs are embedded in protocol mechanics.

From LI.FI’s explanation, a router auction fee is part of the transfer flow, routers earn fees for providing liquidity and fulfilling routes, and gas costs exist on the sending chain and, depending on relayer usage, may be abstracted on the receiving chain. [2]

From the marketing site, Connext publishes a performance and cost target for its intent layer: “<20bps fees and <60 sec latency.” This is useful as an expectation-setting anchor, but it is not, by itself, a guarantee of realized execution costs for every asset and route. [3]

For users and integrators evaluating total cost, the practical approach is to measure:

  • Router fees for typical routes
  • Gas consumption for message passing and settlement
  • Slippage or price impact, where applicable to the asset flow
  • Failure and retry rates, which can translate into operational costs

Supported chains and ecosystem coverage

Connext’s site lists a broad set of EVM networks. Current support shown includes Ethereum, BSC, Arbitrum, Polygon, Gnosis, Optimism, Linea, Metis, Base, and Mode. It also lists additional networks marked “Soon,” including X Layer, Scroll, zkSync, Polygon zkEVM, Avalanche, and Mantle. [3]

This list suggests strong orientation toward Ethereum and EVM rollups, which aligns with the protocol’s messaging around Ethereum L1 security anchoring and canonical bridges. [1]

Comparison with alternatives

Interoperability is a crowded space, and the right comparison depends on whether you need token bridging, generalized messaging, intent-based routing, or app-specific crosschain execution.

Based on Connext’s positioning in the supplied sources, the most relevant comparison axes are:

  • Security model: Connext emphasizes deriving security from canonical bridges and Ethereum L1, plus Watchers for circuit-breaking. Protocols that rely on separate validator sets or different trust assumptions may offer different tradeoffs. [1]
  • Execution model: Connext’s xcall and xApp framing are oriented toward crosschain contract interactions, not only asset transfers. [1]
  • Liquidity and fulfillment: The LI.FI deep dive emphasizes routers, route auctions, and relayers. That is a specific approach to making transfers fast and user-friendly, but it introduces routing dynamics that differ from purely canonical bridge flows. [2]

In practice, teams often compare Connext with other crosschain messaging and bridging solutions, and may also use aggregators (like LI.FI itself) to access multiple routes. The dataset provided for this review does not include a competitor feature matrix or performance benchmarks, so the most credible comparison method is empirical: test your target routes, measure costs and latency, validate failure modes, and review security assumptions end-to-end.

One more comparison consideration is branding continuity. Connext’s rebrand to Everclear may be a non-issue for sophisticated teams, but for newcomers it can add friction during evaluation. [3]

Final verdict

Connext.Network, now transitioning its brand to Everclear, is positioned as developer-oriented interoperability infrastructure for a multichain world. The strongest aspects in the supplied sources are clarity of architecture and interface: a modular approach anchored to canonical bridges and Ethereum L1, a defense-in-depth layer via Watchers, and a simple developer primitive (xcall) intended to make crosschain contract interactions feel approachable. [1]

The LI.FI deep dive adds credible color on how Connext’s router auction and relayer mechanics can support fast, non-custodial transfers and improve UX by reducing destination-chain gas complexity. [2]

Where this review necessarily pulls its punches is hard, current validation. The provided dataset does not include up-to-date quantitative metrics, audit documentation, incident history, or independent benchmarking. Additionally, the rebrand and the “Connext” naming collision with unrelated companies can create confusion during diligence and makes careful source verification essential. [3] [4]

For developers building crosschain apps across EVM networks, Connext is compelling on design intent and documented security philosophy. For risk-sensitive deployments, the next step should be a deeper verification pass beyond the sources provided here: confirm audits, understand current operational safeguards, test routes at production scale, and evaluate how the Everclear transition affects documentation and support continuity.

Frequently Asked Questions