Stablecoin lending vault

A stablecoin lending vault accepts one stablecoin, supplies it to an approved lending market, and gives depositors vault shares whose value follows the vault’s net claim on that market.

This is a generic educational composition, not a recommendation or a model of one deployed vault. The exact stablecoin, lending market, fees, controls, and loss allocation must be checked for each implementation.

Objective and system boundary

The objective is to package lending exposure behind one user-facing claim. Users do not lend directly to individual borrowers. They deposit a stablecoin into a vault; the vault’s strategy supplies that asset to a lending pool. The composition ends at the stablecoin issuer and reserve system, the lending market, its collateral and oracle dependencies, and every authority that can change or interrupt those components.

Depositor --stablecoin--> Vault --stablecoin--> Lending pool --stablecoin--> Borrower
Depositor <--vault share-- Vault <--supplier claim-- Lending pool <--repayment + interest-- Borrower

The arrows describe different assets and claims. A vault share is a pooled share, not the stablecoin itself. The lending supplier position is a debt claim and conditional redeemable claim, not idle stablecoin cash.

Layer mapping

Table: Layer mapping

System layer	Component	Economic role
Money and assets	Stablecoin	Deposit, loan principal, repayment, and accounting unit
Core primitive	Lending pool	Matches pooled supply with collateralized borrowing and interest accounting
Strategy	Approved-market supply strategy	Allocates vault capital to the selected pool and manages entry, exit, and reporting
Product	Vault	Packages strategy execution, share accounting, limits, fees, and redemption
User claim	Vault share	Pooled share of eligible vault net assets under the vault’s rules
Underlying claim	Lending supplier position	Debt claim on pool cash, borrower repayment, reserves, and recognized losses

The product does not create a new external source of return. It packages the return and risks of the underlying lending position.

Actors, assets, claims, and obligations

Table: Actors, assets, claims, and obligations

Actor	Asset controlled or action taken	Claim or obligation
Depositor	Transfers stablecoins to the vault	Holds vault shares and any pending withdrawal claim
Vault	Controls idle stablecoins and the supplier position	Owes shareholders their rule-based portion of eligible net assets
Strategy manager or keeper	Routes supply, withdrawal, reporting, and emergency actions	Must stay within authorized markets, caps, and loss limits
Lending pool	Controls supplied cash, collateral, borrower debt, reserves, and accounting	Owes the vault a supplier claim subject to liquidity and loss rules
Borrower	Receives stablecoins and posts collateral	Owes principal and interest; collateral may be liquidated
Liquidator	Repays unsafe debt and receives permitted collateral	Has no claim beyond the executed liquidation terms
Oracle and market-data path	Provides values used for collateral and liquidation decisions	Creates a trusted input dependency, not a financial claim
Governance, guardian, or admin	Changes parameters, pauses, lists assets, or upgrades code	Exercises disclosed control rights over users’ positions

The vault balance sheet contains both idle stablecoins and a layered supplier claim. Borrower debt and collateral sit inside the lending pool rather than directly on the vault’s balance sheet, but their performance determines the value and liquidity of the vault’s claim.

Step-by-step mechanism

1. Deposit. A user transfers stablecoins to the vault under a deposit cap, allowance, fee, and minimum-share constraint.
2. Mint the user claim. The vault calculates and mints shares using the pre-deposit share value and its explicit rounding rule.
3. Deploy capital. The strategy supplies idle stablecoins to an approved lending pool and records the supplier claim actually received.
4. Lending transforms the capital. Eligible borrowers pledge collateral, borrow pool liquidity, and accrue debt under the market’s rate model.
5. Recognize return. Borrower interest increases lending-pool assets and the vault’s supplier claim after protocol reserves or fees.
6. Report value. The vault recognizes idle cash, the realizable supplier claim, liabilities, impairment, and vault fees in net asset value.
7. Repay or liquidate. Borrowers repay voluntarily, or liquidators repay unsafe debt in exchange for permitted collateral. Any unrecovered debt must be assigned to reserves, backstops, suppliers, or another explicit bearer.
8. Redeem. A share holder burns shares. The vault uses idle cash or withdraws from the lending pool, then transfers no more than the holder’s executable net entitlement.

The six connecting flows

Table: The six connecting flows

Flow	Trace through this composition	What must remain inspectable
Capital flow	Depositor → vault → lending pool → borrower; repayment returns in reverse	Token identity, amount, recipient, available cash, fees, and actual balance changes
Claim flow	Vault share points to vault net assets; supplier position points to the lending pool; borrower debt points back to pool assets	Issuer, holder, backing, seniority, conversion, mint, burn, and impairment rules
Information flow	Stablecoin status, collateral prices, utilization, rates, balances, caps, and loss reports feed decisions	Source, units, decimals, freshness, validity, and failure behavior
Return flow	Borrower interest → lending pool supplier allocation → vault NAV → vault-share value	Borrower as payer, protocol reserve, vault fee, compounding period, and net result
Control flow	Vault roles select markets and limits; lending governance controls listings and risk parameters; stablecoin authorities control issuer-side powers	Proposer, approver, executor, delay, pause, upgrade, recovery, and user exit window
Risk flow	Depeg, bad debt, illiquidity, oracle error, contract failure, or control misuse → supplier claim → vault NAV or redemption → depositor	Trigger, propagation path, reserves or backstop, recognition time, and final loss absorber

These labels are part of the meaning. The composition does not rely on color to distinguish one flow from another.

Balance sheets and state transitions

The simplified accounting identity is:

vaultNetAssets = idleStablecoins
               + realizableSupplierClaim
               - recognizedLiabilities

Share value is then:

shareValue = vaultNetAssets / eligibleVaultShares

Both expressions require a valuation time, unit, recognition policy, eligible share supply, and rounding rule. “Realizable” also requires a loss and liquidity assessment; a displayed supplier balance may not be immediately withdrawable.

Table: Balance sheets and state transitions

Event	Vault assets	Vault liabilities or claims	Lending-pool state
User deposits 100,000 units	Stablecoins increase by 100,000	Vault shares increase by the fair pre-deposit amount	No change yet
Strategy supplies 100,000 units	Idle cash falls; supplier claim rises by the received amount	Vault shares do not change	Pool cash and supplier obligations rise
Borrower draws 70,000 units	Supplier claim remains, but its liquidity composition changes	Vault shares do not change	Pool cash falls; borrower debt rises
Interest accrues and is paid	Supplier claim or idle cash rises by the vault’s net allocation	Fee liability may rise; share supply changes only if the fee model mints shares	Borrower debt and pool assets reflect interest and reserves
Bad debt is recognized	Realizable supplier claim falls unless a reserve absorbs it	Share value falls unless another explicit bearer covers the loss	Unrecoverable debt is charged according to pool rules
Holder redeems	Idle cash or supplier claim falls by executable assets paid	Burned shares and related claim disappear	Pool cash falls if the vault withdraws

Numerical return example

Assume, only for this arithmetic example:

• the vault starts with 1,000,000 stablecoin units and 1,000,000 eligible shares;
• one user deposits 100,000 units with no deposit fee and receives 100,000 shares at the pre-deposit value of 1.00;
• the vault then has 1,100,000 units of net assets and 1,100,000 shares;
• over the period, its supplier claim increases by 55,000 units after the lending protocol’s reserve allocation but before the vault fee; and
• the vault charges a 10% performance fee on that 55,000-unit gain, recognized here as a 5,500-unit liability rather than fee shares.

Table: Numerical return example

Measure	Calculation	Result
Gross lending return	given supplier-claim increase	55,000 units
Vault performance fee	55,000 × 10%	5,500 units
Net gain for shareholders	55,000 − 5,500	49,500 units
Ending vault NAV	1,100,000 + 49,500	1,149,500 units
Ending share value	1,149,500 ÷ 1,100,000	1.045 units per share
New depositor’s modeled value	100,000 × 1.045	104,500 units

The depositor’s 4,500-unit modeled gain is a proportional allocation of net borrower interest. It is not guaranteed yield and is not necessarily the amount immediately redeemable after withdrawal limits, rounding, fees, or pool illiquidity.

Return path

Borrower pays interest
→ lending pool allocates supplier interest after its stated reserve or fees
→ vault's realizable supplier claim grows
→ vault recognizes fees and liabilities
→ vault NAV per eligible share grows
→ depositor may realize value by an executable redemption

Borrowers are the economic payer. Token incentives, if present, are a separate issuance-based return and must not be silently combined with borrower interest. The lending protocol and vault fee recipients take only the amounts authorized by their respective accounting rules.

Loss and delay paths

Credit shortfall

Collateral value falls or liquidation execution fails
→ borrower debt exceeds recovered collateral and applicable backstops
→ lending pool recognizes bad debt
→ vault's supplier claim is impaired
→ vault NAV per share falls
→ depositors absorb the remaining loss

For example, a 44,000-unit impairment with no reserve or other liability would reduce a 1,100,000-unit vault to 1,056,000 units, or 0.96 per share. The user in the separate starting scenario would hold 100,000 shares modeled at 96,000 units. A reserve changes who bears the first loss; it does not make the loss disappear.

Withdrawal illiquidity

If the vault has 1,100,000 units of valid NAV but only 100,000 units can be withdrawn from idle cash and the lending pool now, a 200,000-unit redemption is not immediately executable. That is a liquidity shortfall, not by itself proof of insolvency. Queues, caps, pro-rata rules, and emergency powers determine who waits and whether some holders can exit ahead of others.

Stablecoin depeg or issuer failure

If the stablecoin trades or redeems below the vault’s reporting unit, both loan principal and the vault’s supplier claim can be worth less in that unit. The effect depends on the stablecoin’s backing, redemption access, borrower collateral, oracle choice, and whether liabilities are denominated in tokens or reference-value units.

Control and dependency boundaries

Before treating the vault share as “stablecoin plus yield,” inspect:

• who can choose or replace the lending market, set allocation limits, harvest, pause, migrate, charge fees, recover tokens, and upgrade the vault;
• who can list collateral, set loan-to-value and liquidation parameters, change rate models and caps, use reserves, pause, or upgrade the lending market;
• which oracle prices collateral and whether the stablecoin peg is assumed, measured, capped, or used as a fixed unit;
• whether the stablecoin issuer, custodian, administrator, or contract can freeze, blacklist, mint, redeem, or change backing arrangements; and
• which assets remain liquid under simultaneous borrower demand, depositor withdrawals, liquidations, market stress, and chain congestion.

The canonical concept graph already connects the vault and lending pool to governance risk, oracle risk, liquidity risk, solvency risk, and accounting risk. This page explains one path through those relationships; it does not define a second graph.

Protocol and standard context

The ERC-4626 specification standardizes an interface in which shares represent a claim on a vault’s underlying holdings. It deliberately does not standardize the strategy, and it distinguishes display estimates from operation-specific previews and limits. Conformance therefore does not prove that this composition’s valuation, liquidity, integration, or loss allocation is safe.

Aave’s supply guide provides one current protocol example of assets entering a lending pool, becoming available to overcollateralized borrowers, and accruing supplier interest under utilization-sensitive parameters. The worked composition above is generic: it does not claim that every lending market uses Aave’s contracts, accounting, governance, rates, collateral rules, or recovery mechanisms. The Aave guide was reviewed 2026-08-10.

Security properties to test or verify

These are desired properties, not claims that an implementation has been formally proven:

• deposits mint no more shares than contributed net value permits under the selected pre-deposit price and rounding rule;
• withdrawals burn the corresponding claim and transfer no more than the holder’s executable entitlement;
• idle assets, supplier positions, recognized loss, fees, liabilities, queued claims, and eligible share supply reconcile after every transition;
• strategy calls stay within approved assets, markets, recipients, allowances, caps, and loss limits;
• supplier-claim value cannot be treated as liquid cash when withdrawal is unavailable or impaired;
• bad debt, depeg, fee, reserve use, donation, rounding, and emergency actions cannot remain hidden from NAV and share ownership; and
• every governance, guardian, admin, oracle, keeper, and upgrade path is disclosed and bounded by its promised authorization and delay.

Common misunderstandings

• “The vault pays the yield.” The vault packages and accounts for return; borrowers pay lending interest, while separate incentives may come from token issuance.
• “A stablecoin vault has a stable share price.” The underlying token can depeg, the lending claim can be impaired, and fees or accounting can change value per share.
• “NAV equals cash available now.” NAV is a valuation measure. Redemption also depends on executable lending-pool liquidity, limits, queues, and costs.
• “Overcollateralized lending cannot create bad debt.” Price gaps, oracle failure, congestion, thin liquidity, parameter error, or failed liquidation can leave debt unrecovered.
• “One audited component makes the composition safe.” The vault, stablecoin, lending market, collateral, oracle, governance, and their integrations create transitive assumptions.

Review checklist

1. Which token is deposited, and what direct or indirect redemption rights does it provide?
2. Which contract issues each vault, supplier, debt, and pending-withdrawal claim?
3. Who pays each return component, and who receives every fee?
4. Which prices, units, decimals, timestamps, caps, and liquidity assumptions affect state transitions?
5. Who can change the vault, lending market, stablecoin, oracle, or recovery rules, and how much notice do users receive?
6. Which reserve or backstop bears first loss, and which shareholders bear the remainder?
7. Can the displayed share value actually be redeemed in the required size and time?

Continue with vault share, utilization and interest rates, bad debt, and yield strategy.