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

Pools

A pool in Milky is the unit of capital that funds loans. Each pool is its own on-chain account with its own USDC vault, its own configuration parameters, and its own LP positions. A loan always belongs to exactly one pool, and a pool can fund many loans simultaneously up to its utilization cap.

There is no single global pool. Instead, pools exist as long as they are useful for segmenting risk between different kinds of collateral, term profiles, or operator preferences.

How pools segment risk

Pools segment risk through three independent levers, each of which the pool admin sets at creation time and (for some) can update later.

Allowlists

Each pool publishes an explicit list of collections it will accept as collateral. A loan request against a card from a non-allowlisted collection is rejected at the on-chain create step.

This means a pool can be narrow ("high-grade Pokémon TCG only") or broad ("Pokémon TCG plus the four major sports"), and the LP knows what exposure they're taking on by depositing into that pool.

Per-asset-type exposure caps

Within a pool, the protocol tracks outstanding principal per canonical asset type (a cert + grader + grade identity). A pool admin sets a max_exposure_per_type, and the protocol refuses to draw a new loan that would push that asset type over the cap.

This prevents quiet over-concentration. Without the cap, a pool could end up with 60% of its principal in a single Pokémon Charizard variant; the exposure cap ensures the pool is forced to spread risk across many different cards.

Per-card principal cap and LTV ceiling

In addition to the exposure cap, the pool sets:

  • A max_principal_per_card — the absolute USDC ceiling for a single loan against any single card.
  • A max_ltv_bps — the maximum LTV the pool will accept, capped above by the protocol-wide ceiling of 90%.

Together these mean even if a card is priced very high by the oracle, the pool can still cap its single-loan exposure.

How pools relate to borrowers

When you borrow on Milky, you pick a pool that:

  • Accepts the collection your card belongs to.
  • Offers a term option matching the term/rate you want.
  • Has enough headroom under its utilization cap and per-asset-type cap to fund your principal.

The Milky app filters available pools for your card automatically.

How pools relate to lenders

When you lend on Milky, you deposit into a specific pool. Your share of the pool's NAV is denominated in shares of that pool — there is no cross-pool sharing of yield or risk. If one pool has a bad month, only its LPs are affected.

(See the single-LP note for the current constraint that only the pool admin can deposit.)

Pool lifecycle

A pool moves through a simple lifecycle:

  1. Initialize

    The pool admin calls pool_init with the full parameter set: quote mint, term options, LTV ceiling, principal limits, exposure cap, utilization cap. Some parameters (the admin wallet, the quote mint) are immutable from this point on.

  2. Configure allowlist

    The admin adds AllowedCollection entries for the collections this pool will accept. Without at least one entry, the pool can only fund loans against NFTs without a verified collection.

  3. Operate

    LPs deposit (today: only the admin), borrowers open and repay loans, keepers settle defaults via auction. The pool continuously updates its accounting: outstanding principal, accrued interest, accumulated protocol fees, LP shares.

  4. Update parameters

    The admin can adjust mutable parameters (LTV ceiling, term options, exposure cap, etc.) via pool_update_params. Some parameters have monotonicity constraints (e.g. the exposure cap can be raised but not set to zero).

  5. Pause if needed

    The admin (or, for the global pause, the protocol governance) can halt new loans and new deposits without freezing existing loans or blocking LP withdrawals.

There is no explicit "close pool" instruction; a pool simply runs down to zero shares and zero outstanding principal naturally.

Multiple pools, multiple shapes

Production deployments typically run multiple pools in parallel with different risk profiles:

  • A broad allowlist, low LTV pool that accepts many collections at conservative LTVs and shorter terms.
  • A narrow allowlist, higher LTV pool focused on a specific high-end collection where the operator has deep expertise.
  • A partner-operated pool where a specific institution provides liquidity to a curated allowlist they care about.