If no one bids

Sales don't always clear. A defaulted card may sit through its full window without a single buyer accepting the price. When that happens, the protocol has a clean recovery path that keeps the card safe and reclaims rent without requiring any new on-chain governance.

This is a regular operational scenario, not an edge case. A descending sale on a small or thinly-traded card may legitimately expire without a buyer; the protocol is designed to handle it gracefully.

It should nonetheless be uncommon, and it is a real cost when it happens. Because the price falls all the way to the loan's principal, a card only reaches this path when even the principal is above what any buyer will pay — meaning the card has lost more than the loan-to-value buffer the pool underwrote against.

What triggers the no-bid path

The no-bid recovery instruction is auction_cancel_if_no_bids. It can be called once both of these conditions hold:

The current cluster time is strictly greater than the auction's end_ts.
The auction has never received any bids. (Even one bid that was later outbid moves the auction off this path; the regular settlement flow takes over.)

This instruction is permissionless — anyone can submit it — as is loan_mark_default_and_start_auction, which opened the auction in the first place. The rent refunded by closing the auction and loan accounts goes to the caller, providing a small keeper incentive, and it is more than the starter paid: this closes four accounts where starting allocated one and an escrow. So the same wallet can profitably do both ends.

Until it is called, the loan still exists — and so the borrower can still repay and take the card back. An expired sale with no buyer does not end the redemption right on its own; closing the loan does.

What the instruction does

In one atomic transaction:

Validates the no-bid condition
Checks that end_ts < current_ts and that the auction's total_bids counter is zero. If either fails, the instruction reverts (the auction can either still receive bids, or has bids and needs the settlement path instead).
Moves the card into protocol custody
Transfers the NFT out of the collateral vault (still held under the loan_authority delegate) to a protocol-controlled authority. The transfer uses the same standard-NFT vs programmable-NFT branching as settlement.
Records the held card
Creates an on-chain record of which mint the protocol now holds and which loan it came from, seeded on the mint alone. This is the record the disposal process works from.
Closes loan and auction accounts
Closes the loan account, the auction account, the ActiveLock, and the CertLock. The rents from these closures are refunded to the caller of auction_cancel_if_no_bids.

After the instruction completes, there is no pending sale, no active loan, and no on-chain claim by the borrower on the card.

What happens next

The held-card record is the protocol's note that it holds this card, and alongside it the cancel writes down the four figures a later sale needs: the loan, the borrower, the debt the card stood against, and the closed auction's address. Those are recorded because the same transaction closes the loan and the auction they were readable from.

There is a release handler per collateral standard — protocol_release_held_nft for cards held under Token Metadata and protocol_release_held_nft_core for those held under Metaplex Core — and both now do something. For a period neither did: each body was a single unimplemented!(), so both appeared in the IDL, an SDK could build a transaction against either, and neither transaction could succeed.

What a release does is sell the card off-platform — a dealer, a private buyer, a consignment — in one transaction that does all of the following at once, or none of it:

the sale proceeds are taken from MLKY in USDC,
the card is delivered to the buyer,
a 5% sale commission is taken (0% if MLKY itself is the buyer),
the pool is repaid up to what the loan owed,
anything left over is credited to the borrower, claimable the same way an auction surplus is.

Step 5 works exactly as the auction path's surplus does: the pool's claim is capped at the debt, the rest is the borrower's, and the credit is claimable for twelve months from the day it is written.

A release is a capability, not a schedule

Nothing obliges a sale to happen, and nothing sets a date by which one must. No clock starts when the card enters custody, no instruction expires, and a card can sit in protocol custody indefinitely. Until a sale happens there are no proceeds, so the borrower's equity in the card stays unrealised — there is no residual waiting to be collected, because nothing has been sold.

This is a deliberate decision rather than a gap someone forgot to close. An on-chain reclaim deadline and a published best-effort timeline were both considered and declined: a time-gated exit hands whoever can call it a free option, and any period short enough to be meaningful for a liquid card is wrong for the illiquid ones, which are the entire population that reaches this path. These cards are dealt with case by case, and ADR-004 D10 records the decision so that nobody later closes it by picking a number.

The card is held by a single protocol-wide custody authority, created once per cluster by protocol_authority_init. It is deliberately not the pool's authority: before ADR-004 a no-bid card went to the pool and the pool admin could withdraw it to their own wallet, and closing that path is the point of the change.

In every case, the underlying physical card remains where it has always been: in the issuer's vault (CollectorCrypt or Phygitals). MLKY has never had physical custody at any point.

Effect on the pool

Net asset value (NAV) takes the full hit immediately. When auction_cancel_if_no_bids runs, it subtracts the loan's principal and accrued interest from the pool's books before closing the loan account. It has to — leaving them in place would permanently inflate NAV and price per share (PPS) by a debt that will never be repaid.

NAV and PPS drop by the entire unpaid debt at the moment of cancellation, not gradually and not partially.
The lender does not get the card as compensation. A no-bid is a complete write-off of that loan from the pool's point of view.
A later release does pay the pool, and it arrives as a recovery rather than a repayment. Because the debt was written off at cancellation, the cash from a sale raises NAV by exactly what lands in the vault and touches no principal or interest counter — there is nothing left to un-write-off. Whoever holds shares on the day of the sale gets that lift, which is not necessarily whoever held them on the day of the default.
But nothing obliges a sale, and there is no date by which one must happen. So a lender cannot price a held card as a receivable. The write-off is real and immediate; a recovery is possible and unscheduled.

The honest framing is: a no-bid sale converts a partial recovery into a total write-off, with the possibility of an unscheduled recovery later. That is the worst outcome available to a lender, and avoiding it is most of the argument for lending conservatively against the card in the first place.

The borrower's side

At cancellation there is no residual, because there are no proceeds to distribute. The borrower loses the card and their debt is discharged; nothing is written to a BorrowerCredit, because there is nothing to write.

A residual only exists if and when the card is sold, and then it is written with that day's date — so the twelve-month claim window runs from the sale and not from the default. A long time in custody does not eat into it. What the borrower gets no help with is knowing the sale happened: no notice is sent at cancellation, none while the card sits, and none at the sale, because nothing currently subscribes to the release event. A borrower in this position who stops watching the chain has no prompt at any point, and after twelve months an unclaimed residual can be swept to the insurance fund.

This is therefore still the default outcome in which a borrower with real equity in the card can be left with nothing — the equity may be realised later, by MLKY rather than by a bidder, or it may not be realised at all. It is the reason the redemption right runs until the loan closes rather than until the sale window ends.

How to monitor

Pools that operate at scale should expect a small percentage of defaults to land in protocol custody rather than completing through settlement. Monitoring that proportion is part of standard operational health dashboarding: a pool seeing it often is lending too far up the loan-to-value curve for the cards it is accepting.