Flex Liquidity Pools: Where Capital Efficiency Meets Legal Requirements

By Tigran Bolshoi and Mike Shishko on behalf of Swaps.io

Disclaimer
Development is actively ongoing. Many of the components and features described below are WIP and may be subject to change.

For the latest implementation details, refer to the smart contracts repository:
github.com/swaps-io/flex-pool-contracts

Background

In recent years, the DeFi ecosystem has seen an accelerated shift from
direct on-chain interactions to architectures based on intents –
user-defined desired outcomes executed by a decentralized network of
solvers. Protocols such as UniswapX, 1inch Fusion, CowSwap, Bebop and Velora are
increasingly replacing traditional DEX interfaces by enabling users to
delegate execution logic to professional actors.

One of the key drivers behind this transition has been the need to
abstract away low-level transactional complexity from users, eliminating
the requirement to manually manage routing, bridge and DEX selection,
and transaction execution. Studies of intent-based execution models show
that solver-based competition leads to better price discovery through
price auctions, while mitigating direct MEV extraction.

This trend has also expanded into the cross-chain domain with
intent-based protocols like Across, 1inch Fusion+, Swaps.io, Squid,
Mayan and others. However, despite their growing adoption, the
supporting liquidity infrastructure remains fragmented and
non-standardized.

Operational Bottlenecks for Cross-Chain Solvers

Although the intent paradigm offers clear advantages in execution
efficiency and complexity abstraction, it places a substantial
operational overhead on solvers.

Capital and Liquidity Fragmentation

In most existing cross-chain protocols, solvers must pre-fund liquidity
across multiple chains, manage asset rebalancing, and bear the risks
associated with custody and cross-chain execution. These
responsibilities are not only technically demanding but also
capital-inefficient and economically risky.

Counterparty and Credit Dependencies

To operate efficiently, solvers often seek external credit arrangements
to support their inventory needs, forcing them to operate under the
logic of traditional financial instruments. This effectively places them
in the role of institutional borrowers, taking on the complexity of
credit negotiations and repayment management. These arrangements involve
trusted lenders with fixed-rate terms that are inefficient when capital
is unused.

Regulatory and Legal Exposure

Engaging with trusted and regulated entities, adhering to compliance
procedures significantly increases exposure to legal and financial
regulation. In many cases, it requires broker licenses and may lead to
legal liabilities in case of disputes. Such requirements stand in direct
contrast to the principles of permissionless and decentralized systems.

Need for a Unified Liquidity Layer

What is missing is a unified, permissionless, and programmable liquidity
layer that enables solvers to borrow capital permissionlessly, securely,
and on demand, while allowing liquidity providers to earn additional
yield from solver execution activity in a transparent and risk-isolated
environment. Flex Pools is designed to address this gap.

Flex Pools: Unified Liquidity for the Solver Economy

Flex Pools introduces a unified, cross-chain liquidity layer designed
for intent-based protocols. Instead of relying on fragmented,
self-managed inventories or centralized credit lines, solvers can borrow
and return assets through various providers that access liquidity (i.e.
borrow and return it) in standardized way. Liquidity providers, in turn,
earn additional yield from solver execution flows in a secure,
permissionless environment.

The system aligns the interests of three core participant groups:

• Solvers gain instant, on-demand access to liquidity with no need
  to manage cross-chain inventory or borrow from external creditors.
  Each interaction follows transparent on-chain contract logic, with the
  solver accessing liquidity only at the moment it is needed and paying
  solely for the duration of use. This eliminates long-term debt, fixed
  interest obligations, and regulatory exposure. The protocol
  abstracts away inventory management, rebalancing, and cross-chain
  verification, allowing solvers to focus purely on execution algorithms
  and routing logic – similar to on-chain solving.

• Liquidity Providers benefit from a scalable, multi-chain
  investment model with on-chain guarantees replacing legal liabilities.
  Flex Pools offer programmable liquidity and capital efficiency that
  goes beyond what common liquidity pools can offer, enabling LPs to
  earn additional yield from solvers’ activity.

• Solver-based systems and infrastructures – including
  intent-driven protocols and networks, chain-abstraction smart wallets
  and dapps, fast-fill bridges, and clearing layers – gain access to a
  shared liquidity infrastructure that lowers entry barrier and improves
  execution efficiency. By decoupling liquidity from solvers and clearly
  separating roles, Flex Pools enables greater decentralization and
  composability across the intent-based stack.

Architecture

Overview

Flex Pools is a modular liquidity protocol designed for intent-based
cross-chain execution. It allows solvers to borrow assets on one chain
and return them on another using standardized borrow-and-return
operations. These operations are carried out through a variety of secure
whitelisted taker adapters to third-party providers.

Example of workflow for asset-locking protocol2034×1110 174 KB

The system is organized into enclaves – sets of EIP-4626 tokenized
vaults deployed across multiple chains for a single logical asset. Each
vault manages deposits, withdrawals, and share accounting on its
respective chain. The vaults within an enclave are connected through a
common infrastructure that handles cross-chain messaging and
verification, leveraging event verifiers backed by oracles to ensure
execution validity.

The protocol is designed to be composable, enabling integration with
various taker adapters, event verifiers, and tuners defining fee
models.

Infrastructure

The core of the infrastructure is the FlexPool contract, which
maintains a strict whitelist of approved taker adapters. Each taker is
linked to a specific third-party provider and paired with a tuner that
defines execution and rebalancing fees. Together, the taker-tuner pair
governs how liquidity is moved across chains for a given provider and
enclave.

Flex Pool Infrastructure728×1013 96 KB

Taker contracts are typically scoped to a specific chain-to-chain
channel for better security. In many cases, the taker relies on a helper
Giver contract deployed on the opposite chain, which emits verifiable
events to prove that liquidity has been locked and committed for return
to the pool. As a result, there may be several instances of one provider
in the router – each deployed with different parameters to serve a
specific enclave chain.

Some providers require validation of events from other chains to confirm
asset return. To support this, the protocol uses an IEventVerifier
abstraction that validates cross-chain proofs and ensures the
correctness of take and related operations.

Enclave Model

An enclave is a set of vaults deployed across multiple chains that
manage liquidity for a single logical asset (e.g., USDC, ETH). Each
chain hosts one vault – a standalone FlexPool contract – which
operates independently but shares accounting logic with other vaults in
the same enclave.

Enclaves are liquidity-isolated by design: assets deposited into a vault
remain on that chain unless explicitly moved via a take operation and
later returned either through a give call in a Giver helper contract
or by direct token transfer back to the pool address.

While enclaves operate independently, they are logically connected
through the protocol’s infrastructure. If liquidity becomes unevenly
distributed – for example, when one chain is drained due to solver
activity – the rebalancing mechanism incentivizes redistribution back
to equilibrium.

Asset Accounting

Each FlexPool vault manages a single ERC-20 token. Across chains, the
same logical asset (e.g., USDC) may have different token contracts, but
must retain equivalent value and fungibility. The protocol supports
varying decimals and optionally wrapped or yield-bearing tokens.

Flex Pool Assets801×272 22.5 KB

Each pool tracks the following key asset states:

• Total Assets: The total amount of the asset managed by the pool,
  including all deposits and protocol fees. Represents the full
  obligation to liquidity providers.

• Current Assets: The amount of the asset currently held in the
  vault on the local chain. Includes both available liquidity and the
  rebalance reserve.

• Available Assets: The portion of current assets that is not
  reserved and can be used immediately for take or withdraw.

• Rebalance Assets: A separate reserve held within the vault and
  used to pay solvers for restoring cross-chain balance. Funded from
  take operations that increase imbalance.

• Equilibrium Assets: The difference between the vault’s current
  asset balance and its ideal share of the total liquidity. A positive
  value means the vault holds excess liquidity; a negative value means
  it is underfunded relative to the enclave total. This metric is used
  by tuners to calculate rebalancing incentives during take.

Together, these values ensure accurate accounting and safe liquidity
usage across chains. They also serve as inputs for protocol fee logic
and share-to-asset conversion formulas.

Operations

Flex Pools implement both standard EIP-4626 vault operations and
cross-chain liquidity transfer mechanics.

Vault operations

Liquidity providers interact with the pool through familiar functions:

• deposit / mint: deposit assets in exchange for shares
• withdraw / redeem: burn shares to receive underlying assets
• Preview and limit functions (previewDeposit, maxWithdraw, etc.)
  follow the EIP-4626 spec

Shares are ERC-20 tokens representing proportional ownership. Their
value increases over time as protocol fees accumulate from solver
activity.

Cross-chain operations

• take: transfers assets from the pool to a whitelisted taker
  caller. The taker is responsible for forwarding or locking these
  assets on the current chain and ensuring a corresponding return
  (minGiveAssets) on another chain. Associated fees
  (protocolAssets, rebalanceAssets) are calculated by the assigned
  tuner.
• give: returns liquidity back into an enclave. In most cases, this is
  implemented as a simple ERC-20 transfer to the vault, optionally
  wrapped in a helper giver contract to emit proof-validatable events.
• Rebalancing is handled implicitly via the rebalanceAssets value in
  the take operation. Solvers that relieve excess liquidity may
  receive a rebate, while those that increase imbalance may incur an
  additional fee.

These operations form the core lifecycle of liquidity in Flex Pools –
from provisioning and usage to redistribution across chains.

Takers & Givers

Takers are adapter contracts responsible for handling the execution
logic of a take operation. Each taker is linked to a specific
third-party provider or routing system and is approved through the
pool’s internal whitelist. Takers receive the borrowed assets from the
pool and must guarantee that a corresponding repayment occurs on another
chain.

Takers may rely on paired Giver contracts deployed on the opposite
chain. These contracts wrap a give operation, emitting verifiable
events used to confirm that liquidity has been returned. Givers may
enforce additional logic or safety checks required by the taker’s
provider.

Tuner System

Tuners define the economic parameters of each take operation. They are
modular contracts assigned per taker and are responsible for
calculating:

• Protocol Fee (protocolAssets) – the portion of assets paid to
  the pool, distributed to liquidity providers
• Rebalance Fee (rebalanceAssets) – the incentive or penalty
  based on how the operation affects cross-chain liquidity balance

Tuners implement a standardized interface:

tune(assets) → (protocolAssets, rebalanceAssets)

The most basic implementation is the current LinearTuner, which
applies:

• A fixed fee component
• A percentage-based fee on the requested assets
• A dynamic rebalance adjustment based on the enclave’s
  equilibriumAssets

More advanced tuner types – such as multi-slope models or tuners with
off-chain inputs (e.g. market data, solver scoring) – can be plugged in
without changing the pool logic.

Tuners ensure that fees are adaptive, fair, and aligned with current
liquidity conditions across chains. They also serve as the mechanism for
redistributing execution cost and maintaining systemic balance.

Verifier Layer

Most taker providers require proof that a give operation has occurred
on another chain before allowing a take. To support this, Flex Pools
use a pluggable IEventVerifier interface – an abstract verification
layer that checks cross-chain proofs that confirm the presence of
specific events, exposing a single function:

verifyEvent(chain, emitter, topics, data, proof)

If the event is valid and final, the call succeeds; otherwise, it
reverts. This mechanism allows takers to safely depend on cross-chain
execution results without introducing trust assumptions or centralized
relayers.

Multiple verifier implementations can coexist, enabling support for
different proof systems and oracles.

Rebalancing Logic

As solvers move liquidity across chains using take and give,
imbalances can occur within an enclave. To correct this, the protocol
includes a built-in rebalancing incentive mechanism, fully integrated
into the take operation. Each take call returns a rebalanceAssets
value from the tuner:

• Positive – the solver pays an additional fee, increasing the
  enclave’s rebalance reserve

• Negative – the solver is rewarded with surplus assets from the
  reserve for restoring balance

These incentives are based on the enclave’s equilibriumAssets, which
measure how far the current state deviates from ideal state – where all
total assets on the chain are fully available for take and withdraw
operations.

In addition to solver-driven arbitrage, the protocol is designed to
support native rebalancing via external bridges – like Circle CCTP,
LayerZero, and Everclear, allowing direct movement of assets within
enclaves. Each enclave may be configured with its own set of
rebalancers, enabling flexible strategies per asset and chain.

Provider Integration

The system supports integration with multiple execution providers, each
with their own Taker and optional Giver contracts. These adapters
implement strict on-chain validation flows, often relying on event
proofs or deterministic conditions to ensure solvency and delivery
guarantees. Currently, native support exists for direct asset transfers,
1inch Fusion+, and Across. Future integrations are planned for protocols
like Swaps.io, Debridge, Squid, Mayan and others.

The system may also support universal, provider-agnostic collateral
models, where solvers lock collateral once and access multiple taker
routes across chains and providers.

Liquidity Extensions

To improve capital efficiency and reduce idle funds, Flex Pools are
designed to support advanced liquidity sources beyond static ERC-20
balances. Planned extensions include:

Yield-bearing asset support

Pools may accept deposits in wrapped or interest-generating tokens such
as aTokens (AAVE), cTokens (Compound), LST/LRT, ERC-4626 vault
shares and others. These assets can be automatically unwrapped when used
for take operations, allowing the pool to earn passive yield while
maintaining on-chain availability.

Dynamic buffer management

A background allocator adjusts the ratio between yield-bearing tokens
and native assets based on on-chain and off-chain signals (e.g.,
utilization, volatility, rebalance demand). This ensures that each
enclave always holds an accessible buffer of base liquidity for
immediate solver usage.

Execution Coordination

In high-load or adversarial environments, coordinating access to shared
liquidity becomes critical. Flex Pools are designed to optionally
support external coordination layers that manage the timing and fairness
of take and give operations.

Take Sequencer

An optional mechanism to queue or rate-limit take operations across
solvers. This can help avoid race conditions, overlapping intents, or
liquidity exhaustion in highly contested environments. It can operate
off-chain and coordinate access based on fairness or solver priority
rules.

Give Pre-Approver

A validation mechanism for inbound give operations ensures that
returned assets match expectations and align with prior take activity.
When combined with take coordination, it can help prevent liquidity
shortfalls caused by competing solvers by maintaining an ordered queue
of give and take operations based on actual availability.

Multi-Token Support

A transition to a single pool per chain with multi-token support –
replacing multiple isolated enclaves – is being considered for future
implementation. This would enable more efficient liquidity management
and unified accounting across assets with shared valuation logic, such
as stablecoins.

Risk Management

Flex Pools incorporate multiple mechanisms to reduce operational and
protocol-level risks across chains and integrations:

Event Validation and Finality Thresholds

All events are verified through the abstract IEventVerifier interface,
which delegates proof checking to the underlying oracle. The finality
threshold – the number of confirmations required before accepting a
proof – should be configured at the oracle level, allowing flexibility
per chain without modifying the verifier itself. This setting must
balance fast solver execution with protection against chain reorgs.

Event verifiers provide common event verification logic, which is
agnostic from taker implementation specifics. The verifier interface
requires a taker to provide basic components of an expected event:
emitter contract and chain, event topics and data, as well as a
proof (usually forwarded from call params). Event verifiers can be
upgraded, audited, or replaced independently, subject to governance via
a DAO voting or multisig. All changes may include time delays or staging
mechanisms to prevent sudden trust shifts and allow monitoring before
activation.

Liquidity Provider Scoping

In future versions, liquidity providers may define the set of takers or
providers they trust when depositing into a pool. For example, a
provider may choose to support only 1inch Fusion+, only Swaps.io, or
both. This trust scope is enforced during take operations, ensuring
that a provider’s capital is only used within approved execution flows.

Liquidity Buffers and Withdraw Queue

To protect solvency, each enclave maintains a buffer of available
liquidity. Withdrawals are placed into a queue when instant fulfillment
is not possible. This mechanism ensures that solver operations and
withdraw requests do not exhaust funds simultaneously.

Emergency Controls

Core contracts include pausability features for emergency response. In
case of unexpected behavior, security threats, or verifier failures, the
protocol can:

• Pause take flows per enclave
• Disable specific takers or verifiers
• Temporarily restrict withdrawals

A dedicated emergency role may be authorized to execute critical pauses
instantly, enabling rapid response to active threats or ongoing attacks.

Fair Frontrunning-Resistant Rewards

The initial implementation is built on the ERC-4626 standard, which
inherently carries a frontrunning issue – where large deposits can
manipulate the share price to their advantage. To address this, our
roadmap includes the introduction of a time-based reward distribution
mechanism, based on insights from the 1inch team and their farming
contracts design.

This mechanism will ensure that rewards are allocated continuously and
proportionally, based not only on the staked amount but also on the
duration of each deposit. By incorporating time-weighted distribution,
we aim to eliminate frontrunning incentives while preserving the core
mechanics of ERC-4626.

Fee Model

Each take operation incurs a fee calculated by the assigned tuner.
This fee can include:

• Protocol fee, directed to the pool as retained value
• Rebalance fee, if applicable. Used to incentivize rebalancers
  and maintain cross-chain liquidity balance
• Solver reward, if applicable.

The exact structure is defined by the tuner assigned to the taker and
may be fixed, percentage-based, or dynamically calculated.

Liquidity providers earn returns through:

• Accumulation of protocol fees within the pool
• Optional yield from yield-bearing tokens or integrated LP positions
• Potential partner incentives from integrated protocols

As the pool grows and is used more actively, the value of LP shares
increases, reflecting both base asset accumulation and system-level
integrations.

Ecosystem Growth

Flex Pools are designed as foundational infrastructure for the growing
ecosystem of intent-based protocols, enabling scalable cross-chain
execution with shared liquidity. The protocol is positioned to evolve
along multiple strategic directions:

Intent Protocol Integration

Flex Pools provide a universal liquidity infrastructure for different
protocols like Fusion+, Swaps.io, Across, Squid and others. Any project
can plug into the give/take model without managing its own inventory.

As user demand for intent-based execution grows across domains like
swaps, bridging, and automation, more protocols emerge to support these
flows, and more solvers enter the market seeking efficient access to
capital. Flex Pools serve as a shared liquidity layer for this expanding
ecosystem – the more protocols integrate, the more demand for solver
liquidity rises – driving organic growth of the pools themselves as LPs
respond to yield opportunities linked to real liquidity demand.

Project Bootstrapping

Projects can deploy native Flex Pools to bootstrap cross-chain liquidity
for their tokens, enabling seamless use across networks and protocols.
These pools allow solvers to access project tokens for execution,
supporting permissionless trading and automated rebalancing.

Flex Pools supports major standards – including OFT (LayerZero),
NTT (Wormhole), Warp (Hyperlane), CCT (Chainlink), ITS (Axelar),
xERC20, and more – enabling compatibility with external DeFi and
bridge infrastructure.

This approach lets projects make their tokens natively available across
chains, enabling seamless access and flexible exchange for users –
without relying on centralized market makers or delayed bridging
solutions.

Partner Pools

Flex Pools can integrate with partner liquidity pools, which can offer
users the option to auto-deposit their yield-bearing tokens into
existing Flex Pools that support those assets, enabling additional yield
from solver activity.

This creates a win-win dynamic:

• Flex Pools attract liquidity from partner ecosystems
• Partners enhance yield returns for their LPs
• Providers earn dual yield with minimal setup

OpenIntents (ERC-7683) Support

Flex Pools are designed with forward compatibility for OpenIntents-based
protocols via an abstract IEventVerifier that validates standardized
Open events emitted as part of the OpenIntents specification. This
design allows solvers to interact with Flex Pools across any
OpenIntents-compliant protocol through a unified interface –
simplifying integration, enabling shared liquidity access, and reducing
the cost of supporting new protocols.

Beyond EVM

Flex Pools are designed to operate on any network with a programmable
VM. While initial deployments focus on EVM-compatible chains, expansion
to high-performance environments like Solana is a priority.