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.

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

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.

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:

Upon completion:

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

• The user will receive representing his position in the pool

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

• The user will need to claim his representing his position in the pool after the new lending cycle starts

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

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

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

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

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

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

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

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

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.

Ethereum

Optimism

Arbitrum

Polygon

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

USP

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

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, borrowers can easily see the status of the current lending cycle, a countdown to the epoch end, and the wallet allowance and balance.

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.

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

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.

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 (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. 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 compliant yield sources to process redeems faster.

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

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.

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

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

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

About Pareto

About USP

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

Primary font: GT Sectra

Secondary font: GT America Mono

Colors

Primary colors

Secondary colors

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

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

• Connect a supported wallet

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

Pareto’s protocols are secured by the Hypernative Platform, 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) before any assets are compromised.

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

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

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

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:

Ethereum

Fasanara Digital

Bastion Trading

Adaptive Frontier

Optimism

FalconX

Arbitrum

Bastion Trading

Polygon

Bastion Trading

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

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

• T2: is a short-term yield product, redeemable in less than 1 week ( 7 days) -->

• T3: is a long-term yield product, redeemable in less than 1 month (8-30 days) -->

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: