What is Everclear [formerly Connext]?
Everclear coordinates the global settlement of liquidity between chains, solving fragmentation for modular blockchains.
Everclear is a cornerstone of the chain abstraction stack, seamlessly integrating with intent protocols, solver networks, modular blockchains, and dApps to ensure the most efficient transaction settlement at optimal prices.
Everclear is a novel public good mechanism for settling intents across chains. This mechanism:
- Allows fillers to distribute the costs of rebalancing by netting settlements against other fillers and users within the network.
- Serves as a programmable layer for fillers or users to create and utilize various mechanisms for rebalancing and settling funds, such as integrating with messaging systems, liquidity pools, centralized exchanges (CEX), and more.
- Facilitates permissionless expansion to new chains and rollups, enabling applications on any chain to onboard users from other chains seamlessly.
The Everclear Chain Abstraction Stack
How Everclear Works
There are three types of messages related to intents within Everclear:
- Intent: These messages are created when a user generates an intent, and are dispatched periodically from the source chain to the clearing chain using the transport layer. They contain the source of truth information for the intent data.
- Fill: These messages are generated when a solver fills an intent, and are dispatched periodically from the source chain to the clearing chain using the transport layer. These messages contain information about which solver should be credited in settlement.
- Settlement: These messages are generated when both the intent and fill messages arrive on the clearing chain. They are sent from the clearing chain to the settlement domain, which is where the solver will be repaid for intent execution.
Flow of Funds
When users create intents, funds are deducted from the caller of the
newIntent function and stored in the Spoke contracts. The unclaimed balance for this spoke increases by the intent amount and can be used to settle solvers of other intents within the same domain. Solvers must deposit funds into the Spoke contracts, which are then deducted when fillIntent is called. Both deposit and fillIntent operations can be executed simultaneously by the solver networks, although deposit can also be called at any time before filling.Once an intent is filled and the message is added to the
FillQueue, the solver is considered to have a claim on any available liquidity held in the Spoke contracts. The settlement of these claims occurs through the processSettlementQueue function on the Hub contract. Intent settlement can occur on any solver-configured spoke domain, not necessarily the domains associated with the intents.This system decouples repayment from intent routing, allowing protocol participants to access a global settlement flow across chains. When settlement messages arrive on the spokes, the settlement amounts are deducted from the unclaimed balance held on that spoke, and the solver's balance is increased. Solvers can withdraw this balance from the contracts at any time or use it to fill new intents initiated from the settlement domain.
Components
The system comprises several on-chain and off-chain components:
- Contracts
- Hub: Manages inbound intent and fill messages and dispatches the settlement of solver claims via the gateway contract.
- HubGateway: Handles dispatching messages to the transport layer and formats inbound message payloads to properly call functions on the Hub.
- Auctioneer: Governs solver selection for routers through a race-to-the-bottom auction, where only winning routers are reimbursed for transfers.
- Spoke: Holds funds from created intents (used as liquidity for settlement) and solver balances, formats messages from the Intent and Fill queue, and dispatches them via the SpokeGateway contract.
- SpokeGateway: Dispatches messages to the transport layer and formats inbound settlement messages to properly call functions on the transport layer.
- Agents
- Relayers: Execute periodic transactions across the network, primarily processing queues according to configured age and size thresholds per chain.
- Cartographer: Creates a cross-chain view of the network state, derived from an indexing layer (e.g., subgraphs) on each chain.
- Router: A solver that executes cross-chain transactions broadcast throughout the network, useful for integrating cross-chain applications without their own solver network.
- Transport Layer: The transport layer sends messages throughout the network. The HubGateway and SpokeGateway contracts handle the dispatch and processing of these messages.
