Pool parameters

This page is a reference for every parameter a MLKY pool exposes. It's useful both for would-be pool operators and for LPs and borrowers who want to understand exactly what a pool has committed to.

Parameters are grouped by what they control: liquidity, loans, fees, risk caps, and governance.

Liquidity & accounting

These parameters define how the pool holds and tracks capital.

Parameter	Meaning	Mutable?
`quote_mint`	The SPL token used for deposits, loans, and repayments. USDC in production.	No (set at init)
`quote_vault`	Program-derived address (PDA) holding the pool's idle USDC.	No (derived)
`total_lp_shares`	Sum of all outstanding shares across LP positions.	Auto
`outstanding_principal`	Sum of principal currently lent out.	Auto
`accrued_interest`	Interest recognized as belonging to the pool.	Auto
`protocol_fees_accumulated`	Fee revenue earmarked for the protocol (separate from LP net asset value, or NAV).	Auto

Loan terms

Each pool publishes up to three term options. A borrower picks one at loan creation; the term option fully determines duration, rate, and grace period.

Field	Meaning	Bounds
`term_secs`	Loan duration in seconds.	86,400 (1 day) to 31,557,600 (1 year)
`rate_bps`	Fixed annual percentage rate (APR) in basis points (10,000 = 100%).	Up to 22,000 (220%) per term
`grace_period_secs`	Time after maturity before default is eligible. Set to `min(term_secs, 7 days)`.	Up to 2,592,000 (30 days)

Pools typically advertise three options like 7d / 30d / 90d at progressively higher rates. The protocol does not require all three to be set; one or two options are valid configurations.

Principal & loan-to-value (LTV) limits

These are the per-loan ceilings that bound how much can be borrowed against a single card.

Parameter	Meaning	Protocol bounds
`min_principal`	Smallest allowed principal per loan.	Floor 1 USDC (1,000,000 micro-USDC)
`max_principal`	Largest allowed principal per loan.	Ceiling 1,000,000 USDC
`max_principal_per_card`	Per-card cap to prevent single-card concentration.	Pool-defined (within `max_principal`)
`max_ltv_bps`	Maximum LTV the pool will accept for any loan.	Up to 9,000 (90%); typical default 7,000 (70%)

The actual LTV applied to a given loan is the minimum of max_ltv_bps and the LTV the oracle returns in its signed quote. The oracle can be more conservative than the pool ceiling on a per-card basis.

Risk caps

The risk caps prevent quiet over-concentration as the pool fills up.

Parameter	Meaning	Protocol bounds
`utilization_cap_bps`	Max post-draw utilization (outstanding / net asset value). A limit on lending only — no withdrawal path reads it, so lowering it cannot hold a lender's capital.	Default 8,000 (80%); ceiling 9,500 (95%). Bounded above only: zero is legal and means "lend nothing more"
`max_exposure_per_type`	Max outstanding principal per canonical asset type.	Must be > 0; may move either way but never to zero
`recovery_floor_bps`	Retained, no longer read. Used to set the sale floor as a share of total debt.	1,000 (10%) to 10,000 (100%); default 5,000 (50%)
`max_fmv_micro_usdc`	Per-pool sanity ceiling on the fair market value (FMV) the oracle may attest for one card.	Must be > 0

TypeExposure accounts track running outstanding-principal-by-asset-type, and the protocol refuses any new draw that would push a given asset type over the cap.

The sale floor is no longer a pool setting. It is the defaulted loan's principal, and the starting price is the card's appraised value from the loan's oracle snapshot — both read from the loan, neither configurable.

Allowlists

Allowlists restrict which collections of NFTs can secure loans from this pool. They live in separate AllowedCollection PDAs, one per accepted collection mint, with an active flag the admin can toggle.

Parameter	Meaning
`AllowedCollection.collection_mint`	The Metaplex collection mint to allow.
`AllowedCollection.active`	Whether the collection is currently accepted.

A loan against an NFT whose verified collection isn't on the pool's allowlist will be rejected at create time. NFTs without a verified collection bypass this check (but are still subject to the global Merkle allowlist — the protocol-wide eligibility tree).

Fees

The fee parameters live primarily on the global Config, but pools inherit them and they affect borrower and LP economics directly.

Parameter	Meaning	Bounds
`Config.origination_fee_bps`	Origination fee as a percentage of interest.	Default 200 (2%); max 500 (5%)
`Config.auction_fee_bps`	Retained, no longer read. Was the protocol's share of auction surplus above debt.	Default 5,000 (50%); max 5,000 (50%)
`SALE_COMMISSION_BPS`	Commission on the gross proceeds of a defaulted card's sale. A protocol constant, not a pool or config setting.	500 (5%), fixed
`Config.insurance_fund_split_bps`	Of the protocol fee, what share routes to the insurance fund.	Default 3,000 (30%)

The pool itself accumulates protocol fees in protocol_fees_accumulated; a separate admin instruction (protocol_withdraw_fees) sweeps them to the protocol fee recipient and the insurance fund.

Governance

Parameters that control who can modify the pool.

Parameter	Meaning	Mutable?
`admin`	The wallet authorized to update parameters and (today) deposit liquidity.	No (set at init)
`paused`	Per-pool emergency pause flag. Halts new loans and deposits.	Yes (admin or governance)
`auto_approve_threshold_micro_usdc`	Backend hint for which loans don't need manual review.	Yes

Some constraints worth noting:

The pool admin is immutable. There is no admin-rotation instruction, by design — anyone evaluating the pool can verify the admin pubkey once and trust that it can't silently change.
The auto_approve_threshold_micro_usdc is a backend-only hint that doesn't gate any on-chain behavior. The on-chain program ignores it.

Updating parameters

Most mutable parameters are changed via pool_update_params, which requires the pool admin signature and validates each new value against the same protocol-wide bounds enforced at initialization. A few specific constraints:

max_exposure_per_type can be moved up or down but cannot be set to zero (initialization also requires non-zero). Zero would bypass the cap rather than tighten it; an admin who wants no cap has to recreate the pool.
LTV and the utilization cap are re-checked against their global ceilings on every update, not only at init.
Term options are not updatable. PoolUpdatableParams has no field for them, and term_options is written only by pool_init. A pool that wants different terms is a new pool.