> 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/risks-and-safeguards.md).

# Risks and safeguards

The safeguards Efficient pools enforce, what a pause never stops, how much notice changes get, and the risks from lending markets, feeds, hooks and contracts.

Every Efficient pool runs the same pool code from the factory. So each pool enforces the safeguards below, at the settings its pool operator chooses. The borrowing and collateral safeguards bind only a pool that borrows. The price band binds only a pool that runs one.

{% hint style="warning" %}
Shares in an Efficient pool can fall in value. The checks below limit each fill and, in a pool that borrows, each borrow. They don't limit the size of a depositor's loss.
{% endhint %}

[Risk](https://docs.foreverlong.io/everlong/risk) covers the risks particular to Everlong vaults.

## What each safeguard covers

| Risk                                   | Safeguard                                                                                                                                                                                               | Limits                                                                                                                                                                   |
| -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| A fill at a bad price                  | **Price band.** In a pool with one, every fill, fee included, must price within a band around the feed price. The code caps the band at 10%                                                             | The invariant hook sets the price inside the band, so one fill can cost the pool up to the band. A pool with no band checks no fill price                                |
| A fee outside the pool's terms         | **Fee floor and cap.** The pool refuses a fill whose reported fee rate falls outside them                                                                                                               | The pool checks the reported rate, not the fee it keeps from a fill. In a pool with a price band, the band bounds that fee instead                                       |
| Borrowing past what the book supports  | **Credit check.** A pool's net debt must stay within the LTV pin times the pool asset it owns. The LTV pin is the pool's own loan-to-value ceiling                                                      | The check nets debt at the feed price. A lending market tests gross debt at its own oracle                                                                               |
| A lending market's oracle off the feed | **Oracle band.** The pool borrows only from a lending market whose oracle is within the band of the feed price. The band is at most 20%                                                                 | A band of zero switches it off. It limits new borrowing, not debt already drawn                                                                                          |
| Liquidation                            | **Collateral to the pin.** Each borrow posts collateral first. Anyone can top up once the pool's LTV at a lending market has used a fifth of the room between the pin and that market's liquidation LTV | The pool checks nothing between transactions, and no contract calls the top-up. Each call posts only pool asset not yet posted, at the weakest lending market that's due |
| A position that can't be valued        | **Revert on a frozen mark.** Net asset value and share conversions revert with `VenueFrozen`. They don't price a frozen lending-market position at its last good figures                                | Deposits and exits wait until the position reads again. Swaps go on. Morpho Blue, the only venue type in the code, can't become unreadable                               |

[Hooks](/how-pools-work/hooks.md), [Credit and collateral](/how-pools-work/credit-and-collateral.md) and [The pool and its book](/how-pools-work/the-pool-and-its-book.md) explain the rules behind each check.

## Pauses and what they never stop

**A pause stops what adds risk and leaves open what reduces it.** The pool operator or the guardian can pause a pool. Only the pool operator can unpause it.

A pause stops:

* sells
* deposits
* new price observations
* anchor moves
* lending a buy's surplus
* loan-to-loan swaps, in a pool that enables them

A pause never stops:

* buys
* redemptions
* collateral top-ups
* keeper maintenance
* the emergency calls

No feature switch stops a redemption either.

The protocol Safe can pause new borrowing and supply on the financing router for every pool. Repaying and withdrawing continue. [Roles and governance](/run-a-pool/roles-and-governance.md) lists every pause, including the entry market's and the tranches'.

## The guardian's tightening

**The guardian can tighten a pool's limits but never loosen them.** Any change that would loosen a limit reverts. The guardian can also pause the pool and use the emergency calls, which only reduce risk.

The guardian can cancel scheduled hook sets, lending markets, loan assets and ceiling raises. A loan asset is a token the pool can borrow, such as the other side of its pair. In an Efficient pool that trades BTC against USDC, that's USDC.

Switching off buys or tightening swap limits can hold up some exits. These are exits that wait on a buy to repay debt at a lending market whose oracle has stopped.

## Delays and notice

**Some changes wait at least one day, or 10 days for the first Everlong vault.** They are:

* new hooks, lending markets, loan assets, venue types and pool code
* performance fee rises
* raising a committed ceiling, the most the price band or fee cap can reach

A band-ceiling raise waits at least 10 days. Each of these changes is scheduled onchain first. A feed replacement waits 10 days, or 4 hours while that token's feed is failing.

Everything else takes effect at once. That includes limits, caps, the price and oracle bands, and fee bounds. It also includes feature switches, the keeper, guardian and fee receiver, the allowlist and the LTV pin. A pool operator handover takes effect only once the new address accepts it.

[Roles and governance](/run-a-pool/roles-and-governance.md) lists each change with its delay. It also shows how to read a scheduled change before it executes.

## Lending-market, feed, hook and asset risks

* **Lending markets.** A pool that borrows pays the market's borrow rate on all its debt. A rate ceiling limits only new borrowing. In a pool that lends, the supplied loan asset shares in any loss at that market. Withdrawing it for an exit needs free cash in that market. A pool with no lending market carries none of these risks.
* **Price feeds.** In a pool with a price band, the band, the credit check and net asset value all read the pool's price feed. So a fresh but wrong price passes all three. A stale feed halts that pool's swaps. So does a sequencer outage, if the pool's feed reads an uptime feed. Katana's feed doesn't read one. While swaps are halted, the pool earns no fees and any debt keeps accruing interest. A pool with no price band reads no feed on its swaps, so a feed failure doesn't stop them. See [Price feeds and oracles](/how-pools-work/price-feeds-and-oracles.md).
* **Hooks.** The invariant hook prices every fill inside the pool's checks. So a faulty hook can lose value on each fill, up to the price band. A pool with no price band checks no fill price, so in that pool the invariant hook alone sets each fill's price. The pool checks a hook's identity and interface, never its logic. A hook's own settings follow its code, not the pool's delays.
* **Assets.** A pool carries the risks of its assets, such as the custodian behind a wrapped asset or a stablecoin's peg and issuer.

## Factory pools run by others

**Anyone can create a pool through the factory.** The factory records each pool's provenance but doesn't endorse it. A pool's creator picks its hooks, settings and role holders. The pool's authority, allowlist or price feed contract may not be the standard one.

[Pool operators](/use-efficient/provide-liquidity/pool-operators.md) lists the reads that show who runs a pool and how.

## Contract risk

**Any contract can have a bug, including the lending market's and the feed provider's.** None of the published audit reports reviewed Efficient's current contracts. [Security and audits](/reference/security-and-audits.md) gives the details.

The factory, the financing router and Efficient's price feed can't be upgraded. New pool code reaches every pool together, after the factory's delay. [Deployments](/reference/deployments.md) shows which code each chain runs.