If no one bids

Auctions don't always clear. A defaulted card may sit through its full auction window without a single bidder 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. Fast Dutch auctions on small or thinly-traded cards may legitimately expire without bids; the protocol is designed to handle this gracefully.

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.)

Like loan_mark_default_and_start_auction, this instruction is permissionless — anyone can submit it. The rent refunded by closing the auction and loan accounts goes to the caller, providing a small keeper incentive.

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 pool custody
Transfers the NFT from the borrower's collateral ATA (still held under the loan_authority delegate) into the pool authority's NFT account. The transfer uses the same standard-NFT vs programmable-NFT branching as settlement.
Records the held NFT
Creates a PoolHeldNft account that tracks which mint the pool now holds and which loan it came from. This is the on-chain record the pool admin uses to retrieve the card later.
Closes loan and auction accounts
Closes the loan account, the auction account, the bid escrow vault, 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 auction, no active loan, and no on-chain claim by the borrower on the card. The card is now the pool's responsibility.

What happens next

A PoolHeldNft is the protocol's "we own this card and need to dispose of it" record. The pool admin can then call a separate instruction (pool_admin_withdraw_nft) to claim the card from the pool's NFT account.

What the admin does next is off-chain and depends on the operating context:

Re-auction the card via a different process (e.g. a longer English auction with a lower reserve, or a third-party marketplace).
Re-list at a relisting price the operator believes is more attractive to bidders.
Hold the card on the pool's books while waiting for market conditions to improve, treating the on-chain NFT as an inventory item.

In every case, the underlying physical card remains where it has always been: in the issuer's vault (CollectorCrypt or Phygitals). Milky has never had physical custody at any point. The pool admin's options are therefore constrained only by the on-chain ownership of the NFT and by the issuer's redemption / resale policies.

Effect on the pool

An NFT that ends up in pool custody is not automatically a loss to LPs. Its value depends entirely on what the admin does with it:

If it's later sold for more than the original debt, the recovery flows back into the pool and lifts NAV (less the protocol's share of any surplus).
If it's sold for less, the pool absorbs the shortfall.
If it sits unsold indefinitely, NAV is calculated including the outstanding principal that was never recovered, so PPS reflects the unresolved exposure.

The honest framing is: a no-bid Dutch auction converts a clean "liquidation completed" outcome into a "we hold this card and need to dispose of it" outcome. The expected value is roughly the card's market price, but realization timing is uncertain.

How to monitor