# Liquidity Ticks

Ticks are unsigned, 128-bit identifiers that encode conditions on liquidity, including a maximum loan limit, duration index, and rate index. The [`Tick`](https://github.com/metastreet-labs/metastreet-contracts-v2/blob/master/contracts/Tick.sol) utility library is responsible for encoding and decoding ticks. Deposits are made into specific ticks by depositors, and liquidity is sourced from a selection of ticks to assemble the funds of a loan for borrowers. The ticks used in a loan become the tranches of the loan.

{% code fullWidth="false" %}

```
                            Tick Bit Layout
+-------------------------------------------------------------------+
|                                 128                               |
+--------------------------------------|----------|----------|------+
|                  120                 |    3     |     3    |   2  |
|                 Limit                | Dur. Idx | Rate Idx | Type |
+-------------------------------------------------------------------+
```

{% endcode %}

Limit is a 120-bit value that imposes the maximum limit for funds sourced from the tick can be used in. Duration index is the maximum duration that funds sourced from the tick can be used for, and rate index is the interest rate tier associated with the funds. Duration index and rate index are indices into predetermined, discrete tiers that are assigned at Pool initialization. Finally, the type field is currently set to zero for absolute loan limit ticks.

Ticks can be combined in an ascending fashion to source incrementally larger principals for loans. Each tick used to source funds for a loan must be strictly larger than the previous, following the order implied from the bit encoding: limit, followed by duration, followed by rate.

Example of a possible configuration of durations, rates, and ticks:

<table data-header-hidden><thead><tr><th width="150"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Durations</strong></td><td>30 days</td><td>14 days</td><td>7 days</td></tr><tr><td><strong>Rates</strong></td><td>10%</td><td>30%</td><td>50%</td></tr></tbody></table>

<table><thead><tr><th width="75">#</th><th>Tick (Loan Limit, Duration, Rate)</th><th>Liquidity Available</th></tr></thead><tbody><tr><td>6</td><td><code>(50 ETH,   7 days, 50%)</code></td><td>20 ETH</td></tr><tr><td>5</td><td><code>(40 ETH,   7 days, 50%)</code></td><td>30 ETH</td></tr><tr><td>4</td><td><code>(30 ETH,  14 days, 30%)</code></td><td>30 ETH</td></tr><tr><td>3</td><td><code>(15 ETH,  30 days, 30%)</code></td><td>50 ETH</td></tr><tr><td>2</td><td><code>(5  ETH,  30 days, 10%)</code></td><td>100 ETH</td></tr><tr><td>1</td><td><code>(2.5 ETH, 30 days, 10%)</code></td><td>150 ETH</td></tr></tbody></table>

To assemble a 30 day loan, ticks 1, 2, 3 can be used to create a 15 ETH loan that is organized as follows: 2.5 ETH from tick 1, 2.5 ETH from tick 2, 10 ETH from tick 3. The interest for the loan would be determined by applying the `10%`, `10%`, and `30%` interest rate tiers to the amounts used from each tick and the loan duration.

<table><thead><tr><th width="71">#</th><th>Tick (Loan Limit, Duration, Rate)</th><th>Sourced</th></tr></thead><tbody><tr><td>3</td><td><code>(15 ETH,  30 days, 30%)</code></td><td>10 ETH</td></tr><tr><td>2</td><td><code>(5  ETH,  30 days, 10%)</code></td><td>2.5 ETH</td></tr><tr><td>1</td><td><code>(2.5 ETH, 30 days, 10%)</code></td><td>2.5 ETH</td></tr></tbody></table>

$$\text{Principal} = \text{2.5 ETH} + \text{2.5 ETH} + \text{10 ETH} = \text{15 ETH}$$

$$\text{Interest} = 10% \text{ APR} \times \text{2.5 ETH} + 10% \text{ APR} \times \text{2.5 ETH} + 30% \text{ APR} \times \text{10 ETH} = \text{0.287671 ETH}$$

$$\text{Repayment} = \text{Principal} + \text{Interest} = \text{15.287671 ETH}$$

Note that ticks 4, 5, 6 are ineligible for a 30 day loan, because the loan duration exceeds their maximum duration. A 14 day loan can be assembled from ticks 1-4, and a 7 day loan from ticks 1-6. Longer duration ticks can be used for shorter duration loans.

The loan limit imposes an upper bound on the amount of funds that can be used from a tick, as well as the maximum position of the tick in the capital stack for a loan, but the actual amount pulled from each tick depends on the cumulative amount built up from previous ticks.

Lowers ticks have seniority over higher ones in a loan, meaning that if a loan is liquidated and the liquidation proceeds fall short of the loan repayment, lower ticks will be repaid before higher ones. However, higher ticks will tend to receive greater interest than lower ones, based on the interest distribution described in the [Interest Rate Models](/technical-overview/protocol-design/interest-rate-models.md) section.

Being an oracleless protocol, the Pool does not make assumptions or impose restrictions on the maximum or safe loan limits based on a collateral's current market value. Instead, depositors choose loan limits corresponding to the LTV and risk they are comfortable lending at. This means that it is possible for a depositor to create a very risky, high-LTV position to try to capture more interest, or to create a very conservative, low-LTV position that is underutilized.

The job of selecting ticks for a loan is a process known as tick routing, and is accomplished by the [MetaStreet SDK](https://github.com/metastreet-labs/metastreet-sdk-v2). The tick routing algorithm builds a route through the ticks up to a specified loan amount, choosing the best incremental tick by cost of capital, and prunes the route to a maximum number of ticks by greatest capital contribution. The SDK API is described in more detail in the [SDK](/technical-overview/sdk.md) section.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.metastreet.xyz/technical-overview/protocol-design/liquidity-ticks.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.