Cross-chain / Bridge·EVM · Multi-chain
Everclear (formerly Connext)
Cross-chain clearing layer for intent-based bridges. Connext rebranded to Everclear in June 2024 and pivoted from a direct bridge to a netting/settlement layer that lets solvers across protocols offset their cross-chain balances on the Everclear chain (an Arbitrum Orbit rollup using Hyperlane + EigenLayer). Apps post intents; solvers fill on the destination; Everclear nets and settles them in batches, cutting solver rebalancing costs by up to 90%.
- 01intent-based bridges and aggregators (as a settlement backend)
- 02cross-chain solver/filler infrastructure
- 03USDC settlement via CCTP integration
- 04reducing rebalancing cost for cross-chain liquidity
- 05EVM <-> EVM intent routing
- pnpm add @everclear/sdk viem
| Variable | Scope | Description |
|---|---|---|
| EVERCLEAR_ENVIRONMENT | Client | `mainnet` or `testnet` — selects the Everclear chain RPC, Hub contract addresses, and intent API endpoint. |
Use `@everclear/sdk` (intent layer is exposed as `EverclearAdapter`). Create an intent via `adapter.createNewIntent({ origin, destinations, to, inputAsset, outputAsset, amount, maxFee, ttl, callData })` — this calls `Everclear.newIntent(...)` on the origin spoke contract and emits an `IntentAdded` event. Solvers listening to the Everclear chain pick up the intent, fill it on a `destinations[]` chain, and post a settlement to the Hub. Track via `GET https://api.everclear.org/intents/{intentId}` (states: `ADDED`, `FILLED`, `SETTLED`, `EXPIRED`). For solvers/fillers: subscribe to the Hub on the Everclear chain via Hyperlane mailbox events and call `fillIntent` on the destination spoke. Apps that just need a bridge UX should integrate via a higher-level partner (Socket, Bungee, etc.) that uses Everclear as a backend rather than directly.
- ⚑Connext -> Everclear rebrand: the legacy `@connext/sdk` and xCall flow are DEPRECATED. Do not build new integrations against `xcall`/Amarok contracts — wire to `@everclear/sdk` and the new Hub/Spoke addresses.
- ⚑Intents have a hard `ttl` (time-to-live). If no solver fills before expiry, the intent goes to `EXPIRED` and funds are refundable on the origin chain — surface the expiry countdown in UI and provide a one-click reclaim.
- ⚑Netting is BATCHED: settlement to the origin solver happens on Everclear's epoch boundary (minutes-to-hours), not at fill time. From the user's POV the fill is instant, but solver balances move on epoch — important for solver UX.
- ⚑`destinations` is an array — Everclear lets a single intent be fillable on multiple chains (whichever solver gets there first wins). This is a feature, not a bug; if you need a single destination, pass a one-element array.
- ⚑`maxFee` is the worst-case fee in basis points the user will accept; solvers will not bid if the achievable fee exceeds it. Setting it too tight causes silent non-fills — instrument and tune.
- ⚑Hyperlane is the message-passing layer between spokes and the Everclear Hub; outages on Hyperlane (or the underlying validator set) freeze settlement even if origin/destination chains are healthy. Treat Hyperlane health as a hard dependency.
- ⚑Cosmos / non-EVM spokes are not on the v1 mainnet; assume EVM-only at integration time and check `docs.everclear.org` for current chain coverage.