DEVNETYou are on Solana devnet. Funds are not real. Behavior matches mainnet.

Today's single-LP limitation

Milky's pool model is designed to support many LPs depositing into the same pool, with shares issued at the prevailing PPS. The math, accounting, and on-chain structures all assume multiple positions per pool.

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.

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

Why the constraint exists

Two reasons, both temporary:

  • 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, the model documented in the rest of the lending section becomes live as-is:

  • 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, default-recovery, and protocol-fee mechanics are unchanged.

A small program upgrade is required to remove the single-depositor check; the rest of the system already accounts for the multi-LP case.

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. That model is correct in every detail except the access control on lp_deposit. Once the constraint is lifted, those pages describe production behavior end to end.

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.
  • Lending overview — the full LP model as designed.
  • Risks — including operational and governance risks worth understanding before depositing.