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

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

Yield and loss scenarios

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.

Standard case

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

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

Hedge case #1

Majority of the total vault's liquidity lies on the Senior side (≥99%). See the Formulae section.

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

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

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.

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.

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

• 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

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.

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.

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:

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

• Connect a supported wallet

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:

Upon completion:

• The user’s wallet will reflect a reduction in the deposited stablecoin

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.

The same Spending Approval and deposit flow applies

Upon completion of steps 1, and 2:

• The user’s wallet will reflect a reduction in the deposited stablecoin

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

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.

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

Ethereum

Optimism

Arbitrum

Polygon

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:

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

API access

1. Required vault data

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

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

GET /v1/signatures?_id=signatureId1,signatureId2

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.

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

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

GET /v1/vault/position?walletAddress={walletAddress}

3. Deposit flow

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

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 });

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

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

4. Withdraw flow

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

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 });

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

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

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

Managing requests

All deposit requests (during the RUNNING state), and all withdrawals (instant or standard) are tracked under the requests array of the vaultBlock object. Each entry in this array represents a user-initiated interaction awaiting processing.

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;
}

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.

Requests are retrieved from the latest vault block:

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

Deposit requests

• Cancel the request if status === 'PENDING'

await cdoEpochContract.methods
  .deleteRequest(request.epochNumber)
  .send({ from: walletAddress });

• Claim the request if status === 'CLAIMED'

await cdoEpochContract.methods
  .claimDepositRequest(request.epochNumber)
  .send({ from: walletAddress });

Redeem requests

Handled via the main vault contract vault.cdoEpoch

• If status === 'CLAIMED':

await cdoEpochContract.methods
  .claimWithdrawRequest(request.epochNumber)
  .send({ from: walletAddress });

• If request.isInstant === true:

await cdoEpochContract.methods
  .claimInstantWithdrawRequest(request.epochNumber)
  .send({ from: walletAddress });

Withdraw requests

Handled via the queue contract vault.cdoEpoch.withdrawQueue

• If status === 'CLAIMED'

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

Ethereum

Fasanara Digital

Optimism

FalconX

Arbitrum

Bastion Trading

Polygon

Bastion Trading

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

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

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

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

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

https://api.pareto.credit/

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

Quick start

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:

curl -H "Authorization: Bearer YOUR_API_KEY" https://api.pareto.credit/v1/vaults

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/vaults/:vaultId/integrations — Integrations by vault ID

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

{
  "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 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

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

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

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

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

  • 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

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

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

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.

Monitoring

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

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

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

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

About Pareto

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.

Typography

Colors

Primary colors

Secondary colors

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

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