Executive summary
What Pareto provides
End-to-end infrastructure for onchain credit
Pareto provides the infrastructure to originate, operate and manage onchain credit facilities from start to finish. We bring facility structuring, permissioned access, funding, servicing, reporting and DeFi connectivity into one platform, enabling underwriters, lenders and borrowers to run credit programs on transparent, programmable blockchain rails.
With Pareto’s onchain credit infrastructure and Pareto Studio, Credit Vaults allow operators to launch and manage standard cycle-based or revolving facilities with tailored rates, repayment schedules, permissions and risk controls. Studio provides the interface to configure and manage facilities, while Credit Vaults record capital, borrower exposure, interest and lender positions onchain. Underwriters bring their credit expertise and borrower relationships.
The full spectrum of collateral and credit support
Pareto infrastructure works with:
- Onchain collateral. Flexible collateral management with configurable monitoring, margin calls and grace periods, so collateral requirements and responses can match the facility’s risk profile and agreed terms.
- Offchain collateral. Facilities supported by assets held with qualified custodians, connecting custody arrangements and offchain evidence to the facility’s monitoring and servicing workflows.
- Managed accounts and CEX/bank accounts. Structures built around managed accounts and accounts at centralised exchanges or banks, with agreed account controls, visibility and reporting.
- Unsecured corporate credit. Facilities underwritten against the borrower’s balance-sheet strength and cash flows, including structures supported by parent-company guarantees.
Support across the entire loan lifecycle
Pareto supports facility design and deployment, KYC/KYB and permissions, lender onboarding and funding, borrower drawdowns, interest and fee accounting, repayments, renewals and revolving redraws. Ongoing workflows cover collateral and covenant monitoring, margin calls, grace periods, lender withdrawals, callbacks, defaults and recovery administration.
Underwriters and borrowers can manage facilities through Pareto’s tools or connect their own systems through APIs and SDKs. Facility records and reporting connect onchain activity with the financial, custody and account information needed to operate the credit relationship. Multi-facility coordination supports operators managing a broader credit book.
DeFi integrations out of the box
Built-in integrations with Morpho, Pendle, Aave, Euler and a wider DeFi ecosystem connect credit facilities to onchain liquidity and yield opportunities. Depending on the facility design, these connections support productive use of undrawn capital, lender distribution and complementary yield strategies, without requiring operators to build each integration from scratch.
The result is one infrastructure platform spanning origination, day-to-day loan management and DeFi connectivity – across collateralised and unsecured credit.
AI guide
Use this playbook with AI
Use your AI assistant to turn this playbook into a facility proposal for Pareto. Upload the download below, copy the prompt and answer a few questions at a time. At the end, ask it to “Create my Pareto report.” Review the report, then share it with your Pareto contact or bring it to your introductory call. Open questions are welcome; you do not need every term agreed to start the conversation.
Act as my Pareto credit-origination assistant. Use the attached Credit Origination Playbook to help me understand the options, develop my facility proposal and produce a standalone “Credit Facility Report for Pareto” that I can review and share. Write in clear business language; explain technical terms when needed.
1. Start with the essentials. First confirm you can read the playbook; if not, ask me to upload it. Ask my role and organisation, a brief description of the borrower and funding need, and our current stage and target timeline. Ask no more than three focused questions per turn. Reuse answers and supplied documents instead of asking me to repeat information.
2. Guide me through the decisions. Follow the playbook’s facility design, diligence, launch and appendix sections. Adapt questions to my role and the proposed structure. Explain why each decision matters and cite the relevant playbook heading. I can ask questions or pause at any time. After each topic, summarise what we have established, what is proposed and what remains open. If I do not know an answer, record TBD and continue.
3. Keep the proposal grounded. Use the playbook for process and capabilities, and my answers and documents for facility-specific facts. Label entries Confirmed, Proposed, TBD or Not applicable (with a reason). Confirmed means supported by the stated source, not approved. Cite document titles, dates and sections/pages where available; label unverified statements as user-provided. Flag conflicting evidence. Do not invent terms, figures, approvals or supported configurations. Separate commercial preferences from items Pareto operations must confirm. Show assumptions and inputs for any calculations.
4. Produce the shareable report. When we finish, or whenever I say “Create my Pareto report,” produce the report using the information available. Keep gaps visible rather than delaying the draft. Include the facility/organisation name, preparer and role, date, playbook version and “Draft for discussion with Pareto.” Use concise prose and tables, with these sections:
A. Executive summary — one page maximum. Describe the business, funding purpose, requested amount and currency, facility type, repayment source, credit support, target timing and the specific help or decisions requested from Pareto.
B. Facility terms and decisions. Provide a table with Decision | Proposed or confirmed position | Status | Source | Owner / confirmation needed. Cover standard cycle-based versus revolving structure; cap, tenor and currencies; funding route; draw, repayment and redraw rules; epochs and renewals; rate timing, benchmark, spread, reset and fallback; interest basis, cash versus retained interest; fees; withdrawals and callbacks, including notice and settlement timing.
C. Credit case, collateral and diligence. Summarise repayment capacity and supporting financial evidence. Describe the applicable onchain collateral, qualified-custodian/offchain collateral, managed or CEX/bank accounts, or unsecured balance-sheet/parent-guarantee structure. Record valuation and control arrangements, covenants, margin calls, grace periods, defaults and recovery responsibilities. List evidence received, evidence missing and material concerns.
D. Operating model and integrations. Identify borrower, underwriter, lender and Pareto responsibilities; KYC/KYB and permission status; treasury and reporting owners; lifecycle calendar; deployment and settlement testing; funding commitments; monitoring and reconciliation. Record requested Pareto Studio, API/SDK, DeFi and multi-currency Orchestrator workflows where relevant, with dependencies and Pareto confirmations still needed.
E. Readiness and next actions. Assess each applicable GREEN/YELLOW/RED launch criterion against the playbook, citing evidence or marking it not assessed. Do not infer GREEN from silence. Separate readiness for a Pareto discussion from credit approval or launch readiness. Provide an action table: Open item / decision | Why it matters | Owner | Target date | Evidence or sign-off needed. Use TBD for unassigned owners or dates.
F. Questions for Pareto and evidence appendix. Prioritise the questions Pareto needs to resolve, list supporting documents and relevant playbook sections, and include applicable completed appendix templates. Make the report understandable without our chat history.
5. Review and hand over. Ask me to check the draft for factual errors and confirm what should be shared, then incorporate corrections. Deliver a polished report in Markdown, with a downloadable Word or PDF version if your tools support it, plus a short cover note stating the request, key open items and proposed next step. Credit approval and launch sign-off remain with the responsible people. Prepare the report for me to share; do not send it automatically.
Quickstart
Your route to launch
The underwriter owns the credit decision; the borrower prepares the information and repayment plan; Pareto operations configures and tests the facility. Use the detailed sections and reusable templates to complete each step. Launch follows approval and testing, not a promised setup time.
- Establish the fit. Borrower: explain the business, funding need, currency and use of proceeds. Underwriter: assess the credit case and agree on the diligence scope.
- Agree the terms. Set the facility cap, interest model, fees, loan cycle and repayment obligations. Record the decisions in the term sheet (Section 3).
- Set the protections. Agree credit support, covenants, reporting, withdrawal rights and callback notices. Make the borrower’s liquidity plan consistent with those obligations.
- Complete eligibility. Borrower: supply entity and ownership documents and authorized wallets. Underwriter: obtain the required KYB and compliance approvals (Section 4).
- Prepare to operate. Name the reporting and treasury contacts, agree a cycle calendar, and confirm which cash must be available for repayment and lender exits.
- Deploy and test. Pareto operations configures the approved facility. All parties review a successful test of funding, repayment and withdrawal before launch.
- Approve and fund. Complete the GREEN launch gate, confirm initial lender commitments, then fund the facility and confirm the borrower’s receipt.
Inspect the code · Facility setup
initialize()Connect the deposit asset and strategy, set the initial limit and create the tranche tokens.
IdleCDOCreditVault.sol· lines 44–86setEpochParams()Configure the loan period and buffer, subject to lifecycle restrictions.
IdleCDOEpochVariant.sol· lines 117–125setFeeParams()Set fee recipients, performance fees, fee split and management fees.
IdleCDOCreditVault.sol· lines 461–470
Section 01
1. Roles & Responsibilities
The underwriter (also called the curator) assesses the borrower, structures the facility and monitors credit risk. The borrower provides information, accepts the terms, manages liquidity and meets payment and reporting obligations. Pareto supplies infrastructure and deployment support. The executed agreement defines each party’s legal role; operational permissions are assigned separately.
1.1 Responsibilities
- Underwriter: set borrower eligibility, complete diligence, approve credit terms and document the decision.
- Underwriter and borrower: agree economics, covenants, notices, reporting and the repayment calendar.
- Borrower: provide complete financial information, explain material changes and support ongoing monitoring.
- Underwriter and operations: approve eligible wallets and verify that the configured permissions match the approval.
- Borrower: deliver the agreed data. Underwriter: reconcile it and issue lender reports.
- Borrower: fund payments and raise expected shortfalls early. Underwriter: own the exception and recovery process.
- Underwriter: coordinate initial lender commitments and approve any later expansion.
1.2 RACI Matrix
R = Responsible, A = Accountable, C = Consulted, I = Informed
Activity | Underwriter | Pareto / ops | Borrower | Lender |
|---|---|---|---|---|
Credit approval | R / A | I | R: evidence | I |
Facility terms | A | C: feasibility | R: agreement | C: rights |
KYB / eligibility | A: approval | R: setup | R: own data | R: own checks |
Deployment | C | R / A | C: treasury | I |
Wallet permissions | A: policy | R: verify | R: wallet binding | R: wallet binding |
Reporting | R / A | C: records | R: data | I |
Loan cycles | A: terms | R: execution | R: due payments | I |
Exceptions | R / A | R: technical review | R: remediation | I |
Initial funding | R / A | C | C: readiness | R: allocation |
Legal roles, liability and enforcement rights follow the executed facility agreements.
Inspect the code · Operational authority
setManager()Assign the strategy manager; this owner-controlled role is separate from the legal underwriting role.
IdleCreditVault.sol· lines 185–187setBorrower()Assign the borrower address on the strategy.
IdleCreditVault.sol· lines 191–194_checkOnlyOwnerOrManager()Internal permission check used by the epoch-management functions.
IdleCDOEpochVariant.sol· lines 93–95
Section 02
2. How the Facility Works
A Credit Vault is the on-chain record and settlement point for an agreed credit facility. Approved lenders provide funds; the borrower receives them through the configured funding route. A loan period is also called an epoch. Interest, repayment and lender exits follow the facility’s terms and operating calendar.
2.1 Lifecycle Stages
Stage | Lead | Action | Output |
|---|---|---|---|
1. Originate | Underwriter + borrower | Assess funding need, business and credit fit. | Borrower profile; review scope |
2. Structure | Both | Agree terms, liquidity and support. | Term sheet; cash plan |
3. Verify | Both + compliance | Approve required entity checks and wallets. | Approval and wallet record |
4. Deploy | Pareto operations | Configure approved terms and test settlement. | Verified facility; test results |
5. Fund | Lenders + ops | Accept eligible funds; confirm borrower receipt. | Funding confirmation |
6. Operate | Borrower + ops | Start/close cycles; pay amounts due; monitor exits. | Cycle reconciliation |
7. Report | Borrower + underwriter | Supply data, check covenants and inform lenders. | Reporting pack; exceptions |
8. Review | Underwriter + borrower | Renew, resize or close under approved terms. | Decision; notices; updated records |
Inspect the code · Epochs and settlement
startEpoch()Apply the cycle-start checks, reserve accelerated claims and transfer the available funds to the borrower.
IdleCDOEpochVariant.sol· lines 233–304stopEpochWithDuration()Close the epoch and set the next duration, with an optional recognized loss.
IdleCDOEpochVariant.sol· lines 520–530_stopEpoch()Inspect the internal settlement path, including borrower cash collection, minted interest and default handling.
IdleCDOEpochVariant.sol· lines 330–506
2.2 Choose the funding route
In the standard cycle model, eligible deposits between loan periods are deployed when the next period starts. During an active period, a deposit queue can hold funds until processing; queued cash is not yet a borrower drawdown. Confirm receipt before treating funds as available to use.
Some facilities enable direct deposits during a running period or an AA prefunded queue. Prefunded cash reaches the borrower before final deposit pricing and cannot then be cancelled by the lender. These are distinct modes with different closing and exit restrictions; operations must confirm the selected route. A revolving facility is a separate product variant – do not assume on-demand draws are available in every Credit Vault. See Section 3H for the revolving-facility workflow.
Inspect the code · Deposit routes
The prefunded route is optional.
depositAA()Standard senior-tranche deposit entry point.
IdleCDOCreditVault.sol· lines 99–101depositDuringEpoch()Dedicated mid-epoch deposit path with its pricing and eligibility checks.
IdleCDOEpochVariant.sol· lines 656–733requestDeposit()Queue a deposit while the epoch is running.
IdleCDOEpochQueue.sol· lines 103–127processDeposits()Process a standard queue during the buffer period.
IdleCDOEpochQueue.sol· lines 222–246processDepositsToBorrower()Transfer AA queue funds early, only for an enabled prefunded variant.
IdleCDOEpochQueue.sol· lines 149–180
Section 03
3. Design the Facility
Use these five groups to agree the facility before deployment. The tables are a decision guide, not a menu of universally available settings. The borrower and underwriter agree commercial terms; operations confirms that the selected Credit Vault supports them.
3A. Economics
Decision | Agree together | Why it matters | Record | Approval |
|---|---|---|---|---|
Interest model | Rate timing, benchmark and cash treatment | Defines the payment obligation | Supported mode | Underwriter + borrower |
Rate | Annual rate or benchmark and reset rule | Borrowing cost; lender return | Agreed rate; day count | Underwriter + borrower |
Cycle | Loan period and time between cycles | Matches treasury and exit needs | Duration; calendar | Underwriter + borrower |
Rollover | What remains deployed; what is due | Avoids unexpected cash demands | Payment and notice rules | Underwriter + borrower |
Underwriter fee | Basis, rate, payer and timing | Makes net economics clear | Agreed fee schedule | Relevant parties |
Platform fee | Basis, rate and recipient | Supports reconciliation | Agreed fee schedule | Relevant parties |
3A.1 Choose the Facility and Interest Model
Choose the facility type, then agree rate timing, benchmark, cash treatment and the balance on which interest accrues. Revolving is a facility structure, not a rate type; it can use fixed or variable pricing. Operations confirms the supported combination. See Section 3H.
Decision | Option A | Option B | What to agree |
|---|---|---|---|
Facility type | Standard cycle-based facility | Revolving credit line (Section 3H) | Limit, availability, draw and redraw rules |
Rate timing | Known before the cycle | Determined at settlement | Calculation, approval and notice |
Benchmark | Fixed rate | Variable benchmark; revolving: DeFi yield + spread | Source, spread, reset and fallback |
Cash treatment | Cash interest paid at close | Interest retained in facility value | Cash due, reporting and exit funding |
Interest basis | Deployed loan balance | Revolving: drawn balance; undrawn funds earn DeFi yield | Drawn/undrawn tracking; fees, if any |
Inspect the code · Interest and fees
setAprsWithBuffer()Store the headline APR and its scaling for the period and buffer.
IdleCreditVault.sol· lines 217–220_calcInterestWithApr()Internal annual-rate calculation for the configured loan period.
IdleCDOEpochVariant.sol· lines 807–809setIsInterestMinted()Choose whether interest is represented by strategy tokens rather than collected as cash at each ordinary close.
IdleCDOEpochVariant.sol· lines 166–170_calculateManagementFee()Inspect the fee calculation based on NAV and elapsed time.
IdleCDOCreditVault.sol· lines 558–561
3B. Risk
Decision | Agree together | Why it matters | Record | Approval |
|---|---|---|---|---|
Credit support | Unsecured, guarantee or pledged collateral | Defines repayment support | Executed structure | Underwriter + borrower |
Collateral | Assets, control and enforcement | Determines available protection | Asset and security record | Underwriter + counsel |
Valuation | Source, haircut and review rules | Makes limits measurable | Approved methodology | Underwriter |
Facility cap | Maximum approved exposure | Controls funding size | Amount and currency | Underwriter + borrower |
Concentration | Borrower / strategy exposure | Identifies correlated risk | Limits or explicit single-name exposure | Underwriter |
Covenants | Measures, thresholds and remedies | Provides early warning | Agreed covenant schedule | Underwriter + borrower |
Non-cash interest | Financial evidence and liquidity tests | Monitors repayment capacity | Monitoring commitments | Underwriter + borrower |
3C. Liquidity
Decision | Agree together | Why it matters | Record | Approval |
|---|---|---|---|---|
Withdrawals | Request, notice and settlement timing | An exit request is not instant cash | Route and calendar | Underwriter + borrower |
Callbacks | Rights, price, fees and deadline | Plans early-exit liquidity | Notice and settlement terms | Relevant parties |
Deposits | When cash is accepted and deployed | Separates queued cash from a loan | Enabled funding route | Underwriter + ops |
3D. Operations
Decision | Agree together | Why it matters | Record | Approval |
|---|---|---|---|---|
Reporting | Data, owner and due dates | Supports credit monitoring | Reporting calendar | Underwriter + borrower |
Valuation | On-chain records and borrower evidence | Separates value from cash | Reconciliation method | Underwriter |
Settlement | Asset, chain, wallets and signers | Avoids payment to the wrong place | Verified payment instructions | Operations + borrower |
3E. Access Control
Decision | Agree together | Why it matters | Record | Approval |
|---|---|---|---|---|
Eligibility | Who may lend; approved wallets | Controls facility access | Policy and live settings | Underwriter + ops |
KYB / KYC | Checks required for each party | Separates entity and wallet approval | Completed checks | Compliance owner |
Restrictions | Permitted entities and jurisdictions | Defines the participation perimeter | Approved restrictions | Compliance owner |
Eligibility handover: borrower KYB and lender eligibility are separate checks. Confirm whether the facility uses existing third-party verification through Keyring Connect or a tailored Keyring Pro review. Record who approves the evidence and verify the live wallet permissions; a “KYC-gated” label is not sufficient.
Inspect the code · Wallet eligibility
These functions enforce configured onchain access. They do not perform the borrower’s corporate diligence or establish that KYB has been approved.
setKeyringParams()Configure the Keyring contract and policy identifier.
IdleCDOEpochVariant.sol· lines 142–146isWalletAllowed()Read the credential check used by the vault; an unset Keyring address makes this check permissive.
IdleCDOEpochVariant.sol· lines 984–987_deposit()See where the wallet check is applied to the standard deposit path.
IdleCDOEpochVariant.sol· lines 644–650
3F. Parameter Decision Tree
Step 1: What supports repayment?
- For unsecured credit, assess the borrower’s cash generation and balance sheet and agree to any guarantee. For secured credit, verify the pledged assets, valuation, control and enforcement arrangements. Neither structure removes the need for a repayment plan.
- Choose covenants and reporting that reveal deterioration early. Match the facility cap and cycle to the borrower’s liquidity and asset maturity; collateral alone does not justify a longer cycle.
Step 2: How will interest and lender exits be funded?
- Cash-paid interest makes payment performance observable each cycle. Interest retained in facility value requires clear monitoring of cash versus accrued value and an agreed plan to meet withdrawals.
- Agree standard withdrawal timing, callback terms and any conditional accelerated exit. The borrower should forecast these obligations together with interest and any principal due.
Step 3: Which vaults and currencies are needed?
- For the standard facility, record the designated borrower and deposit asset for each vault. An additional currency normally needs a separately configured vault and separate reporting.
- If several vaults will be coordinated, operations confirms the Orchestrator setup and permissions. Shared execution does not combine cash, claims or credit exposure (Section 5.7).
Step 4: Who can participate?
- Agree eligible lender types, jurisdictions, the invitation process and approved wallets. Confirm the Keyring eligibility route and the actual access settings.
- Approve the distribution approach under the applicable mandate and legal documentation. Eligibility approval and credit approval are different decisions.
3G. Senior and Junior Positions
If the facility uses AA (senior) and BB (junior) positions, agree each class’s economics, contribution, deposit permissions and loss treatment. A junior contribution may absorb ordinary active-position losses first, but withdrawal claims and hard-default recoveries follow different rules. Underwriter and borrower should reconcile the investor description with the actual facility and agreement before launch.
Inspect the code · Senior and junior positions
setBBDepositEnabled()Explicitly enable or disable junior-tranche deposits.
IdleCDOCreditVault.sol· lines 444–447_virtualPriceAux()Inspect ordinary gain allocation and the BB-first active-loss calculation.
IdleCDOCreditVault.sol· lines 287–337finalizeDefaultRecovery()Compare the distinct hard-default path, which applies a common recovery ratio to affected balances.
IdleCreditVault.sol· lines 661–710
3H. Revolving Credit Facilities
A revolving facility lets a borrower draw, repay and draw again within an agreed limit and availability period. Pareto’s described model places undrawn capital in a designated DeFi yield vault; drawn capital funds a loan cycle. This suits recurring working-capital needs, such as receivables finance or trading liquidity. It is a distinct facility variant, not an automatic feature of every Credit Vault.
3H.1 Agree the line before launch
Underwriter and borrower: record the credit limit, currency, availability period, final maturity, permitted uses, draw conditions, cycle length, repayment dates and redraw rights. Confirm the drawn rate, calculation basis, fees, reporting and circumstances that suspend further draws. Keep the facility’s maturity separate from each loan cycle.
Borrower: provide a draw-and-repayment forecast, expected and peak utilisation, repayment sources, treasury contacts and approved wallets. Demonstrate how obligations will be met if receipts arrive late or the next draw is unavailable.
Underwriter and operations: approve the idle-capital vault and its liquidity and risk limits; confirm the supported integration, permissions and lender exit terms. Test withdrawal from the yield vault, borrower receipt, repayment and reallocation before launch. Confirm actual draw timing and any notice requirement before promising on-demand access.
Inspect the code · Revolving-facility setup
This is the programmable-borrower variant at the same pinned revision. Verify that it is the adapter selected for the facility.
initialize()Bind the ERC4626 yield vault, epoch vault, owner, manager, borrower and borrower APR.
ProgrammableBorrower.sol· lines 108–135setVault()Change the idle-capital vault only after unwinding the old position and ending active epoch accounting.
ProgrammableBorrower.sol· lines 158–170setIsProgrammableBorrower()Explicitly enable the borrower adapter on the epoch vault.
IdleCDOEpochVariant.sol· lines 176–180_checkProgrammableBorrowerMode()Inspect the requirement for minted interest and the exclusion of pending instant withdrawals.
IdleCDOEpochVariant.sol· lines 105–107
3H.2 Draw, repay and redraw
Available capital: undrawn funds earn the selected vault’s yield. The credit limit is a contractual ceiling; immediately available liquidity may be lower. Operations confirm what can actually be withdrawn.
Drawdown: the borrower requests funds through the approved route. Check remaining headroom, draw conditions and available liquidity; operations confirm receipt and records the drawn balance, rate and due date. The drawn portion earns the credit rate while the undrawn portion remains in the yield vault.
Settlement and redraw: pay the principal and interest due for the loan cycle, reconcile receipts, and return settled capital to the yield vault as configured. Confirm restored headroom before another draw. Redraw remains subject to the agreement, eligibility and liquidity; repayment does not extend final maturity.
Inspect the code · Revolving draws and repayments
availableToBorrow() is an accounting view; successful funding still depends on the external vault supplying liquidity.
borrow()Borrower-authorized draw entry point; delegates liquidity and principal accounting to
_borrow().ProgrammableBorrower.sol· lines 392–395_borrow()Inspect the draw limits, ERC4626 withdrawal and transfer to the borrower.
ProgrammableBorrower.sol· lines 435–463availableToBorrow()Calculate asset availability after reserving pending withdrawal obligations.
ProgrammableBorrower.sol· lines 350–355repay()Borrower-authorized repayment entry point.
ProgrammableBorrower.sol· lines 419–422_repay()Apply repayments to interest debt, accrued interest and principal, then reinvest cash during an active epoch.
ProgrammableBorrower.sol· lines 466–533
3H.3 Price and monitor both balances
Choose a fixed credit rate or a variable rate linked to the underlying yield-vault return plus an agreed spread. Specify the benchmark, observation/reset method and fallback. In the described model, borrower interest applies only to drawn capital; undrawn yield comes from the DeFi allocation. Confirm any separately agreed fees rather than assuming they are zero.
Report the limit, drawn balance, remaining headroom, idle allocation, available cash, accrued and paid interest, upcoming repayments and lender exits. Keep borrower borrowing cost separate from blended lender return, which combines drawn-credit earnings and undrawn yield. Neither the idle yield nor the blended return is guaranteed.
Agree draw-stop triggers and an escalation owner for late payments, covenant breaches, insufficient liquidity or a yield-vault incident. Underwriter directs the response; borrower supplies a cash plan; operations verifies balances and supported actions. Apply Sections 5.6 and 5.8 for exits and recovery, with the revolving facility’s agreed terms.
Inspect the code · Revolving rates and accounting
This adapter exposes a manager-set fixed borrower APR. Automatic benchmark-plus-spread updates require separately verified rate-setting logic; idle-vault yield is not itself the borrower’s rate.
setBorrowerApr()Checkpoint accrued borrower interest before changing the configured fixed APR.
ProgrammableBorrower.sol· lines 191–196totalInterestDueNow()Calculate the pool-facing result from borrower interest and the idle vault’s gains or losses.
ProgrammableBorrower.sol· lines 330–334borrowerInterestOwedNow()Read the borrower’s interest obligation separately from the pool-facing result.
ProgrammableBorrower.sol· lines 315–317onStopEpoch()Inspect liquidity recall and the debt checks for a full facility close.
ProgrammableBorrower.sol· lines 231–268
Section 04
4. Underwriting & Diligence Playbook
The borrower prepares the evidence; the underwriter evaluates it and records the decision. Core diligence applies to every launch. The underwriter adds depth according to size, complexity and risk; a known borrower does not remove the required checks.
4.1 Core Diligence
- Entity verification: legal name, jurisdiction, registration number, corporate structure.
- UBO (Ultimate Beneficial Owner) identification and sanctions/PEP screening (Underwriter collects directly from borrower).
- Most recent audited or management-prepared financial statements (balance sheet, P&L).
- Description of borrower business model and intended use of facility proceeds.
- Signed Master Loan Agreement (MLA) or equivalent legal documentation.
- Wallet binding confirmation (approved wallet addresses linked to verified entity).
4.2 Additional Institutional Diligence
Where proportionate to the credit decision, request the following in addition to core diligence:
- 2–3 years of audited financial statements.
- Detailed risk analysis: credit scoring, leverage analysis, liquidity assessment.
- Operational due diligence: key personnel, systems, controls, business continuity.
- Legal opinion on enforceability of MLA and guarantee/collateral arrangements.
- Third-party credit assessment or rating (if available).
- Covenant package: financial covenants, reporting covenants, negative pledges.
- Insurance coverage review (if applicable).
- Management meeting or site review where warranted by the borrower’s operating model and the underwriting policy.
4.3 Red Flags & STOP Criteria
Section 05
5. Launch & Ongoing Management
5.1 Pre-Launch Checklist
- Borrower KYB and required compliance approvals complete; lender eligibility handled separately.
- Terms agreed and matched to the configured facility, including currency, rate, fees and cycle.
- MLA / legal documentation executed.
- Agreed credit support and enforcement arrangements finalized and documented.
- Borrower reporting, treasury responsibilities and notice calendar agreed.
- Deployment and permissions verified; funding, repayment and withdrawal tests passed.
- Authorized borrower, operator and eligible lender wallets recorded and tested.
- Initial lender commitments, facility cap and funding route confirmed.
- GREEN launch decision recorded and accepted by the relevant parties (Section 7).
5.2 Monitoring KPIs
Monitor | Evidence | When | Response |
|---|---|---|---|
Utilization | Drawn exposure versus cap | Each cycle | Review sizing against agreed plan |
Payments | Cash due versus cash received | Each due date | Escalate any shortfall |
Covenants | Evidence against agreed thresholds | Agreed cadence | Apply notice / cure process |
Exposure | Borrower, strategy and currency | Each cycle | Review any approved-limit breach |
Lender exits | Requests, funded claims and cash needs | Around each cycle | Update borrower liquidity plan |
Interest / value | Accrual, fees, cash and valuation | Each cycle | Investigate discrepancies |
5.3 Minimal Reporting Pack (Monthly Snapshot)
Agree actual delivery dates with the borrower. A monthly snapshot can be the starting point, supported by monitoring around each cycle and prompt reporting of material events.
- Value and cash: outstanding exposure, accrued interest, actual cash and reconciled facility value, shown separately by currency and tranche.
- Positions and exits: lender balances, pending withdrawal requests, funded claims, callback offers and expected payment dates.
- Performance: interest recognized versus cash collected, fees, losses and repayment performance.
- Changes and incidents: revised terms, wallet or permission changes, late payments, system incidents and actions taken.
- Covenants: agreed measures and thresholds, evidence, pass/breach/waiver status and responsible owner.
- Attestations: borrower confirms supplied data; underwriter records its review, exceptions and conclusions for lenders.
Integration handover: confirm the facility’s available portal, exports, API/SDK, custody connections and monitoring tools with Pareto operations. Assign an owner for each data feed and reconciliation. Product-level integration descriptions do not establish that a particular facility is configured to use them.
Inspect the code · Reporting and valuation
These are onchain inputs for reconciliation, not replacements for borrower financial statements or evidence of immediately available cash.
getContractValue()Read the vault’s net value in deposit-asset units.
IdleCDOCreditVault.sol· lines 125–128virtualPrice()Read tranche value including accounting changes that are not yet saved in
tranchePrice().IdleCDOCreditVault.sol· lines 172–180maxWithdrawable()Inspect the estimate of a user’s withdrawable underlying value.
IdleCDOEpochVariant.sol· lines 911–918totalUnderlying()Read the programmable borrower’s cash plus its external-vault position.
ProgrammableBorrower.sol· lines 536–538
5.4 Exception Handling
Event | First response | Timing | Decision owner |
|---|---|---|---|
Late payment | Borrower explains shortfall and cash plan; ops confirms outcome. | Agreed notice / cure rules | Underwriter |
Covenant breach | Verify evidence and request remediation. | Agreement’s timetable | Underwriter |
Callback | Confirm valid notice, amount and funding plan. | Agreed settlement deadline | Underwriter + borrower |
Operational issue | Check wallets, permissions and settlement with ops. | Prompt investigation | Operations; underwriter informed |
5.5 An Illustrative Operating Calendar
When | Action | Lead |
|---|---|---|
Launch | Confirm approvals and eligible funding; verify borrower receipt. | Both + ops |
During cycle | Monitor exposure, covenants, reporting and upcoming exits. | Both |
Before close | Confirm cash due, wallet balances and approved payment instructions. | Borrower + ops |
At close | Settle and reconcile the amount due; principal may remain deployed. | Borrower + ops |
Next cycle | Review results, process eligible exits, approve continuation and report. | Underwriter + ops |
5.6 Withdrawals and callbacks
Plan lender exits before accepting funding. A standard withdrawal requested between loan periods ordinarily settles after the following loan period. A request queued during an active period waits for the next eligible processing window; joining the queue does not make payment immediate.
Underwriter: communicate the route, notice and expected payment date. Borrower: include due withdrawals in the treasury plan. Operations: distinguish requests awaiting processing from claims already funded, and confirm the cash actually available to pay.
Inspect the code · Withdrawal requests and claims
requestWithdraw()Convert a tranche position into an eligible standard or conditional accelerated request.
IdleCDOEpochVariant.sol· lines 739–791claimWithdrawRequest()Claim through the strategy after the applicable settlement conditions are met.
IdleCDOEpochVariant.sol· lines 967–971processWithdrawRequests()Activate queued requests during the eligible processing window.
IdleCDOEpochQueue.sol· lines 298–329processWithdrawalClaims()Collect settled proceeds for queued withdrawal claims.
IdleCDOEpochQueue.sol· lines 334–369
A rate reduction may enable a conditional accelerated exit where configured. It is not unconditional instant liquidity. Agree the applicable notice and funding timetable; the agreement’s Business Days and the system’s timing must be reconciled.
Inspect the code · Conditional accelerated exits
_isInstantWithdrawEnabled()Inspect the eligibility switches; programmable-borrower mode disables this path.
IdleCDOEpochVariant.sol· lines 839–841getInstantWithdrawFunds()Collect the borrower cash needed for pending accelerated requests after their deadline.
IdleCDOEpochVariant.sol· lines 558–574
For a callback, confirm the contractual right, valid notice, amount, fees and settlement deadline. A lender’s callback escrow offer is a separate step: the price is fixed until cancelled and recreated, and the offer must be filled in full. The borrower or another buyer pays for the offered position; a borrower may then separately retire the acquired position. Do not count an unfilled offer as cash repaid.
Inspect the code · Callback escrow
The function name fullfillWriteOffRequest() uses the spelling in the contract. The escrow implements the token exchange, not the legal callback notice.
createWriteOffRequest()Escrow tranche tokens and record the requested underlying amount.
IdleCreditVaultWriteOffEscrow.sol· lines 86–102deleteWriteOffRequest()Cancel the offer and return the escrowed tranche tokens.
IdleCreditVaultWriteOffEscrow.sol· lines 105–116fullfillWriteOffRequest()Exchange the requested tranche amount for the required cash and deduct the configured exit fee.
IdleCreditVaultWriteOffEscrow.sol· lines 123–155writeOffDeposit()Borrower-only retirement of acquired tranche tokens; a separate step from buying them in escrow.
IdleCDOEpochVariant.sol· lines 936–963
5.7 Multiple currencies and the Orchestrator
Use a separate facility record for each vault: borrower, currency, chain, terms, lender claims and cash due. The Orchestrator lets an authorized operator coordinate supported actions across approved vaults. Operations must verify permission for every participating vault and check every outcome after execution.
It does not convert currencies, pool cash or automatically use one vault to cover another’s losses. A combined action may fail as a whole if one part fails; an allowed default outcome is not proof that all borrowers paid. Reconcile each currency separately, and review any contractual links or shared-borrower risk before describing facilities as independent.
Inspect the code · Multi-vault orchestration
This router coordinates calls. It does not exchange currencies, pool vault balances or prove that facilities are economically independent.
setCreditVaultAllowed()Manage the set of vaults the router may operate.
IdleCreditVaultManagerOrchestrator.sol· lines 67–71startEpoch()Start epochs across the supplied approved vaults.
IdleCreditVaultManagerOrchestrator.sol· lines 75–85stopEpochWithDuration()Batch close actions, with per-action checks on whether a default outcome is allowed.
IdleCreditVaultManagerOrchestrator.sol· lines 89–99_creditVaultQueue()Inspect how a queue’s reported vault linkage is checked against the allowlist.
IdleCreditVaultManagerOrchestrator.sol· lines 166–170
5.8 Loss, default and recovery
Raise an expected shortfall early. The borrower supplies the cause, available cash and a remediation plan. The underwriter records the assessment and follows the agreement’s notice, cure and enforcement process. Operations distinguishes a failed transaction from a recorded default; an operational error alone does not establish insolvency.
For a loss recognized while the facility continues, agree the valuation evidence and allocation before communicating revised balances. Pending withdrawal claims can also bear losses. Senior/junior protection for active positions must not be presented as a guarantee for every claim or recovery scenario.
If hard default is recorded, stop unsupported lending activity and reconcile affected positions, pending exits and previously funded claims. The reviewed recovery process finalizes once, using an approved recovery amount and source. It cannot simply be topped up later or restart lending. Operations must confirm the deployed process before execution.
The underwriter coordinates legal allocation and communications; the borrower supports recovery and evidence collection; operations verifies funding and claims. Previously funded claims and affected claims may receive different treatment. The reviewed hard-default process applies one recovery ratio to affected balances without automatic senior priority. Report actual proceeds and any remaining recovery steps clearly.
For an economic loss that does not constitute a hard default, the curator should first establish and document a defensible valuation using reliable evidence – such as audited NAV, an independent collateral valuation, or third-party marks – and share the loss methodology with lenders. At the end of the loan cycle, the curator can register the approved loss through the loss-enabled stopEpochWithDuration(_lossAmount) flow. This burns the corresponding strategy tokens and immediately reduces the vault’s virtualPrice, realizing the loss on-chain while allowing the Credit Vault to continue operating at the revised value. This path does not set defaulted = true.
For a hard default, the curator should treat the BorrowerDefault event as an immediate freeze of the facility. The current contracts pause the vault, prevent new deposits, withdrawal requests, and lending activity, and do not automatically reduce virtualPrice; downstream collateral integrations should therefore be informed not to rely on an automatic repricing. The curator should reconcile positions at the default boundary, distinguishing funded withdrawal claims, unfunded pending withdrawal claims, and remaining CV token holders, and should not resume ordinary operations until the recovery process is complete.
Recovery is primarily an evidence-led, offchain process: pursue borrower remedies, preserve the facility’s recovery record and communicate the expected treatment of each claim class. The owner or manager finalizes recovered funds through finalizeDefault(), with reserve and claim accounting handled by the strategy. This path covers affected active positions and pending claims; previously funded claims remain separately protected. Verify the deployed recovery mechanism and reconcile actual proceeds, remaining claims and next steps before execution.
Inspect the code · Loss recognition and hard default
stopEpochWithDuration()Supply a recognized economic loss through the supported epoch-close path.
IdleCDOEpochVariant.sol· lines 520–530previewLossAdjustedWithdrawFunds()Inspect how an ordinary loss is split between pending receipts and active positions.
IdleCreditVault.sol· lines 440–460_handleBorrowerDefault()Inspect the hard-default state change, pause and block on new withdrawal requests.
IdleCDOEpochVariant.sol· lines 577–599finalizeDefault()One-time recovery entry point that updates tranche values and enables the supported claim paths.
IdleCDOEpochVariant.sol· lines 194–225
Inspect the code · Recovery reserves and claim payments
Recovery is finalized once in this revision. The supplied recovery amount and source must be agreed and funded before the transaction.
finalizeDefaultRecovery()Pull the approved recovered amount into the strategy reserve and compute the shared recovery ratio.
IdleCreditVault.sol· lines 661–710_claimDefaultedWithdrawRequest()Calculate and pay an affected pending withdrawal claim.
IdleCreditVault.sol· lines 772–784_claimPostDefaultWithdrawRequest()Pay a later request from an active holder using the already-adjusted position value.
IdleCreditVault.sol· lines 760–767_transferFundedClaim()Protect the recovery reserve when paying previously funded claims.
IdleCreditVault.sol· lines 897–907
Section 06
6. Distribution & Bootstrap Strategy
The underwriter coordinates capital formation within its mandate. The borrower supports diligence and funding readiness. Initial capital helps establish operating history; it does not replace credit approval or guarantee later lender demand.
6.1 Bootstrap Options
- Borrower seed: the borrower may invest alongside lenders under disclosed terms. Record whether it has the same rights or a junior position; seed capital alone does not establish first-loss protection.
- Anchor lender: agree a meaningful initial commitment, eligibility, funding timing and any differentiated terms. Do not assume a fixed percentage of the cap or promise priority that the facility does not provide.
- Phased cap: begin at the approved launch size and review increases only after performance, reporting, borrower need and liquidity support the change.
6.2 LP-Facing Materials Checklist
- One-pager / Facility Summary (see Appendix A template).
- Risk Summary: credit support type, key risks, mitigants, covenant summary.
- Reporting Cadence: what LPs receive, when, and in what format.
- Scaling criteria: repayment history, covenant compliance, reporting quality and lender liquidity; every cap increase requires approval.
6.3 A Staged Launch-to-Scale Plan
Milestone | Evidence | Decision |
|---|---|---|
First cycle | Funding and settlement reconciled | Continue only within approved terms |
Initial reporting | Timely data and covenant review | Resolve gaps before expansion |
New lenders | Eligibility and funding readiness | Admit under approved access terms |
Scale review | Payment history, liquidity and demand | Maintain, expand or reduce the cap |
Section 07
7. The Launch Decision
The underwriter records the launch decision with borrower acceptance and operational sign-off. All required conditions must be GREEN before funds are released. YELLOW is a preparation status: document the owner and remedy, then resolve the condition or formally approve an allowed mitigation. RED blocks launch.
7.1 Readiness Table
Status | Criteria |
|---|---|
GREEN | KYB / AML onboarding completed and approved for all counterparties. Agreed credit support and enforcement arrangements finalized and reviewed. Reporting pack format, cadence, and delivery method agreed with borrower and LPs. Test settlement completed successfully (deposit, accrual, repayment, withdrawal). MLA and all legal documentation fully executed. Allowlist configured and tested (borrower + initial LP wallets). Distribution plan confirmed with seed/anchor capital committed. |
YELLOW | A preparation item remains open. Record its remedy and owner; examples to resolve: Financial information: identify any missing evidence and whether approved alternative evidence is sufficient. Funding: confirm that committed, eligible capital covers the planned launch size. Reporting: finish the delivery format and confirm the borrower can meet the agreed cadence. Terms: resolve material covenant thresholds and borrower obligations before launch. Record each open item, owner and target resolution date. YELLOW alone does not authorize funding. |
RED | Any of the following present – DO NOT PROCEED: • Borrower entity unclear, unverified, or in sanctioned jurisdiction. • No financial reporting capability or borrower refuses reporting commitments. Material legal authority, repayment support or enforcement arrangements remain unresolved. • Settlement testing failed or incomplete. • MLA or legal documentation not executed. Withdrawal or callback terms are not aligned with tested operational routes. • Material unresolved red flags from diligence (Section 4.3). |
7.2 Decision Memo Template
Prepare a short decision memo that both parties can use for handover:
- Borrower: [Entity name], [jurisdiction], [business description]. KYB status: [Approved/Pending].
- Facility Terms: [Size], [rate], [cycle length], [credit support type]. Key parameters per Section 3.
- Diligence: evidence reviewed, key findings, residual risks and the underwriter’s approval.
- Readiness: each launch condition, supporting evidence, any approved mitigation and remaining preparation items.
- Decision: GO or NO-GO for funding; approver and approval date, borrower acceptance and operations sign-off.
Section 08
8. Appendix
Appendix A: Credit Facility Summary Template (LP-Facing)
Field | Value |
|---|---|
Facility Name | [Name of Credit Vault] |
Underwriter | [Underwriter entity name] |
Borrower | [Borrower entity name, jurisdiction] |
Facility Size | [Target cap, e.g., $5M USDC] |
Interest Rate | [Fixed/Variable, rate %] |
Cycle Length | [e.g., 14 days] |
Credit Support | [Unsecured + guarantee / Collateralized + type] |
Key Covenants | [Summary of material covenants] |
Reporting | [Monthly; includes NAV, exposures, P&L, covenant checks] |
Eligibility | [KYB required; private placement; jurisdiction restrictions] |
Track Record | [N cycles completed; repayment rate; utilization] |
Contact | [Underwriter contact email] |
Appendix B: Borrower Data Request List
- Certificate of Incorporation / Registration (certified copy).
- Ownership and control chart, with UBO information required by the approved policy.
- Identity documents for relevant owners/controllers and authorized signers, as required.
- Most recent audited financial statements (or management accounts if audit unavailable).
- Description of business model, revenue sources, and intended use of facility proceeds.
- Bank account details for fiat settlement (if applicable).
- Wallet addresses to be bound to the entity.
- Signed MLA / legal documentation.
- Guarantee letter or collateral pledge documentation (as applicable).
- Insurance certificates (if applicable).
- List of material litigation, regulatory actions, or pending proceedings.
- Contact details for CFO / finance lead and legal counsel.
Appendix C: Sample Term Sheet Skeleton (Headings Only)
Note: These are structural headings only. No legal clauses are provided. Consult legal counsel for drafting.
- Parties (Underwriter, Borrower, Pareto as Infrastructure Provider)
- Facility Description (Type, Size, Currency)
- Interest Rate and Fee Structure
- Loan Cycle Mechanics (Draw, Repay, Rollover)
- Credit Support (Guarantee / Collateral / Unsecured)
- Covenants (Financial, Reporting, Operational)
- Eligible Lender Criteria and KYB Requirements
- Withdrawal and Callback Mechanics
- Events of Default and Remedies
- Reporting Obligations
- Representations and Warranties
- Governing Law and Dispute Resolution
- Confidentiality
- Miscellaneous (Amendments, Notices, Assignment)
Appendix D: Frequently Asked Questions
How long does it take to launch a facility from start to finish?
Timing depends on diligence, documentation, eligibility and deployment testing. Agree a plan after the initial review; the quickstart is a sequence of steps, not a promise of launch in minutes or a fixed number of weeks.
Can an Underwriter run multiple facilities simultaneously?
Yes, subject to capacity, approved terms and permissions. Keep records for each vault. The Orchestrator can coordinate supported actions but does not pool different currencies or make one vault cover another’s losses.
What happens if a borrower misses a repayment?
The borrower promptly explains the shortfall and provides a cash plan. The underwriter applies the agreed notice and remedy process; operations checks whether settlement failed or a default was recorded. Recovery is handled separately from a normal rollover.
Who is liable if a borrower defaults?
Responsibilities and liability follow the executed agreements and the circumstances. Pareto provides infrastructure; the underwriter makes the credit decision. The playbook does not replace the facility’s legal allocation of obligations.
Can facility parameters be changed after launch?
Only through the agreed approval and amendment process, with any required lender notices or consents. Operations then applies supported changes and verifies them. A commercially agreed change is not complete until the operational records match.
How does on-chain settlement work?
The Credit Vault records the supported movements in its configured asset. At a rolling close, the borrower pays the amount due under that mode; not all principal necessarily returns. Confirm actual receipts rather than treating accrued value as available cash.
What reporting does Pareto provide vs. what the Underwriter must produce?
The borrower supplies financial and operational data. Pareto’s tools support on-chain records and exports where available. The underwriter reconciles both, reviews covenants and prepares the lender report. Confirm the available integrations for the facility.
Appendix E: Glossary
Term | Definition |
|---|---|
Credit Vault | A smart-contract-based facility on Pareto that manages deposits, loans, repayments, and withdrawals for a specific credit facility. |
KYB (Know Your Business) | Entity-level verification process covering corporate registration, UBO identification, sanctions screening, and compliance approval. |
UBO (Ultimate Beneficial Owner) | The people who ultimately own or control the entity; identification thresholds and evidence follow the applicable policy. |
Allowlist | The approved wallets and eligibility settings for particular actions. Check the live configuration; a label alone is not proof of access control. |
MLA (Master Loan Agreement) | The executed agreement governing the facility’s parties, economics, covenants, notices and remedies. |
TVL (Total Value Locked) | The total capital deposited in a Credit Vault or across the platform. |
NAV (Net Asset Value) | The current value of the facility, accounting for outstanding loans, accrued interest, and cash. |
On-Chain | A transaction or record on the selected blockchain. It must still be reconciled to the agreement and off-chain evidence. |
Smart Contract | Code that performs supported actions when called with the required permissions and conditions; a calendar deadline alone does not execute a payment. |
USDC | A USD-pegged stablecoin commonly used for settlement in on-chain credit facilities. |
DeFi (Decentralized Finance) | Financial services built on blockchain infrastructure, enabling peer-to-peer transactions without traditional intermediaries. |
RWA (Real World Assets) | Traditional financial assets (loans, bonds, receivables) represented or tokenized on-chain. |
PEP (Politically Exposed Person) | An individual who holds or has held a prominent public function, subject to enhanced due diligence. |
Callback | A contractual early-repayment right or related exit process. Distinguish a facility notice from a lender’s escrow offer; see Section 5.6. |