> 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/tranches.md).

# Tranches

How a tranche controller splits an Efficient pool's shares into a senior claim at a target rate and a junior claim that takes losses first.

**A tranche controller splits one pool's shares into a senior claim and a junior claim.** The senior claim accrues interest at a target rate. The junior claim holds the rest and takes the first loss. Depositors enter and leave each tranche in pool shares. They first get those shares through any route on [Provide liquidity](/use-efficient/provide-liquidity.md).

Tranches are optional. A pool works the same with or without them. The controller is a separate contract over one pool, and it uses that pool's roles. Each tranche is an ERC-20 token, and its underlying asset is the pool share.

In the pending redeployment of the first Everlong vault, on Base, the tranche tokens are `sr.ev.cbBTC` and `jr.ev.cbBTC`. [Deployments](/reference/deployments.md) gives the Katana vault's values and the status of the redeployment.

A controller's caps, rate range and deep-window length are set at deployment, and they can't change. The queue and forward-pricing timings are the same for every controller.

## The waterfall

**Losses fall on the junior tranche first.** The senior tranche loses value only once the junior tranche is used up.

The senior claim $$C$$ is the senior principal plus simple interest at the target rate. The claim is measured in the pool asset. The value of the pool shares held for the two tranches is $$V$$, and the tranches split it as follows:

$$
V\_{\text{senior}} = \min(V,,C), \qquad V\_{\text{junior}} = V - V\_{\text{senior}}
$$

While $$V$$ is above $$C$$, junior holders gain when $$V$$ rises by more than $$C$$ over a period, and lose when it rises by less.

[Understanding returns](/use-efficient/provide-liquidity/understanding-returns.md) explains what moves the pool's value per share, and so $$V$$.

## The target rate

**The pool operator or the keeper sets the target rate.** It can be any rate inside a range fixed at deployment. A new rate applies at once. Interest accrues on principal only. Interest accrued before a change keeps the old rate.

The first Everlong vault starts at 4% a year, inside a range of 0% to 6%.

## Coverage caps

**Each cap bounds the senior claim against the tranches' value.** It's a fraction $$\kappa$$, and the bound is $$C \le \kappa V$$. A cap is checked only when a flow it bounds happens. All three caps are write-once.

| Cap                  | What it bounds                                                       | First Everlong vault |
| -------------------- | -------------------------------------------------------------------- | -------------------- |
| Coverage cap         | Junior entries, and junior exits inside their deep window            | 75%                  |
| Senior entry cap     | Senior entries                                                       | 70%                  |
| Junior fast-lane cap | Junior exits at any other time. It can't exceed the senior entry cap | 50%                  |

The senior entry cap sits below the coverage cap. So a senior entry always leaves room for junior exits in the deep lane. No cap bounds a senior exit.

## Entries

**A senior entry settles at once, at the current value.** A junior entry is a forward request.

A senior entry takes an optional deadline. The controller refuses a senior entry that would take the senior claim past the senior entry cap.

A junior entry escrows the depositor's pool shares. It fills whole at a later price update, by the rule in [Forward pricing](#forward-pricing). It fills only while the senior claim is within the coverage cap. Otherwise it waits.

The first entry into each tranche is the pool operator's seed. The junior tranche has to be seeded first. The controller refuses any new junior entry request before the junior seed.

## Forward pricing

**Junior entries and exits fill at a price set after filing.** No one can enter or exit on a move that has already happened. A request runs in four steps:

1. The depositor files the request. It escrows pool shares for an entry, or junior shares for an exit.
2. The request waits for an update of the pool asset's USD [price feed](/how-pools-work/price-feeds-and-oracles.md). It becomes fillable at the first update stamped more than 60 seconds after filing. In the first Everlong vault, that feed is Chainlink's cbBTC/USD.
3. Anyone, the requester included, can fill it within six seconds of that update. It fills at the pool's value at the time.
4. A missed fill rolls to the next update. A request never expires.

Junior shares escrowed for an exit keep their exposure until they fill. They still share the junior tranche's gains and losses.

Cancelling a forward request takes two calls. The first marks the request. The second, more than 66 seconds later, returns the escrow. An update stamped within 60 seconds of the mark can still fill it.

## Senior exits

**A senior exit waits in a seven-day queue.** The request escrows the senior shares and freezes their claim. The frozen claim stays in $$C$$ for the waterfall but earns nothing more.

Settlement isn't automatic. From day seven, the owner or the approved address that filed the request for them has to call it. Settlement pays out pool shares worth the frozen claim at the current value. The payout is capped at the request's share of what the senior tranche holds.

That limit binds only on an impaired book, where $$V$$ is below $$C$$. Until settlement, the owner or that approved address can cancel. A cancel gives the owner back as many senior shares as the frozen claim buys at today's claim per share. The rest are burned. So the holder gives up the interest those shares would have earned while queued.

## Junior exits

**A junior exit is a forward request.** Each fill pays only the part its lane admits. The rest waits for a later update.

* **The fast lane** is open at every update. A fill there stops where the senior claim would pass the fast-lane cap.
* **The deep lane** fills up to the coverage cap, but only at updates inside a deep window. The first window opens eight days after the request. Windows then repeat every eight days plus their length.

The window's length is write-once, from one hour to eight days. It's 2 hours in the first Everlong vault. Eight days is a day longer than the senior queue. So a senior who queues within a day of a junior request can settle first.

[Deposits and exits for apps](/integrate/deposits-and-exits-for-apps.md) gives the calls for each lane.

## Pauses and price outages

**The tranche pause stops entries only.** That includes new junior entry requests and fills of those already filed. The pool operator or the guardian can pause. Only the pool operator can unpause. Exits, exit requests and cancels continue.

While the pool [can't value its shares](/how-pools-work/the-pool-and-its-book.md#when-a-position-cant-be-read), senior entries and settlements revert, and forward fills wait. Filing and cancelling still work.

A tranche controller can't run over a pool with no price band. Such a pool can't value its shares while it holds any loan asset. A loan asset is the other token in a pool's pair, or any extra token the pool can borrow. In an Efficient pool that trades BTC against USDC, the loan asset is USDC.

[Roles and governance](/run-a-pool/roles-and-governance.md) covers each role's powers over the controller. [Risks and safeguards](/use-efficient/risks-and-safeguards.md) explains the risks every pool shares.