# Overview

<figure><img src="/files/aBExGck2bVI3M3uRUP8G" alt=""><figcaption></figcaption></figure>

Welcome to Pareto’s official documentation! \
\
Pareto is a private **credit marketplace** that connects institutional lenders and borrowers, offering scalable yield opportunities and bridging institutional capital with on-chain credit markets.\
\
Designed for asset managers, digital asset funds, and institutional investors, our comprehensive infrastructure provides seamless access to regulatory-compliant alternative credit solutions. Built on transparency, scalability, and automation, Pareto’s Credit Vaults eliminate bureaucratic friction, reduce operational costs, and enhance capital efficiency.

Whether you're a liquidity provider, borrower, curator, or integrator, here you will find everything you need to understand how to securely and efficiently interact with the protocol and its components.


# Credit Vaults

Credit Vaults (CVs) are a suite of smart contracts built to simplify on-chain lending and credit position management for borrowers and lenders. They provide the infrastructure for real-world financing, making it more transparent and efficient.

Assets deposited into a Credit Vault are sent directly to borrower wallets. Only whitelisted borrowers can access loans, and only registered users who complete verification through [Keyring](https://www.keyring.network/) can provide liquidity.

### Features

Credit Vaults introduce several innovations to address inefficiencies in traditional DeFi lending and offer a customized experience for borrowers, curators, and lenders:

* **Diverse IRM**: CVs support both fixed and variable interest rate models. Variable rates are usually benchmarked to third-party data sources, making vault performance easy to monitor.
* **Flexible lending cycles**: Funds are locked for short periods (typically 1 to 4 weeks), called **lending cycles**, allowing high capital utilization and predictable fund management.
* **Regulation compliance**: Native support for privacy-preserving verification and KYC ensures compatibility with regulatory requirements.

### Flow of funds

<figure><img src="/files/xXlVJMDvQwpoW6PKfkCk" alt=""><figcaption></figcaption></figure>

Credit Vaults operate on a cycle-based system. Funds are borrowed in fixed time intervals known as lending cycles.  The IRM and the duration of the first cycle are defined at vault deployment. Thereafter, at the end of each cycle, the curator can update these parameters.

1. Before the first cycle starts, whitelisted lenders deposit funds.
2. The curator triggers the start of the cycle.
3. The borrower receives the funds directly in their wallet.
4. Interest accrues for lenders throughout the cycle.

The process repeats, with updated terms,  if applicable, for all the following cycles.

#### Redeems

While deposits happen in a single step, withdrawals are a two-step process:

{% stepper %}
{% step %}

#### Withdraw request

A user requests to redeem funds (principal and/or accrued interest) at the end of Cycle I.
{% endstep %}

{% step %}

#### Funds claim

At the end of Cycle II, the borrower repays interest and any requested withdrawals. Users who requested to exit can now claim their funds.
{% endstep %}
{% endstepper %}

{% hint style="success" %}
**Early exit**

When the interest rate of the next lending cycle is lower than the previous one by 1% or more (or otherwise provided in the Credit Agreement), lenders are entitled to an **early exit** and can redeem funds with a shorter waiting period, i.e., within 72 hours. &#x20;

For example, a lender requests a withdrawal on Jan 31 during Cycle I, where the interest rate is 15%.  If the Cycle II rate drops to 12%, the lender qualifies for an early exit and can claim his funds 72 hours after Cycle II starts (i.e., on Feb 3).
{% endhint %}

### Architecture

The diagram illustrates the architecture of Credit Vaults

<figure><img src="/files/qXAI8KIv7lg0OHbtJAJp" alt=""><figcaption></figcaption></figure>

The curator, with the express consent of lenders and the borrower, retains the authority to modify, amend, or adjust CV's parameters as necessary to accommodate requests from lenders or the borrower, or to ensure alignment with the terms and conditions outlined in the MLA.


# Tranching

Credit Vaults can **optionally** activate a tranching mechanism to allow users to tailor their lending experience to various risk appetites.

<details>

<summary>Senior class</summary>

This class offers **intrinsic protection on funds**, given by Junior deposits. \
Senior Tranche LPs intrinsically **have a first lien on the underlying assets**, i.e., they are first in line to be repaid in case of default (hack or loss of funds).

</details>

<details>

<summary>Junior class</summary>

This class offers a **greater yield** by dragging more exposure to the underlying yield.\
Junior Tranche LPs have a second lien or no lien at all in case of default (hack or loss of funds).

The Junior class is designed to receive a higher share of yield compared to the Senior one, to proportionally compensate for the higher risk taken.

</details>

### Yield split

The Tranching feature relies on a unique mechanism that manages the return distribution dynamically conditional to the liquidity deposited on each side (Senior, Junior) of the Credit Vault.

* **Senior class** receives most of the underlying yield when liquidity is low on the Junior side (low coverage), or receives a guaranteed minimum portion of the underlying yield when Junior liquidity is high (high coverage)
* **Junior class** receives outperforming APYs, no matter the Senior class liquidity

<details>

<summary>Formulae</summary>

#### Liquidity ratios <a href="#liquidity-ratios" id="liquidity-ratios"></a>

First, we define the Senior and Junior TVL ratios as

$$\text{TVL ratio}*{Sr} = \frac{\text{Liquidity}*{Senior}}{\text{Liquidity}\_{Senior + Junior}}$$

$$\text{TVL ratio}*{Jr} = \frac{\text{Liquidity}*{Junior}}{\text{Liquidity}\_{Senior + Junior}}$$

#### Senior and Junior yields <a href="#senior-and-junior-yields" id="senior-and-junior-yields"></a>

The Senior return can be calculated as

$$\text{APY}*{Sr} = \text{Base APY} \times \text{Yield share}*{Sr} \qquad \tag{1}$$

where the *Base APY* is the underlying Tranches yield and the *Yield share* of the Senior side is a piecewise function conditional to the liquidity on the Senior tranche.

$$\text{Yield share}*{Sr} =  \begin{dcases}  99% & \text{if } \text{TVL ratio}*{Sr} \geq 99%  \         \          \dfrac{\text{Liquidity}*{Senior}}{\text{Liquidity}*{Senior + Junior}} & \text{if } \text{TVL ratio}*{Sr} > 50%  \         \         50% & \text{if } \text{TVL ratio}*{Sr} \leq 50%  \     \end{dcases}$$

The Junior return can be calculated as

$$\text{APY}*{Jr} = \frac{(\text{Base APY} - \text{APY}*{Sr}) \times \text{TVL ratio}*{Sr}}{\text{TVL ratio}*{Jr}} + \text{Base APY} \qquad \tag{2}$$

When Senior liquidity represents 50-99% of the funds in the Tranche, we use Equation (1) to compute the Yield share of the Senior side.&#x20;

Alternatively, we use some fixed percentages. There are two **hedge cases**:

1. The majority of the vault's liquidity lying on the Senior side (more than 99%)
2. Less than half of the vault's liquidity lying on the Senior side (less than 50%)

$$\text{Yield share}*{Sr} =      \begin{dcases}         99% & \text{if } \dfrac{\text{Liquidity}*{Senior}}{\text{Liquidity}*{Senior + Junior}} \geq 99%  \         \         50% & \text{if } \dfrac{\text{Liquidity}*{Senior}}{\text{Liquidity}\_{Senior + Junior}} \leq 50%  \     \end{dcases}$$

In the first case, we set the Yield share of the Senior class equal to 99% while in the second case, we set it equal to 50%. These two hedge cases link to the principle that

> * **Senior class** receives most of the underlying yield when liquidity is low on the Junior side (low coverage), or receives a guaranteed minimum portion of the underlying yield when Junior liquidity is high (high coverage)
> * **Junior class** receives outperforming APYs, no matter the Senior class liquidity

The *guaranteed minimum portion*, aka the *Yield share* of the Senior Tranches, has been set to half the *Base APY* (see HC#2) when the Senior liquidity is smaller than the Junior one.

#### Senior coverage and Junior overperformance <a href="#senior-coverage-and-junior-overperformance" id="senior-coverage-and-junior-overperformance"></a>

The formulas of the Senior coverage provided by the Junior counterparty and the Junior boosted yield vs the underlying return are

$$\text{Coverage}*{Sr} = \frac{\text{Liquidity}*{Junior}}{\text{Liquidity}\_{Senior}}$$

$$\text{Overperformance}*{Jr} = \frac{\text{APY}*{Jr}}{\text{Base APY}}$$

The Senior coverage should not be confused with the overall Tranche coverage that is computed in proportion to the whole tranche TVL

$$\text{Tranche coverage} = \frac{\text{Liquidity}*{Junior}}{\text{Liquidity}*{Tranche}}$$

</details>

### Yield and loss scenarios <a href="#liquidity-ratios" id="liquidity-ratios"></a>

Let's assume to have a Credit Vault generating a 10% yield (base APY), where users deposit 10,000,000 DAI split as follows: 70% on the Senior class, and 30% on the Junior class.

<figure><img src="/files/ukzGdkhhItYsu5EQdFE0" alt=""><figcaption></figcaption></figure>

#### **Standard case**

Between 50 and 99% of the total vault's liquidity lying on the Senior side

| Side   | Liquidity     | Expected APY |
| ------ | ------------- | ------------ |
| Senior | 8,000,000 DAI | 8%           |
| Junior | 2,000,000 DAI | 18%          |

The Senior Yield share is equal to 80%. Senior funds coverage is 25% and the Junior overperformance vs base APY is 1.8x. The Tranche coverage is 20%.&#x20;

#### **Hedge case #1**

Majority of the total vault's liquidity lies on the Senior side (≥ 99%). See the [#formulae](#formulae "mention") section.&#x20;

| Side   | Liquidity     | Expected APY |
| ------ | ------------- | ------------ |
| Senior | 9,999,900 DAI | 10%          |
| Junior | 100 DAI       | 20%          |

The Senior Yield share is set to 99% (HC#1). Senior funds coverage is 0% and the Junior overperformance vs base APY is 1.99x. The Tranche coverage is 0% as well.

#### **Hedge case #2**

Less than half of the total vault's liquidity lies on the Senior side (≤ 50%). See the [#formulae](#formulae "mention") section.&#x20;

| Side   | Liquidity     | Expected APY |
| ------ | ------------- | ------------ |
| Senior | 4,000,000 DAI | 5%           |
| Junior | 6,000,000 DAI | 13%          |

The Senior Yield share is set to 50% (HC#2). Senior funds coverage is 150% and the Junior overperformance vs base APY is 1.33x. The Tranche coverage is 60%.


# Live vaults

<details>

<summary><a href="https://www.fasanara.com/digital">Fasanara Digital</a></summary>

<table><thead><tr><th width="214.625">Borrower</th><th>Fasanara Digital</th></tr></thead><tbody><tr><td>Curator</td><td>Pareto</td></tr><tr><td>Vertical</td><td>Basis Trading (delta neutral)</td></tr><tr><td>IRM</td><td>Variable rate, benchmarked to BTC-OI funding rate</td></tr><tr><td>Chain</td><td>Ethereum</td></tr><tr><td>Asset</td><td>USDC</td></tr><tr><td>Cycle length</td><td>One week</td></tr><tr><td>Buffer length</td><td>24 hours</td></tr><tr><td>Redemptions</td><td>Weekly, 7-day notice</td></tr><tr><td>Performance fee</td><td>20%</td></tr><tr><td>Vault page</td><td><a href="https://app.pareto.credit/vault#0x45054c6753b4Bce40C5d54418DabC20b070F85bE">Link</a></td></tr><tr><td>Addresses</td><td><a href="/pages/VGJccEZaoRpxC0NOCmOc#fasanara-digital">Link</a></td></tr></tbody></table>

</details>

<details>

<summary><a href="https://www.falconx.io/">FalconX</a></summary>

<table><thead><tr><th width="214.625">Borrower</th><th>FalconX</th></tr></thead><tbody><tr><td>Curator</td><td><a href="https://www.m11credit.com/">M11 Credit</a></td></tr><tr><td>Vertical</td><td>Prime brokerage</td></tr><tr><td>IRM</td><td>Fixed rate</td></tr><tr><td>Chain</td><td>Optimism</td></tr><tr><td>Asset</td><td>USDC</td></tr><tr><td>Cycle length</td><td>One month</td></tr><tr><td>Buffer length</td><td>6 hours</td></tr><tr><td>Redemptions</td><td>Monthly, 1-month notice</td></tr><tr><td>Early exit</td><td>Enabled (<span class="math">\Delta > 1</span>)</td></tr><tr><td>Performance fee</td><td>10%</td></tr><tr><td>Vault page</td><td><a href="https://app.pareto.credit/vault#0x24e16F9Fad32891f8bA69cE8fEdd273A2649331A">Link</a></td></tr><tr><td>Addresses</td><td><a href="/pages/VGJccEZaoRpxC0NOCmOc#falconx">Link</a></td></tr></tbody></table>

</details>

<details>

<summary><a href="https://bastiontrading.com/">Bastion Trading</a></summary>

<table><thead><tr><th width="214.625">Borrower</th><th>Bastion Trading</th></tr></thead><tbody><tr><td>Curator</td><td>Pareto</td></tr><tr><td>Vertical</td><td>Market making</td></tr><tr><td>IRM</td><td>Fixed rate</td></tr><tr><td>Chain</td><td>Polygon, Arbitrum, (Ethereum)</td></tr><tr><td>Asset</td><td>USDT, (USDC)</td></tr><tr><td>Cycle length</td><td>One month</td></tr><tr><td>Buffer length</td><td>6 hours</td></tr><tr><td>Redemptions</td><td>Monthly, 1-month notice</td></tr><tr><td>Early exit</td><td>Enabled (<span class="math">\Delta \geq 1</span>)</td></tr><tr><td>Performance fee</td><td>10%</td></tr><tr><td>Vault page</td><td><a href="https://app.pareto.credit/vault#0xaE65d6C295E4a28519182a632FB25b7C1966AED7">Link</a></td></tr><tr><td>Addresses</td><td><a href="/pages/VGJccEZaoRpxC0NOCmOc#bastion-trading-2">Link</a></td></tr></tbody></table>

</details>

<details>

<summary><a href="https://www.adaptivefrontier.com/">Adaptive Frontier</a></summary>

<table><thead><tr><th width="214.625">Borrower</th><th>Adaptive Frontier</th></tr></thead><tbody><tr><td>Curator</td><td>Pareto</td></tr><tr><td>Vertical</td><td>HFT Trading</td></tr><tr><td>IRM</td><td>Fixed rate</td></tr><tr><td>Chain</td><td>Ethereum</td></tr><tr><td>Asset</td><td>USDC</td></tr><tr><td>Cycle length</td><td>One week</td></tr><tr><td>Buffer length</td><td>24 hours</td></tr><tr><td>Redemptions</td><td>Weekly, 7-day notice</td></tr><tr><td>Early exit</td><td>Enabled (<span class="math">\Delta \geq 1</span>)</td></tr><tr><td>Performance fee</td><td>10%</td></tr><tr><td>Vault page</td><td><a href="https://app.pareto.credit/vault#0xae7913c672c7F1f76C2a1a0Ac4de97d082681234">Link</a></td></tr><tr><td>Addresses</td><td><a href="/pages/VGJccEZaoRpxC0NOCmOc#adaptive-frontier">Link</a></td></tr></tbody></table>

</details>

<details>

<summary><a href="https://www.rockawayx.com/">RockawayX</a></summary>

<table><thead><tr><th width="214.625">Borrower</th><th>RockawayX</th></tr></thead><tbody><tr><td>Curator</td><td>Pareto</td></tr><tr><td>Vertical</td><td>Private Credit &#x26; DeFi Liquidity</td></tr><tr><td>IRM</td><td>Fixed rate</td></tr><tr><td>Chain</td><td>Ethereum</td></tr><tr><td>Asset</td><td>USDC</td></tr><tr><td>Cycle length</td><td>One month</td></tr><tr><td>Buffer length</td><td>6 hours</td></tr><tr><td>Redemptions</td><td>Monthly, 31-day notice</td></tr><tr><td>Early exit</td><td>Enabled (<span class="math">\Delta \geq 1</span>)</td></tr><tr><td>Performance fee</td><td>10%</td></tr><tr><td>Vault page</td><td><a href="https://app.pareto.credit/vault#0xEC6a70F62a83418c7fb238182eD2865F80491a8B">Link</a></td></tr><tr><td>Addresses</td><td><a href="/pages/VGJccEZaoRpxC0NOCmOc#rockawayx">Link</a></td></tr></tbody></table>

</details>

<details>

<summary><a href="https://www.abraxascm.com/">Abraxas Capital Management</a></summary>

<table><thead><tr><th width="214.625">Borrower</th><th>Heka Elysium Alpha Bitcoin</th></tr></thead><tbody><tr><td>Curator</td><td>Pareto</td></tr><tr><td>Vertical</td><td>Cross-market Arbitrage</td></tr><tr><td>IRM</td><td>Fixed rate</td></tr><tr><td>Chain</td><td>Ethereum</td></tr><tr><td>Asset</td><td>USDC</td></tr><tr><td>Cycle length</td><td>One week</td></tr><tr><td>Buffer length</td><td>6 hours</td></tr><tr><td>Redemptions</td><td>Weekly, 7-day notice</td></tr><tr><td>Early exit</td><td>Enabled (<span class="math">\Delta \geq 1</span>)</td></tr><tr><td>Performance fee</td><td>10%</td></tr><tr><td>Vault page</td><td><a href="https://app.pareto.credit/vault#0x6dbDEeF7a188bEaFFC2c57006e5D8edAf0C0e9e6">Link</a></td></tr><tr><td>Addresses</td><td><a href="/pages/VGJccEZaoRpxC0NOCmOc#abraxas-capital-management">Link</a></td></tr></tbody></table>

</details>


# USP

**USP** is a synthetic dollar protocol backed by real-world institutional-grade private credit, alongside a globally accessible savings asset, **sUSP**.

{% hint style="info" %}
Pareto's USP is **not** the same as a fiat stablecoin like USDC or USDT. USP is a synthetic dollar, backed by on-chain credit lines. This means that the risks implicated by interacting with USP are inherently different.

Please refer to the [Risks](/product/usp/risks) section for an overview.
{% endhint %}

### USP

Users mint USP ([ERC-20](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/)) by depositing stablecoins, e.g. USDC, USDS, into the `ParetoDollar` contract. The contract mints USP and deposits the underlying assets into [Credit Vaults](/product/credit-vaults). Credit Vaults lend assets to institutional players that perform yield strategies to generate yield later distributed to USP stakers, i.e., sUSP holders (`ParetoDollarStaking` contract). A small percentage of total funds can be deposited also in [ERC-4626](https://ethereum.org/en/developers/docs/standards/tokens/erc-4626/) compliant yield sources to process redeems faster.

The [allocation](/product/usp/allocation) of funds for each credit vault is determined by a board that operates through the `ParetoDollarQueue` contract.

<details>

<summary>Benefits</summary>

USP offers the following benefits:

* **Composable**: USP is a transferable, permissionless asset that integrates across DeFi and CeFi, streamlining capital deployment, risk management, and settlements
* **Capital efficient**: Minted 1:1 against major stablecoins, USP is deployed into a diversified portfolio of liquid, short- and long-term credit, balancing liquidity and yield
* **Protected**: USP holds senior priority in the capital stack and is shielded by a [peg stability reserve](#peg-stability-mechanism) that provides an additional buffer against defaults and market stress

</details>

<details>

<summary>Aquisition</summary>

The acquisition of USP happens either through the USP contract or in a permissionless way through AMM pools. Users can:

* **Acquire USP permissionlessly** using external AMM pools with assets such as USDT or USDC
* **Mint USP directly** by depositing stablecoins (USDC, USDS)*,* subject to clearing users' verification checks
* **Redeem USP directly** by burning the token and receiving backing asset&#x73;*,* subject to clearing users' verification checks

</details>

### sUSP

Once USP is staked into sUSP, users can earn yield from the interest generated by [Credit Vaults](/product/credit-vaults). The interest paid is reflected in a higher sUSP price than the plain USP effectively creating an interest-bearing token. sUSP's yield is also boosted by non-staked USP, for which the collateral will still be used by Credit Vaults, but receive no interest that instead is distributed only to USP stakers. Stake USP is not rehypothecated in any way and just stays in the contract.

<details>

<summary>Benefits</summary>

sUSP offers the following benefits:

* **Yield generating**: sUSP, designed for stable, risk-adjusted returns, allows users to earn yield from Credit Vaults and participate in Pareto’s long-term growth
* **Liquid**: sUSP is fully liquid and non-custodial. Holders can exit at any time by simply unstaking, without lockups or withdrawal restrictions
* **Diversified**: sUSP provides exposure to a broad set of credit lines reducing single-counterparty risk through structured diversification

</details>

<details>

<summary>Acquisition</summary>

* **Stake and unstake USP** through [Pareto's app](https://app.pareto.credit/) to receive rewards from Credit Vaults revenue.

</details>

### Peg stability mechanism

USP is backed 1:1 with funds lent to institutional players. If one of the borrowers fails to deliver the funds back to the vaults, sUSP holders will cover the losses by having their conversion price to USP reduced to keep the peg for USP stable (a Stability Fund has been created to provide a buffer before slashing sUSP holders).

* If the USP price is above $1, verified parties can mint USP by depositing stablecoin collaterals moving its price back to $1.
* If the USP price is below $1 then verified parties can buy USP in the market, request a redemption, and receive stablecoins collateral after waiting the cooldown period, if any.


# Allocation

This section describes how the USP board allocates collateral between the whitelisted yield sources. These are classified according to some liquidity tiers

* T1: is a cash equivalent product, instantly redeemable (0-2 days) --> $$w\_s$$
* T2: is a short-term yield product, redeemable in less than 1 week ($$\leq$$ 7 days) --> $$w\_7$$
* T3: is a long-term yield product, redeemable in less than 1 month (8-30 days) --> $$w\_{30}$$

The weights should satisfy the condition $$w\_s + w\_{7} + w\_{30} ;=; 1.$$

### Allocation rules

1. Sort vaults by descending yield vs duration score $$S\_i$$ (see [#formulae](#formulae "mention"))
2. Fill Tier 2 weight up to the global cap $$c\_7$$. One-fourth of T2 allocations unlock every week and are constantly moved back to T1
3. Allocate the remainder to Tier 3 until the target length (12d) is reached

where $$c\_7$$ limits the exposure to T2 products: too small allocation decreases the yield, but too large one risks draining liquidity if many users redeem within one week.

<details>

<summary>Formulae</summary>

Given some key parameters:

* $$A$$ = total collateral (USDC + USDS)
* $$R\_d$$ = net USP redemptions on the day $$d$$
* $$APR\_{i, \tau\_i}$$= APR and epoch (days) of vault $$i$$
* $$\sigma\_w$$ = daily standard deviation of redemptions (look-back $$W \approx 90d$$)
* $$p$$ = instant-service percentile (e.g. 97.5%)

***

To compute the instant-liquidity buffer (T1)

1. Statistical need --> $$L = z\_p,\sigma\_w,\sqrt{H}$$

   where $$H =$$ days promised instant liquidity (usually 1) and $$z\_p \approx 1.96 ; \text{for} :  p = 97.5%$$&#x20;
2. Add operational cushion --> $$\text{buffer}\_{\min}=L+\kappa\_A$$ \
   where $$\kappa \approx 1%$$ of $$A$$ (oracle lag, gas spikes)
3. Target balance --> $$B\_{\text{sUSDS}}=\max \left(\text{buffer}*{\min},,B*{\min}\right)$$
4. Convert to portfolio weight $$w\_s^{\*}=\dfrac{B\_{\text{sUSDS}}}{A}$$

If the current $$w\_s < w\_s^\*$$ then move funds into T1, otherwise sweep the surplus out of the best-scoring vaul&#x74;*.*

To allocate the surplus, we compute a yield vs duration scoring for every vault $$i$$ using the formula

$$S\_i = \dfrac{\text{APR}\_i - f\_i}{1 + \lambda \tau\_i}$$

where $$f\_i$$ is the annualized fee, and $$\lambda \approx 0.04$$ is a factor used to penalize long-term strategies.

T3 allocation should be larger than the target length ($$\tau\_{\text{target}} \approx 12$$ days)

$$\dfrac{\sum\_i w\_i \tau\_i}{1 - w\_s^{\*}} ;\le; \tau\_{\text{target}}$$

where $$w\_{i, \max}$$ is an optional exposure limit to any single vault or protocol. It should be used only when two or more independent vaults exist.

A keeper routine should be set to rebalance funds either weekly **o**r whenever $$| (w\_s - w\_{s\_\text{target}}) > \varepsilon |$$

```python
def rebalance():
    A = current_AUM()
    sigma_w = stdev(redemptions, window=W)
    L = z_p * sigma_w * sqrt(H)
    B_s = max(L + kappa * A, B_min)
    w_s_target = B_s / A

    scores = [
        (i, (apr[i] - fee[i]) / (1 + lambda_ * tau[i]))
        for i in vaults
    ]
    scores.sort(key=lambda x: x[1], reverse=True)

    alloc = {"sUSDS": w_s_target}
    remaining = 1 - w_s_target
    w7 = 0

    for i, _ in scores:
        if tau[i] <= 7 and w7 < c7:                 # fill T2
            x = min(c7 - w7, remaining)
            alloc[i] = x
            w7 += x
            remaining -= x
        elif remaining > 0:                         # fill T3
            alloc[i] = remaining
            remaining = 0
        if remaining <= 0:
            break

    execute_onchain_swaps(alloc)
```

</details>

### Initial parameters

The USP board can modify the allocation parameters. The default values are:

<table><thead><tr><th width="94.69140625">Variable</th><th width="482.59375">Description</th><th>Default value</th></tr></thead><tbody><tr><td><span class="math">p</span></td><td>Instant-redeem service level</td><td>97–99%</td></tr><tr><td><span class="math">\kappa</span></td><td>Operational cushion</td><td>1–2 % <em>A</em></td></tr><tr><td><span class="math">\lambda</span></td><td>Converts “epoch-day” into APR penalty</td><td>0.03–0.05</td></tr><tr><td><span class="math">\tau_{\text{target}}</span></td><td>Max weighted epoch</td><td>10–14 days</td></tr><tr><td><span class="math">c_7</span></td><td>Upper bound on the total weight of the 7-day vault sleeve</td><td>20–30 % <em>A</em></td></tr><tr><td><span class="math">w_{i, \max}</span></td><td>Optional per-vault cap. Use once the number of vaults is <span class="math">\geq 3</span></td><td>off / 30 % <em>A</em></td></tr></tbody></table>


# Risks

This section describes the risks associated with US&#x50;*,* and the actions taken to mitigate such risks.

<details>

<summary>Stablecoin related risk</summary>

The use of stablecoins such as USDC or USDS introduces additional risks associated with fiat-backed stablecoins. Risks associated with these stablecoins are generally disclosed by the issuer of the token (see [USDC terms](https://docs.pareto.credit/product/usp/www.circle.com/legal/usdc-terms) and [USDS risks](https://docs.sky.money/user-risks)).

Centralized stablecoins provide stability and capital efficiency, but they introduce:

* Unhedgeable custodial risk with bond reserves in regulated bank or trust accounts, which are prone to censorship.
* A critical reliance upon the existing traditional banking infrastructure and country-specific evolving regulations.
* Represent an unsecured credit position to both the issuer and underlying bank holding the reserve assets while mixing these assets with other bank lending activities.

</details>

<details>

<summary>Counterparty risk</summary>

USP generates yield from Credit Vaults that lend funds to TradFi institutions. This introduces a counterparty risk for USP holders given there is a chance that a party fails to meet its obligations, potentially leading to financial losses.&#x20;

To mitigate this risk, USP relies on:

1. Stability fund: 5% of the fees generated by USP are saved in a fund that should cover potential CVs' losses
2. Stakers' deposits: sUSP holders should cover additional losses by having their conversion price to USP reduced to keep the peg for USP stable

</details>


# FAQs

<details>

<summary>What is USP?</summary>

USP is a credit-backed synthetic dollar, built on infrastructure tailor-made for financial institutions. USP uses the [ERC-20](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/) token standard.&#x20;

Unlike traditional stablecoins that rely on fiat reserves or crypto collateral, USP is natively tied to real-world credit exposure. It serves as a foundational asset in Pareto’s on-chain credit ecosystem by enabling users to access, trade, and earn yield from private credit markets.

By combining DeFi composability with TradFi-grade credit underwriting, USP offers a decentralized and scalable alternative to the incumbent offering. One that’s programmable, capital-efficient, and aligned with institutional risk models.

</details>

<details>

<summary>What is sUSP and how does it work?</summary>

sUSP is the staked version of USP, designed to distribute the yield generated by Credit Vaults to stakers. When users stake USP, they receive sUSP, an [ERC-4626](https://ethereum.org/en/developers/docs/standards/tokens/erc-4626/) token that tracks the share of the Credit Vaults exposition.&#x20;

* Staking: USP holders can deposit into the sUSP contract in a permissionless way and receive sUSP in return.
* Yield Accrual: As revenue is generated from the underlying credit activity (e.g., interest from institutional loans), it is periodically distributed to sUSP holders. This causes the exchange rate between sUSP and USP to increase, representing the accrued yield.
* Unstaking: Users can redeem sUSP back into USP at any time, subject to protocol-defined conditions or cooldowns. The amount of USP received reflects the current exchange rate, including any earned yield.

</details>

<details>

<summary>What is USP backing?</summary>

USP is backed 1:1 by Credit Vaults (and USDS).

These funds are deposited into Credit Vaults and borrowed by vetted institutional borrowers to generate yield for stakers. Pareto’s Credit Vaults offers built-in risk controls such as:

* Professional curators overseeing loan terms and counterparty risk
* Institutional KYC and legal structuring
* Transparent reporting and enforcement mechanisms

Additionally, USP token holders are backed by USP stakers (Junior tranche) and a Stability Fund to absorb any loss.&#x20;

</details>

<details>

<summary>Is USP a stablecoin?</summary>

No, USP is not a stablecoin in the traditional sense. While it is soft-pegged to 1, it is better described as a credit-backed synthetic dollar. Unlike fiat-backed stablecoins (USDC, USDT), USP is backed by real-world credit positions, i.e. loans issued to vetted institutional borrowers through Pareto’s Credit Vaults.

</details>

<details>

<summary>How is the USP peg preserved?</summary>

Verified users maintain the peg through arbitrage and a controlled mint/redeem mechanism.

* If USP falls below 1, users can buy it on the market and redeem it for 1 worth of stablecoins, driving USP price back up
* If USP rises above 1, they can mint new USP by depositing stablecoins, increasing supply, and pushing the price down

Non-verified users can trade USP freely on decentralized exchanges but cannot access mint/redeem functions.

In case of borrower default, a Stability Fund covers losses first. If needed, sUSP holders absorb remaining losses by receiving less USP per staked token. The protocol can also burn excess USP to support peg stability.

{% hint style="info" %}
Note: While staking offers yield, sUSP holders bear "junior risk", meaning they may absorb losses if borrowers default and the Stability Fund is insufficient. This tradeoff allows the system to prioritize peg stability for USP while rewarding active participants.
{% endhint %}

</details>

<details>

<summary>What is the Stability Fund? How does it work?</summary>

The Stability Fund is a reserve held by the protocol to absorb losses in the event of a borrower default. It acts as the first line of defense to protect the USP peg before any losses are passed on to sUSP holders. By covering shortfalls proactively, the fund helps maintain confidence in USP and reduces the likelihood of conversion slashing for stakers.

The Stability Fund will be gradually funded by a 5% fee on generated interest, allowing it to grow over time.

</details>

<details>

<summary>How can I get USP?</summary>

There are two ways to get USP:

1. Mint via the [Pareto app](https://app.pareto.credit/): Verified users can mint USP directly by depositing stablecoins into the protocol’s smart contract.&#x20;
2. Buy on the open market: Anyone can purchase USP from decentralized exchanges such as [Uniswap](https://app.uniswap.org/) or [Curve](https://curve.fi/dex/ethereum/swap/?from=0xdac17f958d2ee523a2206206994597c13d831ec7\&to=0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee), just like any other token.

</details>

<details>

<summary>Who can mint and redeem USP?</summary>

Only verified users can mint or redeem USP directly via the [Pareto App](https://app.pareto.credit/). They can either issue new USP (minting) or convert USP back into stablecoins (redeeming), at a 1:1 ratio.

This permissioned model ensures regulatory compliance and controlled issuance tied directly to on-chain credit origination. It also helps maintain the integrity of the 1 peg by limiting mint/redeem access to trusted entities operating within Pareto’s credit infrastructure.

Non-verified users cannot mint or redeem USP but can still access USP through secondary markets.

</details>

<details>

<summary>How does USP manage redemptions?</summary>

Redemptions happen instantly via secondary markets or by burning the token on Pareto.

For sUSP, there’s a 7-day cooldown period, then a 1 to 30-day wait depending on CVs maturity since redemptions align with Credit Vault cycle lengths.

</details>

<details>

<summary>How can I earn with USP?</summary>

Users can earn yield by staking USP into the SUSP vault, Pareto’s yield-bearing layer for credit-backed dollars. Here’s how it works:

* Users stake USP into the protocol to receive sUSP
* As the protocol earns revenue from institutional lending activity, yield is distributed to sUSP holders.
* The value of sUSP increases over time relative to USP, reflecting your accrued earnings.
* Users can unstake anytime, converting sUSP back to USP at the prevailing exchange rate (subject to protocol conditions or cooldowns).

</details>

<details>

<summary>Is USP freely transferrable?</summary>

Yes. USP is fully transferable and freely tradable by anyone on supported decentralized exchanges. You can buy, sell, and use USP in DeFi protocols just like any other ERC-20 token.

However, USP minting, redeeming, and staking require users' verification.

</details>

<details>

<summary>What makes USP unique?</summary>

* Yield from trusted, institutional partners
* Backed by real-world credit
* Built to deliver consistent, market-driven returns
* Institutional-grade design, with open market access
* High composability, that unlocks seamless DeFi integrations

</details>

<details>

<summary>Is USP safe to use?</summary>

USP inherits risk from the underlying credit strategies, but the system is designed with institutional risk controls, curated loan origination, and transparent reporting. While not risk-free, it aims to offer a more capital-efficient and transparent alternative to traditional dollar-pegged assets.

The USP system uses a two-tier risk structure:

* Senior position -> USP holders\
  These users are protected and can redeem USP at 1 unless extreme losses occur. They are last in line to absorb risk.
* Junior position -> sUSP holders\
  Users who stake USP into sUSP earn protocol yield but take on first-loss risk. If a borrower defaults and the Stability Fund is depleted, sUSP value may be reduced to protect USP.

This design mirrors traditional credit tranching by offering a boosted yield to junior participants in exchange for greater risk.

</details>


# Users


# Lenders

Lenders, such as asset managers, digital asset funds, and other professional investors, are an integral part of the Credit Vault setup and are an essential element of the lending-borrowing equation.&#x20;

### Key responsibilities

<figure><img src="/files/sUagZojU0nynVMtWoqsW" alt=""><figcaption></figcaption></figure>

* Lenders must be whitelisted and complete the required [verification](/product/users/lenders/verification) via Keyring before being allowed to interact with Credit Vaults.
* Lenders must allow Credit Vaults (spending allowance) to execute their deposit/redeem requests.
* Lenders can deposit funds between lending cycles or queue their deposit requests if the cycle is running. Upon deposit, lenders receive the equivalent in LP tokens in their wallet, representing their principal and accrued interest. The Credit Vault LP tokens accumulate interest through their exchange rate; over time, each cvToken becomes convertible into an increasing amount of the deposited funds, which represents the interest accrued according to the Credit Agreement.&#x20;
* Lenders can redeem funds by sending a withdrawal request to claim back funds at the end of the following lending cycle. When completing the withdrawal request, lenders send back an amount of LP tokens proportional to the withdrawal amount. At the end of the next lending cycle, they can complete the process by claiming their funds.&#x20;
  * When the interest rate of the next lending cycle is lower than the previous one by 1% or more (or otherwise provided in the Credit Agreement), lenders are entitled to an **early exit** and can redeem funds with a shorter waiting period, i.e., within 72 hours. &#x20;


# Verification

The verification and KYC compliance on Credit Vaults is processed through [Keyring](https://www.keyring.network/).

Keyring offers streamlined and flexible solutions&#x20;

1. Through **Keyring Connect**, it is possible to seamlessly inherit compliance verification from third-party platforms such as Coinbase, Binance, Kraken, and other centralized exchanges. This process includes credentials and information, including entity jurisdiction, source of capital, source of wealth, source of funds, directors, UBOs, significant controllers, and letters of authorization.
2. Alternatively, if required by the Borrower for more comprehensive verification needs, **Keyring Pro** lets borrowers establish bespoken KYC/KYB policies, requesting more detailed information and document uploads from lenders. A live register of verified lenders is maintained within Credit Vaults.


# Guides


# Onboarding

This guide outlines the steps required to complete the onboarding for liquidity providers on Pareto. The process consists of two main phases: verification and contract signature.

To begin:

* Visit [app.pareto.credit](https://app.pareto.credit)
* Select a Credit Vault (e.g., the Fasanara pool)
* Connect a supported wallet

{% embed url="<https://youtu.be/_FRz584LFwo>" %}

{% stepper %}
{% step %}

#### Verification

By default, Credit Vaults offer a zero-knowledge (ZK) verification method powered by Keyring Connect. In select cases, a standard KYC process with document uploads should be followed instead.&#x20;

Keyring Connect integrates existing KYC credentials from centralized exchanges such as Binance, Kraken, and Coinbase. This enables seamless verification while preserving privacy and minimizing data exposure.

* Install the Keyring Chrome extension
* Launch the verification process
* Create or log in to a Keyring account. Verify the account
* Select a centralized exchange (CEX) within the extension to link credentials
* Authenticate and complete the verification process
* Generate credentials. A blockchain transaction will be triggered to cover attestation fees
* Refresh the app page

{% hint style="info" %}
Note: Verified credentials aren't shared across all vaults on Pareto. New credentials must be generated for each vault the user interacts with. Keyring may request periodic re-authentication, similar to session revalidation flows (e.g., Google OAuth).
{% endhint %}
{% endstep %}

{% step %}

#### Contract signature

Before depositing, users are required to sign two agreements:

1. [Terms of Service (ToS)](https://pareto.credit/terms-of-service/) that govern interaction with Pareto
2. Master Loan Agreement (MLA) that governs the lending relationship between the liquidity provider and the borrower (e.g., Fasanara Digital)

These contracts are signed on-chain, linking a unique ID to the user’s address via e-signature. The contract signature requires the execution of a transaction from the verified wallet. Users will be prompted to sign an on-chain message to complete this step.
{% endstep %}
{% endstepper %}


# Deposit

Once [onboarding](/product/users/lenders/guides/onboarding) is completed, users can proceed to deposit into the selected Credit Vault.&#x20;

Users can deposit during the cycle **buffer period**, i.e., the 6 to 24 hours between the end of the previous lending cycle and the start of the new one. Alternatively, users can use the Queue contract to schedule their deposit while a **cycle is running**.

## During a buffer period

Users should sign two transactions:

{% stepper %}
{% step %}

#### Spending approval

To allow Pareto’s smart contract to process users’ deposits
{% endstep %}

{% step %}

#### Deposit

To execute the lending action
{% endstep %}
{% endstepper %}

Upon completion:

* The user’s wallet will reflect a reduction in the deposited stablecoin
* The user will receive [Credit Vault LP tokens](/developers/addresses/product/credit-vaults) representing his position in the pool

{% embed url="<https://youtu.be/TO6t9Kx1ulg>" %}

## While a lending cycle is running

Alternatively, users can use the Queue contract to schedule their deposit while a cycle is running. Users will queue a deposit request, which will be processed by the pool curator at the first available buffer period.&#x20;

The same Spending Approval and deposit flow applies

{% stepper %}
{% step %}

#### Spending approval

To allow Pareto’s smart contract to process users’ deposits
{% endstep %}

{% step %}

#### Request deposit

To execute the deposit request action
{% endstep %}

{% step %}

#### Claim LP tokens

The user will **need to claim** Credit Vault LP tokens representing his position in the pool after the new lending cycle starts
{% endstep %}
{% endstepper %}

Upon completion of steps 1, and 2:

* The user’s wallet will reflect a reduction in the deposited stablecoin
* The user will need to claim his [Credit Vault LP tokens](/developers/addresses/product/credit-vaults) representing his position in the pool after the new lending cycle starts

<figure><img src="/files/NV8IHD3MvyftYf5bgXjT" alt=""><figcaption><p>Claim LP tokens preview when a deposit was made during a cycle running</p></figcaption></figure>

{% embed url="<https://youtu.be/zP68ipECTnU>" %}


# Redeem

Users can withdraw during the cycle **buffer period**, i.e., the 6 to 24 hours between the end of the previous lending cycle and the start of the new one. Alternatively, users can use the Queue contract to schedule their withdrawal while a **cycle is running**. The exit request will be processed by the pool curator at the first available buffer period.&#x20;

While deposits happen in a single step, withdrawals are a two-step process happening during two different cycles:

{% stepper %}
{% step %}

#### Spending approval

To allow Pareto’s smart contract to process users’ LP tokens exit request
{% endstep %}

{% step %}

#### Withdrawal request

A user requests to redeem funds (principal and/or accrued interest) at the end of Cycle I.
{% endstep %}

{% step %}

#### Funds claim

At the end of the following cycle (Cycle II), the borrower repays interest and any requested withdrawals. Users who requested to exit can now claim their funds.
{% endstep %}
{% endstepper %}

Upon completion of steps 1, and 2

* The user’s wallet will reflect a reduction in the [Credit Vault LP tokens](/developers/addresses/product/credit-vaults) representing his position in the pool
* The user will need to claim his stablecoins representing his initial deposit, plus any interest generated after the new lending cycle starts

{% hint style="success" %}
**Early exit**

When the interest rate of the next lending cycle is lower than the previous one by 1% or more (or otherwise provided in the Credit Agreement), lenders are entitled to an **early exit** and can redeem funds with a shorter waiting period, i.e., within 72 hours. &#x20;

For example, a lender requests a withdrawal on Jan 31 during Cycle I, where the interest rate is 15%.  If the Cycle II rate drops to 12%, the lender qualifies for an early exit and can claim his funds 72 hours after Cycle II starts (i.e., on Feb 3).
{% endhint %}

Similarly, users can use the Queue contract to schedule their redemptions while a cycle is running. Users will queue a withdrawal request, which will be processed by the pool curator at the first available buffer period.&#x20;

{% embed url="<https://youtu.be/AP3pbQrNpoQ>" %}


# Curators

Curators are an integral part of the Credit Vault setup and are essential for stakeholder relations and vault activities. They can leverage underwriting on-chain expertise to enhance capital efficiency, mitigate counterparty risk, and elevate market transparency with institutional-grade credit structuring.

New curators should begin with this overview to build a solid foundation, while experienced curators may reference specific sections for targeted guidance.

### Key responsibilities

<figure><img src="/files/km860Qz0M90uMi6MASRl" alt=""><figcaption></figcaption></figure>

* The curator is responsible for opening and closing lending cycles. At the start of a cycle, funds are transferred from the CV to the borrower's wallet. At the end of the cycle, the curator closes the cycle and automatically retrieves interest and processes any withdrawal requests.
* The curator manages the execution of pending deposit and withdrawal requests in the queue contracts.
* If needed, the curator can adjust vault parameters such as APR, fees, and lending cycle length.&#x20;

### Curator app

The Pareto manager app is a specialized front-end interface designed for configuring and managing Credit Vaults. Available at [manager.pareto.credit](https://manager.idle.finance/), this tool provides real-time visibility into fund inflows and outflows. Only whitelisted addresses can interact with the manager app.

From the manager app, curators can easily see the status of the current lending cycle, a countdown to the epoch end, and the borrower's wallet allowance and balance. When a lending cycle ends, they can close it and adjust the length and APR for the following cycle.&#x20;

<figure><img src="/files/fKmfioUTOatofRJetqZu" alt=""><figcaption></figcaption></figure>

**Implementation note:** Some actions are not yet implemented in the manager app. For this reason, curators should interact directly with [vault contracts](/developers/addresses) through verified sources such as [Etherscan](https://etherscan.io/) or [Blockscout](https://www.blockscout.com/). Always verify contract addresses before interaction.


# Borrowers

Borrowers are essential to offer yield strategies to liquidity providers on Pareto. They can leverage proprietary expertise to collect new funds from DeFi users while providing yield strategies that are traditionally limited to TradFi institutions.

### Key responsibilities

<figure><img src="/files/qNAsRBq4LNiPr3PUUUTU" alt=""><figcaption></figcaption></figure>

* At the start of each cycle (also referred to as "loan cycle" or "loan period" in the Credit Agreement), the borrower automatically receives funds deposited into the CV.
* The borrower’s wallet address is fixed and cannot be modified after smart contract deployment.
* Prior to the end of each cycle, the borrower must ensure to have approved (i.e., set allowance) the CV main contract to automatically settle interest payouts and withdrawal requests.
* The borrower’s wallet must maintain sufficient funds to cover interest and standard withdrawal requests at the end of the cycle and repricing withdrawals once a new lending cycle begins.

### Curator app

The Pareto manager app is a specialized front-end interface designed for configuring and managing Credit Vaults. Available at [manager.pareto.credit](https://manager.idle.finance/), this tool provides real-time visibility into fund inflows and outflows. Only whitelisted addresses can interact with the manager app.

From the manager app, borrowers can easily see the status of the current lending cycle, a countdown to the epoch end, and the wallet allowance and balance.

<figure><img src="/files/fKmfioUTOatofRJetqZu" alt=""><figcaption></figcaption></figure>

**Implementation note:** Some actions are not yet implemented in the manager app. For this reason, curators should interact directly with [vault contracts](/developers/addresses) through verified sources such as [Etherscan](https://etherscan.io/) or [Blockscout](https://www.blockscout.com/). Always verify contract addresses before interaction.


# Addresses


# Product


# Credit Vaults

For each vault deployed, the underlying token, main contract, strategy, LP token, and queue contract, if available, are listed. The ABI of the Credit Vault contracts can be found here: [JSON](https://github.com/Idle-Labs/idle-tranches/blob/master/abi/IdleCDOEpochVariant.json)

## Ethereum

### Fasanara Digital

<table data-full-width="false"><thead><tr><th width="189">Description</th><th>Address</th></tr></thead><tbody><tr><td>Token USDC</td><td><a href="https://etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48">0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48</a></td></tr><tr><td>Contract</td><td><a href="https://etherscan.io/address/0xf6223C567F21E33e859ED7A045773526E9E3c2D5">0xf6223C567F21E33e859ED7A045773526E9E3c2D5</a></td></tr><tr><td>Strategy</td><td><a href="https://etherscan.io/address/0xC35D078092872Ec1f2ae82bcd6f0b6b89F0850de">0xC35D078092872Ec1f2ae82bcd6f0b6b89F0850de</a></td></tr><tr><td>LP token</td><td><a href="https://etherscan.io/address/0x45054c6753b4bce40c5d54418dabc20b070f85be">0x45054c6753b4Bce40C5d54418DabC20b070F85bE</a></td></tr><tr><td>Queue</td><td><a href="https://etherscan.io/address/0x0b4F695B05902efc14344d19ED1d0B0E061C8A3E">0x0b4F695B05902efc14344d19ED1d0B0E061C8A3E</a></td></tr></tbody></table>

### Bastion Trading

<table data-full-width="false"><thead><tr><th width="189">Description</th><th>Address</th></tr></thead><tbody><tr><td>Token USDC</td><td><a href="https://etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48">0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48</a></td></tr><tr><td>Contract</td><td><a href="https://etherscan.io/address/0x4462eD748B8F7985A4aC6b538Dfc105Fce2dD165">0x4462eD748B8F7985A4aC6b538Dfc105Fce2dD165</a></td></tr><tr><td>Strategy</td><td><a href="https://etherscan.io/address/0x06975bB418EFFB0029fe278A6fA15B92bb97496F">0x06975bB418EFFB0029fe278A6fA15B92bb97496F</a></td></tr><tr><td>LP token</td><td><a href="https://etherscan.io/address/0xC49b4ECc14aa31Ef0AD077EdcF53faB4201b724c">0xC49b4ECc14aa31Ef0AD077EdcF53faB4201b724c</a></td></tr></tbody></table>

### Adaptive Frontier

<table data-full-width="false"><thead><tr><th width="189">Description</th><th>Address</th></tr></thead><tbody><tr><td>Token USDC</td><td><a href="https://etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48">0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48</a></td></tr><tr><td>Contract</td><td><a href="https://etherscan.io/address/0x14B8E918848349D1e71e806a52c13D4e0d3246E0">0x14B8E918848349D1e71e806a52c13D4e0d3246E0</a></td></tr><tr><td>Strategy</td><td><a href="https://etherscan.io/address/0xa30bE796FB2BAbF9228359E86A041c14e29f86Fc">0xa30bE796FB2BAbF9228359E86A041c14e29f86Fc</a></td></tr><tr><td>LP token</td><td><a href="https://etherscan.io/address/0xae7913c672c7F1f76C2a1a0Ac4de97d082681234">0xae7913c672c7F1f76C2a1a0Ac4de97d082681234</a></td></tr><tr><td>Queue</td><td><a href="https://etherscan.io/address/0x5eCF8bF9eae51c2FF47FAc8808252FaCd8e36797">0x5eCF8bF9eae51c2FF47FAc8808252FaCd8e36797</a></td></tr></tbody></table>

### FalconX

<table data-full-width="false"><thead><tr><th width="189">Description</th><th>Address</th></tr></thead><tbody><tr><td>Token USDC</td><td><a href="https://etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48">0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48</a></td></tr><tr><td>Contract</td><td><a href="https://etherscan.io/address/0x433D5B175148dA32Ffe1e1A37a939E1b7e79be4d">0x433D5B175148dA32Ffe1e1A37a939E1b7e79be4d</a></td></tr><tr><td>Strategy</td><td><a href="http://etherscan.io/address/0x17E9Ab2992dfecBe779a06A92a6cDB9fE6aEeEf3">0x17E9Ab2992dfecBe779a06A92a6cDB9fE6aEeEf3</a></td></tr><tr><td>LP token</td><td><a href="http://etherscan.io/address/0xC26A6Fa2C37b38E549a4a1807543801Db684f99C">0xC26A6Fa2C37b38E549a4a1807543801Db684f99C</a></td></tr><tr><td>Queue</td><td><a href="http://etherscan.io/address/0x5cC24f44cCAa80DD2c079156753fc1e908F495DC">0x5cC24f44cCAa80DD2c079156753fc1e908F495DC</a></td></tr></tbody></table>

### RockawayX

<table data-full-width="false"><thead><tr><th width="189">Description</th><th>Address</th></tr></thead><tbody><tr><td>Token USDC</td><td><a href="https://etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48">0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48</a></td></tr><tr><td>Contract</td><td><a href="https://etherscan.io/address/0x9cF358aff79DeA96070A85F00c0AC79569970Ec3">0x9cF358aff79DeA96070A85F00c0AC79569970Ec3</a></td></tr><tr><td>Strategy</td><td><a href="https://etherscan.io/address/0x3Fc0265E92EeafED0cCd9F8621764Ce0981882cE">0x3Fc0265E92EeafED0cCd9F8621764Ce0981882cE</a></td></tr><tr><td>LP token</td><td><a href="https://etherscan.io/token/0xEC6a70F62a83418c7fb238182eD2865F80491a8B">0xEC6a70F62a83418c7fb238182eD2865F80491a8B</a></td></tr><tr><td>Queue</td><td><a href="https://etherscan.io/address/0xBC6cffAFC8F98d7DF780cE05fA55e14781C1C14D">0xBC6cffAFC8F98d7DF780cE05fA55e14781C1C14D</a></td></tr></tbody></table>

### Abraxas Capital Management \[DEPRECATED]

<table data-full-width="false"><thead><tr><th width="189">Description</th><th>Address</th></tr></thead><tbody><tr><td>Token USDC</td><td><a href="https://etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48">0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48</a></td></tr><tr><td>Contract</td><td><a href="https://etherscan.io/address/0x0Ad21c3Ac4ffE7C1Ed2b1B717cd051DeD365fa32">0x6dbDEeF7a188bEaFFC2c57006e5D8edAf0C0e9e6</a></td></tr><tr><td>Strategy</td><td><a href="https://etherscan.io/address/0xE7E13F902Ea13e6EaAa4ed9A2DE5898436D12cbF">0xE7E13F902Ea13e6EaAa4ed9A2DE5898436D12cbF</a></td></tr><tr><td>LP token</td><td><a href="https://etherscan.io/token/0x6dbDEeF7a188bEaFFC2c57006e5D8edAf0C0e9e6">0x6dbDEeF7a188bEaFFC2c57006e5D8edAf0C0e9e6</a></td></tr><tr><td>Queue</td><td><a href="https://etherscan.io/address/0xeBa43518e4fddA8D82Ad711DA3b27717779DBdF7">0xeBa43518e4fddA8D82Ad711DA3b27717779DBdF7</a></td></tr></tbody></table>

## Optimism

### FalconX \[DEPRECATED]

<table data-full-width="false"><thead><tr><th width="189">Description</th><th>Address</th></tr></thead><tbody><tr><td>Token USDC</td><td><a href="https://optimistic.etherscan.io/token/0x0b2c639c533813f4aa9d7837caf62653d097ff85">0x0b2C639c533813f4Aa9D7837CAf62653d097Ff85</a></td></tr><tr><td>Contract</td><td><a href="https://optimistic.etherscan.io/address/0xD2c0D848aA5AD1a4C12bE89e713E70B73211989B">0xD2c0D848aA5AD1a4C12bE89e713E70B73211989B</a></td></tr><tr><td>Strategy</td><td><a href="https://optimistic.etherscan.io/address/0x2BCf124aa4f7F32f0fe54f498d924B934C942B31">0x2BCf124aa4f7F32f0fe54f498d924B934C942B31</a></td></tr><tr><td>LP token</td><td><a href="https://optimistic.etherscan.io/address/0x24e16f9fad32891f8ba69ce8fedd273a2649331a">0x24e16F9Fad32891f8bA69cE8fEdd273A2649331A</a></td></tr><tr><td>Queue</td><td><a href="https://optimistic.etherscan.io/address/0x463465c334742D72907CA5fB97db44688B4EC3dC">0x463465c334742D72907CA5fB97db44688B4EC3dC</a></td></tr></tbody></table>

## Arbitrum

### Bastion Trading \[DEPRECATED]

<table data-full-width="false"><thead><tr><th width="189">Description</th><th>Address</th></tr></thead><tbody><tr><td>Token USDT</td><td><a href="https://arbiscan.io/token/0xfd086bc7cd5c481dcc9c85ebe478a1c0b69fcbb9">0xFd086bC7CD5C481DCC9C85ebE478A1C0b69FCbb9</a></td></tr><tr><td>Contract</td><td><a href="https://arbiscan.io/address/0x3919396Cd445b03E6Bb62995A7a4CB2AC544245D">0x3919396Cd445b03E6Bb62995A7a4CB2AC544245D</a></td></tr><tr><td>Strategy</td><td><a href="https://arbiscan.io/address/0x5b11507f8a91005ad1591f54ef64133aaba6d06e">0x5b11507F8A91005aD1591F54ef64133AabA6d06E</a></td></tr><tr><td>LP token</td><td><a href="https://arbiscan.io/address/0x97f476f664a95106931f78113489e0361cf1c9fa">0x97F476F664A95106931f78113489e0361Cf1c9Fa</a></td></tr><tr><td>Queue</td><td><a href="https://arbiscan.io/address/0x133F1C751f25C2AAf0E83f0609A67074915144A4">0x133F1C751f25C2AAf0E83f0609A67074915144A4</a></td></tr></tbody></table>

## Polygon

### Bastion Trading \[DEPRECATED]

<table data-full-width="false"><thead><tr><th width="189">Description</th><th>Address</th></tr></thead><tbody><tr><td>Token USDT</td><td><a href="https://polygonscan.com/address/0xc2132d05d31c914a87c6611c10748aeb04b58e8f">0xc2132d05d31c914a87c6611c10748aeb04b58e8f</a></td></tr><tr><td>Contract</td><td><a href="https://polygonscan.com/address/0xF9E2AE779a7d25cDe46FccC41a27B8A4381d4e52">0xF9E2AE779a7d25cDe46FccC41a27B8A4381d4e52</a></td></tr><tr><td>Strategy</td><td><a href="https://polygonscan.com/address/0x4Ddb301403Ee3C4B4099ED128b34c36d86f6df35">0x4Ddb301403Ee3C4B4099ED128b34c36d86f6df35</a></td></tr><tr><td>LP token</td><td><a href="https://polygonscan.com/address/0xaE65d6C295E4a28519182a632FB25b7C1966AED7">0xaE65d6C295E4a28519182a632FB25b7C1966AED7</a></td></tr><tr><td>Queue</td><td><a href="https://polygonscan.com/address/0xeAB324e9450d1EfFa087ccE8eff6C1FB476d60Ff">0xeAB324e9450d1EfFa087ccE8eff6C1FB476d60Ff</a></td></tr></tbody></table>


# USP

## Ethereum

### USP

<table data-full-width="false"><thead><tr><th width="189">Description</th><th>Address</th></tr></thead><tbody><tr><td>Contract</td><td><a href="https://etherscan.io/address/0x97cCC1C046d067ab945d3CF3CC6920D3b1E54c88">0x97cCC1C046d067ab945d3CF3CC6920D3b1E54c88</a></td></tr><tr><td>Staking (sUSP)</td><td><a href="https://etherscan.io/address/0x271C616157e69A43B4977412A64183Cf110Edf16">0x271C616157e69A43B4977412A64183Cf110Edf16</a></td></tr></tbody></table>


# Governance

## Ethereum

<table data-full-width="false"><thead><tr><th width="195">Description</th><th>Address</th></tr></thead><tbody><tr><td>Timelock</td><td><a href="https://etherscan.io/address/0xDa86e15d0Cda3A05Db930b248d7a2f775e575A44">0xDa86e15d0Cda3A05Db930b248d7a2f775e575A44</a></td></tr><tr><td>Treasury multisig</td><td><a href="https://etherscan.io/address/0xFb3bD022D5DAcF95eE28a6B07825D4Ff9C5b3814">0xFb3bD022D5DAcF95eE28a6B07825D4Ff9C5b3814</a></td></tr><tr><td>Developers multisig</td><td><a href="https://etherscan.io/address/0xe8eA8bAE250028a8709A3841E0Ae1a44820d677b">0xe8eA8bAE250028a8709A3841E0Ae1a44820d677b</a></td></tr><tr><td>Pauser multisig</td><td><a href="https://etherscan.io/address/0xBaeCba470C229984b75BC860EFe8e97AE082Bb9f">0xBaeCba470C229984b75BC860EFe8e97AE082Bb9f</a></td></tr></tbody></table>

## Optimism

<table data-full-width="false"><thead><tr><th width="195">Description</th><th>Address</th></tr></thead><tbody><tr><td>Timelock</td><td><a href="https://optimistic.etherscan.io/address/0xa3a3741c48298e21eebe5a59beaf6f89dc0e0c4c">0xa3a3741c48298e21EEbE5A59bEAF6f89DC0E0c4c</a></td></tr><tr><td>Treasury multisig</td><td><a href="https://optimistic.etherscan.io/address/0xFDbB4d606C199F091143BD604C85c191a526fbd0">0xFDbB4d606C199F091143BD604C85c191a526fbd0</a></td></tr></tbody></table>

## Arbitrum

<table data-full-width="false"><thead><tr><th width="195">Description</th><th>Address</th></tr></thead><tbody><tr><td>Timelock</td><td><a href="https://arbiscan.io/address/0xB988641E8D493B5BfF65e63819975b6B33477057">0xB988641E8D493B5BfF65e63819975b6B33477057</a></td></tr><tr><td>Treasury multisig</td><td><a href="https://arbiscan.io/address/0xF40d482D7fc94C30b256Dc7E722033bae68EcF90">0xF40d482D7fc94C30b256Dc7E722033bae68EcF90</a></td></tr></tbody></table>

## Polygon

<table data-full-width="false"><thead><tr><th width="195">Description</th><th>Address</th></tr></thead><tbody><tr><td>Timelock</td><td><a href="https://polygonscan.com/address/0x45f4fb4D0CCC439bB7B85Ba63064958ab7e31EE4">0x45f4fb4D0CCC439bB7B85Ba63064958ab7e31EE4</a></td></tr><tr><td>Treasury multisig</td><td><a href="https://polygonscan.com/address/0x61A944Ca131Ab78B23c8449e0A2eF935981D5cF6">0x61A944Ca131Ab78B23c8449e0A2eF935981D5cF6</a></td></tr></tbody></table>


# Integrators

###


# Web3

This guide describes how to integrate Credit Vaults into Web3 applications using both the Pareto REST API and smart contracts. It is intended for technical audiences familiar with Web3 and frontend frameworks.

## Smart contract instantiation

To interact with on-chain vaults, tokens, and queue contracts, a Web3 contract instance must be created using the ABI and contract address:

```ts
const contract = new web3.eth.Contract(abi, address);
```

This pattern is required for calling methods such as `depositAA`, `requestWithdraw`, `approve`. Refer to the [Web3.js documentation](https://web3js.readthedocs.io/en/v1.10.0/web3-eth-contract.html) for full syntax details.

## API access

All API routes below belong to the public Pareto API at `https://api.pareto.credit`. Refer to the [API chapter](/developers/api) for a complete overview.

### 1. Required vault data

These steps outline the minimum data required to render a vault and enable interactions.

{% stepper %}
{% step %}

#### Load [Vault Entity](https://docs.pareto.credit/developers/api/vaults)

Use either:

* `GET /v1/vaults/{_id}` — by ID
* `GET /v1/vaults?address=0x...` — by address

Only vaults with `visibility: PUBLIC` should be displayed to users.
{% endstep %}

{% step %}

#### Retrieve Signatures

Each vault contains a `signatures` array of the form:

```ts
interface VaultSignature {
  _id: string;
  entity: "ALL" | "LENDER" | "MANAGER";
}
```

Filter all entries where `entity === 'LENDER'`and use the `_id` values to load them. This returns the full signature definitions required to enable future user interactions.

```ts
GET /v1/signatures?_id=signatureId1,signatureId2
```

{% endstep %}

{% step %}

#### Retrieve underlying [Token](https://docs.pareto.credit/developers/api/tokens)

Retrieve token information with:

`GET /v1/tokens/{vault.tokenId}`
{% endstep %}

{% step %}

#### Fetch latest [Vault Block](https://docs.pareto.credit/developers/api/vault-blocks)

Fetch up-to-date vault metrics. This includes share price, APRs, TVL, and queue configuration.

`GET /v1/vault-latest-block?vaultId={vault._id}`
{% endstep %}
{% endstepper %}

### 2. Required wallet access data

Defines the required checks and data fetches needed immediately after wallet connection to verify access and authorization for vault operations.

{% stepper %}
{% step %}

#### Check wallet access

To verify if a wallet is allowed to interact with the vault, instantiate the contract using the `cdoEpoch` ABI and address retrieved from the vault JSON:

```ts
const cdoEpochContract = new web3.eth.Contract(
  vault.cdoEpoch.abi,
  vault.cdoEpoch.address
);
const isAllowed = await cdoEpochContract.methods
  .isWalletAllowed(walletAddress)
  .call();
```

If `isAllowed` is false, initiate a KYC flow using [Keyring Connect SDK](https://www.npmjs.com/package/@keyringnetwork/keyring-connect-sdk). Only after KYC is completed, it's possible to proceed with next steps.
{% endstep %}

{% step %}

#### Signature Validation

Check if the required signatures have been signed:

`GET /v1/signatures/{signatureId}/check?walletAddress=0x...123`

otherwise

```ts
const hash = await web3.eth.personal.sign(
  atob(walletMessage),
  walletAddress,
  ""
);
```

Submit the signed hash:

`POST /v1/signatures/{signatureId}/sign`
{% endstep %}

{% step %}

#### Retrieve Wallet Position

Retrieve the wallet position to track users' deposits, claims, and balances.

```ts
GET /v1/vaults/{vaultId}/position?walletAddress={walletAddress}
```

{% endstep %}
{% endstepper %}

### 3. Deposit flow

Outlines the required contract state and transactions to successfully execute a deposit into a vault.

{% stepper %}
{% step %}

#### Verify allowance and balance

Instantiate the token contract using the vault token ABI and address:

```ts
const tokenContract = new web3.eth.Contract(token.abi, token.address);
const allowance = await tokenContract.methods
  .allowance(walletAddress, spenderAddress)
  .call({ from: walletAddress });
const balance = await tokenContract.methods
  .balanceOf(walletAddress)
  .call({ from: walletAddress });
```

Spender can be found in:

* `vault.cdoEpoch.address` if `NETTING`
* `vault.depositQueue.address` if `RUNNING`
  {% endstep %}

{% step %}

#### Approve token spending

Make sure the amount respects the token's decimals (6 for USDC, USDT, 18 for the majority of ERC-20 tokens).

```ts
await tokenContract.methods
  .approve(spenderAddress, amount)
  .send({ from: walletAddress });
```

{% endstep %}

{% step %}

#### Submit Deposit Transaction

```ts
// during NETTING period
await cdoEpochContract.methods.depositAA(amount).send({ from: walletAddress });
// during cycle RUNNING
await depositQueueContract.methods
  .requestDeposit(amount)
  .send({ from: walletAddress });
```

{% endstep %}
{% endstepper %}

### 4. Withdraw flow

Describes how to prepare, calculate, and submit a withdrawal request from a vault, depending on its current status and configuration.

{% stepper %}
{% step %}

#### Fetch user balance and max withdrawable amount

```ts
const vaultTokenContract = new web3.eth.Contract(
  vaultToken.abi,
  vaultToken.address
);
const balance = await vaultTokenContract.methods
  .balanceOf(walletAddress)
  .call({ from: walletAddress });
const maxWithdrawable = await cdoEpochContract.methods
  .maxWithdrawable(walletAddress, vault.address)
  .call({ from: walletAddress });
```

{% endstep %}

{% step %}

#### Check allowance

The allowance must be verified only when the vault is in RUNNING state and uses the withdrawQueue. In this case, the `withdrawQueue` contract address should be used as `spender`.

```ts
const spender = vault.cdoEpoch.withdrawQueue.address;
const allowance = await tokenContract.methods
  .allowance(walletAddress, spender)
  .call({ from: walletAddress });
```

{% endstep %}

{% step %}

#### Compute the LP tokens required

```ts
const percentage = 1000000 / maxWithdrawable;
const lpAmount = LPDeposited * percentage;
```

{% endstep %}

{% step %}

#### Submit withdrawal request

Track requests in the `block.requests` array

```ts
// during NETTING period
await vaultContract.methods
  .requestWithdraw(lpAmount, vault.address)
  .send({ from: walletAddress });
// during cycle RUNNING
await withdrawQueueContract.methods
  .requestWithdraw(lpAmount)
  .send({ from: walletAddress });
```

{% endstep %}
{% endstepper %}

## Managing requests

There are 3 types of request:&#x20;

* `DEPOSIT`: available during the  `RUNNING` state of the vault cycle
* `WITHDRAW`: available during the `RUNNING` state of the vault cycle. This request can be "standard" or "instant" depending on the next cycle APR.
* `REDEEM`: available during the `WAITING` state of the vault cycle. This request can be "standard" or "instant" depending on the next cycle APR.

All requests must be claimed by users after they have been processed:&#x20;

* `DEPOSIT`: this request can be claimed starting from the next `WAITING` period
* `WITHDRAW`:&#x20;
  * if **standard**: the request can be claimed at the end of the next cycle, during the `WAITING` period
  * if **instant**: the request can be claimed during the `RUNNING` period of the next cycle, after the instant withdrawal delay (usually few days).
* `REDEEM`:
  * if **standard**: the request can be claimed at the end of the next cycle, during the `WAITING` period
  * if **instant**: the request can be claimed during the `RUNNING` period of the next cycle, after the instant withdrawal delay (usually few days).

\
All  vault requests are tracked in the `requests` array of the `vaultBlock` object. Each entry in this array represents a user-initiated interaction awaiting processing.

{% code title="Request schema" %}

```ts
interface VaultBlockRequest {
  type: "DEPOSIT" | "WITHDRAW" | "REDEEM";
  amount: iBigInt;
  block: Block;
  isInstant?: boolean;
  requestedOn: string;
  walletId: string;
  walletAddress: string;
  status:
    | "PENDING"
    | "PROCESSED"
    | "CLAIMABLE"
    | "INSTANT_CLAIMABLE"
    | "CLAIMED";
  epochNumber?: number;
}
```

{% endcode %}

where

* `type`: Indicates if it's a `DEPOSIT`, `WITHDRAW`, or `REDEEM`.
* `status`: Tracks the lifecycle of the request (e.g., `PENDING`, `CLAIMABLE`, etc.).
* `isInstant`: Only present for withdrawals that qualify as "instant".
* `block`: Indicates the vault block in which the request was recorded.
* `epochNumber` : the epochNumber that must be passed to the requests methods

Requests are retrieved from the latest vault block:

```ts
GET /v1/vault-latest-block?vaultId={vaultId}
```

### Deposit requests

Handled via the queue contract `vault.cdoEpoch.depositQueue`

* It's possible to claim the request if `status === 'CLAIMED'`

```ts
await depositQueueContract.methods
  .claimDepositRequest(request.epochNumber)
  .send({ from: walletAddress });
```

* It's possible to cancel the request if `status === 'PENDING'`

```ts
await depositQueueContract.methods
  .deleteRequest(request.epochNumber)
  .send({ from: walletAddress });
```

### Withdraw requests

Handled via the queue contract `vault.cdoEpoch.withdrawQueue`

* For both standard and instant requests, it's possible to claim the request if  `status === 'CLAIMED'`

```ts
await withdrawQueueContract.methods
  .claimWithdrawRequest(request.epochNumber)
  .send({ from: walletAddress });
```

* It's possible to cancel the request if `status === 'PENDING'`

```ts
await withdrawQueueContract.methods
  .deleteWithdrawRequest(request.epochNumber)
  .send({ from: walletAddress });
```

### Redeem requests

Handled via the main vault contract `vault.cdoEpoch`

* It's possible to claim the request if `status === 'CLAIMED'`:

```ts
await cdoEpochContract.methods
  .claimWithdrawRequest()
  .send({ from: walletAddress });
```

* If `request.isInstant === true`  it's possible to use:

```ts
await cdoEpochContract.methods
  .claimInstantWithdrawRequest()
  .send({ from: walletAddress });
```

### Lifecycle summary&#x20;

| Request type        | When    | Claimable From                                         |
| ------------------- | ------- | ------------------------------------------------------ |
| DEPOSIT             | RUNNING | Next WAITING period                                    |
| WITHDRAW (standard) | RUNNING | End of next cycle (WAITING)                            |
| WITHDRAW (instant)  | RUNNING | RUNNING of next cycle (after instant withdrawal delay) |
| REDEEM (standard)   | WAITING | End of next cycle (WAITING)                            |
| REDEEM (instant)    | WAITING | RUNNING of next cycle (after instant withdrawal delay) |


# Smart contract

## Credit Vaults Integrator Guide

### Overview

Credit Vaults are epoch-based lending vaults built on top of `IdleCDOEpochVariant` (the vault) and `IdleCreditVault` (the strategy). Lenders deposit into AA or BB tranches and receive tranche ERC20 tokens. At the start of each epoch, funds are lent directly to a single borrower. At the end of the epoch, the borrower repays interest and funds needed to satisfy pending withdrawals. Tranche prices are updated at epoch stop, and lenders can request withdrawals only between epochs (except for the optional mid-epoch deposit flow).

Key properties:

* Epochs gate deposits and withdrawals. During an epoch, the vault is paused and normal deposits/withdraw requests are blocked.
* Withdrawals are two-step: request between epochs, claim after at least one full epoch has passed.
* If the APR drops enough between epochs and instant withdrawals are enabled, a request becomes an instant withdraw.
* The strategy token (`IdleCreditVault`) has a fixed price of 1 underlying unit and is used as a receipt token for withdrawal requests (because tranche tokens are burned on request).
* KYC gating is enforced via Keyring (`isWalletAllowed`).

Roles (for context only):

* Lenders/integrators: deposit into tranches and manage withdrawals.
* Borrower: receives funds at epoch start, repays at epoch end, may fulfill write-off escrow requests.
* Manager/owner: starts/stops epochs and configures parameters (not covered here).

### Epoch lifecycle (high level)

1. **Buffer period (between epochs)**
   * `isEpochRunning == false`
   * Deposits and withdrawal requests are allowed.
2. **Epoch start**
   * Manager calls `startEpoch()` (not covered here).
   * `isEpochRunning == true`, deposits/withdraw requests paused.
   * Underlyings are sent to the borrower; instant-withdraw funding is handled.
3. **Epoch running**
   * Optional `depositDuringEpoch()` may be enabled.
   * Optional Write-off escrow is available for lenders and borrower to request a withdraw (borrower needs to accept the request).
4. **Epoch stop**
   * Manager calls `stopEpoch()` (not covered here).
   * Interest and pending withdrawal funds are collected.
   * Tranche prices update; new APR set.
   * `isEpochRunning == false` and buffer period starts again.

### Contracts and data model

* **IdleCDOEpochVariant**: main vault contract. Inherits `IdleCDO` and adds epoch logic plus request/claim flows.
* **IdleCreditVault**: strategy/receipt-token contract. Holds pending withdrawal funds and mints receipt tokens for requests.
* **IdleCDOTranche (AA/BB tokens)**: ERC20 tranche tokens with 18 decimals (`ONE_TRANCHE_TOKEN = 1e18`) used as receipt for deposits.
* **IdleCreditVaultWriteOffEscrow**: escrow for in-epoch write-off exits; borrower can buy out lender positions and optionally write off debt.

### Integrator flows

#### 1) Deposit between epochs (standard)

Use this flow when `isEpochRunning == false` (vault not paused).

1. Confirm `IdleCDOEpochVariant.isWalletAllowed(user)` is `true`.
2. `approve` the vault (`IdleCDOEpochVariant`) to spend the underlying token.
3. Call `depositAA(amount)` or `depositBB(amount)`.
4. Receive AA or BB tranche tokens (ERC20, 18 decimals).

Notes:

* Deposits are blocked while the epoch is running because the vault is paused.
* Tranche token price for valuation should be read via `virtualPrice(tranche)`.
* Deposits always require `isWalletAllowed(user) == true` (no bypass).

#### 2) Deposit during an epoch (optional)

Use only if mid-epoch deposits are enabled.

1. Ensure `isEpochRunning == true`, `block.timestamp < epochEndDate`, and `isDepositDuringEpochDisabled == false`.
2. Ensure AYS is not active (`isAYSActive == false`).
3. Approve underlying to the vault.
4. Call `depositDuringEpoch(amount, tranche)`.

Notes:

* The first deposit into a tranche cannot be mid-epoch (tranche supply must be > 0).
* The minted amount is prorated based on remaining epoch time plus the buffer period.
* Funds are immediately transferred to the borrower; strategy tokens are minted to the vault.

#### 3) Normal withdraw (request + claim)

Use this flow between epochs (`isEpochRunning == false`).

1. Call `requestWithdraw(trancheAmount, tranche)`.
   * If `trancheAmount == 0`, the vault treats it as "withdraw all."
   * The function burns tranche tokens and mints receipt tokens in `IdleCreditVault` for the user.
   * The return value is the **underlyings requested**, including next-epoch net interest (no buffer-period interest).
2. Wait at least one epoch. Claim is allowed when:
   * `IdleCreditVault.epochNumber > IdleCreditVault.lastWithdrawRequest(user)`
   * or the vault is closed (`epochEndDate == 0`).
3. Call `claimWithdrawRequest()`.
   * This burns receipt tokens and transfers underlyings from `IdleCreditVault`.

Notes:

* Requests require `isWalletAllowed(user) == true` unless `keyringAllowWithdraw == true`.

#### 4) Instant withdraw (APR drop)

Instant withdrawals are triggered automatically by `requestWithdraw` when:

* `disableInstantWithdraw == false`, and
* `lastEpochApr > IdleCreditVault.unscaledApr() + instantWithdrawAprDelta`.

Flow:

1. Call `requestWithdraw(trancheAmount, tranche)` between epochs.
2. If conditions are met, the request becomes instant:
   * Tranche tokens are burned.
   * Receipt tokens are minted in `IdleCreditVault`.
   * The requested amount equals current underlyings (no next-epoch interest).
3. Claim when `allowInstantWithdraw == true`:
   * This may be true immediately after epoch start if new deposits cover the requests.
   * Otherwise it becomes true after `instantWithdrawDeadline` and manager calls `getInstantWithdrawFunds()`.
4. Call `claimInstantWithdrawRequest()`.

#### 5) Write-off escrow flow (during epoch)

Used to let lenders exit during an epoch by selling tranche tokens to the borrower. This flow is only available if a `IdleCreditVaultWriteOffEscrow` is deployed for the specific credit vault, and the exit is only completed once the borrower accepts it by fulfilling the request.

Lender flow:

1. Ensure `IdleCDOEpochVariant.isEpochRunning() == true` and wallet is allowed.
2. `approve` the escrow to transfer tranche tokens.
3. Call `createWriteOffRequest(trancheAmount, underlyingsRequested)`.
   * Requests accumulate per user; amounts are not auto-priced.
4. Optional: call `deleteWriteOffRequest()` to cancel and reclaim tranche tokens.

Borrower flow:

1. Call `fullfillWriteOffRequest(user, trancheAmount, underlyingsRequested)`.
   * Borrower transfers underlyings to escrow.
   * Exit fee (if set) is taken, remainder is sent to the lender.
   * Tranche tokens are transferred to the borrower.
2. Borrower may then call `writeOffDeposit()` on `IdleCDOEpochVariant` to burn tranche + strategy tokens and reduce expected interest (borrower-only).

#### 6) Default considerations

If the borrower defaults, the vault sets `defaulted == true`, pauses deposits/withdraw requests, and enables transfers of receipt tokens via `IdleCreditVault.allowTransfers()`. Integrators should monitor the `BorrowerDefault` event and treat receipt tokens as claims on whatever recovery process is used.

### Integrator-facing methods (by contract)

#### IdleCDOEpochVariant (vault)

User/integrator calls:

* `depositAA(uint256 amount) returns (uint256 minted)` - Deposit underlying into AA; mints AA tranche tokens (not strategy tokens). `amount` is underlying.
* `depositBB(uint256 amount) returns (uint256 minted)` - Deposit underlying into BB; mints BB tranche tokens (not strategy tokens). `amount` is underlying.
* `depositDuringEpoch(uint256 amount, address tranche) returns (uint256 minted)` - Mid-epoch deposit; `tranche` is `AATranche` or `BBTranche`.
* `requestWithdraw(uint256 trancheAmount, address tranche) returns (uint256 underlyingsRequested)` - Create a withdrawal request; `trancheAmount` is tranche tokens, `tranche` is AA/BB.
* `claimWithdrawRequest()` - Claim a normal withdraw request once eligible (>= 1 epoch after last request).
* `claimInstantWithdrawRequest()` - Claim an instant withdraw request when `allowInstantWithdraw` is true.

Views (from `IdleCDO` / `IdleCDOEpochVariant`):

* `virtualPrice(address tranche) view returns (uint256)` - Tranche price, in underlyings, including accrued interest.
* `getApr(address tranche) view returns (uint256)` - Current APR for the tranche.
* `getContractValue() view returns (uint256)` - Vault NAV in underlying terms.
* `maxWithdrawable(address user, address tranche) view returns (uint256)` - Max underlyings for a normal request.
* `isWalletAllowed(address user) view returns (bool)` - Keyring/KYC allowlist check.

Key public state to read:

* `AATranche`, `BBTranche`, `token`, `strategy`
* `isEpochRunning`, `epochEndDate`, `epochDuration`, `bufferPeriod`
* `instantWithdrawDelay`, `instantWithdrawDeadline`, `instantWithdrawAprDelta`
* `allowInstantWithdraw`, `disableInstantWithdraw`
* `allowAAWithdrawRequest`, `allowBBWithdrawRequest`
* `keyringAllowWithdraw`, `defaulted`, `lastEpochApr`, `lastEpochInterest`, `expectedEpochInterest`
* `fee`, `feeReceiver`, `trancheAPRSplitRatio`, `isAYSActive`, `isDepositDuringEpochDisabled`

Not supported (no-op in Credit Vaults):

* `withdrawAA`, `withdrawBB`, `depositAARef`, `depositBBRef`

#### IdleCreditVault (strategy / receipt token)

Read-only for integrators (calls are restricted to `IdleCDOEpochVariant` for state-changing methods).

User-visible reads:

* Receipt token ERC20: `balanceOf(user)`, `totalSupply()`, `decimals()` - Receipt tokens for pending requests.
* Request tracking: `withdrawsRequests(user)`, `instantWithdrawsRequests(user)`, `lastWithdrawRequest(user)` - Per-user request state.
* Totals: `pendingWithdraws`, `pendingInstantWithdraws`, `totEpochDeposits` - Aggregate counters.
* Epoch tracking: `epochNumber` - Strategy epoch counter for claim eligibility.
* APR data: `getApr()` (scaled), `unscaledApr()` - APR used for epoch interest math.
* Metadata: `token`, `tokenDecimals`, `borrower`, `manager`, `price()` (always `oneToken`) - Vault metadata.
* Transferability: `canTransfer` (false unless defaulted) - Receipt token transfer flag.

#### IdleCreditVaultWriteOffEscrow

User/borrower calls:

* `createWriteOffRequest(uint256 trancheAmount, uint256 underlyingsRequested)` - Lender proposes exit terms (requires escrow deployed).
* `deleteWriteOffRequest()` - Lender cancels and retrieves tranche tokens.
* `fullfillWriteOffRequest(address user, uint256 trancheAmount, uint256 underlyingsRequested)` - Borrower accepts and settles the request (borrower-only).

Views:

* `userRequests(user) -> (tranches, underlyings)`
* `idleCDOEpoch`, `strategy`, `underlying`, `tranche`, `borrower`
* `exitFee`, `feeReceiver`

### Monitoring positions and claimability

#### Active tranche position

* Tranche balance: `IERC20(AATranche|BBTranche).balanceOf(user)`
* Valuation: `balance * virtualPrice(tranche) / 1e18`
* `virtualPrice` includes accrued interest since last accounting update.

#### Pending withdrawal position

* Normal: `IdleCreditVault.withdrawsRequests(user)`
* Instant: `IdleCreditVault.instantWithdrawsRequests(user)`
* Receipt balance: `IdleCreditVault.balanceOf(user)`
  * In steady state, this equals normal + instant requests.

#### Escrowed position

* `IdleCreditVaultWriteOffEscrow.userRequests(user)`
  * `tranches` and `underlyings` requested are both tracked.

#### Claim eligibility

* Normal withdraw claim:
  * `IdleCreditVault.epochNumber > IdleCreditVault.lastWithdrawRequest(user)`
  * or `IdleCDOEpochVariant.epochEndDate == 0` (vault closed)
* Instant withdraw claim:
  * `IdleCDOEpochVariant.allowInstantWithdraw == true`

#### Timing checks

* Epoch status: `isEpochRunning`, `epochEndDate`
* Instant deadline: `instantWithdrawDeadline`

### Practical integration tips

* Tranche tokens are 18 decimals; underlying decimals vary. Convert carefully.
* `requestWithdraw(0, tranche)` withdraws the full tranche balance.
* `maxWithdrawable(user, tranche)` is useful for estimating a normal request amount (net of fees).
* Mid-epoch deposits are disallowed when `isDepositDuringEpochDisabled == true` or `isAYSActive == true`.
* Receipt tokens are non-transferable until `IdleCreditVault.canTransfer == true` (typically on default).


# API

Pareto APIs provide access to campaign data, vault analytics, token information, and third-party integrated services.

{% code title="Base URL" %}

```
https://api.pareto.credit/
```

{% endcode %}

This is the active **major version v1** of the API. All endpoints listed are part of the `v1` namespace.

## Quick start

1. **Request an API key** via [this form](https://tally.so/r/mY9y6B). Once approved, you will receive a key for authentication
2. Use your preferred HTTP client (e.g., Postman, Axios, cURL)
3. Add your API key as a **Bearer Token** in the `Authorization` header
4. Start by fetching vaults or campaign data:

<pre class="language-bash"><code class="lang-bash"><strong>curl -H "Authorization: Bearer YOUR_API_KEY" https://api.pareto.credit/v1/vaults
</strong></code></pre>

## Endpoints

#### [Campaigns](/developers/api/campaigns)

A campaign is a points-based engagement program that allows users to earn rewards by interacting with Pareto.

* `GET /v1/campaigns` — List all campaigns
* `GET /v1/campaigns/:campaignId` — Get campaign by ID
* `GET /v1/campaigns/:campaignId/points` — Get campaign points

#### [Chains](/developers/api/chains)

* `GET /v1/chains` — List supported chains
* `GET /v1/chains/:chainId` — Get chain by ID

#### [Operators](/developers/api/operators)

An entity managing or integrating with Pareto products.

* `GET /v1/operators` — List all operators
* `GET /v1/operators/:operatorId` — Get operator by ID

#### [Token blocks](/developers/api/token-blocks)

* `GET /v1/token-blocks` — List all token blocks
* `GET /v1/token-blocks/:tokenBlockId` — Get token block by ID

#### [Tokens](/developers/api/tokens)

* `GET /v1/tokens` — List all tokens
* `GET /v1/tokens/:tokenId` — Get token by ID

#### [Transactions](/developers/api/transactions)

* `GET /v1/transactions` — List all protocol transactions

#### [Vaults](/developers/api/vaults)

A yield-generating smart contract product.

* `GET /v1/vaults` — List all vaults
* `GET /v1/vaults/:vaultId` — Get vault by ID
* `GET /v1/vaults/performances` — Vault performance overview
* `GET /v1/vaults/:vaultId/integrations` — Integrations by vault ID

#### [Vault blocks](/developers/api/vault-blocks)

* `GET /v1/vault-blocks` — List all vault blocks
* `GET /v1/vault-blocks/:vaultBlockId` — Get vault block by ID
* `GET /v1/vault-latest-blocks` — Latest block data for vaults

#### [Vault categories](/developers/api/vault-categories)

* `GET /v1/vault-categories` — List all vault categories
* `GET /v1/vault-categories/:typeId` — Get category by ID

#### [Vault epochs](/developers/api/vault-epochs)

A predefined period for vault accounting.

* `GET /v1/vault-epochs` — List all vault epochs

#### [Vault performances](/developers/api/vault-performances)

* `GET /v1/vault-performances` — List all performance metrics
* `GET /v1/vault-performances/:vaultPerformanceId` — Get performance by ID

#### [Vault types](/developers/api/vault-types)

* `GET /v1/vault-types` — List all vault types
* `GET /v1/vault-types/:typeId` — Get vault type by ID

## Listing

All listing endpoints across the API (e.g., `/vaults`, `/transactions`, `/tokens`, etc.) follow a consistent response format in consuming paginated data throughout the API:

* `data`: an array of returned resources.
* `totalCount`: the total number of resources matching the query, useful for pagination.

```
{
  "data": [ /* items */ ],
  "totalCount": 123
}
```

## **Pagination, sorting, fields**

To control the number of items returned per request, you can use:

* `limit` — Number of items to return (default: 50, max: 200)
* `offset` — Number of items to skip before starting to collect the result set

```
GET /v1/vaults?limit=10&offset=20
```

The `sort` query parameter allows you to sort results by one or more fields:

* Use `field` for ascending order
* Use `-field` for descending order

```
GET /v1/vaults?sort=-createdAt
```

Some endpoints support the `fields` parameter, which lets you request only specific fields per object:

This can be useful for optimizing network performance and response size.

```
GET /v1/vaults?fields=_id,name,createdAt
```


# Campaigns

Campaigns are point-based programs used to incentivize user activities on Pareto. Users can earn points by interacting with vaults or participating in social activities.

## Structure

Each campaign object includes:

* `_id` *(string)* — Unique identifier
* `code` *(string)* — Campaign code
* `name` *(object)* — Multilingual name, e.g. `{ en: "My Campaign" }`
* `description` *(object)* — Multilingual description
* `rules` *(array)* — Conditions for earning points:
  * `name`, `description` *(object)* — i18n fields
  * `trigger` *(string)* — `DEPOSIT` or `DEPOSIT_REQUEST`
  * `deposit` *(object)* —
    * `type`: `BALANCE` or `AGE`
    * `value`: number
  * `reward` *(object)* —
    * `type`: `AMOUNT` or `MULTIPLIER`
    * `value`: number
  * `frequency` *(object)* — repetition rules (`value`, `unit`)
* `referrals` *(array)* — Invite codes with activation flag
* `startDate` / `endDate` *(string)* — ISO datetime
* `link` *(string)* — URL
* `galxeId` *(number)* — External reference
* `createdAt`, `updatedAt` *(string)* — ISO timestamp
* `createdBy`, `updatedBy` *(string)* — Actor IDs

## Endpoints

{% openapi src="/files/20rffZWSGgtduRDhjOsC" path="/campaigns" method="get" %}
[Campaigns.yaml](https://4223418165-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVSPclqPyChB4NMxFfG2X%2Fuploads%2F4omDdrMriuCBYpOfBwTM%2FCampaigns.yaml?alt=media\&token=22cb65cd-d3ea-4aeb-9e98-879cafedddaa)
{% endopenapi %}

{% openapi src="/files/20rffZWSGgtduRDhjOsC" path="/campaigns/{campaignId}" method="get" %}
[Campaigns.yaml](https://4223418165-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVSPclqPyChB4NMxFfG2X%2Fuploads%2F4omDdrMriuCBYpOfBwTM%2FCampaigns.yaml?alt=media\&token=22cb65cd-d3ea-4aeb-9e98-879cafedddaa)
{% endopenapi %}


# Chains

Chains represent the supported blockchain networks that Pareto interacts with. These include the networks where vaults are deployed, where user interactions occur, and where transactions are tracked.

## Structure

Each chain object includes:

* `_id` *(string)* — Unique identifier for the chain
* `name` *(string)* — Human-readable name of the blockchain (e.g., "Ethereum")
* `chainId` *(string)* — Network ID used internally by Pareto
* `nativeToken` *(string)* — Symbol of the native currency (e.g., ETH, MATIC)
* `explorerUrl` *(string)* — Block explorer base URL for linking transactions or accounts
* `icon` *(string)* — Optional icon URL
* `createdAt`, `updatedAt` *(string)* — ISO timestamps (UTC Unix time)

## Endpoints

{% openapi src="/files/3H2b6H7Qr1KwXijGLVS2" path="/chains" method="get" %}
[Chains.yaml](https://4223418165-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVSPclqPyChB4NMxFfG2X%2Fuploads%2FkHtIyzB2eqrRqVH7ToMB%2FChains.yaml?alt=media\&token=37a59c51-c7c9-4cea-950d-1417df6f8c9a)
{% endopenapi %}

{% openapi src="/files/3H2b6H7Qr1KwXijGLVS2" path="/chains/{chainId}" method="get" %}
[Chains.yaml](https://4223418165-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVSPclqPyChB4NMxFfG2X%2Fuploads%2FkHtIyzB2eqrRqVH7ToMB%2FChains.yaml?alt=media\&token=37a59c51-c7c9-4cea-950d-1417df6f8c9a)
{% endopenapi %}


# Operators

Operators represent key entities that interact with the Pareto protocol. These can be protocol partners, borrowers, or curators responsible for deploying or managing vaults.

## Structure

Each operator object includes:

* `_id` *(string)* — Unique identifier
* `name` *(string)* — Name of the operator
* `code` *(string)* — Unique internal code
* `type` *(string)* — One of: `PROTOCOL`, `BORROWER`, `CURATOR`
* `description` *(object)* — Multilingual description (e.g. `{ en: "This is a protocol operator" }`)
* `shortDescription` *(object)* — Short version of the description
* `caption` *(object)* — Promotional caption
* `rating` *(string)* — Internal rating indicator
* `location` *(string)* — Geographic reference
* `links` *(object)* —
  * `website` *(string)*
  * `twitter` *(string)*
  * `linkedIn` *(string)*
  * `crunchbase` *(string)*
* `createdAt`, `updatedAt` *(string)* — ISO timestamps (UTC Unix time)
* `createdBy`, `updatedBy` *(string)* — Actor IDs for auditing

## Endpoints

{% openapi src="/files/hfzx6WENjgP6s77lEtdb" path="/operators" method="get" %}
[Operators.yaml](https://4223418165-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVSPclqPyChB4NMxFfG2X%2Fuploads%2FXPOBPjMcYUlujnm1hzgO%2FOperators.yaml?alt=media\&token=f34efcec-7881-4fb8-b515-784f235aa72f)
{% endopenapi %}

{% openapi src="/files/hfzx6WENjgP6s77lEtdb" path="/operators/{operatorId}" method="get" %}
[Operators.yaml](https://4223418165-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVSPclqPyChB4NMxFfG2X%2Fuploads%2FXPOBPjMcYUlujnm1hzgO%2FOperators.yaml?alt=media\&token=f34efcec-7881-4fb8-b515-784f235aa72f)
{% endopenapi %}


# Token blocks

Token blocks are periodic snapshots of token-related data captured at specific blockchain blocks. These are used in vault logic and on-chain analytics.

## Structure

Each token block object includes:

* `_id` *(string)* — Unique identifier
* `tokenId` *(string)* — ID of the associated token
* `tokenAddress` *(string)* — Ethereum address of the token (0x... format)
* `price` *(string)* — Price of the token at this block
* `block` *(object)* —
  * `number` *(number)* — Block number
  * `timestamp` *(number)* — Unix timestamp (UTC)
* `createdAt`, `updatedAt` *(string)* — ISO timestamps
* `createdBy`, `updatedBy` *(string)* — Actor IDs

{% openapi src="/files/wGQvB3cy57sPT85EmiTU" path="/token-blocks" method="get" %}
[TokenBlocks.yaml](https://4223418165-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVSPclqPyChB4NMxFfG2X%2Fuploads%2FkzbkpCvUQifQK8BMU1n4%2FTokenBlocks.yaml?alt=media\&token=dbc0764d-a59a-4457-a14a-bb05f5d5b3fb)
{% endopenapi %}

{% openapi src="/files/wGQvB3cy57sPT85EmiTU" path="/token-blocks/{tokenBlockId}" method="get" %}
[TokenBlocks.yaml](https://4223418165-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVSPclqPyChB4NMxFfG2X%2Fuploads%2FkzbkpCvUQifQK8BMU1n4%2FTokenBlocks.yaml?alt=media\&token=dbc0764d-a59a-4457-a14a-bb05f5d5b3fb)
{% endopenapi %}


# Tokens

Tokens are ERC-20 compatible assets used in vaults and tracked by the Pareto protocol across multiple chains.

## Structure

Each token object includes:

* `_id` *(string)* — Unique identifier
* `name` *(string)* — Name of the token
* `symbol` *(string)* — Token symbol (e.g. USDC, WETH)
* `chainId` *(string)* — Chain this token belongs to
* `address` *(string)* — On-chain contract address (0x...)
* `decimals` *(number)* — Token decimal precision
* `color` *(string)* — UI color reference for this token
* `oracle` *(object)* — Price oracle metadata:
  * `address` *(string)* — Oracle contract address
  * `abi` *(array)* — Oracle ABI definition
  * `protocol` *(string)* — Data source (e.g., Idle, AaveV2, Morpho, Clearpool)
  * `fee` *(number, optional)* — Optional oracle fee
  * Additional optional config fields (e.g. `fromBlock`, `USDCAddress`, ...)
* `createdAt`, `updatedAt` *(string)* — ISO timestamps
* `createdBy`, `updatedBy` *(string)* — System actor IDs

## Endpoints

{% openapi src="/files/wYckWbLK8GpnaRCIbupX" path="/tokens" method="get" %}
[Tokens.yaml](https://4223418165-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVSPclqPyChB4NMxFfG2X%2Fuploads%2FMRT60r5LlV5Qc5ADOO9j%2FTokens.yaml?alt=media\&token=7e55e202-cd98-4fd6-ae42-23c31451189d)
{% endopenapi %}

{% openapi src="/files/wYckWbLK8GpnaRCIbupX" path="/tokens/{tokenId}" method="get" %}
[Tokens.yaml](https://4223418165-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVSPclqPyChB4NMxFfG2X%2Fuploads%2FMRT60r5LlV5Qc5ADOO9j%2FTokens.yaml?alt=media\&token=7e55e202-cd98-4fd6-ae42-23c31451189d)
{% endopenapi %}


# Transactions

Transactions represent user and system interactions with Pareto vaults such as deposits, redemptions, and claims.

## Structure

Each transaction object includes:

* `_id` *(string)* — Unique identifier
* `type` *(string)* — One of: `DEPOSIT`, `REDEEM`, `CLAIM`
* `status` *(string)* — One of: `PENDING`, `SUCCESS`, `FAILED`
* `hash` *(string)* — Transaction hash on-chain
* `chainId` *(string)* — Blockchain ID where the transaction occurred
* `walletAddress` *(string)* — Wallet initiating the transaction
* `vaultId` *(string)* — Associated vault
* `epochId` *(string)* — Related epoch (if applicable)
* `tokenId` *(string)* — Token involved
* `amount` *(string)* — Amount transacted
* `amountUSD` *(string)* — USD equivalent of the transaction
* `gasFeeUSD` *(string)* — Gas fee in USD
* `block`: *(object)*
  * `number` *(number)* — Block number
  * `timestamp` *(number)* — Unix timestamp of the block
* `createdAt`, `updatedAt` *(string)* — ISO timestamps
* `createdBy`, `updatedBy` *(string)* — Actor identifiers

## Endpoints

{% openapi src="/files/B0USObu0ut26aUSpA14r" path="/transactions" method="get" %}
[Transactions.yaml](https://4223418165-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVSPclqPyChB4NMxFfG2X%2Fuploads%2FXsgRsP9ujyVoR28Sh8SZ%2FTransactions.yaml?alt=media\&token=b906ab9d-745e-4708-8bef-ff321c364b54)
{% endopenapi %}


# Vaults

Vaults are the core contracts of the Pareto protocol. They represent on-chain vehicles that accept user deposits, deploy strategies, and accrue yield over time.

Each vault is tied to a specific strategy, chain, and token, and is managed by one or more operators.

## Structure

Each vault object includes:

* `_id` *(string)* — Unique identifier
* `tokenId` *(string)* — Accepted token reference
* `chainId` *(string)* — Blockchain network identifier
* `typeId` *(string)* — Reference to vault type
* `categoryId` *(string)* — Vault category
* `operatorIds` *(array\[string])* — Managing entities
* `name` *(string)* — Name of the vault
* `address` *(string)* — On-chain vault contract address
* `symbol` *(string)* — Symbol of the share token
* `protocol` *(string)* — Strategy protocol (e.g., AaveV2, Clearpool, Morpho, etc.)
* `contractType` *(string)* — Contract logic (e.g., BestYield, CDO, CDO\_EPOCH)
* `abi` *(array)* — ABI definition
* `description`, `shortDescription`, `caption` *(object)* — Multilingual metadata
* `keyInfo` *(array)* — Key-value UI information
* `visibility` *(string)* — One of: `PUBLIC`, `RESTRICTED`, `HIDDEN`
* `status` *(string)* — Deployment status (e.g., `READY`, `PAUSED`, `DISABLED`)
* `feePercentage` *(number)* — Vault fee as percentage
* `createdAt`, `updatedAt` *(string)* — ISO timestamps
* `createdBy`, `updatedBy` *(string)* — System actor IDs

## Endpoints

{% openapi src="/files/qfgujM7qOV6XUfxXLdaa" path="/vaults" method="get" %}
[Vaults.yaml](https://4223418165-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVSPclqPyChB4NMxFfG2X%2Fuploads%2FAyYSrRq1aBgsILZyllL0%2FVaults.yaml?alt=media\&token=f5705c11-672f-431b-af13-054a7da5d9b1)
{% endopenapi %}

{% openapi src="/files/qfgujM7qOV6XUfxXLdaa" path="/vaults/{vaultId}" method="get" %}
[Vaults.yaml](https://4223418165-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVSPclqPyChB4NMxFfG2X%2Fuploads%2FAyYSrRq1aBgsILZyllL0%2FVaults.yaml?alt=media\&token=f5705c11-672f-431b-af13-054a7da5d9b1)
{% endopenapi %}

{% openapi src="/files/qfgujM7qOV6XUfxXLdaa" path="/vaults/performances" method="get" %}
[Vaults.yaml](https://4223418165-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVSPclqPyChB4NMxFfG2X%2Fuploads%2FAyYSrRq1aBgsILZyllL0%2FVaults.yaml?alt=media\&token=f5705c11-672f-431b-af13-054a7da5d9b1)
{% endopenapi %}

{% openapi src="/files/qfgujM7qOV6XUfxXLdaa" path="/vaults/{vaultId}/integrations" method="get" %}
[Vaults.yaml](https://4223418165-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVSPclqPyChB4NMxFfG2X%2Fuploads%2FAyYSrRq1aBgsILZyllL0%2FVaults.yaml?alt=media\&token=f5705c11-672f-431b-af13-054a7da5d9b1)
{% endopenapi %}


# Vault blocks

Vault blocks are detailed blockchain-based snapshots of a vault’s state at a specific block height. They are used for calculating APR/APY, tracking liquidity, and generating analytics.

## Structure

Each vault block object includes:

* `_id` *(string)* — Unique identifier
* `vaultId` *(string)* — Vault being tracked
* `vaultAddress` *(string)* — Smart contract address of the vault
* `block` *(object)*:
  * `number` *(number)* — Block number
  * `timestamp` *(number)* — Unix timestamp of the block
* `APRs` *(object)* — Non-compounded APRs:
  * `BASE`, `HARVEST`, `REWARDS`, `GROSS`, `NET`, `FEE` *(number)*
* `APYs` *(object)* — Compounded yield rates:
  * `BASE`, `HARVEST`, `REWARDS`, `GROSS`, `NET`, `FEE` *(number)*
* `totalSupply` *(string)* — Total shares issued by the vault
* `price` *(string)* — Price per share
* `TVL` *(object)* —
  * `token` *(string)* — TVL in vault token
  * `USD` *(string)* — TVL in USD
* `pools` *(array of objects)* — Breakdown of pool-level performance:
  * `address` *(string)*
  * `protocol` *(string)*
  * `rates`: `{ supply: number, borrow: number }`
  * `utilization`: `{ supplied: string, borrowed: string, rate: number }`
  * `available`: `{ toBorrow: string, toWithDraw: string }`
* `allocations` *(array)* — Optional pool allocation breakdown
* `createdAt`, `updatedAt` *(string)* — ISO timestamps
* `createdBy`, `updatedBy` *(string)* — Actor IDs

## Endpoints

{% openapi src="/files/91tLoA1zmjeP32AG0yzv" path="/vault-blocks" method="get" %}
[VaultBlocks.yaml](https://4223418165-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVSPclqPyChB4NMxFfG2X%2Fuploads%2FutXySYq67YODk76iQB8a%2FVaultBlocks.yaml?alt=media\&token=864b3632-a901-4f33-9d4f-d59b74ccb7ba)
{% endopenapi %}

{% openapi src="/files/91tLoA1zmjeP32AG0yzv" path="/vault-blocks/{vaultBlockId}" method="get" %}
[VaultBlocks.yaml](https://4223418165-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVSPclqPyChB4NMxFfG2X%2Fuploads%2FutXySYq67YODk76iQB8a%2FVaultBlocks.yaml?alt=media\&token=864b3632-a901-4f33-9d4f-d59b74ccb7ba)
{% endopenapi %}

## Vault latest blocks

Vault latest blocks are real-time snapshots of the most recent state for each vault. Unlike vault blocks (historical), these represent the **current** or **latest available** data.

## Endpoints

{% openapi src="/files/MVFdgZ8bP1chFWQOTXo8" path="/vault-latest-blocks" method="get" %}
[VaultLatestBlocks.yaml](https://4223418165-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVSPclqPyChB4NMxFfG2X%2Fuploads%2FZmlBYllofNTVGllwBoao%2FVaultLatestBlocks.yaml?alt=media\&token=158a3b3b-1268-476d-8c20-3fde8bf3bc49)
{% endopenapi %}


# Vault categories

Vault categories group vaults by their investment profile, strategy type, or risk classification. They provide high-level metadata for sorting and UI filtering.

## Structure

Each vault category object includes:

* `_id` *(string)* — Unique identifier
* `code` *(string)* — Unique category code (e.g. "CAT\_1", "STRATEGY")
* `name` *(object)* — Multilingual name (e.g., `{ en: "Stable Yield" }`)
* `description` *(object)* — Multilingual description
* `createdAt`, `updatedAt` *(string)* — ISO timestamps (UTC Unix time)
* `createdBy`, `updatedBy` *(string)* — Actor IDs

## Endpoints

{% openapi src="/files/UKOkJpLKVrCWc1fzucQF" path="/vault-categories" method="get" %}
[VaultCategories.yaml](https://4223418165-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVSPclqPyChB4NMxFfG2X%2Fuploads%2FaZwO8LlCnjkQecLpuarQ%2FVaultCategories.yaml?alt=media\&token=1ecfdc66-fe4a-457a-99aa-7e0fad7c930f)
{% endopenapi %}

{% openapi src="/files/UKOkJpLKVrCWc1fzucQF" path="/vault-categories/{typeId}" method="get" %}
[VaultCategories.yaml](https://4223418165-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVSPclqPyChB4NMxFfG2X%2Fuploads%2FaZwO8LlCnjkQecLpuarQ%2FVaultCategories.yaml?alt=media\&token=1ecfdc66-fe4a-457a-99aa-7e0fad7c930f)
{% endopenapi %}


# Vault epochs

Vault epochs define fixed-duration accounting periods used in vault logic to compute returns, manage liquidity flows, and determine claim availability.

## Structure

Each vault epoch object includes:

* `_id` *(string)* — Unique identifier
* `vaultId` *(string)* — Vault the epoch belongs to
* `vaultAddress` *(string)* — Address of the vault
* `block` *(object)* —
  * `number` *(number)* — Block number
  * `timestamp` *(number)* — Unix timestamp
* `count` *(number)* — Epoch sequence index
* `status` *(string)* — One of: `WAITING`, `RUNNING`, `DEFAULTED`, `CURE`
* `startDate` *(string)* — ISO 8601 start date
* `endDate` *(string)* — ISO 8601 end date
* `startCureDate` *(string)* — When cure phase begins (if applicable)
* `apr` *(number)* — Estimated APR
* `lastApr` *(number)* — APR from previous epoch
* `expectedInterest` *(string)* — Interest forecasted during this epoch
* `unclaimedFees` *(string)* — Fees not yet claimed
* `deposits` *(string)* — Total deposits in epoch
* `duration` *(number)* — Duration in seconds
* `bufferDuration` *(number)* — Buffer window after epoch ends
* `withdrawType` *(string)* — Either `INSTANT` or `STANDARD`
* `withdraws` *(object)* —
  * `amount` *(string)*
  * `fees` *(string)*
* `depositQueue` *(object)* —
  * `amount` *(string)*
  * `lastAmount` *(string)*
  * `isInstant` *(boolean)*
* `withdrawQueue` *(object)* —
  * `amount` *(string)*
  * `lastAmount` *(string)*
  * `isInstant` *(boolean)*
* `instantWithdraws` *(object)* —
  * `allowed` *(boolean)*
  * `delay` *(number)*
  * `amount` *(string)*
  * `aprDelta` *(number)*
  * `deadline` *(string)* — ISO 8601 date
  * `disabled` *(boolean)*
* `createdAt`, `updatedAt` *(string)* — ISO 8601 timestamps
* `createdBy`, `updatedBy` *(string)* — Actor IDs

## Endpoints

{% openapi src="/files/7U0prelIcGhy2veYPBw3" path="/vault-epochs" method="get" %}
[VaultEpochs.yaml](https://4223418165-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVSPclqPyChB4NMxFfG2X%2Fuploads%2FDsjQoYFYV9f1jzS1GzQR%2FVaultEpochs.yaml?alt=media\&token=6204c9c0-61b0-400d-9708-8abb00bd138d)
{% endopenapi %}


# Vault performances

Vault performances track yield metrics, user activity, and reward distributions for vaults. These metrics are used in analytics, reporting, and performance visualization on Pareto.

## Structure

Each vault performance object includes:

* `_id` *(string)* — Unique identifier
* `vaultId` *(string)* — Vault being tracked
* `vaultBlockId` *(string)* — Related vault block reference
* `block` *(object)* — Block information:
  * `number` *(number)* — Block number
  * `timestamp` *(number)* — Unix timestamp
* `age` *(number)* — Block age in seconds
* `holders` *(number)* — Number of unique users in the vault
* `realizedAPY` *(number)* — Realized annual percentage yield
* `accruedRewards` *(array of objects)* —
  * `tokenId` *(string)* — Reward token ID
  * `amount` *(string)* — Raw amount of rewards
  * `amountUSD` *(string)* — Value in USD
  * `APR` *(number)* — APR contribution
  * `percentage` *(number)* — Share of total reward
* `earnings` *(object)* —
  * `USD` *(string)* — USD-denominated earnings
  * `token` *(string)* — Token earnings amount
  * `percentage` *(number)* — Share of vault value
* `createdAt`, `updatedAt` *(string)* — ISO 8601 timestamps
* `createdBy`, `updatedBy` *(string)* — Actor IDs

## Endpoints

{% openapi src="/files/zlD9JUjbEtPWgFZATV1H" path="/vault-performances" method="get" %}
[VaultPerformances.yaml](https://4223418165-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVSPclqPyChB4NMxFfG2X%2Fuploads%2FXXw4wqlMIQLVc4GctVm1%2FVaultPerformances.yaml?alt=media\&token=7e7e0c81-9c15-4099-8ad8-ae6a965bd241)
{% endopenapi %}

{% openapi src="/files/zlD9JUjbEtPWgFZATV1H" path="/vault-performances/{vaultPerformanceId}" method="get" %}
[VaultPerformances.yaml](https://4223418165-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVSPclqPyChB4NMxFfG2X%2Fuploads%2FXXw4wqlMIQLVc4GctVm1%2FVaultPerformances.yaml?alt=media\&token=7e7e0c81-9c15-4099-8ad8-ae6a965bd241)
{% endopenapi %}


# Vault types

Vault types define internal classifications for vault contracts, distinguishing between different logic structures, yield mechanisms, or operational modes. These types are useful for rendering vault metadata, sorting/filtering in UI, or determining strategy compatibility.

## Structure

Each vault type object includes:

* `_id` *(string)* — Unique identifier
* `code` *(string)* — Internal reference code for the vault type
* `name` *(object)* — Multilingual object (e.g., `{ en: "Fixed Rate" }`)
* `description` *(object)* — Multilingual description object
* `createdAt`, `updatedAt` *(string)* — ISO UTC timestamps
* `createdBy`, `updatedBy` *(string)* — Actor IDs

## Endpoints

{% openapi src="/files/fMNUrvCfynkKiWTVUFcW" path="/vault-types" method="get" %}
[VaultTypes.yaml](https://4223418165-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVSPclqPyChB4NMxFfG2X%2Fuploads%2Fnog2Tsujcp2Qn2g6OhTX%2FVaultTypes.yaml?alt=media\&token=ec22e215-c95e-422d-b147-bd6105f38913)
{% endopenapi %}

{% openapi src="/files/fMNUrvCfynkKiWTVUFcW" path="/vault-types/{typeId}" method="get" %}
[VaultTypes.yaml](https://4223418165-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVSPclqPyChB4NMxFfG2X%2Fuploads%2Fnog2Tsujcp2Qn2g6OhTX%2FVaultTypes.yaml?alt=media\&token=ec22e215-c95e-422d-b147-bd6105f38913)
{% endopenapi %}


# Security

## Audits

Pareto’s products have undergone multiple audits by both security firms and independent experts. A full list of security reports is available on the Audits page.

{% content-ref url="/pages/ahOIkaUWcjDO9AczVuyH" %}
[Audits](/developers/security/audits)
{% endcontent-ref %}

## Monitoring

Pareto’s protocols are secured by the [Hypernative Platform](https://www.hypernative.io/), which provides real-time monitoring and protection to prevent fund losses. The system detects and mitigates cyberattacks, automatically pausing on-chain smart contracts (see *Pauser* under [Addresses](/developers/addresses)) before any assets are compromised.&#x20;

Continuous surveillance extends to the front end, smart contract vulnerabilities, private keys, and multi-signature wallets.


# Audits

<table><thead><tr><th width="130">Date</th><th width="250">Scope</th><th width="221">Auditor</th><th>Report</th></tr></thead><tbody><tr><td>Jun 2026</td><td>Credit vaults</td><td>Sherlock (<a href="https://x.com/IAm0x52">0x52</a>)</td><td><a href="https://drive.google.com/file/d/1tkpk3Rl-O5JWPN0jT2717DtFUnpksRlB/view?usp=sharing">Link</a></td></tr><tr><td>May 2026</td><td>Credit vaults</td><td>Sherlock (<a href="https://x.com/IAm0x52">0x52</a>)</td><td><a href="https://drive.google.com/file/d/1K8K84VQrejNZnRzvjuIFMPHMw2ReWoQH/view?usp=sharing">Link</a></td></tr><tr><td>Mar 2026</td><td>Credit vaults</td><td>Sherlock (<a href="https://x.com/IAm0x52">0x52</a>)</td><td><a href="https://drive.google.com/file/d/1UwmUQX-9VwK-2FIkKOu_62k4Lm-gC1K-/view?usp=drive_link">Link</a></td></tr><tr><td>Feb 2026</td><td>Credit vaults</td><td>Sherlock (<a href="https://x.com/IAm0x52">0x52</a>)</td><td><a href="https://drive.google.com/file/d/1B5VFcZMcf8KVbBkslmfutIzHmraOkdUX/view">Link</a></td></tr><tr><td>Jan 2026</td><td>Credit vaults</td><td>Sherlock (<a href="https://x.com/IAm0x52">0x52</a>)</td><td><a href="https://drive.google.com/file/d/1V1LP5WR01QxHN8M51OXG6N7vrG9b2d0Y/view">Link</a></td></tr><tr><td>Aug 2025</td><td>Credit vaults</td><td>Sherlock (<a href="https://x.com/IAm0x52">0x52</a>)</td><td><a href="https://drive.google.com/file/d/1n8RNsqN7hXcQHwtmksKHYhW8zXVfiDB5/view?usp=sharing">Link</a></td></tr><tr><td>Apr 2025</td><td>USP</td><td><a href="https://www.sherlock.xyz/">Sherlock</a></td><td><a href="https://drive.google.com/file/d/1P8QsDc118cJmp5cCOneefM5NN7xhx5Io/view?usp=sharing">Link</a></td></tr><tr><td>Apr 2025</td><td>USP</td><td>X77 (<a href="https://x.com/s4muraii77">1</a>, <a href="https://x.com/0x3b33">2</a>)</td><td><a href="https://drive.google.com/file/d/15UH3nytMdm_BYSX2XHd77-uZlTXsOLV1/view?usp=sharing">Link</a></td></tr><tr><td>Apr 2025</td><td>USP</td><td><a href="https://code4rena.com/@hansfriese">Hans Friese</a></td><td><a href="https://drive.google.com/file/d/1dBlNpGjnhcryl0s-muvuQGORVz-TzBCM/view?usp=sharing">Link</a></td></tr><tr><td>Jan 2025</td><td>Credit vaults</td><td><a href="https://www.sherlock.xyz/">Sherlock</a></td><td><a href="https://drive.google.com/file/d/1ONqxBgT1GvdYoA-QBAQ7OGlBDicQ4xcI/view?usp=sharing">Link</a></td></tr><tr><td>Nov 2024</td><td>CVs withdraw queue</td><td><a href="https://code4rena.com/@hansfriese">Hans Friese</a></td><td><a href="https://drive.google.com/file/d/1bu-K45CsMWeIST676uEyIgTSAOImDtXe/view?usp=sharing">Link</a></td></tr><tr><td>Oct 2024</td><td>CVs deposit queue</td><td><a href="https://code4rena.com/@hansfriese">Hans Friese</a></td><td><a href="https://drive.google.com/file/d/1aIGWfo1-WXTgE3DfLfZYyJ6NNs8-esNT/view?usp=sharing">Link</a></td></tr><tr><td>Oct 2024</td><td>Credit vaults</td><td><a href="https://code4rena.com/@hansfriese">Hans Friese</a></td><td><a href="https://drive.google.com/file/d/1rTfKCkQbhVEk6qgYsluuHD2acXRxA4e1/view?usp=sharing">Link</a></td></tr><tr><td>Aug 2024</td><td>Credit vaults</td><td><a href="https://code4rena.com/@hansfriese">Hans Friese</a></td><td><a href="https://drive.google.com/file/d/1nr5kvwheKoYBDWe4M5DotKcapHWoqFSh/view?usp=sharing">Link</a></td></tr></tbody></table>


# Media kit

Pareto brand guidelines provide logos, icons, and descriptions about the brand.

## About Pareto

<details>

<summary>Tagline</summary>

A private credit marketplace for institutional borrowers and lenders.

</details>

<details>

<summary>Short description</summary>

Pareto is a private credit marketplace that connects institutional lenders and borrowers, providing scalable, yield-generating opportunities.

</details>

<details>

<summary>Boilerplate description</summary>

Pareto is a private credit marketplace that connects institutional lenders and borrowers, providing scalable, yield-generating opportunities and enabling institutional capital to move onchain.

Tailored for asset managers, digital asset funds, fintechs, and other professional investors, Pareto offers seamless access to regulatory-compliant alternative credit products, alongside whitelabel infrastructure that enables partners to launch branded credit products onchain.

</details>

## About USP

<details>

<summary>Tagline</summary>

USP is a credit-backed synthetic dollar.

</details>

<details>

<summary>Short description</summary>

USP is a synthetic dollar protocol backed by real-world institutional-grade private credit, alongside a globally accessible savings asset, sUSP.

</details>

## Brand assets

### Logos

Pareto's logo visually represents the core principles of liquidity flow, financial connectivity, and cyclical capital movement, emphasizing the Pareto 80/20 principle.

<figure><img src="/files/UDD2h4nlmvagyTqGs53g" alt=""><figcaption></figcaption></figure>

{% file src="/files/1pvIANVdP8gxEWXJWYDv" %}

### Typography

Primary font: [Inter](https://fonts.google.com/specimen/Inter)

Secondary font: [GT America Mono](https://www.grillitype.com/typeface/gt-america)

### Colors

#### Primary colors

<table data-view="cards"><thead><tr><th></th><th data-hidden data-card-cover data-type="files"></th></tr></thead><tbody><tr><td>#254839</td><td><a href="/files/iDsT2i7NR3yvMblgYFZh">/files/iDsT2i7NR3yvMblgYFZh</a></td></tr><tr><td>#081912</td><td><a href="/files/9lafzQMtJwN9BHa9s4H0">/files/9lafzQMtJwN9BHa9s4H0</a></td></tr><tr><td>#E3E8E2</td><td><a href="/files/os374GXqXnGIqiNMixFm">/files/os374GXqXnGIqiNMixFm</a></td></tr></tbody></table>

#### Secondary colors

<table data-view="cards"><thead><tr><th></th><th data-hidden data-card-cover data-type="files"></th></tr></thead><tbody><tr><td>#70B19E</td><td><a href="/files/QZjm8nAKwjPPluGUVQEf">/files/QZjm8nAKwjPPluGUVQEf</a></td></tr><tr><td>#48685A</td><td><a href="/files/X8rOmx1voGlTOvq0ffdp">/files/X8rOmx1voGlTOvq0ffdp</a></td></tr><tr><td>#F9F9F9</td><td><a href="/files/nkvOfoj2gWDjmu7fw136">/files/nkvOfoj2gWDjmu7fw136</a></td></tr></tbody></table>