> 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/use-efficient/provide-liquidity/pool-operators.md).

# Pool operators

Who runs an Efficient pool, what its pool operator controls and earns, Everlong as one pool operator, and what a depositor can read before depositing.

**A pool operator is the address that owns an Efficient pool.** It chooses the pool's hooks, loan assets, limits and roles. A loan asset is a token the pool can borrow. The first one is the other token in the pool's pair: USDC, in an Efficient pool that trades BTC against USDC.

Any address can create a pool through the factory. The creator supplies an authority contract and names the pool operator as its owner.

Depositors choose which pools to fund. Every pool enforces the same core checks, whoever operates it. [How Efficient works](/how-efficient-works.md) lists them.

Market makers, liquidity managers and teams that manage lending markets can all run pools. [Getting started](/run-a-pool/getting-started.md) covers the setup for a proprietary market maker.

## What a pool operator controls

**The pool operator sets a pool's pricing, financing and limits.** It works inside bounds that the pool code or the creator fixes.

| Area               | What the pool operator sets                                                                                                                                                          | Limits and notice                                                                                                                                                                                                                   |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Pricing            | The hooks: the required invariant, fee and recentring hooks, plus the optional controller and loan-to-loan swap hooks                                                                | A new hook set waits for the governance delay and executes only while the pool is paused. The wait is at least 10 days while the band ceiling lets the pool run with no price band, or while a raise to such a ceiling is scheduled |
| Financing          | Up to 16 loan assets. In a pool that uses lending markets, up to 32 venues, with their debt and supply caps and borrow-rate ceilings                                                 | Each new loan asset or venue waits for the governance delay                                                                                                                                                                         |
| Credit             | In a pool that borrows, the LTV pin, which the keeper can also move. In a pool that uses lending markets, the oracle band against each market's oracle                               | The pin stays in an envelope fixed at creation. The oracle band is at most 20%                                                                                                                                                      |
| Swaps              | Each loan asset's price band, fee floor, per-swap cap and execution buffer. The pool-wide fee floor and cap                                                                          | The price band is at most 10%. The band and the fee cap sit under committed ceilings. Raising a ceiling waits for the governance delay, at least 10 days for the band                                                               |
| Deposits           | The listed depositors and on-off switch of any deposit allowlist, the cap on `mintProRata` entries, the DEX routers for single-asset conversions and the entry market's discount cap | Whether the pool has an allowlist contract, and which one, is fixed at creation. A pool with none admits every depositor. The `mintProRata` cap starts at zero, which keeps that entry closed. The discount cap is at most 10%      |
| Pause and switches | The pause, and the feature switches that turn flows such as deposits, sells, buys and lending on or off                                                                              | Only the pool operator unpauses. No pause or switch blocks a proportional exit                                                                                                                                                      |
| Performance fee    | The pool operator's own rate                                                                                                                                                         | A ceiling fixed at creation, at most 50%. A rise waits for the governance delay. A pool with no price band takes none                                                                                                               |
| Roles              | The keeper, the guardian and the fee receiver                                                                                                                                        | Each appointment takes effect at once                                                                                                                                                                                               |

The keeper runs routine maintenance, such as recentring the anchor. In a pool that borrows, it can also move the LTV pin inside its envelope.

The guardian can pause the pool and tighten limits, but never loosen them. It can also cancel scheduled hook sets, venues, loan assets and ceiling raises.

Neither role is required, because the pool operator can make every keeper and guardian call itself.

No pool role can change the settings fixed at creation. These include the pool asset, the first loan asset, the allowlist contract and the governance delay. The shared pool code and each pool's protocol fee belong to the protocol Safe, not to any pool operator.

[Roles and governance](/run-a-pool/roles-and-governance.md) lists every call and the notice each change gets.

## What a pool operator earns

**The pool operator earns its part of the performance fee.** The fee is charged only on gains in value per share above the high-water mark. The pool mints that part as new shares to the pool operator's fee receiver.

A pool with no price band charges no performance fee. So it pays its pool operator nothing until a band is attached.

Swap fees stay in the pool for every share. The pool has no management fee. [Fees](/use-efficient/fees.md) covers both parts of the performance fee and how a rise takes effect.

## Everlong as a pool operator

**Everlong is one pool operator on Efficient.** It runs Everlong vaults on its own hook, the Everlong hook. The vaults earn yield in the pool asset, starting with BTC. The first vault trades cbBTC against USDC on Base and is financed through Morpho Blue.

The leverage curve in the swap quote belongs to the Everlong hook, not the pool. So other invariant hooks don't need to quote one. [The Everlong strategy](https://docs.foreverlong.io/everlong/everlong-strategy) lists the hook's settings and the first vault's configuration, including who holds each role.

Depositors in Everlong vaults start at [Everlong](https://docs.foreverlong.io/everlong), the yield product built on Efficient.

## Before depositing

**The factory records every pool it creates.** That record shows where a pool came from. It doesn't show that anyone has reviewed the pool.

The pool checks that its required hooks and any loan-to-loan swap hook are bound to it. It also checks that each one reports the current interface version. [Hooks](/how-pools-work/hooks.md) covers these checks.

On each swap between the pool asset and a loan asset, the pool keeps the fee within the floor and cap. It also keeps every fill's price inside the price band, if the pool has one. It never checks a hook's pricing logic, only the bounds each fill must meet.

A depositor can read a factory pool's setup onchain before depositing:

| Check               | Where to read it                                                                                                                          |
| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| Provenance          | `isPool(pool)` on the factory, and the creator in its `PoolCreated` event                                                                 |
| Hooks               | `hooks()` on the pool, and `pendingHookSet()` for a scheduled change                                                                      |
| Roles               | `core()` on the pool, then `owner()`, `guardian()`, `keeper()` and `feeReceiver()` on that authority contract                             |
| Limits and fees     | `limits()`, `dials()` and `ceilings()` on the pool, and `loanConfig(i)` for each loan asset                                               |
| Notice and switches | `switches()` on the pool for the feature switches and the governance delay, and `paused()` for the pause                                  |
| Deposit access      | `depositAllowlist()` on the pool, then `isDepositAllowed(address)` on that contract. A zero address means the pool admits every depositor |

On the lens, `identity(pool)` returns the pool's contracts, hooks and roles in one call. [Swaps for aggregators and solvers](/integrate/swaps-for-aggregators-and-solvers.md) describes it. [Roles and governance](/run-a-pool/roles-and-governance.md) lists every read and the events that announce a scheduled change.

**The factory doesn't check that a pool's authority, allowlist or price feed contract is the standard one.** [Roles and governance](/run-a-pool/roles-and-governance.md#factory-provenance) explains what the standard `EverlongCore` guarantees. It also covers what to read in a pool that uses other contracts.

[Risks and safeguards](/use-efficient/risks-and-safeguards.md) covers the risks of a pool run by others.