> For the complete documentation index, see [llms.txt](https://docs.efficientdex.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.efficientdex.com/integrate.md).

# Integrate

How aggregators, solvers and apps find Efficient pools, choose a route, and quote and execute swaps, deposits and exits through the contracts.

**Aggregators, solvers and apps integrate Efficient through its contracts.** The factory lists every pool, the lens reads them, and each pool quotes and settles onchain. Each factory is the beacon for the pools it creates. So they all run the same pool code behind the same ABI. One integration of the pool's calls covers every pool from that factory, whichever hooks price it.

| Integration        | For                                                                   | Page                                                                                 |
| ------------------ | --------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| Swaps              | Aggregators, solvers and trading contracts that route orders to pools | [Swaps for aggregators and solvers](/integrate/swaps-for-aggregators-and-solvers.md) |
| Deposits and exits | Wallets and apps that move depositors into and out of pool shares     | [Deposits and exits for apps](/integrate/deposits-and-exits-for-apps.md)             |

[Smart contracts](/reference/smart-contracts.md) lists every contract, event and common error. The calls on this page are from the pending redeployment. [Deployments](/reference/deployments.md) lists the chains and the code each one runs until that redeployment ships.

## Choose a route

**Every swap route ends in the pool's `swap`.** The routes differ in which pools they reach, what they pull and what they check.

| Swap route        | Reaches                  | What the integrator handles                                                                                                                                                                                              |
| ----------------- | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| The pool's `swap` | Any pool                 | Approves the pool. The pool enforces the minimum output and deadline, pulls only the input it uses and returns the input used                                                                                            |
| `PoolSwapAdapter` | One pool per deployment  | Approves the adapter. The adapter pulls the whole input, refunds the rest and returns the input used. It checks the pool's report and reverts with `Misreport` on a mismatch                                             |
| Tycho adapter     | Every factory pool       | Sell orders only, which fix the input, in either direction. There's no minimum output, so the calling contract checks what it receives. The deadline is the current block, and the adapter doesn't return the input used |
| KyberSwap         | The first Everlong vault | Its DEX library includes an Everlong liquidity source that quotes the first pool                                                                                                                                         |

Efficient is integrated with the relevant aggregators, including KyberSwap and Bebop's BopAMM. It plans to add others where relevant, such as 0x. The Tycho adapter is Efficient's own contract, and Tycho's indexing of the pools is planned.

Deposits and exits go through the pool's proportional calls, the asset router, the entry market or a tranche token. The asset router and the entry market's `fillPar` and `crank` settle them through the pool's proportional calls. The entry market's `net` and `fill` move existing pool shares instead, and so does the tranche controller. The depositor approves the senior or junior tranche token, because the tranche controller takes entries only from its tokens. [Deposits and exits for apps](/integrate/deposits-and-exits-for-apps.md) gives each route's calls.

`PoolSwapAdapter`, the asset router, the entry market and the tranche contracts are each deployed for one pool. Not every pool has them. All but the tranche tokens answer `POOL()` with the pool they serve. A tranche token's `asset()` returns that pool instead. An integrator checks that binding before routing through any of them.

## Find pools

**The factory lists every pool it has created.** It also answers whether any address is one of them. Anyone can create a pool through it. So a listing shows where a pool came from, not that anyone has reviewed it.

| Call or event                             | Returns                                                                                                                    |
| ----------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| `pools()`                                 | Every pool the factory has created, in creation order. Its length is the pool count                                        |
| `isPool(address)`                         | Whether the factory created that address                                                                                   |
| `PoolCreated`                             | Each new pool and its creator, its invariant hook with that hook's code hash, and hashes of its hook set and risk settings |
| Tycho adapter `getPoolIds(offset, limit)` | A page of factory pools as 32-byte ids                                                                                     |

The indexed `creator` field of `PoolCreated` is the only record of who created a pool. The event's `hookSetHash` commits to the full hook set. The pool's `HooksSet` event lists that set in the same transaction.

The lens's `identity(pool)` returns a pool's bindings in one call. They are its pool asset, the other token in its pair, its price feed, its hooks and its role holders.

**Integrators call each pool through `IFLAMM` for swaps, deposits, exits and reads.** They use `FLAMM`'s ABI for the calls `IFLAMM` lacks. Those include `swapLoan`, `maintainCollateral`, `mintProRata` and the deposit and exit maximums.

Each pool is a beacon proxy. Its implementation runs swaps itself and passes most other calls to the full pool contract. So an explorer shows only four entries for that implementation.

A factory pool can run hooks that someone else wrote, under its own pool operator. [Pool operators](/use-efficient/provide-liquidity/pool-operators.md) gives the reads that show who runs a pool. [Risks and safeguards](/use-efficient/risks-and-safeguards.md) covers pools run by others.

## Quote and execute a swap

**A pool's `swap` trades only its pool asset against the other token in its pair.** Each swap is exact input, in either direction. Any other pair reverts, with `InvalidPair` on the pool and `BadPair` on either adapter.

For example, take an Efficient pool that trades BTC against USDC, where depositors have put in only BTC. BTC is its pool asset, and USDC is the other token in its pair.

1. Check that the direction is open by calling the pool's `swapContext(poolAssetIn, amountIn)`. It reverts whenever the pool would refuse the swap before pricing it. That covers a direction whose feature bit is clear, and a sell while paused or with no room left. If the pool can borrow the other token, it also covers a sell while that token is off peg.
2. To see why a direction is closed, read the feature bitmap. It's the first value the pool's `switches()` returns, and the lens doesn't report it. Bit 1 (value 2) turns sells on, and bit 2 (value 4) turns buys on. A pause stops sells but not buys.
3. Quote with `previewSwap` on the pool or the lens, or with the Tycho adapter's `price` and `getLimits`. On an Everlong vault with leverage on, these quote the better of the curve fill and the leverage fill. So an offchain model prices both.
4. Approve the contract being called for the input token. The pool has no swap callback, because it pulls the input it uses from the caller.
5. Execute with a minimum output and a near deadline. Size any other leg from the `amountInUsed` and `amountOut` the call returns. Either direction can fill in part, at the per-swap cap or where the invariant hook stops a fill. If the pool can borrow the other token, a sell can also stop at the credit room. If not, it can stop at the pool's cash in that token instead.

A sell larger than the pool can fund reverts instead of filling in part. But `previewSwap` and `getLimits` cap their quotes at that funding.

[Swaps for aggregators and solvers](/integrate/swaps-for-aggregators-and-solvers.md) covers both adapters and the rest of the lens. A preview reserves nothing. [Trade](/use-efficient/trade.md#the-preview) explains where a swap can still differ from it.

## Quote a deposit or exit

Deposit and exit previews and maximums sit on the pool, not the lens. [Deposits and exits for apps](/integrate/deposits-and-exits-for-apps.md#reads-before-any-route) lists them with each route's calls.