Everclear

• Name: Everclear
• URL: https://www.everclear.org/
• Category: cross-chain clearing layer / intent-settlement infrastructure / chain-abstraction netting protocol
• Summary: Everclear is a clearing layer for solver imbalance, not a bridge worth inflating into a base rail. The useful read is invoice policy, epoch timing, netting queues, and virtual-balance repayment for chain-abstraction operators that do not want 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:
  • https://www.everclear.org/
  • https://docs.everclear.org/
  • https://docs.everclear.org/concepts/overview.md
  • https://docs.everclear.org/concepts/how-it-works/architecture.md
  • https://docs.everclear.org/developers/protocol-mechanics.md
  • https://docs.everclear.org/developers/getting-started.md
  • https://docs.everclear.org/developers/guides/quickstarter.md
  • https://docs.everclear.org/developers/audits.md
  • https://github.com/everclearorg
  • https://github.com/everclearorg/audits

Internal linkages

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

Control surface

• Practical authority accumulates around epoch timing, invoice discount policy, spoke support, queue processing, and which repayment paths stay liquid enough to matter.

• Netting removes some bridge churn, but it does not remove operator policy. It just moves the interesting decisions into queue design, discount markets, and repayment defaults.

• The leverage is straightforward: if upstream routers dump the ugly rebalancing problem here by default, Everclear gets to tax timing, balance-sheet convenience, and invoice clearing.

• Last reviewed: 2026-06-16 UTC