An onchain lending system connects lender claims, borrower obligations and collateral controls through deterministic accounting. Its design must handle interest, rounding, withdrawals, collateral valuation and losses under changing liquidity. This guide develops a proposed architecture for that lifecycle, including how delayed-redemption assets differ from immediately tradable collateral. It describes technology design, not an offer to lend or borrow.
Separate claims, cash and collateral
A lending market contains different kinds of value. Suppliers hold claims on a pool. Borrowers owe principal plus accrued interest. The pool holds immediately transferable cash and may hold receivables or collateral after liquidation. Treating all of these as one balance obscures whether the system can meet a withdrawal now.
Start with an accounting identity that relates assets, liabilities, reserves and recognized losses. State which amounts are measured in underlying units and which are shares. Define how an interest payment changes supplier claims and protocol reserves, and how bad debt changes the value of those claims. A donation to a contract address must not silently become borrower collateral or repayment.
Collateral also needs a clear custody model. A deposit may remain as the original token, become a vault share or enter a restricted adapter. Each option changes what the market can transfer during repayment or liquidation. Supporting an ERC-20 interface alone does not establish that a token is safe or usable as collateral.
Price utilization without promising immediate withdrawal
Utilization compares borrowed value with an agreed measure of lendable capital. The exact denominator matters when a market contains reserves, pending withdrawals or recognized losses. A rate curve can encourage repayment and new supply as utilization rises, but an interest-rate change cannot instantly create settlement liquidity.
Withdrawal design therefore needs its own policy. A market might permit withdrawals only from available cash, maintain a liquidity buffer, or introduce a queue. Specify whether queued claims continue earning interest, whether they can be cancelled, and what happens when new deposits arrive. Avoid letting a new supplier unknowingly fund preferential exits for another class of claim.
Rate changes also affect liquidations. A position close to its maintenance boundary can become unsafe through accrual even when its collateral price is unchanged. Risk monitoring must project obligations over the time required to execute a recovery. A cap on new borrowing may be more direct than relying exclusively on a steep rate curve during stress.
Translate collateral policy into enforceable limits
Collateral admission should examine executable liquidity, price-feed behavior, transfer restrictions and operational dependencies. A stable reference price says little about whether a large position can be sold during a stressed market. A tokenized fund may have an orderly redemption route but no immediate permissionless buyer.
| Control | Engineering question |
|---|---|
| Borrow cap | How much debt can this market create? |
| Collateral cap | How much exposure can the exit route absorb? |
| Concentration limit | Which issuer or dependency can dominate the pool? |
| Isolation boundary | Which other accounts can bear a shortfall? |
| Oracle policy | Which operations remain valid with stale data? |
For cross-collateral accounts, evaluate all obligations together. For isolated markets, verify that shared liquidity, fees or reserves do not create an undocumented path for losses to cross the boundary. The implementation should match the policy described to integrators.
Model redemption as an asynchronous credit exposure
The institutional design briefs introduce a useful architecture for assets with delayed issuer settlement. The asset enters a controlled position; a financing party supplies an immediate settlement asset; the issuer processes redemption; received proceeds repay the obligation. This is a proposed workflow whose implementation depends on issuer permissions, funding and the operating arrangement.
ERC-7540 provides a standard model for asynchronous vault requests and claims. It can inform an adapter interface, but it does not guarantee issuer settlement or eliminate credit exposure. The lending ledger still needs to track the request, reserved asset, expected settlement window and received amount.
A delayed request should remain visible as open exposure. If proceeds are partial, repayment should reflect actual receipt and leave a recoverable residual obligation. An acknowledgment must not release the asset and create cash simultaneously. Duplicate callbacks, changed recipient addresses and requests that expire after acceptance belong in the state-machine specification.
Specify loss recognition and recovery before a shortfall
A liquidation repays debt by realizing collateral value; it is not a guarantee that all debt will be covered. Define the recovery routes available for each asset and the conditions under which the protocol recognizes a shortfall. Delaying recognition can overstate supplier claim value and let early withdrawals transfer losses to remaining suppliers.
A proposed loss policy may include borrower equity, defined reserves and a separately committed backstop. Each layer needs a balance source, activation condition and limit. A named reserve with no funded assets is not recovery capacity. If losses eventually reduce supplier claim value, specify the accounting transition and test that withdrawals cannot bypass it.
Emergency settings should preserve useful recovery actions where feasible. Freezing new borrowing while permitting repayment is different from disabling every state change. The interface should expose the actual operating mode so integrators do not treat a failed transaction as an ordinary liquidity shortage.
Use tests that follow a market through stress
Validate normal accounting with an independent reference model, then explore adversarial sequences. Change prices, accrue interest, supply and withdraw, transfer collateral, liquidate partially and inject a settlement delay. Check conservation of value with an explicit rounding tolerance rather than comparing only the function's return value.
Token integration tests should cover rejected transfers, transfer fees, rebasing, changing decimals assumptions, blocked recipients and callback behavior where those token types are supported. Unsupported behavior should fail explicitly at admission or use. Fork tests help reveal real integration behavior, while local models let engineers explore extreme inputs reproducibly.
Operational acceptance should include a reconciliation report linking supplier claims, total debt, cash, reserves and losses at the same checkpoint. Monitor utilization, queue age, collateral concentration, overdue receivables and recoverable liquidation depth. A small, capped launch creates evidence for increasing limits; it does not remove the need to rehearse an orderly unwind.
Common engineering questions
Does a lending vault's total asset value equal withdrawable cash?
No. Total value can include outstanding loans or other receivables. Immediate withdrawals depend on available transferable assets and the market's withdrawal policy.
Can assets with delayed redemption support onchain lending?
They can be considered in a design that controls the asset, tracks redemption requests, finances the timing gap and defines delay and shortfall handling. This requires asset-specific integration and credit limits.
What does ERC-4626 standardize?
It standardizes a tokenized vault interface for assets and shares. It does not establish collateral quality, guarantee liquidity or prescribe a lending market's loss allocation.