Yield, utilization & risks

Yield on MLKY is variable — there is no fixed annual percentage rate (APR) for LPs, only a realized return determined by the loans the pool has actually written and how those loans actually resolve. This page describes the levers behind the headline number.

What drives yield

Realized yield for an LP is the rate of change of price per share (PPS) over time, and PPS is driven by net asset value (NAV). The mechanical levers are:

Pool utilization. A pool with $0 outstanding earns no interest. A pool at 100% utilization is fully productive but has no headroom for new loans. The protocol caps utilization (typically 80%), which limits how much of the pool gets lent out.
Term composition. Shorter loans roll over more often and can capture rate changes faster; longer loans lock in a rate but stay productive through low-demand stretches.
Default rate. Loans that repay in full deliver their stated interest; loans that default deliver a recovery via auction, which can be more or less than the original payoff.
Shortfalls. A defaulted card that sells for less than the debt reduces PPS by the difference. This is the only direction defaults move your return: a default cannot pay the pool more than the loan was going to. Your claim is principal plus interest, and everything above it belongs to the borrower. Note also that the 5% sale commission comes off the gross before you are paid, so a sale must clear at roughly debt ÷ 0.95 — not at the debt — to leave you whole.
Origination fees. A small slice of every loan's interest is taken at draw time; today this revenue accrues to the pool/protocol pair and contributes to NAV growth.

Headline APR estimates shown in the app are forward-looking projections based on current pool composition and term options. They are not promised rates and should not be assumed to hold for any specific time window.

Utilization caps

Each pool has a utilization_cap_bps (default 80%, ceiling 95%). The protocol refuses to draw a new loan if doing so would push the post-draw utilization above the cap. This protects price per share from over-concentration in a single drawdown event, since shortfalls would otherwise eat through a thinner buffer.

When utilization is at the cap, new draws are rejected even if the pool has nominal available principal. The economic mechanism is intentional: high demand for a pool's liquidity translates into "no new draws" rather than into ever-deeper utilization.

The cap is a limit on lending, not on withdrawing. It is set by the pool's own admin, and no withdrawal path reads it — so it cannot be used to keep you from redeeming your shares, and a pool admin lowering it cannot affect your exit. What limits a withdrawal is the pool's actual free cash, which is a fact about the loan book rather than a setting: see Withdrawals for the four things that do bound one. This was not always true. Between the multi-lender release and 2026-08-25 the cap did gate withdrawals, and a pool admin who set it low could refuse an exit indefinitely; that is fixed, and the fix is in the same upgrade as the change that stopped a pool pause holding your capital.

How much a loan can be

Loan-to-value (LTV) is not one number. Every quote takes the lowest of three independent ceilings: the global protocol cap, your pool's max_ltv_bps, and — almost always the binding one — the LTV that the oracle's pricing confidence earns for that specific card.

Confidence is a function of how well-evidenced the card's price is: how tight Alt.xyz's confidence band is, and how large the graded population is at that grade. A heavily-traded blue chip clears a higher tier than a thinly-traded long-tail card.

Milky is currently running this live table:

Confidence tier	Min confidence	Min graded population	Max LTV
Blue chip	70	500	80%
Standard	50	100	60%
Long tail	30	50	40%

A card whose confidence or population falls below the long-tail row is refused outright — the protocol declines to quote rather than lend against a price it cannot evidence. Illiquid cards are already filtered by the demand/allowlist gates, which is why long-tail is 40% rather than 20%. Gate 0 can still raise the practical FMV floor — a $30 card can fail it even at 80% LTV — and at 80% Gate 0 is the much tighter floor.

For you as an LP this cuts both ways. A 60% LTV on a standard card means the card would have to lose roughly 40% of its value before the debt exceeds what it is worth. A borrower also gets more principal per card than they did under the old 20% long-tail grant.

Loss scenarios

These are the ways an LP can lose money on a MLKY pool:

Auction shortfall

A defaulted card sells for less than the debt (principal + fixed interest). The pool absorbs the difference, NAV drops, and PPS drops accordingly. Multiple shortfalls in quick succession can drag PPS materially.

This is most likely when:

The card's market price has fallen sharply since the loan was opened (recall the loan rate is fixed; the protocol does not reprice mid-loan).
The auction launches into a thin order book (fewer bidders means a lower clearing price).

A shortfall is the expected shape of a default, not an unlucky one. A borrower who can repay profitably will repay — and since August 2026 they can repay right up until the card sells, so that filter now applies during the sale as well as before it. The loans that reach a completed sale are disproportionately the ones where the card is worth less than the debt. Pricing that in is the point of the floor described below.

The sale floor — the setting that decides whether a default resolves

Every default sale has a floor: the lowest price it will accept. That floor is your full payoff — principal and interest — grossed up for the two charges a sale carries, and it is not a pool parameter you set.

The sale opens at the card's appraised value — the fair market value the oracle signed when the loan was written.
The price falls over 24 hours down to the floor, and never past your payoff.
Below the floor, no bid is accepted and the card moves into protocol custody instead. You take a complete write-off and you do not receive the card.

The gross-up is why the floor sits above your payoff rather than on it. A 5% buyer's premium comes off the winning bid first, then a 5% sale commission off what is left, so the floor is payoff ÷ 0.95 ÷ 0.95 — about 1.108 × the payoff. Both charges therefore come out of the buyer's price rather than out of your recovery.

In a descending sale a buyer takes the price the moment it reaches what the card is worth to them, so the floor does not set what you receive — it only sets how far the price may fall before the sale is called off. What the floor buys you is that a completed sale always repays you in full; what it costs you is that a card which has fallen below the floor finds no buyer at all, and you take the whole loss rather than part of it.

The asymmetry is worth stating plainly, because it is sharper than it used to be:

A sale that clears returns you principal and interest in full, with the commission and the premium paid by the buyer.
A sale that does not clear returns you nothing at all.

There is no middle outcome any more. Until August 2026 the floor was your principal, which meant a sale at the floor paid both charges off the top and handed back about 90% of your capital and none of your interest — a partial recovery. Raising the floor removed that band in both directions: no partial recoveries, and more cards that do not sell.

The single lever you actually control here is loan-to-value at origination. A card that has to fall below your principal before a sale fails is a different risk at 50% LTV than at 80%.

What the issuer can do to a locked card

Both scenarios above assume two things: that the card is still there to sell, and that the sale can run. On a loan against a Phygitals card, both are trust assumptions rather than things the protocol enforces.

Phygitals issues its cards into a Metaplex Core collection, and that collection holds three standing permissions over every card in it — to transfer it, to burn it, and to freeze it. None of them pause while a card is collateral. The lock MLKY places stops the borrower from selling and stops a buyer from taking it; it does not stop the issuer, because Metaplex weighs the issuer's permission ahead of the lock rather than behind it.

The three do not fail the same way, and the third would be the hardest to recognise if it happened to you:

Transferred. The card moves to somebody else and the loan has nothing behind it. There is no sale to run and no protocol action that brings it back, so your outcome is the same as a sale with no buyer: a complete write-off. Of the three, this is the one MLKY has tested against Metaplex's own program, and it behaves as described here.
Burned. The card is destroyed, and for you that is the same outcome as a transfer — the collateral is gone and there is nothing to sell. MLKY has not reproduced this one. It rests on the burn permission being built the same way as the transfer permission, which reading Metaplex's code says it is.
Frozen. The card stays exactly where it is and nothing is taken from you. What stops is the exit. Settling a sale means handing the card to its buyer, and a frozen card cannot be handed to anyone, so a default cannot be liquidated: the loan stays open, the principal stays outstanding, and there is no shortfall to measure because no sale ever completes. It ends when the issuer reverses it and not before. This is also the only one of the three that is not card-by-card — a freeze is set on the collection, so it would reach every Phygitals loan in your pool at the same moment. It is the least established of the three: it is what the permission exists to do, but MLKY has neither tested it nor seen it.

Neither LTV nor the sale floor helps against any of these. They set how far a card's price may fall before you are short, not whether the card is there or whether the sale can run. The per-card principal cap bounds a single transfer or burn to one loan's size; it does not bound a freeze, which is set once and reaches the whole collection.

Nothing suggests any of this has ever happened. Phygitals is a partner MLKY lists deliberately, and it is the same relationship that puts a physical card in a vault behind every token. It is written down because it is a real dependency you should be able to find before you deposit, not because there is reason to expect it. The decision to accept it and disclose it rather than stop taking the collateral is recorded in ADR-007, and trust assumptions places it beside the protocol's other trusted parties.

Smart-contract or oracle failure

If the on-chain program has a bug, or the oracle signs an incorrect price that leads to over-collateralized lending, NAV could be impacted. The protocol uses extensive on-chain validation to mitigate this, but it cannot be eliminated entirely. See risks for the full write-up.

Operational disruption

MLKY relies on off-chain components (the oracle, keeper bots that trigger auctions, the indexer feeding the front end). If those go down, borrowers may not be able to open new loans and keepers may not start auctions promptly. NAV is not directly affected, but the pool's earning capacity and timely default resolution are.

Regulatory or jurisdictional change

A change in the regulatory environment for tokenized real-world assets could affect the protocol's ability to operate certain pools or accept certain kinds of collateral. This is hard to quantify but is part of the honest picture for any LP.

Loss mitigations the protocol provides

Launch-tightened LTVs leave a wide buffer between the loan and the card's market price. See how much a loan can be below for the numbers.
Per-asset-type exposure caps prevent the pool from quietly concentrating in one card type.
Per-card principal caps cap the size of any single bad outcome.
Sale-driven recovery means defaults resolve at a market-clearing price rather than at a number somebody chose, and the floor means no completed sale returns you less than your whole payoff.
Pause functionality lets the protocol globally halt new loan creation in an emergency without freezing existing loans or LP withdrawals.

Practical guidance

If you're considering becoming an LP on MLKY:

Treat the displayed APR as an estimate and look at recent realized PPS changes to ground your expectations.
Understand which pool you're depositing into — different pools accept different collections and operate at different LTV ceilings and term mixes. Your pool's max_ltv_bps is a ceiling, not the LTV borrowers will get; the per-card confidence tier usually binds first.
Match your liquidity needs to the pool's term composition. A pool full of 90-day loans will have a slow withdrawal queue if utilization spikes.
Read risks end to end. There is no asterisk-free version of the failure modes.