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 (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 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

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:

Architecture

The diagram illustrates the architecture of Credit Vaults

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.

This section describes the risks associated with USP, and the actions taken to mitigate such risks.

Ethereum

USP

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

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

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

Ethereum

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

About Pareto

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.

Key responsibilities

• Lenders must be whitelisted and complete the required via Keyring before being allowed to interact with Credit Vaults.

Once is completed, users can proceed to deposit into the selected Credit Vault.

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:

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

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

Structure

Each transaction object includes:

• _id (string) — Unique identifier

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

The verification and KYC compliance on Credit Vaults is processed through .

Keyring offers streamlined and flexible solutions

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.

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

USP

Users mint USP () by depositing stablecoins, e.g. USDC, USDS, into the ParetoDollar contract. The contract mints USP and deposits the underlying assets into . 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 compliant yield sources to process redeems faster.

The of funds for each credit vault is determined by a board that operates through the ParetoDollarQueue contract.

sUSP

Once USP is staked into sUSP, users can earn yield from the interest generated by . 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.

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.

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

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
• createdAt, updatedAt (string) — ISO timestamps

• createdBy, updatedBy (string) — System actor IDs

Endpoints

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
• earnings (object) —

  • USD (string) — USD-denominated earnings

  • token (string) — Token earnings amount
• createdAt, updatedAt (string) — ISO 8601 timestamps

• createdBy, updatedBy (string) — Actor IDs

Endpoints

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)
• createdAt, updatedAt (string) — ISO timestamps (UTC Unix time)

• createdBy, updatedBy (string) — Actor IDs for auditing

Endpoints

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.

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

Upon completion of steps 1, and 2

• The user’s wallet will reflect a reduction in the 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

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.

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

• 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.

Curator app

The Pareto manager app is a specialized front-end interface designed for configuring and managing Credit Vaults. Available at , 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.

Implementation note: Some actions are not yet implemented in the manager app. For this reason, curators should interact directly with through verified sources such as or . Always verify contract addresses before interaction.

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

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

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)
• allocations (array) — Optional pool allocation breakdown

• createdAt, updatedAt (string) — ISO timestamps

• createdBy, updatedBy (string) — Actor IDs

Endpoints

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

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

Allocation rules

1. Sort vaults by descending yield vs duration score (see )

2. Fill Tier 2 weight up to the global cap . 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 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.

Initial parameters

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

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

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. 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:

Endpoints

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

• GET /v1/chains — List supported chains

• GET /v1/chains/:chainId — Get chain by ID

An entity managing or integrating with Pareto products.

• GET /v1/operators — List all operators

• GET /v1/operators/:operatorId — Get operator by ID

• GET /v1/token-blocks — List all token blocks

• GET /v1/token-blocks/:tokenBlockId — Get token block by ID

• GET /v1/tokens — List all tokens

• GET /v1/tokens/:tokenId — Get token by ID

• GET /v1/transactions — List all protocol transactions

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/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

• GET /v1/vault-categories — List all vault categories

• GET /v1/vault-categories/:typeId — Get category by ID

A predefined period for vault accounting.

• GET /v1/vault-epochs — List all vault epochs

• GET /v1/vault-performances — List all performance metrics

• GET /v1/vault-performances/:vaultPerformanceId — Get performance by ID

• 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.

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

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

• Use field for ascending order

• Use -field for descending order

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.

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

• Select a Credit Vault (e.g., the Fasanara pool)

• Connect a supported wallet