Today's single-LP limitation

This page describes the program before Phase 4, and is owed a rewrite

The require! it is written about has been removed. Phase 4 took the single-LP rule out of lp_deposit, last of five slices, once time-based accrual, non-accrual on default, the FIFO withdrawal queue and pool_recovery_deposit were all in — the four mechanisms that make a second lender safe rather than a source of free money at the first lender's expense.

Two things are still true and are the reason this page has not simply been deleted. pool.admin is written exactly once and there is still no way to replace it, and with the deposit gate gone that is sharper rather than softer: a pool admin can now hold strangers' money and nobody can appoint a successor. Phase 4 acts on it in exactly two places — the queue's creation and the accrual backfill are both permissionless, so no pool can be stranded behind a lost key — and nowhere else.

The lender-facing copy for a queued withdrawal is now written: Withdrawals describes the request-process-cancel queue, what a partial fill does to your place in it, and which of the two pause flags can hold your exit shut. Nothing has been deployed, so what is live today still behaves as the body of this page describes.

Milky's pool model is designed to support many LPs depositing into the same pool, with shares issued at the prevailing price per share (PPS). The share math and the net asset value (NAV) accounting are written for multiple positions per pool. One on-chain path is not, and it is described further down.

However, the on-chain lp_deposit instruction currently enforces a single-LP constraint: only the wallet that initialized the pool — the pool admin — can deposit USDC into it. A second wallet attempting to deposit will be rejected by the program.

It is worth being precise about how firm that is, because "currently" can read like a setting somebody could change. It is not:

lp_deposit carries require!(lender.key() == pool.admin, Unauthorized).
pool.admin is written exactly once, in pool_init, and marked immutable post-init. There is no field for it on PoolUpdatableParams and no admin-transfer instruction anywhere in the program.

So the set of wallets that can fund a pool is fixed at the moment the pool is created, and changing it takes a program redeploy — not a configuration change, not a signature from anyone. Every LP on Milky today is the admin of the pool they are lending into.

This page exists so anyone evaluating Milky as an LP knows about the limitation up front.

Why the constraint exists

Two reasons were behind introducing it, both temporary. A third one held until August 2026 and has since been resolved — see the blocker this page used to describe below:

Operational maturity. A multi-LP pool is a stronger guarantee surface: deposits and withdrawals from a wider set of wallets, more diverse risk profiles, and broader expectations about uptime and withdrawal liquidity. The team is intentionally validating the underlying mechanics in a single-LP setting before opening up.
Risk isolation. With a single LP funding each pool, any operational or oracle hiccup in early deployments is contained to that LP. As the protocol's track record matures, opening multi-LP deposits becomes a more reasonable risk to take.

What the multi-LP path will look like

When the constraint is lifted, most of the model documented in the rest of the lending section becomes live as written:

Anyone can deposit USDC into a pool that accepts it.
Shares are minted at the current PPS, so new depositors don't dilute existing positions.
Shares are burned for USDC at the current PPS at withdrawal time, with no fixed-term lockup on the LP position itself (only the underlying loans are time-locked).
Yield and protocol-fee mechanics are unchanged.

Default recovery used to be the exception, and it was not a small one. The next section is about why, and about why it no longer is.

The blocker this page used to describe has been removed

This page previously argued that removing the single-depositor check was only half the job, because of a second problem in the program. That problem was real, and it has since been fixed by deleting the instruction that caused it. The history is kept here because the argument is the reason the fix happened, and because anyone reading an older snapshot of this page needs to know which half is out of date.

What the problem was. Until August 2026, pool_admin_claim_defaulted_collateral let a pool admin take a defaulted card instead of selling it. When they did, the program moved the pool's books down by the full debt, transferred the card to an associated token account owned by the pool admin personally, and took no payment into the pool for it. There was no way back: the instruction closed the Loan, so no later auction was possible.

Under the single-depositor rule that netted out exactly — the wallet losing the debt and the wallet gaining the card were the same economic entity. Remove the rule and it stopped netting out. It became a free option for the pool admin to take any defaulted card worth more than nothing, while every other LP absorbed the written-off debt pro rata through NAV, with the admin choosing which defaults to exercise it on after seeing the card and the market.

What was done about it. ADR-004 deleted pool_admin_claim_defaulted_collateral outright, along with pool_admin_withdraw_nft, which was the other route from a defaulted card to a pool admin's wallet. Neither instruction exists in the program. A defaulted card is now sold by Milky, and every pool admin — with one LP or a hundred — receives the same thing an ordinary LP does: cash, capped at principal plus interest.

The deletion was not made for this reason. It was made because the claim path also defeated the borrower's right to the residual: while it existed, one transaction from the lender the moment grace expired decided the outcome of a default, and the promise to the borrower was worth whatever the lender chose to leave them. Fixing that fixed this too.

So the second prerequisite is closed. Lifting the single-LP constraint is now the deposit check and the pooled-accounting work described below, and nothing about default recovery.

What is still outstanding

Multi-LP deposits are Phase 4 of the protocol roadmap, and the deposit check is deliberately the last thing removed rather than the first. Depositing into a pool with drawn loans, under accounting that recognises interest at draw rather than over time, would let a late depositor capture a full term's interest they were never exposed to. The ordering is: time-based accrual, non-accrual and reversal on default, a withdrawal queue priced at processing, a cash reserve — and then the gate comes out.

What this means for the rest of these docs

Sections like LP shares & NAV and Yield, utilization & risks describe the designed model with multiple LPs and a moving PPS. Read them with the access control on lp_deposit in mind: it is what stops you depositing today.

What you can do today

Borrow against your cards on existing pools (this surface is open and unaffected by the limitation).
Watch the public roadmap for the multi-LP rollout announcement.
Reach out if you're an institutional LP interested in operating your own pool — the single-LP model is a good fit for partner-operated pools where one entity wants concentrated exposure.