Everclear

  • Name: Everclear
  • URL: https://www.everclear.org/
  • Category: cross-chain clearing layer / intent-settlement infrastructure / chain-abstraction netting protocol
  • Summary: Everclear is a cross-chain clearing layer for solver imbalances, not a primary bridge worth romanticizing into more than that. The official docs describe a hub-and-spoke netting system that turns fills and repayments into invoices, deposits, epochs, and virtual balances so chain-abstraction operators do not have to rebalance every route the hard way.
  • What it does:
    • Provides a clearing layer for cross-chain intents so fillers and applications can net rebalancing flows instead of bridging every repayment directly across chains
    • Uses a hub-and-spoke architecture with Spoke contracts on supported domains and a Hub on the clearing chain to ingest intents, fills, deposits, invoices, and settlements
    • Lets users or integrators create intents through API-guided transaction payloads that submit signed data to the onchain FeeAdapter flow
    • Batches queue processing and settlement across epochs, turning unmatched intents into discounted invoices that can be purchased by rebalancers or arbitrageurs
    • Credits solvers via virtual balances on spokes, allowing repayment to be decoupled from the original route and reused for future fills or withdrawn later
    • Exposes public protocol documentation, API surfaces, audit references, and a GitHub organization with protocol, bot, and audit repositories
  • Key claims:
    • Everclear’s homepage calls it “the new foundation of the chain abstraction stack” and frames the product around efficient cross-chain settlement rather than point-to-point bridging
    • The docs explicitly describe Everclear as “a novel public good mechanism for settling intents across chains” that socializes rebalancing costs via netting
    • Official architecture docs define three message types—intent, fill, and settlement—and say repayment can occur on any solver-configured spoke domain rather than needing to mirror the original source/destination path
    • The protocol mechanics docs describe invoice/deposit queues, epoch-based discounting, and settlement queues as core primitives, which is a stronger signal of a clearing-and-auction design than of a simple bridge router
    • Everclear’s docs and GitHub surface show supporting operational components beyond contracts alone, including relayers, a cartographer agent, routers, an audit repo, and a market-making bot (mark)
  • Whitepaper: No canonical standalone whitepaper or litepaper surfaced in this pass. The clearest current source of truth is Everclear’s official docs, homepage, and public GitHub organization; see ../whitepapers/everclear-primary-sources-2026-04-27.md.
  • Sources:

Internal linkages

  • Best upward reads: across and cctp.
  • Keep this note on netting, queue policy, and repayment design rather than treating Everclear like a general bridge or transport layer.

Comparable to / differs from

  • Comparable to: Across only in the loose sense that both sit in the same multichain execution stack.
  • Differs from: CCTP, which moves dollars rather than netting cross-chain obligations.

Governance / control risk

  • Practical authority accumulates around epoch timing, invoice discount policy, spoke support, queue processing, and which repayment paths remain liquid enough to matter.
  • Netting reduces some bridge churn, but it does not remove operator policy from the system.

Rent / leverage sink

  • The leverage is in becoming the place where upstream routers dump the ugly rebalancing problem.

  • If Everclear becomes default clearing plumbing, it gets to tax discount markets, repayment timing, and balance-sheet convenience.

  • Last reviewed: 2026-06-05 UTC